Cómo redactar una política de gobernanza de IA (+ qué incluir)

Solo el 11 % de las organizaciones están completamente preparadas en seguridad de IA, según The Netwrix 2026 Data and Identity Security Report.

La adopción de IA en la mayoría de las organizaciones ocurrió a través de elecciones individuales de herramientas antes de que las revisiones de seguridad se pusieran al día: los empleados conectaron Microsoft Copilot, ChatGPT y docenas de funciones de IA integradas a su trabajo diario antes de que alguien escribiera reglas de acceso que gobernaran lo que esas herramientas podían acceder.

Ese riesgo persiste porque el acceso de IA sigue un patrón de revisión diferente al de las solicitudes normales de usuario. Estas herramientas y las identidades de agente detrás de ellas pueden heredar permisos, consultar contenido sensible y crear nuevas preguntas de auditoría más rápido de lo que la revisión manual puede catalogarlas.

Los equipos de seguridad necesitan visibilidad sobre qué herramientas existen, a qué datos pueden acceder, quién las aprobó y cómo los equipos gestionan las excepciones. Una política escrita cierra esa brecha definiendo qué puede tocar la IA antes de que un incidente plantee la cuestión, fortaleciendo la ciberresiliencia y manteniendo la adopción de IA responsable.

¿Qué es una política de gobernanza de IA?

Una política de gobernanza de IA es el documento que define las reglas sobre cómo los empleados, contratistas y proveedores de una organización pueden usar herramientas de IA: qué datos pueden acceder esas herramientas, qué herramientas aprueba la organización y cómo los equipos escalan las violaciones.

Los equipos suelen usar "gobernanza de IA" y "política de IA" indistintamente, pero describen diferentes capas del mismo problema, y la distinción determina quién es responsable de qué.

Un marco de gobernanza de IA es el programa más amplio y continuo dentro del cual opera la política: los roles, ciclos de revisión y herramientas que mantienen la política actualizada. Marcos de referencia externos, como el NIST AI Risk Management Framework (AI RMF) y ISO/IEC 42001, proporcionan la estructura del marco, mientras que la política traduce esa estructura en reglas que su equipo puede seguir.

¿Cuáles son ejemplos de políticas de gobernanza de IA?

Los principios abstractos son fáciles de aceptar y difíciles de implementar. Las políticas de referencia de software empresarial, salud, servicios financieros y contratación de defensa muestran cómo cambian los requisitos según el tipo de datos y la regulación.

Políticas de acceso a datos para Enterprise Copilot y modelos de lenguaje grande (LLM)

Estos son los análogos más cercanos a lo que la mayoría de los equipos de seguridad de mercado medio necesitan redactar, aparte de cualquier regulación sectorial específica a seguir. Se centran en reglas de acceso a datos vinculadas a una categoría de herramienta específica ya en uso, como Microsoft 365 Copilot o ChatGPT, lo que mantiene la aplicación basada en flujos de trabajo reales. Estas políticas suelen combinar etiquetas de sensibilidad con un modelo operativo que separa la propiedad de la taxonomía de la aplicación técnica.

Políticas de gobernanza de IA en salud

Las organizaciones de salud construyen estas políticas en torno a la Ley de Portabilidad y Responsabilidad de Seguros de Salud (HIPAA), separando el uso clínico de IA (herramientas diagnósticas o para pacientes, sujetas a las normas más estrictas de acceso y auditoría) del uso administrativo de IA (programación, facturación, documentación interna), ya que ambos conllevan diferentes niveles de riesgo bajo la misma regulación. Una cláusula definitoria en una política modelo: las organizaciones pueden ingresar información de salud protegida (PHI) en una herramienta de IA solo cuando el proveedor haya firmado un Acuerdo de Asociado Comercial.

Políticas de gobernanza de IA para servicios financieros y contratistas de defensa

Estos se basan en los marcos específicos que los impulsan: los servicios financieros incluyen Service Organization Control 2 (SOC 2), el Reglamento General de Protección de Datos (GDPR) y la Digital Operational Resilience Act (DORA), mientras que la contratación de defensa incluye la Cybersecurity Maturity Model Certification (CMMC). Ambos vinculan los niveles de riesgo directamente a si una herramienta de IA accede a datos financieros de clientes o a información no clasificada controlada (CUI).

Las políticas de defensa van más allá: según la guía de la Information Security Oversight Office (ISOO), los contratistas no pueden ingresar CUI en herramientas de IA públicas o de consumo, y cualquier herramienta de IA que procese CUI debe aparecer en el Plan de Seguridad del Sistema del contratista.

Utilice estos ejemplos para fundamentar su propia política en las herramientas, tipos de datos y obligaciones de cumplimiento que su organización realmente tiene.

Por qué importa una política de gobernanza de IA

Una política escrita proporciona a la adopción de IA un modelo de gobernanza que los equipos de seguridad pueden medir, aplicar y mejorar. También convierte la aprobación de herramientas, el acceso a datos, la supervisión y la escalada en evidencia revisable.

La adopción de IA amplía la superficie de ataque más rápido de lo que la seguridad puede evaluarla

Cada nueva función de Copilot, ChatGPT o IA integrada necesita acceso a los datos organizacionales, y cada una crea una nueva vía de acceso que debe gestionarse. El Informe de Seguridad de Datos e Identidad Netwrix 2026 encontró que el 76 % no gobierna ni supervisa completamente las identidades no humanas en sus entornos, por lo que la mayoría de las adopciones de herramientas de IA ocurren sin visibilidad continua.

Los marcos regulatorios están pasando de una guía voluntaria a la aplicación obligatoria

Las obligaciones de evaluación de conformidad del EU AI Act para sistemas de alto riesgo se aplican generalmente desde el 2 de agosto de 2026, y los sistemas de alto riesgo cubiertos por la legislación de productos del Anexo I a partir del 2 de agosto de 2027. Una política documentada ayuda a demostrar que la organización siguió el requisito antes de que fuera obligatorio. Esperar a que una regulación sea vinculante antes de documentar nada no deja evidencia de un esfuerzo de buena fe.

Los auditores y los consejos ahora esperan una política documentada

Cuando la dirección pregunta, "¿Estamos seguros con AI?", una política escrita es la evidencia de que la respuesta es más que una opinión. Una garantía verbal se desmorona durante una auditoría o revisión de incidentes. La política traduce una postura de seguridad en algo que un auditor puede leer y a lo que un consejo puede señalar, lo que se alinea con la expectativa formalizada en ISO/IEC 42001.

El principio de menor privilegio se aplica a las herramientas de IA solo cuando una política define su acceso

Los equipos de seguridad han pasado años restringiendo el acceso humano por rol. Los equipos suelen eximir a las herramientas de IA de esa misma disciplina por defecto, tratándolas como extensiones del humano que las desplegó o como cuentas de servicio genéricas. Identity guidance desalienta ambos enfoques porque least privilege requiere acceso limitado y responsable. Una política designa a las herramientas de IA como su propia clase de cuenta, sujeta a límites reales de acceso.

Las organizaciones que no tienen uno ya lo están pagando

El Informe de Seguridad de Datos e Identity 2026 de Netwrix encontró que el 72 % de las organizaciones afirma que el riesgo relacionado con la identidad para datos sensibles ha aumentado en los últimos dos años debido a la IA y la automatización. La brecha de políticas ya se refleja en los datos de riesgo, y las organizaciones que lo reportan son las que adoptan la IA más rápido.

Qué incluir en una política de gobernanza de IA

Una política útil necesita cláusulas que seguridad, legal, TI y propietarios de datos puedan traducir en decisiones sobre aprobación y acceso. Cada cláusula debe conectar una declaración de política con el propietario, herramienta, categoría de datos o control que la haga aplicable.

• Alcance y aplicabilidad: Define a quién cubre la política y a qué se aplica, incluidos empleados, contratistas, proveedores y herramientas de shadow AI ya en uso. Sin un alcance explícito, la política solo regula las herramientas que la gente ya conoce, dejando el resto sin regulación.
• Roles de gobernanza y comité directivo: Nombres de quienes poseen la política y a quién escalar cuando algo queda fuera de ella. Sin un propietario nombrado, la "aplicación de la política" recae en quien detecte el problema primero.
• Clasificación de riesgos: Clasifica los casos de uso de IA en bajo, medio y alto riesgo según los datos o decisiones que afectan. Sin niveles, todos los casos de uso de IA reciben el mismo nivel de escrutinio, por lo que los de alto riesgo se revisan poco y los de bajo riesgo generan fricciones innecesarias.
• Reglas de acceso y uso de datos: Especifica qué datos puede y no puede acceder cada nivel de riesgo de la herramienta de IA. Es la cláusula que convierte una declaración de valores en un control aplicable. Sin ella, "uso responsable de IA" no tiene significado técnico.
• Proceso de revisión de herramientas y proveedores aprobados: Establece cómo los responsables de seguridad, legales y de datos evalúan y aprueban una nueva herramienta de IA antes de que alguien la conecte a los datos de la empresa. Sin esto, la adopción de la herramienta ocurre por quien la encontró primero, en lugar de mediante una revisión de seguridad.
• Requisitos de monitoreo y auditoría: Define cómo la organización verifica que los equipos sigan la política en la práctica. Una política que nadie verifica contra la realidad solo existe en el papel.
• Respuesta y escalada de incidentes: Establece qué ocurre cuando una herramienta de IA causa o revela un problema de seguridad o cumplimiento. Sin esto, los equipos manejan un incidente relacionado con IA de forma improvisada, con el procedimiento incorrecto o demasiado tarde.
• Alineación regulatoria: Asocia la política con los marcos aplicables, incluyendo NIST AI RMF, ISO/IEC 42001 y el EU AI Act. Esto permite que una sola política cumpla con múltiples obligaciones de cumplimiento en lugar de requerir un documento separado por regulación.
• Revisar y actualizar la frecuencia: Comprométase a revisar la política en un calendario establecido y tras eventos importantes, como nuevas categorías de herramientas, cambios regulatorios o incidentes. Las herramientas de IA cambian más rápido que la mayoría de los ciclos de revisión de políticas, por lo que una política sin frecuencia queda obsoleta en meses.

Cómo redactar una política de gobernanza de IA que equilibre la adopción con la responsabilidad

La dirección quiere que la adopción de IA sea rápida; la seguridad asume las consecuencias si se actúa sin cuidado. Redacte la política en el orden que los equipos de seguridad necesitan para obtener evidencia: primero los propietarios, luego las herramientas y los flujos de datos, después los niveles de riesgo, las reglas de acceso, el mapeo regulatorio y la cadencia de revisión. Las reglas de acceso escritas antes del inventario suelen pasar por alto las herramientas que ya generan exposición.

1. Reúne un equipo de gobernanza multifuncional antes de escribir una palabra

Comience nombrando los puestos reales: un líder de seguridad de la información o de Identity and Access Management (IAM) para encargarse de la aplicación, legal y cumplimiento de la normativa, un propietario de TI o de datos que conozca dónde se almacenan los datos sensibles, un representante de la unidad de negocio que use herramientas de IA a diario y un patrocinador ejecutivo que pueda aprobar excepciones.

Elija al presidente según el rol que ya tenga autoridad para vincular unidades de negocio fuera de seguridad, no solo dentro de ella. En organizaciones lideradas por seguridad, ese es el CISO. En organizaciones orientadas al riesgo, es un ejecutivo senior de riesgos, porque las unidades de negocio ya responden a ese rol en riesgos empresariales, y la gobernanza de IA necesita la misma autoridad o esas unidades lo tratarán como opcional.

Limítelo a una persona por rol, con un suplente solo cuando la carga de trabajo lo exija. Si seguridad redacta la política sola, se lee como un documento de seguridad y puede carecer de la autoridad para gobernar las unidades de negocio que generan el riesgo.

2. Inventaria las herramientas de IA y los flujos de datos que ya tienes, incluida la shadow AI

Cree el inventario a partir de cuatro fuentes a la vez: gasto en SaaS, registros de compras, extensión del navegador, auditorías de concesiones Open Authorization (OAuth) y una encuesta directa a las unidades de negocio.

Corrobore los cuatro, porque los empleados suelen omitir herramientas que asumen que son "solo un asistente de escritura" y los registros de compras no incluyen gastos individuales. Las suscripciones individuales pueden pasar desapercibidas bajo los umbrales de aprobación, y las revisiones de gastos pueden no detectar niveles de IA agrupados dentro de contratos SaaS existentes.

Para Microsoft 365, enumere las aplicaciones empresariales y los principales de servicio en Entra ID, y marque aquellos que tengan permisos delegados o de aplicación de Microsoft Graph, ya que cada concesión es una vía de acceso que las herramientas de IA pueden usar.

Las auditorías de concesión de consentimiento OAuth y los pasos de remediación de Microsoft para concesiones de consentimiento ilícitas ayudan a detectar y limpiar autorizaciones riesgosas. Registra el propósito de cada herramienta, el propietario del negocio y los datos que toca en un inventario de sistemas de IA mientras avanzas.

3. Clasifique los casos de uso de IA por nivel de riesgo

Clasifique cada caso de uso según dos criterios juntos:

1. Qué datos toca la herramienta (públicos, internos, regulados o información de identificación personal (PII)).
2. Qué hace con esos datos (los resume y muestra, informa una decisión empresarial o toma una acción autónoma).

Una herramienta que solo reescribe textos públicos de marketing tiene bajo riesgo sin importar lo sofisticada que sea. Una herramienta que extrae registros de clientes para responder tickets de soporte tiene alto riesgo incluso si su salida parece rutinaria.

Una herramienta autónoma que ejecuta transacciones o modifica la producción se sitúa en el nivel superior y requiere aprobación humana obligatoria. Si opera en la UE, superponga estos niveles internos sobre las categorías del EU AI Act para que ambos esquemas permanezcan visibles.

4. Defina qué datos puede y no puede acceder cada nivel de riesgo

Escriba cada regla de acceso como una asignación directa del nivel de riesgo a la categoría de datos. Las herramientas de bajo riesgo tienen acceso a contenido no sensible y ya público. Las herramientas de riesgo medio están limitadas para acceder a conjuntos de datos específicos ya clasificados. Las herramientas de alto riesgo requieren aprobación escrita explícita, registro de acceso y un revisor humano nombrado antes del despliegue.

Para datos regulados, nombre la condición explícitamente: PHI requiere un Acuerdo de Asociado Comercial firmado, y CUI no puede ingresarse en ninguna herramienta fuera de un entorno acreditado.

5. Defina la escalada y la respuesta a incidentes antes de publicar

Indique qué sucede cuando una herramienta de IA causa o revela un problema de seguridad o cumplimiento: quién es notificado, con qué rapidez y qué proceso de respuesta a incidentes existente lo atiende. Vincule la ruta de escalación con los roles de gobernanza nombrados en el paso 1, para que el problema tenga un responsable asignado en lugar de depender de quien lo detecte primero.

Sin este paso por escrito, los equipos terminan manejando un incidente relacionado con IA de forma improvisada, con el procedimiento incorrecto o demasiado tarde, justo la brecha que una política debería cerrar antes de que un incidente plantee la cuestión.

6. Asigne su política a los marcos regulatorios que correspondan

Una matriz de control puede servir para todos los marcos que utilices. Alinea las cuatro funciones de AI RMF (Govern, Map, Measure, and Manage) con las cláusulas del sistema de gestión ISO/IEC 42001 y los niveles de riesgo del AI Act, y luego redacta el lenguaje de la política una sola vez para esa matriz combinada.

Los dos estándares se complementan: el NIST AI RMF proporciona las acciones de gestión de riesgos operativos, e ISO/IEC 42001 ofrece la arquitectura de gobernanza y la pista de auditoría. Usar el mismo lenguaje de control en estos marcos reduce la documentación duplicada en todas las obligaciones que tienes.

7. Establezca una cadencia de revisión antes de publicar

Comprométase a un intervalo específico, al menos anual, además de desencadenantes nombrados que obliguen a una revisión fuera de ciclo: adopción de una nueva categoría de herramienta de IA, un cambio regulatorio, un incidente o una adquisición o reorganización, incluidos cambios importantes en los procesos empresariales y los requisitos de datos relacionados.

Ajuste la cadencia según el riesgo, con equipos revisando sistemas de mayor riesgo con más frecuencia y el comité de gobernanza reuniéndose en un calendario recurrente sin excepción. Escriba la cadencia, los desencadenantes y el responsable en el propio documento. Un calendario de revisión que solo vive en la mente de alguien caduca en cuanto esa persona cambia de rol.

Cómo aplicar una política de gobernanza de IA en la práctica

Las cláusulas de la política necesitan controles técnicos que seguridad pueda verificar. “La política dice no” solo importa cuando la visibilidad, la revisión de accesos, las alertas y la revocación hacen que esa respuesta sea verdadera.

Obtenga visibilidad completa de lo que sus herramientas de IA pueden acceder realmente

La aplicación comienza con un mapa en vivo de las conexiones de herramientas de IA a datos: concesiones OAuth, Microsoft 365 y Microsoft Entra ID permisos, extensiones de navegador y cualquier función de IA integrada dentro de las plataformas SaaS existentes.

Cierre la puerta principal al mismo tiempo: desactive el consentimiento del usuario para aplicaciones no verificadas y dirija las nuevas solicitudes a través del flujo de trabajo de consentimiento administrativo, para que las nuevas integraciones de IA entren por defecto en el proceso de revisión.

Los equipos de seguridad suelen poder responder "quién tiene acceso a qué" para cuentas humanas; este paso construye la respuesta equivalente para herramientas y agentes de IA, incluyendo permisos efectivos que resultan de grupos anidados y accesos heredados.

Las herramientas nativas de Microsoft ayudan aquí, aunque Purview DSPM for AI ejecuta su evaluación automática de riesgos solo en los 100 principales sitios de SharePoint, por lo que una vista más amplia de la data security posture ayuda a validar la imagen nativa e identificar brechas.

Para Copilot específicamente, combine etiquetas de sensibilidad con restricciones de acceso al sitio SharePoint y Restricted Content Discovery para que el exceso de compartición nunca alcance los datos base de los que Copilot se alimenta.

Aplica el principio de menor privilegio para la IA de la misma manera que lo haces para las personas

Trate las identidades de herramientas de IA y identidades de agentes como su propia clase de cuenta, sujetas a la misma revisión de acceso y flujo de trabajo de atestación ya utilizado para cuentas humanas. Requiera acceso limitado y con expiración en lugar de permisos amplios y permanentes, y ejecute el proceso de incorporación, traslado y salida que también regula la desvinculación humana frente a la desactivación de herramientas de IA.

Zero Standing Privilege modela esta disciplina usando cuentas efímeras con alcance de tarea, ephemeral accounts en lugar de credenciales elevadas persistentes.

Escuelas del Este del Condado de Carver aplicaron exactamente esta disciplina: en lugar de dejar cuentas de administrador alrededor de los datos de los estudiantes, el distrito limitó el acceso privilegiado solo cuando fue necesario usando Netwrix Privilege Secure, y la implementación tomó días en lugar de un proyecto de un trimestre.

Ancle cada identidad de agente a un human sponsor para que cada cuenta tenga un propietario responsable cuando el propietario humano se vaya. La guía actual de identidad recomienda cadencias de revisión más cortas para agentes que para personas, al menos trimestralmente y mensualmente para agentes con privilegios altos, porque el acceso de agentes cambia más rápido que las certificaciones anuales.

Supervise la exposición de datos impulsada por IA de forma continua

La supervisión debe ser continua, porque una revisión de acceso puntual queda obsoleta en cuanto aparece una nueva herramienta o integración de IA. Rastrea qué datos consultan y recuperan realmente las herramientas de IA, más allá de los permisos registrados, y señala patrones de volumen o sensibilidad que estén fuera del uso aprobado.

En Microsoft 365, las interacciones de Copilot se registran en el registro unificado de auditoría, por lo que confirme que la retención de auditoría coincide con el período de evidencia que la política establece antes de que un auditor solicite los registros del año pasado. Esto proporciona a los equipos de seguridad evidencia de que las reglas de acceso de la política se alinean con el comportamiento real de la IA.

Netwrix AI Governance, entregado a través de Netwrix 1Secure™, añade seguimiento y generación de informes de la interacción con Copilot que los equipos de seguridad pueden conservar como evidencia de auditoría.

Automatice alertas y escaladas cuando una herramienta de IA cruce su límite de acceso

La detección solo tiene valor si activa la ruta de escalamiento que la política ya define. Dirija automáticamente los hallazgos al incident response process nombrado en la sección de gobernanza de la política y registre cada alerta como evidencia de auditoría. La ruta de escalamiento debe conectarse a un proceso de revocación funcional con propiedad y tiempos claros.

Convierte tu política de gobernanza de IA en un control aplicable

Una política escrita reduce el riesgo cuando cada cláusula se corresponde con un control técnico: visibilidad de lo que las herramientas de IA pueden acceder, mínimo privilegio para identidades de IA y monitoreo continuo.

Muchos riesgos relacionados con la IA siguen la misma ruta de acceso que los incidentes de identidad: los atacantes usan credenciales legítimas para acceder a los datos, y una herramienta de IA con acceso permanente excesivo se convierte en otra identidad con permisos excesivos en el entorno.

La seguridad de los datos y la seguridad de la identidad son el mismo problema visto desde dos ángulos, y la política reduce el riesgo solo cuando ambos se aplican juntos.

Solicita una demostración para ver cómo 1Secure mapea el acceso a herramientas de IA, rastrea las interacciones de Copilot y convierte las reglas de acceso de tu política en evidencia de auditoría.