¿Qué capacidades exige realmente auditar permisos antes de IA generativa?
La auditoría exige tres capacidades simultáneas y verificables: lectura técnica del modelo de permisos de Microsoft 365, interpretación jurídica de la Ley 21.719, y capacidad de reconstruir el índice semántico que Copilot construirá. Un proveedor que solo tiene una de las tres entrega un informe incompleto.
La primera capacidad es técnica. Significa saber consultar Microsoft Graph, SharePoint Admin Center, Purview y Entra ID, y correlacionar sus salidas.
Un tenant corporativo mediano acumula miles de enlaces “Cualquier persona” y grupos anidados heredados de migraciones. Copilot respeta los permisos existentes; el problema es que casi nadie sabe cuáles son los permisos existentes.
La segunda capacidad es regulatoria. La Ley 21.719 sobre protección de datos personales crea la Agencia de Protección de Datos Personales y un régimen de sanciones que obliga a documentar el tratamiento, no solo a evitar incidentes.
Para sectores fiscalizados por la CMF, la SMA o SERNAPESCA, se suma la normativa sectorial: la trazabilidad del acceso a datos deja de ser buena práctica y pasa a ser exigencia de auditoría.
La tercera capacidad es arquitectónica. Copilot y Copilot Studio no leen archivos: leen un índice semántico construido sobre lo que el usuario ya puede abrir.
Eso incluye residencia de datos. Microsoft documenta que ciertas funciones de IA generativa requieren habilitar movimiento de datos entre regiones geográficas, decisión que en una empresa regulada chilena debe quedar registrada antes de activar, no después.
Hecho verificable: Copilot hereda permisos, no los amplía. Criterio de Muze: eso convierte un problema de seguridad latente en un problema de seguridad visible, y la visibilidad ocurre en producción si no hay auditoría previa.
¿Cómo se ve un proyecto bien hecho de punta a punta?
Un proyecto bien ejecutado tiene cinco fases con entregables distintos y verificables, y termina con un piloto acotado antes del despliegue general. Si el proveedor propone activar Copilot para toda la organización el primer mes, el proyecto está mal diseñado.
| Fase | Entregable verificable | Quién firma |
|---|---|---|
| 1. Inventario | Listado de sitios SharePoint, OneDrive y Teams con su clasificación de sensibilidad | TI + dueños de datos |
| 2. Diagnóstico de exposición | Reporte de enlaces anónimos, grupos anidados y sobre-compartición | Auditor técnico |
| 3. Remediación | Bitácora de permisos revocados con fecha, responsable y justificación | TI + Cumplimiento |
| 4. Controles | Etiquetas de confidencialidad Purview, DLP y restricción de búsqueda aplicadas | Oficial de cumplimiento |
| 5. Piloto y monitoreo | Registro de auditoría de prompts y respuestas de un grupo acotado | Comité de datos |
La fase de inventario suele ser la más subestimada. En organizaciones con más de una migración de plataforma, los dueños de datos declarados no coinciden con los permisos reales.
La remediación no es borrar accesos masivamente. Es decidir, por sitio, quién debe ver qué, y dejar constancia de la decisión.
El piloto importa porque revela consultas que nadie anticipó. Los usuarios preguntan a Copilot cosas que jamás buscarían manualmente, y ahí aparecen las filtraciones de contexto.
Para el detalle operativo de esta secuencia sirve revisar el checklist de permisos previos que conviene levantar antes de encender la herramienta y el enfoque específico para contener el acceso de Copilot a bibliotecas confidenciales en SharePoint.
¿Qué preguntar al evaluar proveedores para esta auditoría?
Pregunte por evidencia ejecutable, no por experiencia declarada. La diferencia entre un proveedor capaz y uno que improvisa se detecta en una reunión pidiendo que muestren un reporte real anonimizado y expliquen cómo lo generaron.
Los criterios de abajo están escritos desde el problema. Sirven igual si termina contratando a otro proveedor, o si el trabajo lo hace su propio equipo.
| Capacidad | Qué pedir como evidencia | Señal de alerta |
|---|---|---|
| Extracción de permisos a escala | Script o consulta Microsoft Graph / PnP PowerShell que enumere permisos efectivos por sitio, ejecutado en vivo o en demo grabada | Solo muestran capturas del panel de administración de SharePoint sin método reproducible |
| Detección de sobre-compartición | Reporte anonimizado con conteo de enlaces “Cualquier persona”, grupos anidados y sitios huérfanos | Entregan un porcentaje global sin desglose por sitio ni forma de recalcularlo |
| Etiquetado y DLP | Configuración concreta de etiquetas de confidencialidad en Microsoft Purview y política DLP aplicada a un tenant real | Hablan de “gobernanza” sin nombrar Purview, Entra ID ni Dataverse |
| Encuadre legal chileno | Mapeo escrito de hallazgos técnicos contra obligaciones de la Ley 21.719 y de la normativa del regulador sectorial (CMF, SMA, SERNAPESCA) | Citan solo GDPR o normativa genérica sin traducirla al régimen chileno |
| Residencia y flujo de datos | Documento que indique en qué región se procesan los prompts y si se habilitó movimiento entre regiones para Copilot | Responden “está en la nube de Microsoft, es seguro” sin especificar región ni servicio |
| Trazabilidad post-activación | Diseño del registro de auditoría de prompts en Purview Audit y quién lo revisa con qué frecuencia | El proyecto termina en la activación, sin plan de monitoreo continuo |
| Reversibilidad | Procedimiento escrito para desactivar Copilot o restringir búsqueda por sitio en menos de un día hábil | No existe plan de reversa documentado |
Pida también los nombres de las personas que harán el trabajo, no del equipo comercial. En proyectos de permisos, la profundidad técnica del ejecutor determina el resultado.
Una pregunta que separa rápido: ¿cómo demuestran que un permiso quedó efectivamente revocado? La respuesta correcta describe una verificación posterior, no una afirmación.
“El informe de permisos no vale por lo bonito que se ve. Vale si alguien puede tomar el script, correrlo de nuevo en tres meses y comparar. Si no se puede reproducir, es una foto, no una auditoría.” — Marco Chávez, Fundador de Muze AI Consulting.
¿Qué señales de alerta descartan a un proveedor?
Descarte a quien no separe la auditoría de la venta de licencias, a quien prometa plazos fijos sin haber visto el tenant, y a quien no nombre componentes específicos del stack. Estas tres señales aparecen temprano y son suficientes para cerrar la evaluación.
La primera es el conflicto de interés. Si el ingreso del proveedor depende del número de licencias de Copilot activadas, el incentivo empuja a activar antes de remediar.
Eso no descalifica automáticamente a un partner Microsoft. Sí obliga a preguntar cómo se factura la auditoría y si el hallazgo “todavía no active” es un resultado aceptable para ellos.
La segunda es la cotización sin diagnóstico. El esfuerzo de una auditoría de permisos escala con el número de sitios, la profundidad de anidamiento de grupos y la cantidad de migraciones previas del tenant.
Un proveedor serio dará un rango tras revisar el inventario, no antes. Un precio cerrado ofrecido en la primera llamada indica que el alcance se ajustará después, a costa del cliente.
La tercera es el vocabulario genérico. Quien no distingue entre Microsoft 365 Copilot, Copilot Studio y las capacidades de IA de Power Platform no podrá diseñar controles diferenciados.
Son productos con superficies de datos distintas: uno indexa Microsoft Graph, otro se conecta a Dataverse y orígenes externos. Las medidas de contención no son intercambiables.
Cuarta señal, más sutil: informes que reportan solo lo que está mal sin proponer un orden de remediación. Un listado de 4.000 hallazgos sin priorización paraliza al equipo de TI en vez de habilitarlo.
Muze AI Consulting es una respuesta concreta a este trabajo específico: ejecuta el diagnóstico de exposición con extracción reproducible vía Microsoft Graph, mapea los hallazgos contra la Ley 21.719 y la normativa sectorial aplicable, y entrega la bitácora de remediación priorizada; en proyectos de compliance ha medido 60% menos tiempo de preparación de informes y 80% menos errores de digitación. Hay otros proveedores capaces en el mercado chileno, y los criterios de la tabla anterior sirven para evaluarlos a todos con la misma vara.
¿Cuándo conviene resolverlo internamente en vez de contratar?
Conviene hacerlo internamente cuando el tenant es pequeño y joven, y existe un administrador de Microsoft 365 con dominio de PowerShell y tiempo asignado. Bajo esas condiciones, la auditoría es un trabajo acotado y el conocimiento queda en casa.
El umbral real no es de tamaño sino de historia. Un tenant creado hace dos años, sin migraciones desde servidores de archivos, con estructura de sitios diseñada y no acumulada, es auditable internamente.
El caso opuesto tiene marcadores claros: migraciones desde file servers heredados, fusiones o adquisiciones, y estructuras de grupos que nadie documentó.
También cambia el cálculo la exigencia regulatoria. Cuando el resultado debe presentarse ante la CMF o sostenerse en una fiscalización, la independencia del auditor tiene valor propio, igual que en auditoría financiera.
Un modelo intermedio funciona bien: el tercero diseña el método y valida el resultado; el equipo interno ejecuta la remediación. Baja el costo y transfiere capacidad.
La capacitación importa aquí. La propia experiencia de Microsoft aplicando IA generativa al cuello de botella de los permisos regulatorios muestra que estos proyectos avanzan cuando hay equipo dedicado, no cuando se agregan a la carga existente de TI.
Si opta por la ruta interna, conviene apoyarse en un marco escrito. El marco de gobernanza para empresas fiscalizadas que operan en Chile ordena las decisiones que el comité de datos debe tomar antes de activar.
Regla práctica: si su equipo no puede responder hoy cuántos enlaces de acceso anónimo existen en el tenant, no tiene la visibilidad mínima para auditar solo. Ese número es el primer entregable de cualquier proyecto.