Marco de Gobernanza de IA: Cómo Construir Uno que Funcione

La IA llega a la mayoría de las organizaciones por varias puertas a la vez. Un asistente con licencia aquí, una función de IA activada dentro de una herramienta SaaS existente allá, y un puñado de herramientas para las que nadie abrió un ticket.

El marco de gobernanza que debería cubrirlo todo suele llegar más tarde, si es que llega. En The Netwrix 2026 Data and Identity Security Report, el 41 % de las organizaciones ya ejecutan IA agente en producción en nombre de los humanos, mientras que el 11 % ha operacionalizado la gobernanza de IA mediante revisiones continuas, proactivas y obligatorias.

La confianza refleja esa brecha, y no es nada alentadora. Solo el 18% de las organizaciones con ingresos entre 100 millones y 1.000 millones de dólares se sienten muy seguras de aprobar una auditoría independiente de la gobernanza y controles de IA, según Grant Thornton.

Mientras tanto, el 42 % de los líderes de TI del mercado medio encuestados en The Netrio’s Mid-Market AI Readiness Report reportaron un incidente o exposición de seguridad relacionado con IA confirmado en el último año. El marco que cierra esa distancia vincula cada regla escrita a un control que alguien puede probar y un registro que alguien puede consultar.

¿Qué es un marco de gobernanza de IA?

Un marco de gobernanza de IA es un conjunto estructurado de políticas, roles, procesos y controles que regulan cómo una organización diseña, implementa y utiliza sistemas de IA. Esto incluye asistentes con licencia, herramientas públicas a las que el personal accede mediante un navegador, funciones de IA integradas en aplicaciones SaaS y modelos internos.

ISO/IEC 42001 se refiere a un sistema de gestión de IA, que enfatiza la estructura operativa. Un marco de gestión de riesgos de IA se centra en identificar y tratar el riesgo.

Estos tres documentos a menudo se confunden, y la distinción determina quién es responsable. Un framework define la responsabilidad y el proceso a lo largo de las etapas del ciclo de vida. Una policy establece la regla, y una assessment evalúa qué tan bien funciona cada una en una fecha determinada.

Por qué es importante un marco de gobernanza de IA

El marco se gana su lugar al convertir decisiones dispersas en algo que un consejo, un regulador o un auditor pueden inspeccionar:

• Aprobación basada en evidencias: Seguridad puede aprobar un despliegue de IA con una lista nominativa de a qué accede cada herramienta y bajo qué identidades, en lugar de una garantía de quien la creó.
• Un registro de auditoría defendible: Evaluaciones de riesgos, informes de acceso, historial de configuración y actas de comité están todos en un solo lugar cuando alguien los solicita.
• Radio de explosión contenido: El alcance y los límites de acceso determinan cuántos datos puede alcanzar una sesión de IA comprometida o mal configurada.
• Aprobaciones más rápidas, no más lentas: Un proceso de entrada permanente y niveles de riesgo permiten que los casos de bajo riesgo pasen rápidamente y dirigen el resto a una revisión real.
• Un programa en lugar de dos: El riesgo de IA se integra en los registros, bibliotecas de control y puertas de revisión ya en funcionamiento, por lo que nada se mantiene dos veces.

Cada uno de ellos depende de lo mismo: saber qué puede lograr actualmente la IA en un entorno en vivo.

Por qué los programas de gobernanza existentes quedan rezagados frente a la IA

Tres fuerzas impactan al equipo de seguridad aproximadamente al mismo tiempo. Cada una amplía la distancia entre lo que la política afirma y lo que el entorno puede demostrar.

La IA llega más rápido de lo que se aprueba

El uso supera a la política, y las cifras no están cerca. La 2026 AI Pulse Poll de ISACA encontró que el 90 % de los profesionales de confianza digital creen que los empleados usan IA en su organización, mientras que solo el 38 % de esas organizaciones tienen una política formal y completa de IA.

La secuenciación explica la mayoría de la deficiencia. El informe de encuesta RSM AI encontró que aproximadamente un tercio de las organizaciones del mercado medio avanzan a pilotos o producción antes de que existan controles de gobernanza, y el 16 % solo alcanza la gobernanza después de que algo sale mal. Lo que se acumula es un montón de aprobaciones únicas y excepciones no documentadas. Funciona bien hasta que alguien pide evidencia.

Los plazos de cumplimiento han comenzado a pasar

Los estándares llegaron primero y establecieron la expectativa de estructura. ISO publicó ISO/IEC 42001 el 18 de diciembre de 2023 como un estándar internacional para sistemas de gestión de IA, y la mayoría de los equipos lo combinan con el NIST AI RMF como un complemento voluntario.

Luego, el cronograma de la UE cambió, y no en la dirección que la mayoría de los equipos había planeado. El Digital Omnibus on AI, adoptado como Reglamento (UE) 2026/1744 el 8 de julio de 2026, pospuso la mayoría de las obligaciones de alto riesgo hasta el 2 de diciembre de 2027 para sistemas independientes del Anexo III y hasta el 2 de agosto de 2028 para sistemas del Anexo I integrados en productos.

Dos fechas no cambiaron y ambas ya pasaron. Las obligaciones de transparencia del Artículo 50 y los poderes de ejecución de la Comisión sobre modelos de IA de propósito general se aplican desde el 2 de agosto de 2026, según el AI Act enforcement timeline. Los sistemas generativos ya en el mercado antes de esa fecha tienen hasta el 2 de diciembre de 2026 para cumplir con la obligación de marcado del Artículo 50(2), que es el próximo plazo real para la mayoría de los equipos.

La IA amplifica la deuda de permisos que ya tienes

Una herramienta de IA utiliza el acceso que ya existe. La propia guía de Microsoft sobre el exceso de compartición es clara al respecto: Copilot hereda los permisos y protecciones existentes de Microsoft 365, por lo que los sitios con permisos excesivos, el acceso heredado y las etiquetas de sensibilidad faltantes deben corregirse antes de la implementación.

Años de compartición ad hoc que nadie notó se vuelven buscables en el momento en que un prompt puede acceder a ellos. Arreglar primero esa capa es también donde aparece el beneficio, ya que las organizaciones con identidad unificada y gobernanza de datos tienen casi cinco veces más probabilidades de reportar plena preparación para IA.

Los seis pilares de un marco de gobernanza de IA funcional

La mayoría de los marcos publicados ocultan la visibilidad del acceso a los datos dentro de dominios más amplios como la privacidad o la gobernanza de datos. Tiene su propio pilar porque la certificación y la auditoría dependen de ello, y los procedimientos de auditoría de IA de ISACA solicitan específicamente registros de acceso, procesos de gestión de cambios y políticas basadas en roles.

1. Alcance e inventario

El alcance define a qué se aplican todos los demás controles. Nombra los sistemas de IA y los casos de uso involucrados, junto con los objetivos comerciales, la tolerancia al riesgo y las obligaciones regulatorias asociadas a cada uno.

La cláusula 4.3 de ISO/IEC 42001 exige que el alcance esté disponible como información documentada. Una declaración de alcance sin inventario de respaldo falla en la primera muestra.

2. Rutas de propiedad y aprobación

La responsabilidad recae en personas nombradas. Un patrocinador ejecutivo, un líder de gobernanza, seguridad, protección de datos y los propietarios de las unidades de negocio tienen cada uno un derecho específico de decisión.

El control A.3.2 de ISO/IEC 42001 lo establece claramente, exigiendo que "los roles y responsabilidades para AI se definan y asignen según las necesidades de la organización." La prueba práctica es si alguien puede decir quién aprueba un nuevo caso de uso y quién puede desactivarlo.

3. Política asignada a controles

La política cubre el uso aceptable, tipos de datos prohibidos, requisitos de intervención humana, expectativas de transparencia y manejo de incidentes. Una política funciona cuando cada línea nombra el control que la aplica.

Esos controles son restricciones de acceso, data classification, una de las soluciones DLP ya implementadas, acceso condicional y registro. Una regla sin control detrás es una sentencia, no una salvaguarda.

4. Visibilidad de datos e identidad

Este pilar responde a dos preguntas sobre cualquier interacción con IA. ¿A qué datos podría acceder la herramienta y qué identidad humana, máquina o no humana la invocó?

También es el pilar que la mayoría de los programas no pueden demostrar. El informe cuantifica por qué, encontrando que el 74 % de las organizaciones carecen de una vista única y unificada de los datos sensibles y las identidades que pueden acceder a ellos. El acceso concedido y el acceso efectivo son listas diferentes, y se separan rápidamente en cualquier entorno con historial.

5. Gestión del ciclo de vida

El ciclo de vida va desde los datos hasta el desarrollo del modelo, despliegue, revisión y retiro, con una puerta de decisión en cada transición. El retiro es la puerta que casi nadie alcanza y es la que preguntan los auditores.

La gestión del ciclo de vida de Identity ya maneja a los que se unen, cambian y salen para las personas, y los agentes de IA pertenecen a la misma disciplina. La subcategoría MANAGE 2.4 del NIST AI RMF exige mecanismos y responsabilidades asignadas para sustituir, desconectar o desactivar sistemas de IA que funcionen de manera inconsistente con el uso previsto.

6. Medición y mejora

La medición ofrece al comité de gobernanza elementos para decidir. Las métricas que merecen su lugar son el recuento de incidentes de IA, excepciones de políticas, cobertura de evaluación de riesgos y efectividad del control.

Las cláusulas 9 y 10 de ISO/IEC 42001 cubren el monitoreo, auditoría interna, revisión de la gestión y acción correctiva. Nada que no cambie una decisión vale la pena rastrear.

Cómo construir el marco en cinco pasos

Los pilares describen lo que contiene el marco terminado. Construirlo sigue un orden diferente, comenzando con la IA ya presente en el entorno en lugar de la política que alguien quiere redactar. Realice estos cinco pasos en secuencia.

1. Inventariar la IA que ya está en funcionamiento

Extraiga de tres fuentes, porque ningún sistema único lo sabe todo. Las aplicaciones con licencia y los service principals provienen de su identity provider, las funciones de IA integradas provienen de las notas de lanzamiento del proveedor y los centros de administración, y las herramientas no autorizadas provienen de los registros de salida.

Espere que la lista sancionada subestime considerablemente. Una encuesta de PagerDuty de 2026 encontró que el 66 % de los profesionales de oficina han usado IA en el trabajo a pesar de creer que sus políticas no lo permitían, y solo el 20 % de las organizaciones monitorean o regulan completamente la shadow AI.

Luego clasifique lo que encontró en niveles de riesgo. La productividad interna, los servicios orientados al cliente y el uso de datos regulados requieren diferentes niveles de escrutinio, y el nivel determina cuánto trabajo restante recibe un sistema.

2. Asigne propietarios y cree la ruta de aprobación

Asigne a cada sistema de IA un propietario nombrado en TI, seguridad, protección de datos o la línea de negocio que lo utiliza. Los equipos, comités y listas de distribución no cuentan.

Luego, mapea la ruta de la solicitud, desde la evaluación de riesgos hasta el diseño del control, la aprobación y la fecha de revisión. Anota quién concede excepciones y quién puede suspender un sistema cuando su riesgo cambia.

Mantenga la honestidad con la certificación de acceso recurrente access certification, que confirma que los administradores, cuentas de servicio, aplicaciones y agentes de IA solo mantienen lo que necesitan para su trabajo actual. Active Directory service accounts suelen ser donde se esconden los derechos obsoletos.

3. Asigne cada regla a un control que pueda probar

Tome la política línea por línea y escriba el control que la aplica junto a ella. Si no puede nombrar uno, la regla aún no es aplicable y debe incluirse en la lista de brechas.

Establezca las líneas rojas de forma clara y sin ambigüedades. No se permite el acceso de IA generativa a información personal identificable (PII) no clasificada, con exclusiones específicas para datos legales y de recursos humanos.

El acceso privilegiado debe gestionarse en sus propios términos. Los administradores que configuran servicios de IA necesitan elevación, por lo que se deben emitir credenciales just-in-time (JIT) de corta duración por sesión aprobada y aplicar zero standing privilege a las cuentas que integran esos servicios.

4. Incorpora la IA en los procesos que ya ejecutas

Agregue categorías de riesgo de IA a los registros de riesgo existentes, bibliotecas de control y rastreadores de problemas, luego dirija los casos de uso de IA a través de las puertas de recepción, gestión de cambios y revisión de seguridad ya establecidas. La guía de ISACA recomienda exactamente eso, con la gestión de riesgos de IA que complementa los programas establecidos de ciberseguridad, riesgo y privacidad.

Trate la IA de terceros e integrada de la misma manera, registrando el proveedor, los flujos de datos, el método de integración, los términos de retención, el propietario y el plan de salida. Cuando las revisiones de acceso requieran herramientas, compare las IGA tools con los sistemas ya incluidos en el alcance.

5. Establezca el ritmo y luego demuestre que funciona

Establezca la frecuencia de revisión antes de que se deba realizar la primera revisión e incorpore estas medidas en los ciclos existentes de IT risk assessment. Verifique qué herramientas de cumplimiento ya implementadas pueden generar informes antes de comprar algo nuevo.

Luego prueba el marco de trabajo como lo haría un auditor. Elige un sistema de IA, obtén su propietario, nivel de riesgo, conjunto de controles, informe de acceso y fecha de última revisión, y verifica cuánto puedes generar en una hora.

Alineando el marco con NIST AI RMF e ISO/IEC 42001

Un marco construido de esta manera termina escrito en tu propio vocabulario. Los auditores, clientes y reguladores no lo pedirán así. Preguntan con qué estándar te alineas, y el mapeo te permite responder sin reconstruir nada.

La cláusula 5 de ISO/IEC 42001 cubre la propiedad y la política de IA, las cláusulas 6 y 8 cubren la evaluación de riesgos e impactos, y las cláusulas 9 y 10 cubren la medición y mejora. Cuatro de los seis pilares mencionados se han renombrado.

Cuál de los dos mapeas primero no es cuestión de azar, y la razón se pierde porque ambos se nombran juntos. ISO/IEC 42001 es auditable y certificable. El NIST AI RMF no lo es. Esa diferencia determina lo que puedes reclamar y dónde debe estar tu evidencia.

Lo que el AI RMF puede y no puede hacer por un programa centrado en datos

El núcleo de AI RMF organiza la gestión de riesgos en Gobernar, Mapear, Medir y Gestionar, y sus subcategorías son declaraciones de resultados, no requisitos. NIST no publica esquemas de evaluación de conformidad, criterios de acreditación ni requisitos para organismos de certificación. Puedes decir que tu programa se alinea con AI RMF o que los controles se corresponden con sus subcategorías. No puedes decir "certificado NIST AI RMF."AI RMF Core organizes risk management across Govern, Map, Measure, and Manage, and its subcategories are outcome statements, not requirements. NIST publishes no conformity assessment schemes, accreditation criteria, or certification body requirements. You can say your program aligns with the AI RMF or that controls map to its subcategories. You can't say "NIST AI RMF certified."

Hay una segunda limitación que vale la pena conocer antes de mapear cualquier cosa. En las 72 subcategorías, ninguna menciona access control, identity, authentication, permissions o data provenance. Así que saber qué identities pueden acceder a qué datos, lo que realmente activa un paquete de evidencia, se relaciona con el AI RMF por interpretación y no por gancho textual.

Tres familias de subcategorías soportan ese peso en la práctica. El conjunto de terceros es el más fuerte, con GOVERN 6.1 que cubre políticas para el riesgo de IA de terceros, MANAGE 3.1 que requiere que "los riesgos y beneficios de IA de recursos de terceros se monitoreen regularmente", y MAP 4.2 que cubre controles internos de riesgo para componentes de terceros. MEASURE 2.7 y 2.10 son donde se registran las evidencias de evaluación de seguridad y privacidad. Para la desasignación, combine MANAGE 2.4 con GOVERN 1.7.

Por qué el crosswalk de NIST necesita traducirse antes de una auditoría

NIST publica un crosswalk desde las subcategorías de AI RMF a ISO/IEC 42001, y ahorra trabajo real. También tiene una característica que confunde a los equipos. Cada una de sus 202 referencias de control apunta al Anexo B, y no cita controles del Anexo A.

Esa distinción determina si su mapeo supera una auditoría. El Anexo A es normativo, sus controles dicen "shall" y la Declaración de Aplicabilidad se basa en él. El Anexo B es una guía de implementación; sus controles dicen "should" y establece claramente que las organizaciones no tienen que justificar la inclusión o exclusión de esa guía en la Declaración de Aplicabilidad. Una fila de correspondencia que envía MANAGE 2.4 a "B.9.4 Intended use of the AI system" apunta a un consejo, no a un control auditable.

La traducción es mecánica porque 42001 numera los dos anexos en paralelo, por lo que B.9.4 es la guía para A.9.4. Omitirlo es el error común. Otra cosa que hay que saber: el crosswalk apunta a ISO/IEC FDIS 42001, el borrador final, en lugar del estándar publicado.

La cláusula que la mayoría de los programas omiten

La evaluación de riesgos y la evaluación de impacto son obligaciones separadas en 42001, y confundirlas es la brecha más común en una Declaración de Aplicabilidad por primera vez. La cláusula 6.1.2 evalúa el riesgo para sus propios objetivos de IA, con probabilidad, niveles de riesgo y criterios de riesgo. La cláusula 6.1.4 evalúa el impacto externo en individuos, grupos de individuos y sociedades, sin utilizar ese mecanismo de probabilidad.

La relación es unidireccional. La cláusula 6.1.4 requiere que los resultados de la evaluación de impacto se consideren en la evaluación de riesgos, mientras que la nota 6.1.2 indica que una organización puede usar una evaluación de impacto para valorar las consecuencias. Cada una tiene su propia obligación de información documentada; el Anexo A.5 controla el lado del impacto, y la cláusula 8.4 exige realizar ambas a intervalos planificados o tras cambios significativos y conservar los resultados. ISO/IEC 42005 proporciona el método, aunque es una guía y no puede certificarse.

La visibilidad de datos e identidad se basa en los controles más que en las cláusulas. De los 38 Annex A controls en nueve categorías, A.7.5 Data provenance es el que un programa centrado en datos desea, ya que requiere un proceso documentado para registrar la procedencia de datos de IA.

Lo que realmente exige la certificación

La certificación se realiza en dos etapas según ISO/IEC 17021-1, con la competencia del organismo de certificación establecida por ISO/IEC 42006, publicada en julio de 2025. La etapa 2 es la que se planifica, ya que evalúa la implementación y efectividad in situ contra artefactos como evaluaciones de riesgo completadas y registros de eventos del sistema de IA.

La Etapa 1 es la que sorprende a las personas. Evalúa la preparación para la Etapa 2, incluyendo si las auditorías internas y la revisión de la gestión se han realizado realmente y no solo programado. Debe haber completado un ciclo completo de auditoría interna, lo que generalmente retrasa la fecha real de certificación un trimestre respecto a lo que los equipos suponen.

Lista de verificación del marco de gobernanza de IA

Seis preguntas revelan brechas que se convierten en hallazgos de auditoría. Responda cada una según el entorno que tiene, no el que está en la política:

• ¿El programa nombra propietarios responsables y establece ciclos de revisión con fechas reales?
• ¿Ha encontrado todos los sistemas de IA en uso y los ha relacionado con los datos e identidades a los que acceden?
• ¿Apuntan sus políticas de IA a controles técnicos específicos, que cubren restricciones de acceso, DLP, acceso condicional y registro?
• ¿El marco se alinea con NIST AI RMF, ISO/IEC 42001 o ambos, para que se pueda evaluar la cobertura?
• ¿Puede generar evaluaciones de riesgos, registros de configuración, informes de acceso y actas de comités bajo solicitud?
• ¿Tiene un plan para actualizar el marco a medida que cambian las herramientas, regulaciones y riesgos?

Cualquier cosa que no puedas responder es una brecha que necesita un responsable, un plan de remediación y una fecha de validación.

Cómo Netwrix cierra la brecha de evidencia en la gobernanza de IA

El cuarto pilar es donde la intención de gobernanza se encuentra con la realidad ambiental, y funciona con datos que las herramientas nativas mantienen en forma resumida o dispersan por portales. Netwrix proporciona esa capa a través de capacidades de AI governance, y vale la pena ser preciso sobre lo que hace cada producto.

Informando lo que la IA puede alcanzar

Netwrix 1Secure responde a la pregunta previa al despliegue mientras la decisión aún es reversible, informando sobre los datos sensibles a los que Copilot puede acceder antes de que alguien lo habilite. Después del lanzamiento, informa sobre la actividad de Copilot, listando usuarios, marcas de tiempo y recursos referenciados, y señalando respuestas que exponen datos sensibles. También rastrea roles, permisos y cambios en Microsoft Entra ID.

Netwrix Access Analyzer aborda la parte más difícil de la cuestión. Resuelve la pertenencia a grupos anidados para calcular el acceso efectivo para usuarios de Active Directory y Microsoft Entra ID, sitios de SharePoint y sistemas de archivos, mostrando accesos abiertos y herencias rotas. Eso convierte el pilar cuatro de una afirmación en un informe por identidad que puedes entregar.

Conservación de pruebas más allá de la ventana de registro

Los frameworks se auditan meses después de tomar decisiones, lo que convierte esto en un problema de retención antes que de informes. Netwrix Auditor registra quién cambió qué y cuándo con valores antes y después, y crea informes de estado en el tiempo a partir de instantáneas diarias de configuración.

Dos clientes regulados muestran la diferencia en el momento de la inspección. First National Bank and Trust of Beloit mantiene el cumplimiento continuo de OCC para 300 usuarios en 17 ubicaciones, reemplazando una semana completa de trabajo manual con listas de verificación por una hora de preparación.

Credissimo demuestra cumplimiento con GDPR e ISO/IEC 27001 en sus operaciones de financiación al consumidor, generando informes de auditoría un 85 % más rápido, en un día en lugar de una semana.

Netwrix cubre la capa de acceso a datos, identidad y generación de informes de auditoría que necesita el pilar cuatro y que las plataformas más amplias de gobernanza de IA asumen que ya tienes. Esas plataformas gestionan el flujo de trabajo general; el proveedor de IA mantiene el control del comportamiento del modelo; y el marco, el comité y las decisiones permanecen contigo.

Pruebe el framework primero en un sistema

El liderazgo confía en un marco cuando los datos actuales de acceso, configuración y actividad informan sus decisiones. Esto desaconseja lanzar todo el programa de una vez. Elija un sistema de alto impacto y luego mida la exposición de datos sensibles, el alcance de los permisos, el volumen de excepciones y la integridad del paquete de evidencias.

Un asistente con licencia que funciona en su tenant existente es el mejor prototipo, porque su modelo de permisos se basa en decisiones de acceso ya establecidas y las herramientas de visibilidad existen hoy. Ejecute los seis pilares en ese sistema, vea qué prueba la evidencia y aplique el patrón al resto del inventario de IA desde ahí.

Solicite una demostración para ver hasta dónde pueden llegar sus herramientas de IA, mapear las identidades detrás de ellas y conservar el historial de cambios que su próxima auditoría solicitará.