Copilot ya está en el risk register: lo que cambia para mí como CISO

 

Hace dieciocho meses, cuando alguien hablaba de poner Copilot en el risk register corporativo, te miraban como si exageraras. Hoy, no puedes presentarte ante el comité de auditoría sin tener Copilot ahí. Es una de esas transiciones que pasaron rápido y silenciosamente.

Voy a contar cómo lo manejo, porque sé que hay otros CISOs leyendo esto que están en la misma encrucijada.

Lo primero: el comité de auditoría no quiere oír “Copilot está bien gestionado porque tenemos sensitivity labels”. El comité quiere oír qué riesgo específico estás controlando, cómo lo mides, cómo lo monitoreas, quién es accountable, qué evidencia tienes.

Mi entry en el risk register de Copilot tiene seis ítems separados. Lo aprendí a fuerza de iteraciones.

Riesgo 1 — Filtración de datos por respuestas inapropiadas

Causa: oversharing de permisos más grounding amplio. Control primario: SAM más Purview DLP más sensitivity labels. KRI: porcentaje de prompts bloqueados por DLP por mes, tendencia. Evidencia: dashboard de Purview con histórico.

Riesgo 2 — Prompt injection y exfiltración asistida

Causa: contenido externo procesado por el modelo. Control: Prompt Shields más Spotlighting más URL allowlist más confirmación de acciones con efecto lateral. KRI: número de incidents de Prompt Shield triage por mes, severidades. Evidencia: tickets de SOC.

Riesgo 3 — Identidades de agente sin governance

Causa: agentes desplegados sin sponsor o sin scope claro. Control: Entra Agent ID más sponsor tasks más access reviews. KRI: porcentaje de agentes registrados sobre total detectado, agentes huérfanos. Evidencia: reporte trimestral de Entra Agent ID más Agent 365.

Riesgo 4 — Shadow AI en endpoints

Causa: agentes locales no inventariados. Control: Defender más Intune discovery más política de allowlist. KRI: número de agentes detectados fuera de lista, evolución mensual. Evidencia: dashboard de Defender.

Riesgo 5 — Dependencia de proveedor y continuidad

Causa: dependencia crítica de Microsoft 365 más servicios de IA. Control: planes de continuidad, BCP/DR del proveedor revisado, alternativas evaluadas. KRI: SLA cumplido, incidents reportados por Microsoft. Evidencia: reportes contractuales.

Riesgo 6 — Cumplimiento regulatorio

Causa: requisitos cambiantes (EU AI Act, regulaciones locales). Control: legal más compliance reviews trimestrales, in-country processing donde aplique. KRI: gaps identificados en último review. Evidencia: actas de los reviews.

Cada riesgo tiene dueño nombrado. Cada control tiene evidencia. Cada KRI tiene umbrales.

Lo que aprendí presentando esto

El comité no premia complejidad. Premia claridad. Mi primera presentación tenía 20 ítems. Bajó a 6. Cada uno entendible en 30 segundos. Si tu entry no se lee en 30 segundos, no se lee.

El comité quiere ver evolución. Una foto del riesgo hoy es menos útil que la tendencia. ¿Estamos mejor o peor que hace 6 meses? ¿Por qué? Esa narrativa es lo que te da credibilidad o te la quita.

El comité quiere oír qué pasaría si fallara el control. No solo “tenemos control X”. También “si X falla, qué tenemos”. Defensa en profundidad explicada con palabras, no jerga.

 

 

Lo que más me costó

Convencer a operación de que cada control necesita evidencia documentada. “Lo hacemos pero no lo escribimos en ningún lado”. Ese es el peor estado posible. La evidencia que no existe, en una auditoría, es un control que no existe. Tomó meses cambiar el hábito.

Convencer a finanzas de que el budget de seguridad de Copilot no es opcional ni puntual. Es operativo, recurrente. Si quieres mantener los controles, financia la operación, no solo el setup.

Convencer al equipo de IA de que governance no es enemigo de innovación. Es lo que le permite a innovación durar. Esto fue cultural y tomó un año entero.

 

Mi consejo

No copies mi lista. Tu contexto es distinto. Pero usa la estructura: causa, control, KRI, evidencia, dueño. Eso es transversal.

Empieza pequeño y honesto. Mejor 3 riesgos bien gestionados que 15 mal documentados. El comité huele el bullshit a kilómetros.

Habla con tu auditor antes de la primera presentación. Pregúntale qué quiere ver. Te ahorras un trimestre de reescritura.

 

Y la última: este risk register no es estático. Cada quarter cambia. Hace seis meses no tenía la categoría de shadow AI. Hace tres no tenía in-country processing. La velocidad del espacio te obliga a actualizar. Si tu entry de Copilot se ve igual hace un año, probablemente no estás mirando.

OWASP Top 10 para agentic AI: cómo lo aterrizo en Copilot Studio

 

OWASP sacó el Top 10 para agentic AI en marzo. Microsoft, fiel a su estilo, publicó casi al mismo tiempo cómo se mapea a Copilot Studio. He pasado las últimas semanas intentando hacer que el mapeo le hable a mi equipo.

El Top 10 no es un descubrimiento — la mayoría de las categorías ya las veníamos manejando. Lo valioso es que da nomenclatura común. Cuando hablo con un auditor, con un cliente, con un nuevo miembro del equipo, podemos decir “AAI:01 - Memory Poisoning” y los dos sabemos a qué nos referimos. Antes era cada uno con su jerga.

 

Voy a recorrer rápido cómo lo aterrizo en Copilot Studio. No es una guía exhaustiva, es lo que hago yo.

Recorrido por los 10

AAI:01 Memory Poisoning — el agente acumula contexto, alguien lo contamina, el agente actúa sobre datos envenenados. En Copilot Studio: limito el scope de la memoria del agente, no le doy acceso a memorias persistentes salvo necesidad clara, audito qué entra a la memoria del agente. Si el agente consume documentos compartidos, los pasamos por sensitivity labels y DLP antes de que entren a su corpus.

AAI:02 Tool Misuse — el agente usa una herramienta para algo distinto a su propósito. En Copilot Studio: cada conector con scope mínimo necesario. Si el agente solo necesita leer del CRM, no le des escritura. Si solo en una tabla, no en todas. Esto requiere paciencia con el setup pero paga después.

 

AAI:03 Privilege Compromise — el agente termina con más permisos de los que debería. En Copilot Studio: revisión periódica de permisos del agente. Entra Agent ID más access reviews. Esto es lo que hablé en otro post — meter al agente al ciclo de governance estándar.

AAI:04 Resource Overload — el agente consume tantos recursos que se vuelve indisponible o caro. En Copilot Studio: rate limits, cost caps por agente, monitoring de consumo. Si un agente sube su consumo súbitamente, alerta.

 

AAI:05 Cascading Hallucinations — un agente alucina, otro toma esa salida como verdad, y la cadena de errores crece. En Copilot Studio multi-agente: validación entre nodos, no encadenar agentes sin un punto de verificación. Costoso pero necesario en flujos críticos.

AAI:06 Intent Breaking and Goal Manipulation — esto es prompt injection con vocabulario más fancy. En Copilot Studio: Prompt Shields activo, Spotlighting cuando hay inputs de fuera, system prompts robustos, validation de outputs.

AAI:07 Misaligned and Deceptive Behaviors — el agente hace algo que parece OK pero no es lo que el usuario quería. En Copilot Studio: confirmación explícita de acciones con efecto lateral. Si el agente va a mandar correo, modificar archivo, ejecutar transacción — confirma con el humano. Esto, aunque agrega fricción, es no-negociable.

 

 

AAI:08 Repudiation — el usuario o el agente niega haber hecho una acción y no hay forma de probarlo. En Copilot Studio: logging completo activado en Purview, identidad de agente clara (Entra Agent ID), trazabilidad end-to-end. Auditable es no-negociable.

 

AAI:09 Identity Spoofing and Impersonation — alguien se hace pasar por el agente o el agente se hace pasar por alguien. En Copilot Studio: identidad robusta del agente, autenticación mutua donde aplica, MFA en quien crea o modifica agentes.

 

AAI:10 Overwhelming HITL — el humano en el loop recibe tanto input que deja de validar. En Copilot Studio: diseño de aprobaciones que no satura. Si tu agente genera 1000 acciones al día y todas requieren aprobación humana, la aprobación deja de ser real. Hay que pensar el HITL como recurso escaso.

Cómo lo opero

He empezado a documentar cada agente en una matriz: para cada uno de los 10 ítems, ¿cuál es nuestro control, cuál es la evidencia, quién es el dueño? Cuando el auditor llega — y va a llegar — el documento ya existe. No lo armas la semana antes.

¿Es todo? No. Hay categorías que el Top 10 cubre superficialmente. Por ejemplo, supply chain de modelos: si tu agente usa un modelo custom, ¿cómo lo verificaste? Eso está implícito en varios ítems pero no es categoría propia. Lo cubro aparte.

¿Lo recomendaría como base para tu programa? Sí. Tener el Top 10 como vocabulario y línea base, y construir tu programa por encima, te ahorra inventar la rueda. Que es lo que más tiempo nos hace perder en seguridad: discutir taxonomía cuando deberíamos estar implementando controles.

La pieza que faltaba: DLP de Purview para Copilot

 

Llevaba meses esperando que Microsoft sacara DLP de Purview específicamente para Copilot. En Ignite 2025 anunciaron la GA de la versión que actúa sobre archivos y correos con etiquetas de sensibilidad. En diciembre 2025 entró en preview la versión que actúa sobre prompts. La GA de prompts está prevista para finales de marzo de 2026 — y a la fecha en que escribo, ya está accesible para la mayoría de tenants empresariales.

Voy a contar para qué sirve esto en los términos en que se lo expliqué a mi gerente, que no es técnico pero firma los presupuestos.

Una cosa es proteger los archivos en reposo. Si tienes un PDF con contratos confidenciales, le pones un sensitivity label “Confidencial - Externo Restringido”, y Copilot ya no lo procesa para usuarios fuera del scope autorizado. Esa parte estaba.

Otra cosa, y aquí es donde estábamos cojos, es proteger lo que el usuario teclea en el prompt. Imagínate que el usuario está pidiendo a Copilot que le ayude a redactar un correo y, sin pensar, copia y pega un número de tarjeta de crédito de un cliente. O un número de seguridad social. O un fragmento entero de un contrato bajo NDA. Eso no es un archivo etiquetado. Es texto plano que el usuario metió a la fuerza. Antes de la nueva DLP, ese contenido se procesaba sin más.

Ahora, Purview escanea el prompt en tiempo real buscando Sensitive Information Types (SITs). Hay built-in para datos como SSN, tarjetas, IBANs. Y puedes definir custom — por ejemplo, “código de proyecto interno X-confidential” o el nombre clave de tu producto que no se debe filtrar. Si lo detecta, bloquea la respuesta. Copilot no responde. El usuario ve un mensaje de policy.

Qué tan bien funciona

Razonablemente. He hecho pruebas con tres SITs custom y dos built-in. Falsos positivos: pocos pero existen, sobre todo cuando los SITs custom tienen patrones genéricos. Falsos negativos: encontré un par cuando el usuario partía el dato sensible en dos prompts seguidos. La DLP no correlaciona conversación; mira prompt por prompt. Eso es un gap real.

La latencia agregada es mínima. En mis pruebas, menos de 200ms. No la sienten los usuarios.

 

Mi orden recomendado

Primero, defines el corpus de SITs que tienen sentido para tu negocio. No metas todo lo que se te ocurra — cada SIT activo es coste de inferencia y potencial fricción. Yo arranqué con seis: tarjetas, SSN/CURP local, IBAN, dos nombres de proyecto críticos, y un patrón regex para códigos internos. Suficiente para empezar.

Segundo, lo pones primero en modo audit, no block. Una semana en audit te dice si tu corpus es razonable. Si en una semana se dispararían 5,000 bloqueos al día, algo está mal.

Tercero, comunicas a los usuarios antes de cambiar a block. Un correo simple. “A partir del lunes, si pegas datos sensibles en Copilot, no responderá. Aquí los tipos de datos. Si tienes que trabajar con esto, usa este canal alternativo”. Sin esa comunicación, los tickets te entierran.

Cuarto, mides. ¿Cuántos prompts bloqueados por semana? ¿De qué usuarios y áreas? ¿Hay patrones que sugieran necesidad de capacitación? La DLP es solo el dique. La cultura es el río.

Lo que me sigue molestando es que la correlación cross-prompt no existe todavía. Si el usuario es astuto, puede partir un dato sensible y meterlo en pedazos. La DLP de prompts no lo va a pillar. Para eso, necesitas combinar con Insider Risk en Purview. Microsoft sabe que es un gap y dicen que están trabajando.

 

Para mí, esta es la pieza del 2026 que más rápido cambia el riesgo real de Copilot. Si solo puedes hacer una cosa este trimestre, hazla esta.

Por qué a cada agente le tengo que poner nombre y apellido

 

Una de las cosas que me costó más vender internamente este año fue la idea de tratar a cada agente como una identidad de primera clase. La cara del CFO cuando le dije “oye, vamos a tener miles de identidades nuevas, y todas van a costarnos gobernarlas” no fue de las mejores reuniones del trimestre.

Pero es lo que toca.

Microsoft Entra Agent ID, todavía en preview a mayo de 2026, es la pieza estructural. La idea es simple: el agente no es un script anónimo que corre con el token de un humano. El agente tiene su propia identidad, sus propios permisos, su propio dueño accountable, y entra al ciclo de vida de IGA igual que un empleado.

 

Lo que cambia en la práctica

Antes, si el agente “robot-X” hacía algo raro, el log decía “user: maria.gonzalez”. Tenías que preguntarle a María si era ella o su agente. Ahora el log dice “agent: robot-x | sponsor: maria.gonzalez”. Forensia más limpia, accountability sin ambigüedad.

Antes, cuando María se iba de la empresa, el agente seguía corriendo con su identidad heredada hasta que alguien se acordara. Ahora hay sponsor tasks en Lifecycle Workflows: si el sponsor humano sale, hay un workflow que pide reasignar o suspender al agente. No es perfecto — la implementación a veces requiere intervención manual — pero existe el carril.

Antes, no podías hacer access reviews sobre lo que un agente puede ver. Ahora sí. Y aquí va lo importante: la primera vez que corrí un access review sobre un agente de Copilot Studio que llevaba ocho meses corriendo, encontré que tenía acceso a SharePoint sites que ya nadie usaba. Permisos que se habían heredado de la cuenta de servicio que el agente reemplazó. Limpiamos casi 200 permisos huérfanos en una tarde.

 

Lo que no me gusta

Que sigue siendo preview. Quiero esto en GA ya. Las features de governance de identidades de máquina nunca van rápido en el roadmap, y entiendo por qué (es complicado hacerlo bien), pero el problema ya está aquí.

Que la integración con Copilot Studio aún tiene gaps. No todos los agentes legacy se migran solos. Tienes que ir uno por uno reasignando, lo cual con una empresa con cientos de agentes pequeños es trabajo manual.

Que el billing de las identidades de agente no está claro todavía. Microsoft dice que se factura como parte de Agent 365, pero la documentación todavía es ambigua sobre cuándo cuenta como identidad facturable y cuándo no. He visto facturas con sorpresas.

Para empezar

Define la política primero, antes de tocar el portal. ¿Qué agentes requieren sponsor? ¿Cuántos sponsors mínimos necesita un agente crítico, uno o dos? ¿Cómo defines “crítico” para empezar? ¿Qué pasa si el sponsor está de vacaciones, sigue corriendo el agente o se pausa? Sin estas definiciones, te vas a meter en un lío político con managers que se sienten responsables de algo que no entienden.

Inventario antes que governance. Si no sabes cuántos agentes corren ya en tu tenant, el primer ejercicio es contarlos. Yo hice un script básico de exportar todo lo que Copilot Studio reporta y crucé contra lo que Defender ya estaba viendo. Aparecieron varios que no estaban en mi lista. Eso solo ya valió el ejercicio.

Y por último — y esto es opinión personal — no esperes a que GA salga para empezar a pensar en esto. La gobernanza de identidades de agente va a ser el control compensatorio más importante del 2026 y 2027. Si llegas tarde, no hay forma de retro-encajarlo limpiamente.