ISO/IEC 42001 y NIST SP 800-218A: la estructura que tu gobierno de IA probablemente no tiene

Cuando una organización decide que necesita gobernar su uso de inteligencia artificial, la secuencia habitual es previsible. Se forma un comité, se redacta una política interna, se define qué herramientas están permitidas y qué datos no se pueden compartir, y se comunica.

El documento resultante suele ser razonable y suele tener el mismo problema: es una lista de restricciones sin estructura de gestión detrás. No define roles, no define ciclo de vida, no define cómo se evalúa el riesgo de un caso nuevo, no define qué evidencia se conserva ni quién revisa qué.

Existen marcos formales que sí proveen esa estructura. Vale la pena conocerlos antes de improvisar, aunque no se busque certificación.

ISO/IEC 42001: sistema de gestión de IA

ISO/IEC 42001 proporciona una estructura de sistema de gestión para organizaciones que desarrollan, proveen o usan inteligencia artificial.

La expresión “sistema de gestión” es la clave. Es la misma familia estructural que las normas de calidad o de seguridad de la información: no dicta qué tecnología usar, sino que establece cómo la organización se organiza para gestionar algo de forma sistemática y demostrable.

Eso implica, entre otras cosas: definir el contexto y el alcance, asignar roles y responsabilidades, establecer políticas, evaluar y tratar riesgos, definir controles operativos, medir el desempeño, auditar internamente y mejorar de forma continua.

Lo útil de esta estructura, incluso para una organización que no busca certificarse, es que impone preguntas que la política improvisada omite. Quién es responsable de cada sistema de IA. Cómo se evalúa el impacto antes de desplegar. Qué se documenta y por cuánto tiempo. Cómo se detecta que algo cambió. Qué pasa cuando un sistema deja de comportarse como se esperaba.

NIST SP 800-218A: desarrollo seguro con IA generativa

El segundo marco ataca un problema distinto y complementario. NIST SP 800-218A extiende el marco de desarrollo seguro de software con prácticas específicas para inteligencia artificial generativa y modelos fundacionales.

La distinción importa. El desarrollo seguro tradicional asume artefactos deterministas: se sabe qué hace el código, se puede revisar y se puede probar exhaustivamente. Un sistema con modelos generativos introduce elementos que no encajan en ese modelo: datos de entrenamiento cuya procedencia hay que verificar, modelos cuyo comportamiento no se deduce de su especificación, prompts que son código funcional pero no se tratan como tal, y salidas que no se pueden validar por comparación exacta.

Las prácticas que agrega apuntan justamente ahí: procedencia de datos y modelos, protección de la cadena de suministro de componentes de IA, evaluación de comportamientos no deseados, y gestión de los riesgos específicos que introduce la generación.

Cómo usarlos sin lanzar un programa de certificación

La objeción evidente es que adoptar dos marcos formales es un proyecto grande que una organización mediana no va a emprender. Es cierto. Y no es necesario.

Hay una forma intermedia que rinde: usar los marcos como listas de verificación de completitud sobre lo que ya se tiene.

Toma la política de IA que tu organización ya escribió y contrástala con las preguntas que estos marcos obligan a responder:

• ¿Existe un inventario de los sistemas y modelos de IA en uso, con dueño identificado?
• ¿Los casos de uso están clasificados según su nivel de riesgo?
• ¿Hay una evaluación de impacto antes de desplegar algo nuevo?
• ¿Hay responsables nombrados para modelos, datos, prompts y agentes?
• ¿Se conserva la procedencia de los artefactos: de dónde salió cada modelo, cada conjunto de datos, cada instrucción?
• ¿Existe control de versiones sobre todo lo anterior?
• ¿Hay modelado de amenazas específico para estos sistemas?
• ¿Hay monitoreo en operación y un procedimiento de respuesta a incidentes?
• ¿Hay revisiones posteriores a incidentes sin búsqueda de culpables?
• ¿Existen criterios explícitos de suspensión y reversión?

Diez preguntas. La mayoría de las políticas internas responde tres o cuatro. Las que faltan son, casi siempre, exactamente las que un auditor o un cliente corporativo va a preguntar primero.

El componente que más se omite

De esa lista, el que más consistentemente falta es el inventario.

Suena elemental y no lo es. Para hacer un inventario honesto hay que saber qué sistemas de IA están en uso, incluidos los que ningún comité aprobó: la extensión que alguien instaló, el asistente que un área contrató con su propio presupuesto, el agente que un equipo levantó para un piloto y quedó corriendo.

Ese inventario es la base de todo lo demás. No se puede clasificar el riesgo de lo que no se sabe que existe, ni asignar responsables, ni evaluar impacto, ni suspender nada.

Y tiene una propiedad valiosa: se puede construir sin ningún marco formal, en unas semanas, preguntando. El resultado casi siempre sorprende por su tamaño.

Cómo clasificar casos de uso sin un comité permanente

De las diez preguntas, la de clasificación de riesgo es la que más se traba, porque suena a que requiere criterio experto para cada caso. Se puede resolver con un esquema simple que la mayoría de las organizaciones puede aplicar sin ayuda externa.

Tres preguntas determinan el nivel de exigencia.

¿La salida afecta a una persona identificable? Decisiones o recomendaciones sobre crédito, contratación, evaluación de desempeño, acceso a un servicio, precio individual, atención de un reclamo. Si la respuesta es sí, el caso requiere el tratamiento más exigente, sin discusión.

¿La salida se usa sin revisión humana efectiva? No si formalmente hay un revisor, sino si ese revisor tiene tiempo, información y autoridad para cambiar el resultado. Un caso sin revisión efectiva sube un nivel respecto de donde estaría con ella.

¿El error se detecta rápido y se corrige barato? Un error que se descubre en minutos y se revierte con un clic tiene un perfil de riesgo distinto de uno que se descubre en la auditoría anual.

Con esas tres preguntas, la mayoría de los casos se clasifica en minutos y sin ambigüedad. Un asistente que ayuda a redactar comunicaciones internas: no afecta a persona identificable, hay revisión, el error es barato. Nivel bajo. Un sistema que prioriza solicitudes de crédito: afecta a personas, la revisión suele ser nominal, el error es caro y tardío. Nivel alto.

Lo que cambia según el nivel no es si se permite, sino qué se exige: profundidad de la evaluación previa, granularidad de la trazabilidad, frecuencia de revisión, y si hace falta una evaluación de impacto formal antes de desplegar.

Esta clasificación tiene una virtud organizacional adicional. Convierte el gobierno de IA en un proceso proporcional en vez de en un obstáculo uniforme. Cuando todo caso de uso requiere el mismo trámite, los casos de bajo riesgo se hacen por fuera del proceso —porque el trámite no se justifica— y el gobierno pierde visibilidad justamente sobre el volumen.

Un proceso ligero para lo ligero es lo que permite ser exigente donde efectivamente importa.

Por qué conviene hacerlo ahora

Hay una razón de calendario. Para organizaciones con exposición europea, la aplicación general del Reglamento de Inteligencia Artificial llega el 2 de agosto de 2026, con excepciones y períodos de transición específicos.

Pero la razón más fuerte no es regulatoria: es comercial. Los clientes corporativos ya están incluyendo preguntas sobre gobierno de IA en sus procesos de contratación. Y esas preguntas se parecen mucho a las diez de arriba.

Una organización que puede responderlas con evidencia tiene una ventaja concreta en cada negociación. Una que no puede, tiene una conversación incómoda cada vez.