NIST AI RMF para equipos técnicos: el marco de riesgo de IA traducido a acciones de QA
GOVERN, MAP, MEASURE y MANAGE, traducidas a lo que significan para el equipo que construye y testea sistemas de IA. Con la advertencia de dónde el marco te exige más que tener QA.
El NIST AI Risk Management Framework (AI RMF 1.0) es el marco voluntario del gobierno de EE. UU. para gestionar riesgos de IA, publicado en enero de 2023 y organizado en cuatro funciones: GOVERN, MAP, MEASURE y MANAGE.[1] No es certificable ni auditable formalmente (nadie te puede “aprobar en NIST”), pero se convirtió en el vocabulario compartido de facto para gobernanza de IA en EE. UU., y cada vez más regulaciones y contratos lo citan como referencia.[2]
Para un equipo técnico, el problema del AI RMF no es su contenido sino su altitud: son unas 40 páginas de principios (más un Playbook de más de 140 con acciones sugeridas),[2:1] escritas para organizaciones enteras. Esta guía hace una sola cosa: traducir cada función a lo que significa para el equipo que construye y testea sistemas de IA, con la advertencia honesta de dónde el marco te exige más que “tener QA”.
Antes, dos aclaraciones de mapa que evitan confusiones frecuentes. Primera: a 2026, la versión vigente sigue siendo la 1.0; NIST extiende el marco mediante perfiles, no con números de versión nuevos.[2:2] Segunda: el perfil que le importa a cualquier equipo con LLMs es el Generative AI Profile (NIST AI 600-1, julio de 2024), que aplica las cuatro funciones a 12 categorías de riesgo propias o exacerbadas por la IA generativa, incluida la “confabulación” (el nombre que NIST le da a las alucinaciones), la inyección de prompts y la privacidad de datos.[3]
GOVERN: quién responde por la IA (la función transversal)
Qué pide el marco: políticas, roles y responsabilidad organizacional sobre el riesgo de IA. Es la única función que aplica a toda la organización y no sistema por sistema.[1:1]
Traducción para el equipo técnico: que exista un dueño con nombre y apellido de la calidad de cada sistema de IA, criterios de aprobación escritos antes del despliegue, y un proceso definido para incidentes. En la práctica, GOVERN es la respuesta a la pregunta “¿quién firmó que esto podía salir a producción, y con qué evidencia?”. Si la respuesta es “nadie, salió porque funcionaba en la demo”, GOVERN es tu brecha.
MAP: qué puede salir mal, en tu contexto
Qué pide el marco: contextualizar el riesgo de cada sistema: propósito, usuarios, impactos posibles, dependencias de terceros.[1:2]
Traducción: el inventario de tus sistemas de IA y, por cada uno, sus modos de falla concretos. Para un agente de atención en banca: inventar tasas, malinterpretar condiciones, no derivar un fraude. Para un tutor educativo: enseñar errores, ceder ante la insistencia del alumno. MAP es, en lenguaje de QA, el análisis de riesgo que precede al diseño de casos de prueba, y el Generative AI Profile funciona como checklist de partida: sus 12 categorías (confabulación, sesgo, privacidad, seguridad de la información, integridad de la cadena de valor, etc.) son una lista de “¿este riesgo aplica a mi sistema?” lista para usar.[3:1]
MEASURE: la función donde los planes mueren
Qué pide el marco: evaluar los riesgos mapeados con métricas cuantitativas y cualitativas, de forma continua.[1:3]
Traducción: testing y evaluación sistemática. Casos de prueba derivados de los riesgos de MAP, evaluadores que puntúan cada dimensión (precisión, alucinaciones, sesgo, escalamiento), umbrales definidos y resultados registrados. Aquí va la advertencia más útil de toda la literatura de implementación: el patrón de fracaso más común es completar GOVERN y MAP en papel y nunca operacionalizar MEASURE, y sin medición continua, MANAGE no tiene base de evidencia y el tratamiento del riesgo se vuelve adivinanza.[4] Dicho de otro modo: una organización puede tener el comité, las políticas y el inventario, y aun así no saber si su chatbot alucina, porque nunca lo midió. MEASURE es donde el marco deja de ser un documento y se convierte en una práctica, y es exactamente el terreno del QA de IA.
MANAGE: cerrar el ciclo
Qué pide el marco: tratar los riesgos según prioridad, monitorear después del despliegue, responder a incidentes y gestionar cambios.[1:4]
Traducción: lo que en esta casa llamamos el ciclo completo. Umbrales que bloquean releases, monitoreo continuo en producción, regresión ante cada cambio, y cada incidente convertido en caso de prueba permanente. MANAGE es MEASURE en régimen: la medición dejando de ser un evento pre-lanzamiento y volviéndose el sistema nervioso del sistema de IA.
El resumen operativo
| Función | La pregunta que responde | El artefacto de QA que la evidencia |
|---|---|---|
| GOVERN | ¿Quién responde y con qué reglas? | Criterios de aprobación escritos; dueño del sistema; proceso de incidentes |
| MAP | ¿Qué puede salir mal aquí? | Análisis de riesgo por sistema; checklist del GenAI Profile |
| MEASURE | ¿Cómo lo sabemos, con números? | Planes de prueba, evaluaciones multidimensionales, umbrales, resultados registrados |
| MANAGE | ¿Qué hacemos al respecto, siempre? | Gates de release, monitoreo continuo, regresión, incidentes convertidos en casos |
¿Y para qué alinearse con un marco voluntario? Tres motivos pragmáticos: es el lenguaje que hablan los reguladores y los clientes enterprise en EE. UU. (y se mapea bien contra el EU AI Act y contra ISO/IEC 42001, que sí es certificable);[2:3] estructura lo que un buen equipo de QA de IA ya hace, dándole nombre presentable ante una auditoría; y anticipa lo que los contratos ya empiezan a exigir. Es, en definitiva, el vocabulario con el que la IA responsable se vuelve gestionable: funciones, riesgos y evidencia en lugar de principios.
Ahí es donde una plataforma de evaluación hace la diferencia práctica: ArtificialQA opera el corazón de MEASURE y MANAGE, con casos derivados de tus riesgos, evaluadores calibrados por dimensión, umbrales que funcionan como criterios de aprobación, ejecuciones comparables en el tiempo y resultados auditables. El marco pide evidencia continua de que mides y gestionas el riesgo; el tablero de evaluación es esa evidencia.
Preguntas frecuentes
¿El NIST AI RMF es obligatorio? No: es voluntario y no certificable.[2:4] Pero es referencia creciente en regulaciones, contratos y evaluaciones de proveedores en EE. UU., y alinearse con él suele ser la vía práctica para responder cuestionarios de clientes enterprise.
¿Qué diferencia hay entre el AI RMF y la ISO/IEC 42001? El AI RMF es una guía voluntaria (nadie te certifica); la ISO/IEC 42001 es un estándar de sistema de gestión certificable por auditores. Comparten espíritu y se mapean bien: muchas organizaciones usan el RMF como marco de trabajo y la ISO como certificación.
¿Qué es el Generative AI Profile (AI 600-1)? El perfil que NIST publicó en julio de 2024 aplicando las cuatro funciones a la IA generativa: define 12 categorías de riesgo (confabulación, inyección de prompts, privacidad, sesgo, etc.) con acciones sugeridas mapeadas a GOVERN, MAP, MEASURE y MANAGE.[3:2] Si tu sistema usa LLMs, es el documento por el que conviene empezar.
¿Por dónde empieza un equipo chico? Por MEASURE de un solo sistema: elegir el agente de mayor riesgo, mapear sus modos de falla con el GenAI Profile como checklist, armar el plan de pruebas y medir. Con esa evidencia en la mano, GOVERN y MANAGE se construyen sobre algo real en lugar de sobre papel.
¿Cumplir el AI RMF me cubre ante el EU AI Act? No automáticamente: son instrumentos distintos, uno voluntario estadounidense y otro ley europea. Pero el trabajo se superpone mucho, sobre todo en la evidencia de testing y monitoreo, y hay crosswalks publicados entre ambos.[2:5] Consulta con tu equipo legal para tu caso.
Este artículo es informativo y no constituye asesoría legal. Verifica tus obligaciones concretas con tu equipo legal o de compliance.
CEO de QAlified e ingeniero en sistemas, con amplia experiencia en inteligencia artificial, calidad de software y transformación digital. Ha liderado proyectos de misión crítica en Latinoamérica y Estados Unidos, y es un referente de la comunidad de testing en la región.
