Cómo diseñar una estrategia DLP para Microsoft 365 Copilot y agentes

Publicada el 5 de octubre de 2026. Estado de las funciones, licencias y nombres comprobados ese día en la documentación oficial de Microsoft.

En esta guía uso «estrategia DLP» en el sentido amplio con el que se suele pedir: evitar que la información sensible acabe donde no debe. Microsoft Purview Data Loss Prevention es una de las piezas, y no la primera. Las demás son permisos, etiquetas, gobierno de agentes, identidad y registros, y cada una se configura en un sitio distinto.

Una nota sobre nombres: en su documentación de 2026, Microsoft habla de Microsoft Copilot y de Copilot Chat, mientras la licencia completa sigue llamándose Microsoft 365 Copilot y la ubicación de DLP, «Microsoft 365 Copilot and Copilot Chat» (qué es Microsoft Copilot). Aquí uso Microsoft 365 Copilot para la experiencia que trabaja con datos de la organización.

Cinco agentes en marcha y nadie mirando el conjunto

Una empresa activa Microsoft 365 Copilot para buena parte de la plantilla. En pocos meses aparecen cinco agentes: uno de RR. HH. que responde dudas sobre vacaciones y nóminas, otro de soporte interno, uno comercial que prepara ofertas, uno conectado al CRM y otro que consulta la documentación técnica. Funcionan, la gente los usa y nadie se ha quejado.

El problema aparece cuando alguien pregunta por el conjunto. Nadie ha revisado a la vez:

• qué información puede consultar cada agente y con qué identidad;
• qué conectores utiliza y hacia dónde envían datos;
• qué sitios de SharePoint están compartidos con más gente de la que debería;
• qué documentos tienen etiqueta y cuáles no;
• qué respuestas o acciones habría que impedir;
• qué ocurre cuando un agente llama a un sistema externo.

Yo no empezaría por la política. Primero dibujaría el recorrido de la información: quién pregunta, qué agente responde, de dónde saca los datos, qué hace con ellos y a qué sistema los puede mover. Sobre ese dibujo se ve qué controles existen ya, cuáles faltan y cuáles tienen poco que ver con DLP.

Copilot y los agentes trabajan sobre información que ya existe en la organización. Lo que cambia es la velocidad: encuentran, combinan, resumen y mueven en segundos lo que antes exigía saber dónde buscar. Si los permisos estaban demasiado abiertos o había documentos sensibles sin clasificar, ese problema ya existía; ahora se nota antes.

El mapa: por dónde viaja la información cuando intervienen Copilot o un agente

Este es el recorrido que conviene dibujar para Copilot y para cada agente. Junto a cada paso están los controles que pueden actuar en ese punto.

Ocho capas, y no todas son DLP

Llamar DLP a todo lo anterior complica las conversaciones entre seguridad, cumplimiento y administración. Prefiero separar ocho capas y decir qué tipo de control es cada una.

Solo la tercera es DLP en sentido estricto. Power Platform llamó durante años «directivas DLP» a la cuarta; hoy Microsoft las denomina directivas de datos (data policies), y actúan sobre conectores y funciones sin analizar el contenido.

Primer error: pensar que Copilot se salta los permisos

Microsoft lo documenta sin ambigüedad: Copilot solo muestra datos de la organización sobre los que el usuario tiene, como mínimo, permiso de lectura (datos, privacidad y seguridad de Copilot). Las consultas se ejecutan en el contexto de seguridad de quien escribe el prompt, y eso incluye los permisos dados a personas externas, por ejemplo en canales compartidos de Teams.

Que Copilot respete los permisos tiene una consecuencia menos cómoda: hereda también los que sobran. Un sitio compartido con «Todos excepto los usuarios externos», un enlace válido para toda la organización o la carpeta de un proyecto cerrado con los permisos de entonces siguen siendo accesibles. Antes hacía falta conocer la ruta o acertar con el buscador; con Copilot basta con preguntar.

A esto se le llama sobreexposición (oversharing): personas o grupos con acceso a información que no necesitan para su trabajo. Copilot amplifica la sobreexposición que ya había, porque la hace visible y fácil de aprovechar. Por eso lo trato como un problema de gobierno del dato: la solución pasa primero por los permisos, y DLP llega después.

Con los agentes, la pregunta se amplía. Una herramienta de un agente puede usar las credenciales de quien pregunta o las de quien creó el agente. En el segundo caso, el usuario puede llegar a datos que por sí mismo no vería. Lo trato en las secciones de identidad y agentes autónomos.

Capa 1 · Permisos y sobreexposición

Antes de cualquier regla de DLP revisaría los permisos de los repositorios que Copilot y los agentes pueden consultar. Si una persona puede abrir un documento, Copilot puede usarlo en sus respuestas, dentro de los límites que soporta el servicio.

Qué revisar en SharePoint, OneDrive y Teams

Marca lo que tengas comprobado. Las marcas solo sirven para tu lectura: no se guardan ni se envían.

SharePoint Advanced Management, incluido con las licencias de Copilot, aporta informes de gobierno del acceso a los datos, revisiones de acceso por parte de los propietarios de cada sitio y directivas de propiedad y de sitios inactivos (SharePoint Advanced Management). En Purview, DSPM añade evaluaciones de riesgo que señalan sitios sobreexpuestos con información sensible.

Controles temporales mientras se corrige

Sanear permisos lleva semanas. Mientras tanto, la guía de despliegue de Microsoft propone dos medidas provisionales (base segura y gobernada para Copilot):

• Restricted Content Discovery saca sitios concretos de la búsqueda de toda la organización y de las respuestas de Copilot, y retira de esos sitios los accesos a funciones de IA. No cambia los permisos, solo funciona con sitios de SharePoint (no con OneDrive) y Microsoft la plantea como medida temporal (Restricted Content Discovery).
• Purview DLP para Copilot excluye de las respuestas el contenido con determinadas etiquetas. Lo explico en la capa 3.

Las dos medidas deberían tener fecha de retirada. Cuando un sitio está saneado, se levanta la restricción; si se queda puesta, Copilot pierde contenido útil y el problema de fondo sigue sin resolver. Como protección permanente, la misma guía recomienda aplicar Restricted Access Control por defecto en los sitios críticos y limitar los enlaces «Cualquier persona» y los grupos de toda la empresa.

Capa 2 · Clasificación y etiquetas de confidencialidad

Las etiquetas de confidencialidad (sensitivity labels) de Microsoft Purview Information Protection indican qué es sensible y pueden aplicar marcas, cifrado y restricciones de uso. Con Copilot cumplen tres funciones: informan al usuario, condicionan lo que el asistente puede resumir cuando hay cifrado y sirven de condición en las políticas DLP.

Poner una etiqueta no impide por sí solo que Copilot lea un archivo. El efecto depende de la configuración: si cifra o no, qué derechos concede y a quién, y si alguna política DLP usa esa etiqueta.

VIEW, EXTRACT y cifrado

• Si la etiqueta cifra, el usuario necesita los derechos VIEW y EXTRACT para que Copilot devuelva el contenido (Purview y Microsoft 365 Copilot).
• Con VIEW pero sin EXTRACT, Copilot puede enlazar el elemento, pero no resumirlo (derechos de uso).
• Hay que activar las etiquetas en SharePoint y OneDrive. Sin eso, los archivos cifrados a los que llegan Copilot y los agentes se limitan a los que el usuario tiene abiertos en las aplicaciones de Office en Windows.
• El contenido con Double Key Encryption no es accesible para Copilot, ni almacenado ni abierto en la aplicación (Double Key Encryption).
• Los correos con S/MIME no se devuelven, y los documentos protegidos con contraseña solo se usan si el usuario ya los tiene abiertos.
• Copilot Chat muestra la etiqueta de mayor prioridad entre las fuentes que ha usado, y Copilot en Word, PowerPoint y Outlook hereda la etiqueta del documento de origen al crear contenido nuevo.

Con los agentes hay matices. En Copilot Studio, las etiquetas se respetan cuando la fuente de conocimiento es SharePoint (o Dataverse con autoetiquetado del Data Map), y el cifrado solo se admite mediante etiquetas y con SharePoint como fuente (Purview y Copilot Studio). Las instancias de agente de Agent 365 necesitan que el archivo se comparta expresamente con ellas y que el cifrado les conceda VIEW y EXTRACT; una etiqueta que da permisos a todos los usuarios de la organización no basta, y lo que crean no hereda la etiqueta de las fuentes (Purview y Agent 365).

Qué debería poder hacer Copilot con cada etiqueta

Esta escala es una propuesta para orientar la conversación con el negocio. Los nombres y el número de etiquetas dependen de la taxonomía de cada organización.

Para etiquetar a escala, el autoetiquetado de Purview en SharePoint y OneDrive acaba de ampliar su límite diario (nota de 30 segundos sobre el autoetiquetado); requiere licencias de nivel E5.

Capa 3 · Purview DLP para Copilot: qué hace exactamente

Microsoft Purview Data Loss Prevention tiene una ubicación propia para Copilot, llamada «Microsoft 365 Copilot and Copilot Chat». Sus políticas actúan sobre la interacción con el asistente: qué contenido puede usar para responder, qué prompts procesa y cuándo puede salir a la web (DLP para Microsoft 365 Copilot).

Cuatro controles y su estado

Microsoft ha creado además una política por defecto, «Default DLP policy - Protect sensitive M365 Copilot interactions», que detecta tipos de información confidencial en los prompts y arranca en modo simulación: registra, pero no bloquea (política por defecto). Antes de crear otra, revisaría esa: qué tipos detecta, quién recibe las alertas y cuándo pasarla a aplicación.

Límites que conviene conocer antes de diseñar:

• Una regla no puede combinar etiquetas y tipos de información confidencial; hacen falta reglas separadas dentro de la política.
• La ubicación solo existe en la plantilla personalizada y, al elegirla, se desactivan las demás ubicaciones de esa política.
• Los cambios tardan hasta cuatro horas en aplicarse. Admite alertas, notificaciones y modo simulación, pero no unidades administrativas.
• DLP no analiza los archivos que el usuario adjunta al prompt; solo el texto que escribe.
• En correo, la restricción por etiqueta cubre los mensajes enviados desde el 1 de enero de 2025, y las convocatorias de calendario quedan fuera.
• En Word, Excel y PowerPoint, la política se evalúa al abrir el archivo. Si la etiqueta cambia con el documento abierto, se aplica la siguiente vez que se abra.

Qué cubre: Copilot, Cowork y agentes

La restricción por etiqueta se aplica en Microsoft 365 Copilot, Copilot Chat, Cowork y Copilot en Word, Excel y PowerPoint. Con los agentes conviene precisar:

• Agentes de Copilot Studio: una política de la ubicación de Copilot puede impedir que procesen contenido con una etiqueta concreta cuando su fuente de conocimiento es SharePoint y están publicados en Teams, SharePoint o Microsoft 365 Copilot (Purview y Copilot Studio).
• Instancias de agente de Agent 365: se incluyen en las políticas DLP como si fueran usuarios, o mediante un grupo de seguridad, para bloquear o auditar los intercambios entre personas y agentes en Teams, SharePoint, OneDrive y correo. El agente no sabe que se le ha bloqueado, así que su responsable tiene que vigilar el efecto en los flujos posteriores (Purview y Agent 365).
• IA de terceros: en los equipos incorporados a Purview, Endpoint DLP puede avisar o bloquear cuando alguien pega datos sensibles en un sitio de IA generativa desde el navegador, que es la parte técnica de lo que se suele llamar Shadow AI. En la versión web de Copilot Chat admite bloquear el pegado de contenido sensible y los archivos con determinadas etiquetas.

Ejemplo: excluir lo «Altamente confidencial»

DLP añade una barrera sobre lo que Copilot puede usar. Los permisos siguen decidiendo quién llega al dato, y las etiquetas, qué es sensible. Los agentes, además, tienen capacidades que esta ubicación no gobierna: conectores que sacan datos del tenant y acciones que modifican otros sistemas. De eso se ocupan las capas siguientes.

Capa 4 · Copilot Studio y las directivas de datos de Power Platform

Los agentes de Copilot Studio viven en entornos de Power Platform y se gobiernan con directivas de datos (data policies), que se configuran en el centro de administración de Power Platform. Desde principios de 2025 se aplican en todos los tenants. Las exenciones que permitían dejar agentes fuera ya no existen, y los agentes que estaban exentos quedaron sujetos a las directivas (directivas de datos para agentes).

Qué gobiernan

La aplicación es en tiempo real: quien crea el agente ve la capacidad deshabilitada, recibe un error y no puede publicar mientras haya infracciones.

Grupos, endpoints y directivas avanzadas

• Los conectores se clasifican en Business, Non-business o Blocked, y un agente no puede combinar conectores de grupos distintos. Los conectores nuevos caen en el grupo por defecto, que en muchas organizaciones bloquea.
• El filtrado de endpoints permite autorizar o denegar URL concretas para HTTP, para sitios públicos y para SharePoint como conocimiento. En Power Platform sigue en preview y no evalúa endpoints dinámicos, variables de entorno ni entradas personalizadas (filtrado de endpoints).
• Los conectores personalizados se clasifican, a nivel de tenant, por patrones de URL del host. En las directivas nuevas, la regla comodín «*» viene como «Ignore»: si no hay otra regla, el conector personalizado se puede usar junto a conectores de cualquier grupo (conectores personalizados).
• Las directivas avanzadas de conectores (advanced connector policies) invierten el modelo: todo bloqueado salvo lo permitido, por entorno o grupo de entornos, con bloqueo a nivel de servidor MCP. Todavía no cubren conectores personalizados ni HTTP, y los controles propios de Copilot Studio siguen en las directivas clásicas hasta que Microsoft publique reglas dedicadas (directivas avanzadas de conectores).
• Los cambios se propagan con retraso: normalmente en menos de una hora y, en entornos grandes, hasta en 24 horas. Lo que incumple pasa a cuarentena y falla en ejecución (directivas de datos de Power Platform).

¿Son lo mismo que Purview DLP?

No. Una organización con Copilot y Copilot Studio necesita las dos, porque responden a preguntas distintas.

Una protege el contenido y la otra limita las capacidades del agente.

Capa 5 · Conectores, HTTP, MCP y herramientas

Cada conexión amplía lo que un agente puede leer y hacer: un conector a un CRM, una petición HTTP a una API, un servidor MCP (Model Context Protocol), una skill o una herramienta de un tercero. Para analizar el riesgo cuenta menos el tipo de conexión que lo que permite hacer.

Seis preguntas antes de aprobar una conexión

1. ¿Qué datos puede leer y de qué sistemas?
2. ¿Qué puede escribir, crear o borrar?
3. ¿Qué acciones ejecuta, y pide confirmación antes?
4. ¿Con qué identidad se conecta: la del usuario, la del creador o una propia?
5. ¿Puede llamar a sistemas externos o a endpoints que no controlamos?
6. ¿Puede enviar información fuera del tenant, y queda registrado?

MCP: tres caminos que se gobiernan en sitios distintos

MCP llega hoy por al menos tres vías al ecosistema de Microsoft 365. Comparten protocolo, pero cada una se gobierna desde una consola distinta.

Un detalle con impacto: si un servidor MCP o una API se autentica con una clave de API, el acceso no pasa por Microsoft Entra y Conditional Access no puede aplicarse (Conditional Access para agentes). Para conexiones con datos sensibles preferiría OAuth con la identidad del usuario.

Capa 6 · Identidad: un agente también debería tener solo lo que necesita

El principio de mínimo privilegio se aplica igual a los agentes. La diferencia es que un agente puede actuar de tres maneras, y cada una se controla en un sitio distinto (Conditional Access para agentes):

• En nombre del usuario (acceso delegado): usa los permisos de quien pregunta, y las políticas se dirigen a los usuarios.
• Con su propia identidad y sin usuario presente (solo aplicación): es lo habitual en agentes autónomos, y las políticas se dirigen a la identidad del agente o a su plantilla (blueprint).
• Con su propia cuenta de usuario de agente, que puede tener buzón, licencias y pertenecer a grupos. Las políticas que apuntan a «todos los usuarios» no incluyen estas cuentas.

Microsoft Entra Agent ID está disponible para todos los clientes de Entra, y desde julio de 2026 Copilot Studio crea uno para cada agente nuevo, sin opción de desactivarlo por entorno (novedades de Copilot Studio). Para aplicar a los agentes los controles de seguridad de Entra (Conditional Access, protección de identidad y gobierno) hace falta Microsoft Agent 365 (qué es Microsoft Entra Agent ID).

Las cuentas de quienes crean y administran agentes merecen la misma protección que las de administración; las claves de acceso (passkeys) son la opción resistente al phishing (manual de passkeys en Entra ID).

Capa 7 · Observabilidad: qué se ve, dónde y qué no

Una estrategia DLP que solo bloquea y no registra pierde el contexto: no sabrás qué se intentó, quién lo hizo ni si la política estaba bien diseñada. Con Copilot y los agentes, la evidencia está repartida entre varias herramientas.

Purview Audit

Las interacciones con Copilot, Cowork y los agentes de Copilot Studio se registran en Audit (Standard) sin configuración adicional, siempre que la auditoría esté activa (auditoría de Copilot). Cada registro CopilotInteraction incluye, entre otros datos:

• los recursos consultados, con su etiqueta, si la acción tuvo éxito y qué política la bloqueó o restringió;
• si se detectó inyección indirecta de prompts en un recurso o un intento de jailbreak en el prompt;
• el agente implicado, con su identificador, nombre y versión, y la aplicación donde ocurrió.

El registro de auditoría no contiene el texto de las conversaciones. Los prompts y las respuestas se guardan en el buzón del usuario; se consultan desde DSPM con el rol adecuado y se buscan, conservan o exportan con eDiscovery.

En Copilot Studio se auditan además las acciones de quienes crean y administran agentes: creación, publicación, compartición, cambios de autenticación, componentes y variables de entorno (auditoría de Copilot Studio). La autenticación de los agentes con Agent ID queda en los registros de Microsoft Entra, y las aplicaciones de IA de terceros se auditan con facturación por uso y 180 días de retención.

DSPM: la vista de postura

Data Security Posture Management (DSPM) de Purview muestra dónde está el riesgo y propone políticas; el bloqueo lo hacen después DLP o las etiquetas. La versión actual sustituye a DSPM for AI, que Microsoft mantiene como «classic», e incluye una página de observabilidad de IA con las aplicaciones y agentes que han tenido actividad, los de alto riesgo y las interacciones con datos sensibles (DSPM).

Sirve para descubrir el uso real, revisar interacciones con información sensible, lanzar evaluaciones de sobreexposición y crear con un clic las políticas que recomienda. Esas políticas son de DLP, Insider Risk o etiquetado, y cada una mantiene sus requisitos de licencia.

Insider Risk y Adaptive Protection

La plantilla Risky AI usage de Insider Risk Management detecta prompts y respuestas con información sensible en Copilot y en los agentes, además de visitas a sitios de IA generativa, y alimenta la puntuación de riesgo de cada usuario. La plantilla Risky Agents, en preview, vigila el comportamiento de los agentes de Copilot Studio y Foundry: acceso a archivos sensibles, visitas a sitios de riesgo o compartición externa (plantillas de Insider Risk Management).

Adaptive Protection convierte ese riesgo en controles más estrictos. Por ejemplo, una política puede bloquear a un usuario con riesgo elevado que intenta pegar datos sensibles en una IA de terceros y limitarse a avisar al resto. Conviene precisar dónde actúa: en DLP para Exchange, Teams, dispositivos y aplicaciones en la nube no gestionadas, y en preview con Conditional Access y con retención (Adaptive Protection). La ubicación de Copilot en DLP no ofrece hoy la condición de nivel de riesgo (referencia de directivas DLP).

Ninguna de las dos es imprescindible para empezar. Requieren licencias de nivel E5 y, antes de activarlas, conviene pasar por asesoría jurídica y el DPO, informar a la representación de los trabajadores y hacer una evaluación de impacto, como con cualquier monitorización de la actividad de las personas.

Microsoft Defender

Defender cubre las amenazas en tiempo de ejecución. Desde el 1 de julio de 2026, sus capacidades de seguridad para agentes de Copilot Studio y Foundry requieren licencia de Agent 365 (transición a Agent 365). La protección en tiempo real evalúa las invocaciones de herramientas antes de ejecutarlas; para los agentes de Copilot Studio está en preview, y la regla por defecto solo audita hasta que se crean reglas de bloqueo (protección en tiempo real).

Qué verás y qué no

Capa 8 · Gobierno: inventario, responsables y ciclo de vida

No puedes aplicar DLP a un inventario que no tienes. Antes de decidir políticas hay que saber qué agentes existen, quién responde de cada uno, qué datos usan y dónde están publicados.

Registro de agentes y Agent 365

El registro de agentes del centro de administración de Microsoft 365 reúne los agentes de Microsoft, los de partners, los publicados por la organización y los compartidos por sus creadores. Señala los que se quedan sin propietario cuando se elimina a su creador y los gestionados fuera de Agent 365, y permite bloquearlos, eliminarlos o reasignarlos (registro de agentes). Las señales de riesgo de cada agente requieren licencia de Microsoft 365 E7 o de Agent 365.

Microsoft Agent 365 está disponible desde el 1 de mayo de 2026 para el segmento comercial, con licencia por usuario, y Microsoft lo presenta como el plano de control para observar, gobernar y proteger agentes (Agent 365). Aporta un inventario unificado con telemetría, identidades de Entra para los agentes, integración con Purview para auditoría y protección de datos, y con Defender para detección. Microsoft indica que funciona mejor sobre E5. Para quien no tiene E5, el punto de partida sigue siendo el registro de agentes y las consolas que ya tiene.

Del desarrollo a la retirada

Cada agente debería tener una ficha mínima, revisable en cada paso:

Responsable

Persona y área que responden del agente.

Finalidad

Para qué existe y quién lo usa.

Datos

Fuentes de conocimiento y su etiqueta más alta.

Conectores y acciones

Qué lee, qué escribe y con qué credenciales.

Políticas

Entorno, zona, directivas de datos y DLP que le aplican.

Pruebas

Qué se probó antes de publicar, incluidos intentos de inyección de prompts.

Aprobación

Quién la dio y cuándo.

Revisión o caducidad

Fecha en la que se revisa o se retira.

Con la gestión del ciclo de vida de aplicaciones (ALM) de Power Platform, los cambios pasan por soluciones y canalizaciones entre desarrollo, prueba y producción; Copilot Studio permite además control de código fuente con GitHub y despliegues con historial auditable (seguridad y gobierno de Copilot Studio). Si nadie en la organización es responsable de esta ficha, el gobierno de agentes acaba siendo de nadie; cuando no hay equipo propio, es una tarea que encaja con un CISO as a Service. Para el marco general de gobierno de la IA, ISO/IEC 42001 y una política de IA dan la estructura.

Zonas: no todos los agentes merecen el mismo control

Microsoft propone gobernar Copilot Studio por zonas según quién construye: desarrollo ciudadano, desarrollo acompañado y desarrollo profesional (gobierno por zonas). Yo prefiero ordenarlas por lo que el agente toca, es decir, datos y acciones. La siguiente es una propuesta de ACBSEC, inspirada en la de Microsoft pero distinta de su clasificación oficial.

La formación de quienes crean agentes forma parte del control. El artículo 4 del Reglamento de IA exige además medidas de alfabetización proporcionadas al uso que cada persona hace de la IA.

Matriz: qué permitir según el dato y el uso

Esta matriz es un ejemplo para adaptar. Cruza el tipo de dato con cuatro formas de uso, y cada organización debería rellenar la suya con negocio, seguridad y cumplimiento.

Agentes autónomos: cuando nadie escribe el prompt

Un agente reactivo espera a que alguien le escriba. Un agente autónomo actúa cuando ocurre algo: llega un correo, se crea un archivo en SharePoint, cambia un registro en Dataverse o pasa una hora. Con ese cambio de modelo cambia también el riesgo.

Microsoft lo advierte en su documentación: si un agente publicado tiene triggers autenticados, sus usuarios podrían acceder a información o provocar acciones con las credenciales del creador. Además, la carga del trigger puede contener datos sensibles que el agente acabe escribiendo en otro sitio; el ejemplo de Microsoft es un agente que usa correos entrantes para crear filas en Dataverse (triggers de eventos).

Antes de aprobar un agente autónomo haría cinco preguntas:

• ¿Qué evento lo dispara, y quién puede provocarlo desde fuera?
• ¿Qué datos llegan en la carga del trigger y cuáles consulta después?
• ¿Qué acción ejecuta y con qué credenciales?
• ¿Qué límites tiene en frecuencia, volumen y destinos?
• ¿Qué pasa si la entrada es incorrecta o maliciosa, por ejemplo un correo con instrucciones ocultas?

Las directivas de datos permiten bloquear los triggers con el conector Microsoft Copilot Studio, y en mi propuesta de zonas los agentes autónomos solo existen en la zona 3. En Cowork, las tareas basadas en eventos preparan por defecto las acciones para que el usuario las apruebe, y cada tarea se ejecuta con sus permisos (preguntas frecuentes de Cowork).

Un caso de exfiltración: dónde se puede cortar el flujo

Un documento confidencial, un agente con conocimiento en SharePoint, un conector hacia un servicio externo y un SaaS de terceros. El agente resume el documento y envía el resumen al SaaS para preparar una propuesta. Nadie ha actuado de mala fe, y aun así la información ha salido.

Ninguno de los ocho cortes basta solo. Los permisos fallan cuando alguien comparte de más, DLP no ve lo que no está etiquetado y las directivas de datos no saben qué contiene el documento. La protección sale de combinarlos.

DLP para Copilot en 7 niveles

Así combinaría las capas en un proyecto. Cada nivel se apoya en el anterior: sin inventario no se puede clasificar con criterio, y sin permisos saneados las políticas DLP tapan síntomas. Es el método de trabajo de ACBSEC y no forma parte de la documentación de Microsoft.

Caso práctico: una empresa de 600 personas

Diez controles que revisaría antes de desplegar

Prioridad 1: antes de ampliar Copilot o de publicar más agentes. Prioridad 2: durante el despliegue. Es un orden de trabajo orientativo.

Errores que evitaría

• Empezar creando reglas DLP sin clasificar datos. Sin taxonomía, las reglas bloquean de más o no protegen nada concreto.
• Asumir que Copilot ignora los permisos. Los respeta, y por eso hereda la sobreexposición; el trabajo está en los permisos.
• Confiar solo en Secure Score. Ayuda a priorizar, pero no dice qué datos ven Copilot y los agentes, como explico en la guía de auditoría de Microsoft 365.
• Etiquetar todo como confidencial. Si todo es confidencial, la etiqueta deja de informar y las excepciones se disparan.
• Bloquear todos los conectores. Quienes crean agentes buscan rodeos; funciona mejor una lista aprobada por zona.
• Permitir HTTP sin control. Es la forma más directa de enviar datos a cualquier endpoint.
• No diferenciar desarrollo, prueba y producción. Los experimentos acaban con datos reales y los cambios llegan sin revisar.
• Olvidarse de los agentes antiguos. Sus creadores se van y los agentes siguen compartidos.
• Monitorizar a las personas y no a los agentes. Muchas acciones las ejecutan agentes con su propia identidad o con la del creador.
• Comprar licencias antes de definir la política. Primero qué proteger y dónde; después, qué capacidad falta.

Licencias: qué pide cada capacidad

Esta tabla resume lo que Microsoft documenta a 5 de octubre de 2026. Los planes cambian a menudo, así que comprueba siempre los Product Terms y la documentación vigente antes de decidir. Para el resto de Purview tienes la guía de licencias de Purview y el simulador de licencias.

Preguntas frecuentes

¿Microsoft Copilot respeta los permisos de Microsoft 365?

Sí. Microsoft 365 Copilot solo muestra datos de la organización sobre los que el usuario tiene al menos permiso de lectura, y cada consulta se ejecuta en el contexto de seguridad de quien escribe el prompt. Eso incluye los permisos concedidos a personas externas, por ejemplo en canales compartidos de Teams. La consecuencia práctica es que Copilot hereda también los permisos excesivos: si un sitio de SharePoint está abierto a toda la organización, cualquiera puede obtener su contenido preguntando. Por eso la revisión de permisos y enlaces va antes que cualquier política DLP. Con los agentes hay que comprobar además qué credenciales usan sus herramientas, porque algunas pueden actuar con las de su creador.

¿Qué es DLP para Microsoft 365 Copilot?

Es una ubicación de Microsoft Purview Data Loss Prevention, llamada «Microsoft 365 Copilot and Copilot Chat», que aplica políticas a la interacción con el asistente. Permite impedir que Copilot use archivos y correos con determinadas etiquetas de confidencialidad, que procese prompts con tipos de información confidencial o que los envíe a la búsqueda web y, en preview, que use correos de remitentes externos. Solo existe en la plantilla de política personalizada y no se combina con otras ubicaciones en la misma política. No sustituye a la revisión de permisos ni gobierna los conectores de los agentes de Copilot Studio, que dependen de las directivas de datos de Power Platform.

¿Se puede impedir que Copilot use información sensible?

Sí, combinando varias medidas. Las políticas DLP de la ubicación de Copilot excluyen de las respuestas el contenido con las etiquetas elegidas, aunque el elemento puede seguir apareciendo en las citas. Las etiquetas que cifran exigen los derechos VIEW y EXTRACT para que Copilot resuma; con solo VIEW, el asistente enlaza el documento pero no lo resume. El contenido con Double Key Encryption no es accesible para Copilot. Mientras se revisan los permisos, Restricted Content Discovery saca sitios concretos de SharePoint de las respuestas. Ninguna de estas medidas retira el acceso directo de quien ya podía abrir el documento; eso se corrige en los permisos.

¿Cómo funciona Purview DLP con Copilot cuando una política coincide?

Depende de la condición. Si el elemento tiene una etiqueta incluida en la política, Copilot no usa su contenido para responder y, en Word, Excel o PowerPoint, desactiva sus funciones sobre ese archivo. Si el prompt contiene tipos de información confidencial y la acción es procesar prompts, Copilot no responde ni usa el prompt para buscar. Con la acción de búsquedas web, responde con datos internos pero sin consultar la web. Los cambios en la política tardan hasta cuatro horas en aplicarse y los archivos adjuntos al prompt no se analizan. El modo simulación permite medir el impacto antes de bloquear.

¿Copilot Studio utiliza DLP?

Utiliza dos mecanismos distintos. Las directivas de datos de Power Platform, que antes se llamaban directivas DLP, se aplican a todos los agentes de Copilot Studio desde principios de 2025 y ya no admiten exenciones: deciden qué conectores, fuentes de conocimiento, canales, HTTP, skills y triggers puede usar un agente. Además, Purview DLP en la ubicación de Copilot puede impedir que un agente procese contenido con una etiqueta concreta cuando su conocimiento está en SharePoint y se publica en Teams, SharePoint o Microsoft 365 Copilot. Para los agentes publicados en canales que no son de Microsoft, Purview necesita facturación por uso.

¿Cuál es la diferencia entre Purview DLP y las directivas de datos de Power Platform?

Purview DLP mira el contenido: etiquetas, tipos de información confidencial en el prompt o el remitente de un correo, y decide si Copilot puede usarlo. Las directivas de datos de Power Platform miran la configuración del agente: qué conectores, fuentes, canales, HTTP o triggers puede usar, y bloquean la publicación o la ejecución si incumple. La primera se configura en el portal de Purview y suele administrarla seguridad o cumplimiento; la segunda, en el centro de administración de Power Platform. Una organización con Copilot y Copilot Studio necesita las dos, porque ninguna cubre lo que hace la otra.

¿Cómo se protegen los agentes de Copilot Studio y se evitan fugas de datos?

Con controles en varias capas: entornos separados por zona de riesgo, directivas de datos que limitan conectores, HTTP, canales y triggers, fuentes de conocimiento con permisos saneados y etiquetadas, credenciales del usuario en lugar de las del creador y confirmación antes de las acciones de escritura. Para el contenido etiquetado, Purview DLP puede impedir que el agente lo procese si su conocimiento está en SharePoint. A todo ello se suman la auditoría de las acciones de los creadores y de las interacciones, y una revisión periódica de cada agente con su responsable. Con Agent 365 se añaden Conditional Access para agentes y la protección en tiempo real de Defender.

¿Qué papel tienen las etiquetas de confidencialidad en Copilot?

Tres. Informan al usuario: Copilot Chat muestra la etiqueta de mayor prioridad entre las fuentes usadas, y Copilot en Word, PowerPoint y Outlook hereda la etiqueta del origen al crear contenido nuevo. Condicionan el acceso cuando cifran: sin los derechos VIEW y EXTRACT, Copilot no resume el documento. Y sirven como condición en las políticas DLP de la ubicación de Copilot. Para que funcionen con archivos cifrados almacenados hay que activar las etiquetas en SharePoint y OneDrive. Una etiqueta sin cifrado ni política DLP asociada informa, pero no impide que Copilot use el contenido.

¿Puede Copilot leer archivos cifrados?

Sí, si el usuario que pregunta tiene los derechos VIEW y EXTRACT sobre el archivo y el cifrado procede del servicio Azure Rights Management, con etiqueta o sin ella. Con VIEW pero sin EXTRACT, Copilot puede enlazar el documento, pero no resumir su contenido. El contenido protegido con Double Key Encryption no es accesible para Copilot. Los correos con S/MIME no se devuelven y los documentos protegidos con contraseña solo se usan si el usuario ya los tiene abiertos. El cifrado con Customer Key o con clave propia (BYOK) sí es compatible. En los agentes de Copilot Studio, el cifrado solo se admite mediante etiquetas y con SharePoint como fuente.

¿Cómo se controlan los conectores en Copilot Studio?

Desde las directivas de datos del centro de administración de Power Platform. Cada conector se clasifica como Business, Non-business o Blocked, y un agente no puede combinar conectores de grupos distintos. Los conectores personalizados se clasifican por patrones de URL del host, y conviene revisar la regla comodín, que en las directivas nuevas viene como «Ignore». Para HTTP, sitios públicos y SharePoint como conocimiento existe el filtrado de endpoints, en preview. Las directivas avanzadas de conectores permiten un modelo de lista de permitidos por entorno, con bloqueo por servidor MCP, aunque todavía no cubren conectores personalizados ni HTTP.

¿Cómo se protegen los agentes que utilizan MCP?

Primero hay que saber por qué vía llega el MCP. En Copilot Studio, un servidor MCP entra como conector de Power Platform, así que lo gobiernan las directivas de datos, y bloquear ese conector bloquea sus herramientas. Los conectores federados de Microsoft 365 Copilot usan MCP con la identidad del usuario y se gestionan en el centro de administración de Microsoft 365. Los servidores registrados en Agent 365 se aprueban o bloquean en la página Tools. En todos los casos conviene preferir OAuth a las claves de API, porque con una clave el acceso no pasa por Entra ni por Conditional Access, y limitar qué herramientas de escritura se exponen.

¿Qué registros genera Microsoft Copilot?

Cada interacción genera un registro CopilotInteraction en Purview Audit (Standard), sin configuración adicional si la auditoría está activa. El registro incluye quién, cuándo y dónde, los recursos consultados con su etiqueta, las políticas que bloquearon o restringieron el acceso, el agente implicado y si se detectaron intentos de jailbreak o inyección indirecta de prompts. No incluye el texto: prompts y respuestas se guardan en el buzón del usuario y se consultan con DSPM o eDiscovery. También se auditan las acciones de administración de Copilot y las de los creadores en Copilot Studio. Audit (Premium) amplía la retención.

¿Cómo se auditan los agentes de Microsoft?

Combinando fuentes. Purview Audit registra las interacciones con agentes, con su identificador, nombre y versión, y en Copilot Studio también la creación, la publicación, la compartición y los cambios de autenticación. Los agentes con Entra Agent ID dejan su autenticación en los registros de Entra. En Agent 365, las instancias de agente se auditan como usuarios, incluidas sus interacciones con herramientas y con otros agentes. DSPM muestra en su página de observabilidad de IA los agentes con actividad y los de alto riesgo, y Defender añade la búsqueda avanzada y las alertas en tiempo de ejecución, que desde julio de 2026 requieren Agent 365.

¿Qué papel tiene Microsoft Agent 365?

Microsoft lo presenta como el plano de control para observar, gobernar y proteger agentes, propios y de terceros. Está disponible desde el 1 de mayo de 2026 con licencia por usuario y se incluye en Microsoft 365 E7. Aporta un registro unificado con telemetría, identidades de Microsoft Entra para los agentes con Conditional Access y protección de identidad, integración con Purview para auditoría y protección de datos, e integración con Defender para detección y protección en tiempo real. Los agentes de Copilot Studio se integran automáticamente. Trabaja junto a las directivas de datos y a Purview DLP, que siguen siendo necesarias.

¿Qué licencia necesito para DLP en Copilot?

Depende de la capacidad. Impedir que Copilot procese archivos y correos con determinadas etiquetas requiere Microsoft 365 E5, Office 365 E5, Microsoft Purview Suite o Microsoft 365 E5 Information Protection and Governance; no está en Business Premium ni en Microsoft 365 E3. La protección de prompts con tipos de información confidencial está disponible para todos los usuarios de Microsoft Copilot y Copilot Chat. Las directivas de datos de Copilot Studio se administran en Power Platform. Para las identidades y la seguridad de agentes en Entra y Defender hace falta Agent 365. Comprueba siempre los Product Terms vigentes.

Qué haría esta semana

1. Comprobar si la política por defecto de DLP para Copilot está en simulación y qué ha registrado.
2. Exportar el registro de agentes y localizar los que no tienen propietario.
3. Confirmar que la auditoría está activa y buscar registros CopilotInteraction de la última semana.
4. Lanzar una evaluación de sobreexposición en DSPM o los informes de acceso de SharePoint Advanced Management.
5. Comprobar si las etiquetas están activadas en SharePoint y OneDrive.
6. Revisar qué entornos de Power Platform permiten HTTP, chat sin autenticación y conectores personalizados sin clasificar.
7. Revisar qué conectores federados están activados en el tenant.

Con esas respuestas ya se puede decidir dónde tiene sentido la primera política DLP. Si quieres hacerlo acompañado, el servicio de Data Loss Prevention parte de ese diagnóstico y el de seguridad en el entorno Microsoft lo conecta con la identidad y las licencias. Si el foco es el gobierno de la IA en su conjunto, la consultoría de ciberseguridad en IA cubre también el Reglamento de IA.