Auditoría de inteligencia artificial.

Audito sistemas de inteligencia artificial desde 2017. Antes de que existiera una norma. Antes de que Europa hablara de AI Act. Antes de que NIST publicara su Risk Management Framework. Esa antigüedad importa: el criterio aplicado a IA hoy no se aprende leyendo la norma publicada en 2023; se construye habiendo auditado sistemas reales en producción cuando aún no había marco.

1. Auditar IA no es auditar software

Lo primero que cualquier auditor que llega a IA desde ISO 27001 tiene que entender: el marco mental que sirve para auditar software no sirve para auditar un sistema que aprende. El software se prueba contra requisitos; el sistema que aprende se prueba contra distribuciones. El software falla cuando hay un bug; el sistema que aprende falla cuando el dato de producción se aleja del dato de entrenamiento.

El control típico de seguridad de la información — control de acceso, cifrado, integridad — sigue siendo necesario en un sistema de IA. Pero es insuficiente. Sumar a ese marco la dimensión del comportamiento estadístico del modelo, de la deriva de datos, de la fragilidad ante ejemplos adversariales, de la opacidad de las decisiones, es lo que distingue una auditoría de IA de una auditoría de software con IA dentro.

El error más común en auditorías de IA hoy es auditar al sistema como si fuera software. La conformidad documental queda perfecta. El riesgo real queda sin detectar.

2. Lo que hay que medir además de la conformidad

La norma ISO/IEC 42001:2023 establece requisitos para sistemas de gestión de IA. Es necesaria. No es suficiente. En la práctica, lo que hace defendible una certificación 42001 son cinco dimensiones que la norma menciona pero que la mayoría de las auditorías documentan superficialmente.

Deriva del modelo en producción. Cuánto se aleja la distribución de los datos de entrada en producción de la distribución del entrenamiento. Sin medición continua de deriva, el sistema certificado en enero puede ser otro sistema en julio.

Trazabilidad de la decisión. Si el modelo niega un crédito, recomienda un tratamiento o filtra un currículum, qué prueba documental sostiene esa decisión específica. No la del modelo en general: la de la decisión individual.

Fragilidad ante ejemplos adversariales. Qué pasa cuando alguien empuja al modelo fuera del rango para el que fue entrenado. La fragilidad no es bug: es propiedad estadística del sistema.

Concentración de proveedor. De dónde vienen los modelos de fundación. Cuánto del comportamiento real del sistema depende de una decisión tomada por OpenAI, Anthropic, Google o Meta en su próxima versión. Si esa decisión cambia, el sistema certificado cambia — sin que la organización certificada haya hecho nada.

Capacidad de auditar lo que se decide. Para algunos modelos de gran escala, especialmente los basados en deep learning, no hay forma técnica de explicar a posteriori una decisión individual. La auditoría tiene que reconocer ese límite, no fingir que se resuelve con un "explainability layer" decorativo.

3. ISO 42001, AI Act, NIST AI RMF: qué se elige y por qué

Las organizaciones que tomamos decisiones serias sobre IA hoy se mueven entre tres marcos principales. Cada uno tiene su lógica.

ISO/IEC 42001:2023. Es la norma certificable internacional. Estructura del Anexo SL, integrable con ISO 9001, 27001, 14001. Auditable por terceros acreditados. Le falta especificidad técnica sobre métricas de modelo, pero gana en compatibilidad con la operación normal de un sistema de gestión.

AI Act europeo. Es regulación, no norma voluntaria. Su lógica es clasificar el sistema por nivel de riesgo y aplicar obligaciones graduadas. Lo que le falta de detalle técnico lo compensa con su carácter mandatorio en la UE y con la posibilidad de multas significativas. Para empresas que operan en Europa, no es opcional.

NIST AI Risk Management Framework. Es marco de referencia, no certificable. Más fuerte que ISO 42001 en la dimensión técnica (mide y discute deriva, fragilidad, sesgo con mucho más detalle). Estándar de facto en muchos sectores de Estados Unidos.

La elección real, en una empresa internacional, es combinada. La certificación se firma contra ISO 42001 por su estructura y por su reconocimiento. La gobernanza técnica interna se construye con NIST AI RMF por su rigor. La obligación legal se cumple contra AI Act porque no hay alternativa. Quien recomienda usar uno solo de los tres no entendió ninguno bien.

Sobre el detalle de cada uno y la elección real de las empresas, ampliamos en el ensayo ISO 42001 vs NIST AI RMF: qué eligen las empresas.

4. Las preguntas que un board debería hacer antes de firmar

Si vos sos miembro de board y mañana te ponen sobre la mesa una propuesta de gobernanza de IA, no tenés que entender la matemática del transformer. Tenés que poder hacer cinco preguntas que separen propuesta seria de propuesta cosmética.

Primera: ¿Cómo medís deriva del modelo en producción y con qué cadencia? Si no hay respuesta operativa, no hay gobernanza.

Segunda: ¿Qué pasa si nuestro proveedor del modelo de fundación cambia su versión sin avisar? Si la respuesta es "no debería pasar", no hay plan de continuidad.

Tercera: ¿Qué decisiones tomamos automatizadamente y qué probaríamos en tribunal sobre esas decisiones? Es la pregunta de trazabilidad individual.

Cuarta: ¿Quién audita esto y bajo qué cadena de acreditación? Porque hay auditores que firman 42001 sin haber auditado un modelo en su vida.

Quinta: ¿Qué decidimos NO automatizar todavía y por qué? Es la pregunta más importante. La frontera entre lo que la IA puede hacer y lo que la organización debe decidir conscientemente no hacer es la que define a una gobernanza seria.

Estas preguntas en detalle, y por qué importan, están en el ensayo Gobernanza de IA: preguntas que un board debería hacer.

5. Lo que enseña haber auditado IA antes de la norma

Entre 2017 y 2023 audité sistemas de IA sin marco vigente. La metodología que apliqué entonces, refinada con cada caso, es la que sigo aplicando hoy. La ventaja de haberlo hecho antes de la norma es que la norma no es el punto de partida: el sistema real lo es. La norma se aplica sobre el sistema, no al revés.

Lo aprendido en ese período se condensa en cinco principios que sigo usando:

1. El alcance es el documento que importa. Auditar IA "como sistema" es ambiguo. Hay que auditar el sistema específico, con el dataset específico, en la operación específica. Lo que se nombra en el alcance, se audita. Lo que no, queda fuera y debe declararse fuera.
2. La validación cruzada en el laboratorio no es validación en producción. Los KPIs que el equipo de data science reporta son condición necesaria, no suficiente. La auditoría requiere ver el comportamiento del modelo con datos de producción reales, no con muestras curadas.
3. La explicabilidad post-hoc decorativa no es explicabilidad. Una "explicación" generada después de la decisión, que no afecta el funcionamiento del modelo, no es prueba de gobernanza. Es post-marketing técnico.
4. El proveedor del modelo de fundación es parte del alcance. Aunque el contrato diga que es servicio externo, su comportamiento determina el del sistema certificado. Hay que auditar la cadena, no solo el eslabón propio.
5. Hay decisiones que un sistema no debería tomar todavía. No por incapacidad técnica: por incapacidad de auditar técnicamente lo que decide. Recomendar contra el uso de IA en cierto caso es output legítimo de una auditoría seria.

Estos cinco principios se aplican en cada auditoría que firmo desde el IAC.

6. Cómo se contrata una auditoría de IA

Auditorías formales bajo ISO/IEC 42001 con la cadena acreditada del IAC, programas de evaluación técnica de IA pre-norma o assessments con marco NIST AI RMF se contratan a través del International Accreditation Center. El IAC mantiene la cadena de acreditación, los equipos formados con práctica en terreno y la cobertura internacional en nueve países sobre diez normas ISO.

El sello propio IAC 42001 opera desde 2024 como marco técnico. Eso ya está en práctica para clientes que aceptan trabajar con el marco propio mientras la marco técnico avanza.