Auditoría de Gobernanza de IA para Equipos de Seguridad y TI

La dirección aprueba Microsoft 365 Copilot, y dos días después el departamento legal quiere saber qué archivos sensibles puede leer. En la encuesta detrás del Netwrix 2026 Data and Identity Security Report, el 71 % de los líderes de seguridad y TI dijeron que no pueden determinar inmediatamente qué identidades tienen acceso a un dato sensible específico.

El asistente en sí rara vez es el problema. La documentación de Microsoft indica que Copilot muestra datos organizacionales a los que los usuarios individuales tienen al menos permisos de visualización, por lo que cada membresía de grupo obsoleta y sitio compartido en exceso se convierte en un posible resultado de la solicitud. La brecha de control está en la capa de permisos subyacente, donde años de compartición ad hoc se acumulan sin revisión.

Probar la identidad de capa uno y un archivo a la vez es lo que produce una respuesta que nadie tiene que aceptar por confianza.

¿Qué es la auditoría de gobernanza de IA?

La auditoría de gobernanza de IA examina si los controles que regulan el acceso de la IA a datos, identidades y flujos de trabajo funcionan según lo diseñado. La evidencia incluye registros, resultados de pruebas, informes de permisos y revisiones fechadas.La guía de auditoría de PwC plantea la tarea como probar el diseño y la efectividad de los controles relacionados con IA. Eso significa documentar cómo está diseñado cada control, cómo funciona y cómo la dirección lo prueba.

Una auditoría de gobernanza termina con la efectividad del control. Las pruebas de rendimiento del modelo son una disciplina separada que abarca sesgo, deriva, precisión y explicabilidad.

El alcance abarca gobernanza y políticas, riesgos técnicos y de modelo, y controles de acceso a datos e identidad. El IIA's AI Auditing Framework asigna ese trabajo por responsabilidad, mapeándolo al Modelo de Tres Líneas para que los órganos de gobernanza, la dirección y la auditoría interna tengan cada uno una parte definida. La identidad está explícitamente dentro del alcance, y el ISACA AAIA outline requiere que los auditores evalúen el programa específico de gestión de identidad y acceso de IA de una organización.

Por qué la auditoría de gobernanza de IA importa más que el documento de políticas

Una política expresa una intención. Una auditoría produce los artefactos que muestran que esa intención sobrevivió al contacto con un inquilino activo. Esa brecha separa un programa de gobernanza de una diapositiva de gobernanza, y se refleja en cuatro formas específicas.

Aprobando la adopción de IA basada en evidencia

Los equipos de seguridad deben aprobar implementaciones de IA en un plazo establecido por otros. Una auditoría completa les permite aprobar con una lista nombrada de qué herramientas de IA acceden a qué datos bajo qué identidades. La aprobación se basa en un límite que alguien realmente probó, no solo describió.

Convertir la política en un registro de medición

La expectativa del NIST AI RMF para la medición continua se encuentra en MEASURE 2.4. Indica que la funcionalidad y el comportamiento del sistema de IA y sus componentes, identificados en la función MAP, deben "ser monitoreados cuando están en producción." Una auditoría convierte una política escrita en un registro que cumple con esa expectativa, construido a partir de registros, informes de permisos, resultados de pruebas firmados y revisiones con fechas y nombres adjuntos.

Detectar la exposición antes de que se convierta en un incidente

Los sitios compartidos en exceso y los permisos obsoletos aparecen según el calendario de otra persona, generalmente durante una investigación. El Netwrix 2026 Data and Identity Security Report encontró que el 75 % de las exposiciones de datos sensibles comienzan con identidades comprometidas o permisos mal configurados. Eso convierte a la capa de permisos en el lugar más rentable para buscar.

Una auditoría programada convierte esas condiciones en hallazgos con tickets y responsables asignados, meses antes de una revisión de brechas.

Una auditoría programada convierte esas condiciones en hallazgos con tickets y responsables asignados meses antes de una revisión de brechas.

Dar a la dirección un número que se mueva

Los consejos financian el trabajo que pueden rastrear, y una auditoría completada proporciona un recuento de brechas abiertas, junto con responsables y fechas objetivo. Los equipos obtienen ese recuento de pruebas de control fallidas y hallazgos no resueltos, por lo que el progreso se lee como una línea de tendencia, similar a la conformidad con parches o las tasas de fallos de phishing.

Cómo auditar los controles de gobernanza de IA

Una auditoría defendible responde cinco preguntas, en orden. Cubre qué sistemas de IA están en uso, qué datos sensibles puede acceder cada uno, bajo qué identidades operan, qué controles se aplican y qué evidencia demuestra que esos controles funcionan. Siga los seis pasos a continuación en secuencia y finalice cada uno con el artefacto nombrado al final.

1. Construya y verifique el inventario de activos de IA y acceso a datos

Extraiga el inventario de tres fuentes, porque ningún sistema conoce todo. Tome aplicaciones de IA con licencia y service principals de Microsoft Entra ID. Añada funciones de IA integradas de las notas de la versión y el centro de administración de cada proveedor SaaS, además de herramientas no autorizadas de los registros de salida o su CASB. Para cada entrada, registre el propietario, el propósito comercial, el entorno y los repositorios que la herramienta puede leer.

Luego concilie las tres listas y trate cada diferencia como un hallazgo. Asigne a cada herramienta no registrada un propietario nombrado y una fecha de decisión, decida si conservarla o bloquearla, y registre el resultado. El uso no autorizado rara vez aparece en los registros de compras, por eso shadow AI security debe incluirse en la primera revisión junto con las herramientas autorizadas.

Aplica el mismo escrutinio a las herramientas que ya aprobaste, ya que la aprobación y la seguridad son cuestiones separadas. Si Copilot es seguro en un inquilino determinado depende de lo que sus identidades licenciadas puedan acceder, y este inventario responde a eso.

Considere el paso completo cuando cada herramienta de IA en el entorno aparezca en una lista única, con un propietario y un mapeo de fuente de datos. NIST AI RMF GOVERN 1.6 requiere mecanismos para inventariar sistemas de IA y asignarles recursos según las prioridades de riesgo organizacional. Esta lista cumple con ese requisito. El artefacto es un inventario validado con una lista adjunta de hallazgos.

2. Pruebe cada política de IA contra el rol que la aplica

Lea cada política de uso de IA en función de cuatro preguntas antes de revisar cualquier control. Establezca qué uso es aceptable, qué tipos de datos están prohibidos, dónde se requiere la intervención humana y cuánto tiempo se conserva la salida. Anote la respuesta a cada una y marque cualquier pregunta que la política deje abierta.

Luego, crea un mapa de dos columnas que coloque cada declaración de política junto al rol nombrado responsable de hacerla cumplir. Nombra a la persona, ya que un nombre de equipo no le da al auditor a nadie con quien entrevistar sobre quién aprueba un nuevo caso de uso de IA y quién revisa los resultados en flujos de trabajo de alto riesgo. Cualquier declaración sin un nombre adjunto es el hallazgo.

Extienda la gobernanza que ya aplica en lugar de escribir un conjunto paralelo de reglas de IA. Una IAM risk assessment ya documenta las rutas de aprobación, y un programa establecido de identity governance and administration ya define la propiedad de roles. Confirme que se extienden al uso de IA y registre dónde terminan.

GOVERN 2.1 requiere que los roles, responsabilidades y líneas de comunicación para mapear, medir y gestionar el riesgo de IA estén documentados y sean claros para las personas y equipos en toda la organización. El artefacto es ese mapa de política a rol, con las declaraciones sin propietario listadas como brechas.

3. Mapear el acceso efectivo para cada fuente de datos accesible por IA

Ejecute este paso en cuatro fases, avanzando desde la licencia hasta el archivo. Primero, liste los usuarios y grupos que tienen licencias de Copilot. Segundo, resuelva cada grupo a su membresía real, incluidos los grupos anidados. Tercero, liste los sitios de SharePoint, Teams y buzones que contienen datos sensibles y a los que la membresía resuelta puede acceder.

La cuarta pasada cubre las identidades que la gente olvida, comenzando con los invitados. Las cuentas de invitados amplían el mapa más rápido que cualquier otra cosa, así que audita Teams guest access contra los mismos sitios sensibles. Luego repite todo el ejercicio para identidades no humanas, ya que Active Directory service accounts y los registros de aplicaciones a menudo tienen un acceso más amplio que cualquier persona en la nómina.

Comience el mapeo con el informe nativo, luego verifique lo que omitió. El informe "Site permissions for users" de Microsoft enumera los sitios de SharePoint o OneDrive a los que un usuario especificado puede acceder, directamente o a través de grupos, y es la vista nativa por identidad más cercana.

Antes de considerar que ese resultado está completo, verifique tres límites en su propio entorno. El informe depende del organization-wide permissions report, que muestra solo los 100 sitios principales por número de usuarios permitidos y excluye sitios archivados y sitios en estado de bloqueo NoAccess. Los datos pueden retrasarse hasta 48 horas, y cada inquilino está limitado a cinco informes actualizados cada 30 días.

Cubre el resto con herramientas que resuelven el anidamiento en toda la infraestructura en una sola pasada. Ese es el trabajo de una capacidad de data access governance, y la categoría más amplia de herramientas de data access governance que existen para cerrar exactamente esta brecha. El resultado es un conjunto de hallazgos de acceso por identidad con calificaciones de riesgo.

4. Demostrar que el registro puede reconstruir una interacción con IA

Prueba el rastro seleccionando una interacción reciente de Copilot e intentando reconstruirla solo a partir de los registros. Recupera el inicio de sesión, el evento de aviso, los archivos modificados y cualquier cambio administrativo en la configuración de IA, luego verifica si file access monitoring cubre los repositorios involucrados. Todo lo que no puedas recuperar se incluirá directamente en la lista de hallazgos como una brecha de cobertura.

Sepa qué tipo de registro contiene qué antes de concluir que falta algo. Los registros de auditoría CopilotInteraction de Purview CopilotInteraction audit records capturan metadatos de interacción y referencias a los archivos que Copilot usó para responder una solicitud. Sin embargo, los cuerpos de la solicitud y la respuesta residen en el buzón del usuario y requieren eDiscovery para recopilar.

Next, measure your retention window against the investigation window you'd actually need. Under Microsoft's audit retention policies, Audit (Standard) retains records for 180 days, and Audit (Premium) extends that period to 1 year for Microsoft Entra ID, Exchange, OneDrive, and SharePoint activity generated by users with E5 or equivalent licensing. Anything longer than a year requires the 10-Year Audit Log Retention add-on in addition to E5.

Cierra el paso comprobando si los registros realmente se conectan entre sistemas. Confirma que el equipo puede vincular un evento de IA a una identidad y luego a un registro de acceso a archivos sin correlación manual, y señala cualquier brecha en las herramientas donde la cadena se rompe. El artefacto es una evaluación de cobertura y retención de registros que indica la ventana por carga de trabajo.

5. Realice pruebas de control desde una identidad permitida y una no permitida

Define la prueba antes de ejecutarla, porque un resultado esperado escrito después no tiene valor. Elige un archivo con una etiqueta de sensibilidad conocida, una identidad que debería acceder a él y otra que debería ser rechazada, luego anota el resultado que esperas de cada una.

Emita la misma solicitud de recuperación desde ambas identidades y compare las dos respuestas. La identidad permitida debe devolver el contenido, y la identidad restringida debe rechazar o devolver un resultado vacío. Revise el registro de auditoría de ambos intentos, porque un fallo silencioso que no deja registro es un hallazgo en sí mismo.

Aplica a DLP el mismo tratamiento superficie por superficie en el mismo archivo de prueba. Ejecuta las políticas en modo de simulación antes de aplicarlas, y utiliza las mejores prácticas de políticas DLP que se adapten al inquilino. Repite cada caso en chat, en Word y en resumen de correo electrónico, porque una política que funciona en uno puede comportarse diferente en otro.

Registre el alcance, el resultado esperado, el resultado real y la corrección para cada caso, luego firme los documentos de trabajo y adjunte las capturas de pantalla y las exportaciones de registros. El artefacto es un registro de prueba firmado en el que cada caso fallido tiene un responsable y una fecha de nueva prueba.

6. Redacte el informe para que los hallazgos se conviertan en remediación

Estructura el informe como cualquier otro IT risk assessment entregable, cubriendo alcance, metodología, hallazgos, calificaciones de riesgo y remediación. Ordena los hallazgos por importancia, para que el lector vea primero la brecha más grave.

Para cada observación, incluya los cinco elementos que un revisor busca antes de firmar. La herramienta de redacción de informes del IIA recomienda una calificación de criticidad y una declaración de hechos que cubre condición, criterios, causa y efecto, además de un plan de acción de gestión que nombra la acción acordada, el personal responsable y una fecha límite.

Establezca la próxima fecha de auditoría antes de distribuir el informe, mientras el alcance aún está fresco. Prográmela en un intervalo planificado y agregue disparadores de cambio para nuevas funciones de IA, cambios de permisos, revisiones de políticas y cambios en el registro. El artefacto es ese informe, con una fecha de reexamen ya en el calendario.

Cómo verificar los controles de acceso de Microsoft 365 Copilot

Microsoft Copilot obtiene su propia aprobación porque sus barreras de protección están en superficies administrativas nombradas a las que un método genérico no puede apuntar, y porque uno de esos controles está siendo retirado. La guía de implementación de Microsoft secuencia un despliegue en descubrir, clasificar, auditar, asegurar, monitorear y gobernar, con cada verbo correspondiente a una prueba con un resultado registrado.

1. Lea primero la evaluación de riesgo de datos de Purview

Abra Microsoft Purview Data Security Posture Management (DSPM), vaya a Discover y luego a Data risk assessments, y lea la evaluación predeterminada antes de ejecutar algo personalizado. Se ejecuta semanalmente contra los 100 sitios de SharePoint más usados, y los primeros resultados tardan aproximadamente 4 días en aparecer en un nuevo tenant.

Trate el resultado como una lista corta que aún necesita ampliarse, ya que las clasificaciones de uso y sensibilidad apuntan en direcciones diferentes. Lleve todo lo que señale la evaluación al mapeo por identidad del paso 3 y mantenga los sitios sin clasificar dentro del alcance.

2. Extraiga los informes de gobernanza de acceso a datos de SharePoint

Genere los informes de Data Access Governance y revise los enlaces compartidos riesgosos, el estado de permisos y la exposición de Everyone Except External Users (EEEU). Cada concesión EEEU en un sitio con datos regulados es un hallazgo, y los enlaces compartidos anónimos son los más rápidos de revocar.

Verifique su nivel de licencia antes de confiar en la cobertura que ofrecen esos informes. Solo E5 proporciona informes de actividad, limitados a 10,000 sitios con 28 días de datos. Los informes instantáneos y las acciones de remediación requieren SharePoint Advanced Management, que incluye una licencia Copilot, el complemento Plan 1 o Microsoft 365 E7.

3. Reemplace la búsqueda restringida de SharePoint con un control compatible

Verifique si el inquilino aún depende de Restricted SharePoint Search (RSS) para frenar a Copilot, y registre un hallazgo de migración donde sea que lo haga. Microsoft anunció la retirada a través del centro de mensajes de Microsoft 365, bloqueando la activación de RSS a partir del 31 de julio de 2026 y retirando completamente la función el 31 de enero de 2027.

Planifique el reemplazo mientras aún haya tiempo, ya que las configuraciones existentes de RSS no se migrarán automáticamente a Restricted Content Discovery. Haga un inventario de los sitios actualmente protegidos por RSS y asigne cada uno a una corrección de permisos o a una entrada de Restricted Content Discovery.

4. Pruebe las etiquetas y DLP en cada superficie de Copilot

Verifique etiquetas de sensibilidad primero en los archivos de prueba, luego verifique la configuración de Purview DLP en Microsoft 365 Copilot y Copilot Chat. Ejecute el mismo caso en Copilot Chat, en Word y en el resumen de correo electrónico, y registre cada superficie por separado.

Compare el resultado con lo que realmente realiza la acción de la política. La acción DLP impide que Copilot procese contenido sensible, pero deja intacto el acceso del usuario al archivo, por lo que un usuario que aún abre el documento ha pasado la prueba. Para cada caso, registre la identidad, el archivo, el resultado esperado, el resultado real, la etiqueta o regla DLP aplicable y la marca de tiempo.

5. Exporte la evidencia y programe la nueva verificación

Exporte los registros de auditoría de Purview de la actividad de Copilot para la ventana de prueba y configure la retención del registro de auditoría para que coincida con el período de investigación que el equipo realmente necesitaría. Programe Microsoft Entra access reviews para las membresías de grupo que controlan el acceso a Teams y al sitio, luego asigne un responsable a cada prueba fallida y reserve la fecha para la nueva prueba.

Evalúe la verificación de Copilot según un estándar concreto único en lugar de una lista de configuraciones revisadas. El equipo la aprueba cuando puede nombrar un archivo, demostrar que Copilot no lo resumirá bajo una identidad restringida, explicar qué permiso, etiqueta o regla DLP lo detuvo y mostrar el registro de Purview que prueba que la prueba se realizó.

Lista de verificación de evidencia y preparación para una auditoría de gobernanza de IA

Una auditoría de acceso a datos de IA se basa en artefactos que un auditor puede inspeccionar. Cuatro categorías tienen la mayor importancia:

• Evidencia de inventario: La lista de sistemas y herramientas de IA con propietarios y entornos, además de la documentación de las fuentes de datos a las que cada sistema puede acceder
• Evidencia de políticas y controles: Políticas de uso con registros de cambios, definiciones de roles y una matriz responsable, accountable, consulted e informed (RACI) para la gobernanza de IA, y una evaluación de riesgos por caso de uso de IA
• Evidencia de Identity, acceso y monitoreo: Informes de acceso por identidad, registros de actividad de IA y registros de eventos de control como activaciones de DLP, decisiones de Conditional Access y resultados de revisiones de acceso
• Evidencia de revisión y supervisión: Minutas o tickets que documentan decisiones de gobernanza de IA, un registro de auditoría de la remediación tras evaluaciones previas y métricas que rastrean el desempeño de la gobernanza a lo largo del tiempo

Falle en cualquiera de los cuatro, y ese es el hueco que un auditor encuentra primero. Las preguntas de preparación a continuación prueban lo mismo desde otra perspectiva, y cada una sin respuesta es una brecha que necesita un responsable, un plan de remediación y una fecha para volver a evaluar.

Cómo Netwrix cierra la brecha de auditoría en la gobernanza de IA

Cuatro de los pasos anteriores se ejecutan con datos que las herramientas nativas conservan brevemente o dispersan en varios portales, abarcando permisos efectivos, registros de actividad de IA, aplicación a nivel de indicaciones e historial de cambios.

Netwrix agrupa esos bajo AI governance como una capacidad de plataforma nombrada para entornos híbridos de Microsoft, y un producto diferente realiza cada función.

Informes sobre lo que Copilot puede alcanzar, antes y después del despliegue

Netwrix 1Secure informa sobre los datos sensibles a los que Copilot puede acceder antes de que un inquilino lo habilite, lo que responde a la pregunta de preparación mientras el despliegue aún es reversible. Después del lanzamiento, lista usuarios, marcas de tiempo y recursos referenciados para cada interacción, y señala las respuestas de Copilot que exponen datos sensibles.

La cobertura abarca SharePoint Online, servidores de archivos Windows, Active Directory, Microsoft Entra ID y Exchange Online, por lo que el paso 4 del seguimiento de registros solicitado se obtiene desde una sola consola.

Calculando permisos efectivos detrás de cada identidad

Netwrix Access Analyzer resuelve la membresía anidada de grupos AD y la herencia rota de SharePoint para calcular a qué puede acceder realmente cada identidad, mostrando accesos abiertos y derechos obsoletos que los informes por sitio aplanan. Esto convierte el mapeo de cuatro pasos del paso 3 en un informe que puedes entregar a un auditor.

La evaluación de Microsoft 365 Copilot readiness realiza el mismo análisis antes del despliegue, para que el contenido con permisos excesivos se corrija antes de que cualquier usuario reciba una notificación.

Bloqueo de datos sensibles en indicaciones de IA en el endpoint

Netwrix Endpoint Protector inspecciona el contenido del aviso en el endpoint y bloquea datos sensibles antes de que lleguen a ChatGPT, Microsoft Copilot, Google Gemini, Claude o DeepSeek. Cada evento bloqueado se vincula con la identidad detrás de él, lo que convierte una regla escrita de datos prohibidos en algo que el paso 5 puede probar.

Conservando evidencia de cambios más allá de la ventana nativa de registros

Netwrix Auditor registra cada configuración y cambio de directorio de AD y Entra ID con valores antes y después en un rastro buscable. Conserva esos valores en un Archivo a Largo Plazo que por defecto es de 120 meses, mucho más allá del período estándar de 180 días de Purview.

Dos clientes regulados muestran el valor de ese rastro retenido durante una auditoría. First National Bank y Trust of Beloit mantienen el cumplimiento continuo de OCC para 300 usuarios en 17 ubicaciones con Netwrix Auditor, reemplazando el trabajo manual de listas de verificación que antes tomaba una semana completa por una hora de preparación. Flagler Bank identifica y mitiga el riesgo de TI en toda su red con un departamento de TI de una sola persona, cerrando investigaciones en 10 minutos que antes la búsqueda manual de registros extendía por horas.

Netwrix informa sobre el acceso a datos de IA y lo bloquea en el endpoint. La capa de aplicación propia de Microsoft sigue determinando lo que una identidad puede hacer dentro de Microsoft 365 mediante etiquetas de sensibilidad, Purview DLP y Acceso Condicional. La auditoría verifica esos controles, y el comportamiento del modelo permanece con los equipos de ciencia de datos y riesgo de modelos.

Solicite una demostración para mapear qué identidades puede alcanzar Copilot, monitorear lo que muestra después del despliegue y conservar la evidencia de cambios que un examinador solicitará.