En diciembre de 2023, la Organización Internacional de Normalización publicó la ISO/IEC 42001, la primera norma internacional dedicada específicamente a la gestión de sistemas de inteligencia artificial dentro de una empresa. No dice qué debe responder una IA. Dice cómo una organización debe administrar su uso: con un dueño definido, evaluación de riesgo, evidencia guardada y un ciclo de revisión que no termina el día del lanzamiento.
En poco más de un año, la norma dejó de ser papel y se volvió práctica de mercado. Según un reportaje de BrightDefense, más de 100 organizaciones ya obtuvieron la certificación a nivel global, entre ellas AWS, Google, Microsoft, Anthropic, Snowflake, ServiceNow y la consultora BCG, varias certificando directamente los propios servicios de IA que venden a otras empresas.
El motivo para que quien decide preste atención no es el sello en sí. Es lo que la investigación muestra detrás de él: la mayoría de las empresas ya tiene alguna política de IA escrita, y la mayoría no tiene un sistema que sostenga esa política en el día a día.
Cuando la política se queda solo en papel
Una encuesta de AuditBoard con Panterra Research, publicada en 2025 con más de 400 profesionales de auditoría y cumplimiento en Estados Unidos, Canadá, Alemania y Reino Unido, midió esa distancia directamente. El 86% de las organizaciones dijo conocer las normas que afectan el uso de IA, desde la ley europea hasta el Marco de Gestión de Riesgo de IA del gobierno estadounidense, publicado por el NIST en enero de 2023. Pero solo el 25% reportó tener un programa de gobernanza de IA totalmente implementado.
La causa más citada no fue falta de herramienta — menos del 15% señaló eso como el problema principal. Fue falta de dueño: el 44% citó la ausencia de responsabilidad clara como la mayor barrera, seguida de falta de conocimiento interno (39%) y falta de recursos (34%). El informe resume el hallazgo en una frase: la gobernanza es una capacidad que se opera todos los días, no una casilla que se marca en una auditoría.
Ese es exactamente el vacío que la ISO/IEC 42001 intenta llenar. La norma sigue la misma estructura de ciclo continuo usada por las normas de calidad y de seguridad de la información — planificar, ejecutar, verificar, actuar — y exige que la empresa documente el alcance del sistema, defina roles y responsabilidades, y evalúe el riesgo contra un criterio declarado, no contra la impresión de que todo está bien. Una norma complementaria, la ISO/IEC 23894, detalla cómo ese riesgo debe identificarse, evaluarse y tratarse a lo largo de todo el ciclo de vida de un sistema de IA, desde el diseño hasta el uso diario.
Una política sin dueño no sobrevive al primer cambio de equipo. Una política sin evidencia no sobrevive a la primera auditoría. Una política sin ciclo de revisión queda desactualizada el mismo mes en que llega una herramienta nueva de IA a la empresa.
Por qué escribir una política no basta
La norma de ISO exige lo opuesto a una intención declarada: registro fechado de cada decisión, criterio de riesgo por escrito y mejora continua demostrable. Por eso también la certificación, por sí sola, no es un atajo legal. Según un análisis de ISMS.online sobre la ley europea de IA, la ISO/IEC 42001 seguía fuera del círculo de normas oficialmente reconocidas por la Unión Europea: una norma solo otorga presunción legal de conformidad después de publicarse con ese estatus específico, y la 42001 todavía no tenía ese sello. Contar con la certificación demuestra madurez de gestión; no reemplaza, por sí sola, la documentación técnica que la ley exige para los sistemas de alto riesgo.
Para quienes venden tecnología de IA a otras empresas, el efecto práctico ya apareció antes de que la ley se acomodara. El mismo reportaje de BrightDefense describe la norma convirtiéndose en exigencia contractual: clientes corporativos, sobre todo en sectores regulados como salud y servicios financieros, empezaron a pedir prueba independiente de que el proveedor administra el riesgo de IA — no solo la promesa de que lo hace.
Para las empresas latinoamericanas que aún no han pensado en certificarse, el mensaje no es correr detrás del sello. Es que el mercado ya está definiendo, en la práctica, qué cuenta como gobernanza seria: dueño definido, acceso controlado, decisión registrada y revisión recurrente. Eso vale antes, durante y después de cualquier certificación formal — y vale también para quien nunca va a certificarse, pero necesita demostrarlo a un cliente, un socio o un auditor.
Lo que tiene que existir en la práctica
Un sistema de gestión de IA — con certificación o sin ella — se sostiene en mecanismos verificables, no en texto de política.
Identidad corporativa, no cuenta personal. El acceso a la IA viene del mismo directorio de usuarios de la empresa, el mismo inicio de sesión usado para entrar a la red — no de una cuenta personal creada por cuenta propia. Cuando alguien sale de la empresa, el acceso cae con esa persona, sin depender de que alguien recuerde revocarlo.
Acceso conforme al rol de cada persona. Cada persona y cada agente de IA ven solo lo que su rol autoriza, incluso dentro de una herramienta conectada con decenas de funciones diferentes.
Aprobación humana conforme al riesgo. Las acciones y documentos considerados sensibles pasan por revisión antes de convertirse en información oficial que la IA usa como referencia, con quien escribe separado de quien aprueba.
Registro de auditoría por área. Cada decisión relevante — crear un agente, aprobar un documento, cambiar un permiso — queda registrada y consultable después. Es justamente el "criterio declarado" y el "registro fechado" que la norma exige.
Conocimiento aprobado con fuentes. Lo que la IA usa como referencia proviene de documentos con dueño y versión vigente, no de cualquier archivo suelto que alguien encontró con prisa.
Reutilización con permiso definido. Lo que funciona para una persona puede ponerse a disposición de otras, con alcance definido por persona, grupo o rol — sin convertirse en acceso libre para todos.
Así fue diseñada la plataforma Skyller: identidad proveniente del directorio de la empresa, aprobación humana conforme al riesgo y registro de auditoría por defecto, no como configuración extra que alguien tiene que recordar activar.
La ganancia de tratar la gobernanza como sistema
La ganancia más directa aparece en el momento de la auditoría. Cuando cada decisión queda registrada por defecto, reconstruir lo que ocurrió — quién aprobó un documento, quién cambió un permiso, qué agente ejecutó qué acción — es cuestión de minutos, no de semanas reuniendo capturas de pantalla y planillas manuales. Es la diferencia entre pasar una auditoría y temerle a una.
Hay una ganancia menos obvia, pero igual de relevante: una vez que el mecanismo de aprobación y registro ya existe por diseño, no necesita reconstruirse cada vez que cambia la legislación o un cliente pide una prueba nueva. Skyller, por ejemplo, ya llega con más de 170 modelos de políticas y procesos listos, así que el equipo adapta un flujo de aprobación existente en lugar de diseñar cada uno desde cero.
El efecto colateral es cultural. Cuando el sistema separa naturalmente a quien crea conocimiento de quien lo aprueba, y registra la diferencia, la resistencia inicial de "un control más" tiende a convertirse en "esto me protege". El mismo registro que sirve para un regulador o un auditor externo también sirve, internamente, para explicar por qué un agente de IA hizo lo que hizo — sin depender de la memoria de quien estaba en la sala ese día.
La gobernanza es una capacidad central de la empresa, no un paso de cumplimiento para marcar como hecho.
Una hoja de ruta para empezar
Antes de escribir una política de IA más, vale la pena diseñar cómo se va a convertir en sistema. Una hoja de ruta posible:
- Nombre un único dueño para la gobernanza de IA. Mientras la responsabilidad esté repartida entre TI, legal y cada área por su cuenta, nadie va a exigir el ciclo de revisión — y fue exactamente ahí donde el 44% de las empresas de la encuesta de AuditBoard se estancó.
- Haga un inventario de lo que ya está en uso. Antes de escribir una regla nueva, liste los asistentes de IA, autorizados o no, que el equipo ya usa hoy en el trabajo.
- Defina el acceso por rol, no por persona. Decida qué puede hacer cada función con IA antes de decidir qué va a pedir cada persona individualmente más adelante.
- Elija qué exige aprobación en dos etapas. No todo documento necesita revisión doble — pero los que se vuelven referencia para las respuestas de la IA deberían tenerla.
- Asegúrese de que toda decisión relevante quede registrada. Si hoy reconstruir "quién aprobó qué" exige preguntarle a las personas, el sistema todavía no existe — solo la intención de él.
