Seguridad Microsoft Copilot 365: riesgos y controles para empresas 2026

Microsoft Copilot 365 ha sido la mayor introducción de IA generativa en entornos corporativos de los últimos años. A diferencia de un chat aislado, vive dentro del tejido productivo de la organización: indexa SharePoint, OneDrive, Teams, Outlook y Exchange, y genera respuestas mediante un patrón RAG (Retrieval Augmented Generation) que combina el grafo de Microsoft con un modelo de lenguaje de gran tamaño. La superficie atacable y el riesgo de filtración crecen exactamente en la misma proporción.

Este artículo recorre cómo funciona Copilot 365 por dentro, por qué el data oversharing se ha convertido en su talón de Aquiles, qué supuso la vulnerabilidad EchoLeak, qué controles ofrece Microsoft de forma nativa y qué plan de despliegue minimiza el riesgo sin frenar el negocio. La conclusión adelantada: Copilot 365 no se debe desplegar sin una fase previa de gobernanza de SharePoint y políticas de etiquetado.

Lo esencial

• Copilot 365 respeta los permisos de Microsoft 365, pero amplifica enormemente el oversharing histórico de SharePoint y Teams al hacer descubrible mediante lenguaje natural lo que antes estaba enterrado.
• El vector prompt injection indirecta vía correos y documentos SharePoint es real y documentado. La vulnerabilidad EchoLeak, reportada por Aim Security en 2025 y mitigada por Microsoft, marcó el patrón.
• Microsoft Purview aporta los controles clave: DLP, Sensitivity Labels, Restricted SharePoint Search, audit logs y DSPM for AI. No se activan solos.
• El despliegue prudente exige una fase de higiene SharePoint de 60 a 90 días antes de habilitar licencias a la plantilla.
• El encaje regulatorio es claro: RGPD, NIS2 art 21, ISO 27001 A.5.23 y, si Copilot interviene en decisiones automatizadas, AI Act.

Cómo funciona Copilot 365 técnicamente

Copilot 365 se apoya en tres componentes que conviene entender porque cada uno introduce su propio riesgo.

El primero es Microsoft Graph: el grafo de objetos y relaciones del tenant (usuarios, archivos, correos, mensajes de Teams, sitios de SharePoint). Copilot pregunta al Graph qué información puede ver el usuario que ha lanzado la consulta. Aquí está la base del modelo de permisos.

El segundo es el Semantic Index, un índice vectorial que mapea el contenido del tenant en una representación semántica. Sin él, Copilot solo podría hacer búsquedas por palabra clave. Con él, responde a preguntas en lenguaje natural sobre documentos, correos y conversaciones, respetando los permisos de cada usuario.

El tercero es el modelo de lenguaje, históricamente basado en variantes grounded de GPT-4 turbo desplegadas dentro de la frontera de servicio de Azure OpenAI dedicada a Microsoft 365. La consulta del usuario, el contexto recuperado por Graph y Semantic Index y las instrucciones del sistema viajan al modelo, que devuelve una respuesta sintetizada con citas a los documentos fuente.

La promesa formal de Microsoft es que Copilot respeta el modelo de permisos de M365. Es cierto. El problema no es que enseñe lo que el usuario no debería ver. Es que enseña, perfectamente buscable y en una sola consulta, todo lo que el usuario técnicamente sí puede ver pero que nunca habría encontrado.

Riesgo principal: data oversharing

El data oversharing es, con diferencia, el riesgo número uno de Copilot 365 y la causa raíz del mayor número de incidentes reales.

SharePoint y Teams llevan más de una década acumulando deuda de permisos. La opción Anyone in the organization para compartir enlaces se utiliza por defecto en miles de organizaciones. Bibliotecas creadas para un proyecto puntual quedan abiertas a toda la empresa. Sitios de Teams heredan permisos amplios al añadir invitados. Antes de Copilot, todo ese material existía pero estaba enterrado bajo capas de navegación que nadie recorría, y la búsqueda nativa actuaba como un control de hecho.

Con Copilot esa fricción desaparece. Un empleado puede preguntar en lenguaje natural por la última revisión salarial, el plan de adquisiciones, las cláusulas del próximo contrato con un cliente clave o la valoración de una unidad de negocio antes de su venta. Si en algún rincón del tenant hay un documento al que ese usuario tiene acceso técnico, Copilot lo encontrará, lo resumirá y citará la fuente.

El usuario no está atacando nada. Usa la herramienta exactamente para lo que se ha diseñado. El control de seguridad falló mucho antes, cuando alguien marcó como Anyone in organization una biblioteca que debía ser privada. Copilot 365 actúa como un revelador implacable de toda la herencia de permisos mal mantenidos de un tenant. Casos documentados describen empleados accediendo de forma involuntaria a salarios, evaluaciones de desempeño, planes de despido o información de M&A en la primera semana de uso. En ninguno hubo brecha técnica. En todos, hubo fallo de gobernanza previa.

EchoLeak y prompt injection en Copilot

El segundo gran vector es la prompt injection indirecta. Un atacante deposita instrucciones maliciosas en una fuente que Copilot va a leer como parte de su contexto, por ejemplo el cuerpo de un correo, un documento en SharePoint o un mensaje en Teams. Cuando el usuario consulta a Copilot, el modelo procesa esas instrucciones como si fueran parte de la consulta legítima.

La vulnerabilidad EchoLeak, reportada en 2025 por Aim Security y mitigada por Microsoft mediante actualizaciones del servicio, ilustró el patrón en su forma más limpia. Un actor externo enviaba un correo construido al buzón de la víctima. Cuando esta interactuaba después con Copilot, el asistente leía el correo como parte de su contexto y ejecutaba las instrucciones embebidas, lo que conducía a exfiltración de información sensible hacia un endpoint controlado por el atacante.

Microsoft corrigió el bug concreto, pero el patrón es generalizable a cualquier asistente que combine recuperación de contexto, ejecución de herramientas y entrega de respuestas. La superficie crece con cada nueva integración: cuando Copilot lee no solo correos y documentos sino también páginas web, transcripciones de reuniones y datos de terceros vía Graph Connectors, cada fuente pasa a ser un canal potencial de inyección. La lección no es que Copilot sea inseguro, sino que todo asistente RAG corporativo necesita controles específicos contra prompt injection indirecta y logs que permitan reconstruir qué contexto se inyectó en qué respuesta.

Riesgos específicos de Copilot 365

Más allá del oversharing y la inyección, conviene tener un mapa explícito de los riesgos diferenciales.

• Data oversharing vía Semantic Index: el ya descrito. Riesgo principal en probabilidad e impacto.
• Indirect prompt injection: correos, documentos SharePoint, mensajes Teams o fuentes externas indexadas pueden contener instrucciones maliciosas que el modelo trate como legítimas.
• Output data exfiltration: Copilot puede ser inducido a verter información confidencial en una respuesta que el usuario luego copia o reenvía sin advertir su sensibilidad.
• Alucinaciones en decisiones críticas: el modelo puede inventar referencias normativas, cláusulas contractuales o cifras financieras con apariencia autorizada.
• Auditability gaps: los logs de Purview no siempre permiten reconstruir qué fragmento de qué documento se entregó al modelo en una respuesta concreta.
• Multi-tenant exposure en Copilot for Service partners: cuando un partner integra Copilot sobre datos de varios clientes, una mala segmentación abre cruce de información.
• GraphConnectors de terceros: extensiones que indexan Jira, Confluence, ServiceNow o repositorios de código heredan sus problemas de permisos y suman superficie de inyección y fuga.

Preparación pre deployment

La regla más importante: Copilot 365 no se despliega sin una fase previa de gobernanza. Activar licencias en un tenant con SharePoint mal mantenido es la receta de las brechas más sonadas que han llegado a prensa.

La fase previa tiene tres bloques. El primero es la higiene de SharePoint: identificar bibliotecas y sitios con permisos demasiado amplios (en particular Anyone in the organization), revisar herencias rotas, eliminar enlaces de acceso anónimo caducados, archivar contenido obsoleto y reagrupar sitios huérfanos. Microsoft ofrece SharePoint Advanced Management como complemento de pago con herramientas específicas para esta limpieza, incluida la posibilidad de Restricted Search durante la transición.

El segundo bloque es el etiquetado de sensibilidad: desplegar Sensitivity Labels de Purview, asegurar la aplicación por defecto a sitios, contenedores y archivos, configurar la herencia para que el contenido generado o adjuntado por Copilot mantenga la etiqueta de la fuente y definir qué contenido se considera confidencial, altamente confidencial y restringido.

El tercero son las políticas de retención. Sin retención coherente, el tenant acumula material caducado que Copilot puede traer a colación. Una organización mediana suele necesitar entre 60 y 90 días para esta fase. Acortarla es donde más cuesta la prisa.

Controles técnicos Microsoft nativos

Una vez ordenada la base, Microsoft ofrece un conjunto de controles nativos que se deben activar y operar de forma coordinada.

• Purview DLP orientado a Copilot: bloquea o avisa cuando el modelo intenta procesar o devolver contenido etiquetado como sensible, evitando que datos altamente confidenciales aparezcan en respuestas exportables.
• Sensitivity Labels con label inheritance: la etiqueta de la fuente se propaga al contenido generado por Copilot, manteniendo cifrado, marca de agua y restricciones de copia.
• Restricted SharePoint Search: limita el alcance del índice a una lista permitida de sitios durante la transición. Red de seguridad temporal muy útil en pilotos.
• Conditional Access Copilot aware: políticas de Entra ID que condicionan el acceso por ubicación, dispositivo gestionado, riesgo de sesión o cumplimiento del endpoint.
• Audit logs de Purview: traza qué usuario consultó qué documento mediante Copilot, qué etiquetas se aplicaron y si hubo interacciones con DLP.
• DSPM for AI: dentro de Purview, ofrece una vista específica del riesgo de IA en el tenant, identifica prompts y usuarios anómalos y prioriza políticas. Panel semanal para el CISO.

Activar estos controles no es opcional para un despliegue serio.

Plan de deployment paso a paso

Un plan razonable de despliegue de Copilot 365 se estructura en cinco fases.

Fase 1. Gobernanza y limpieza de SharePoint, 60 a 90 días. Inventario de sitios, identificación de oversharing, ejecución de campañas de revisión con propietarios de cada sitio, eliminación de accesos amplios innecesarios, archivado de contenido obsoleto, despliegue de SharePoint Advanced Management si procede. Sin esto, no se pasa a la siguiente fase.

Fase 2. Sensitivity Labels y DLP. Definición de la taxonomía de etiquetas, despliegue progresivo en bibliotecas y contenedores, configuración de etiquetado automático para los tipos de información más críticos (datos personales, datos financieros, propiedad intelectual), publicación de políticas DLP específicas para Copilot, configuración de la herencia de etiquetas hacia el contenido generado por el modelo.

Fase 3. Piloto controlado. Activación de Copilot para un grupo limitado, idealmente entre 30 y 80 usuarios, con perfiles variados de departamento y antigüedad. Restricted SharePoint Search activado. Monitorización intensiva mediante DSPM for AI y audit logs. Recopilación de casos reales de uso, incidencias, falsos positivos de DLP y necesidades de formación. Duración recomendada: cuatro a ocho semanas.

Fase 4. Rollout por fases con comunicaciones. Activación escalonada por departamentos. Cada ola va acompañada de formación específica para el equipo, guía de uso aceptable, advertencias sobre verificación de respuestas y canales claros para reportar incidentes. Mantenimiento de las políticas DLP afinadas tras el piloto.

Fase 5. Monitorización continua y revisión de gobernanza. Revisión trimestral del estado de oversharing, ajuste de políticas, revisión de logs y métricas de DSPM, gestión del ciclo de vida de Graph Connectors y revisión anual del marco con el comité de seguridad y la dirección.

Saltarse cualquier fase, especialmente la primera, es un atajo que se paga después. Las organizaciones que han desplegado Copilot sin esta secuencia han tenido que detener el rollout y volver atrás. Eso cuesta mucho más, en dinero y en reputación interna, que hacerlo bien desde el principio.

Encaje normativo

Copilot 365 toca de lleno varias normativas vigentes en la Unión Europea.

El RGPD aplica desde el primer día. Si el contenido indexado por Copilot incluye datos personales, lo cual ocurre en prácticamente cualquier tenant corporativo, hay que actualizar los registros de actividades de tratamiento, evaluar la necesidad de una evaluación de impacto y revisar el contrato de encargado con Microsoft. Cuando entran en juego datos especiales del artículo 9 (salud, religión, sindicales), la diligencia se eleva: estos datos no deberían ser accesibles por Copilot sin controles específicos.

NIS2 exige en su artículo 21 medidas de gestión de riesgos de ciberseguridad. La letra g menciona explícitamente las prácticas básicas de higiene cibernética. Desplegar Copilot sin gobernar SharePoint ni etiquetar contenido sensible es, de manera defendible, una carencia de higiene cibernética. Las entidades esenciales e importantes deben poder demostrar que han evaluado el riesgo y que han activado controles proporcionados.

ISO 27001 cubre el escenario en el control A.5.23, dedicado a la seguridad en el uso de servicios en la nube. Un auditor pedirá la evaluación de riesgos del servicio Copilot, la lista de controles aplicados, los registros de monitorización y la política de uso aceptable.

El AI Act europeo entra en juego cuando Copilot interviene en decisiones que pueden clasificarse como alto riesgo según el anexo III: recursos humanos, evaluación crediticia, acceso a servicios esenciales. En esos contextos, la organización pasa a ser deployer de un sistema de IA y asume obligaciones específicas de supervisión humana, registro y evaluación de impacto.

La buena noticia es que un programa serio de gobernanza de Copilot cubre los cuatro encajes a la vez. La mala es que improvisar no cubre ninguno.

Preguntas frecuentes

¿Copilot 365 ve mis datos personales como administrador del tenant?

Microsoft no accede al contenido del tenant para entrenar modelos ni lo comparte con OpenAI. El servicio se ejecuta dentro de la frontera de servicio de Microsoft 365 y los datos del cliente quedan dentro del tenant. El administrador del tenant, en cambio, sí puede revisar mediante audit logs qué interacciones ha tenido cada usuario con Copilot. Esa capacidad es la base de la monitorización legítima y debe estar contemplada en la política de privacidad interna.

¿Se puede entrenar el modelo con los datos de mi organización?

No de forma predeterminada. Copilot 365 utiliza el contenido del tenant únicamente para responder a la consulta del usuario en ese momento (RAG), no para reentrenar el modelo base. Las respuestas no se reutilizan para mejorar el modelo público de OpenAI ni de Microsoft. Esta separación es uno de los compromisos contractuales clave del servicio.

¿RGPD aplica si Copilot solo se usa internamente?

Sí. El RGPD aplica a cualquier tratamiento de datos personales con independencia del canal. Si Copilot accede a correos, calendarios o documentos que contienen datos personales de empleados, clientes o terceros, hay tratamiento. Y por tanto, obligaciones de información, base jurídica, contrato con el encargado y derechos del interesado.

¿Es obligatorio auditar antes de desplegar?

Obligatorio en sentido estricto no, pero es práctica recomendada y requisito implícito de NIS2, ISO 27001 y de cualquier marco de gestión de riesgos serio. Un despliegue sin auditoría previa de oversharing y sin políticas de etiquetado es, en la práctica, un incidente esperando a ocurrir.

¿Cuál es el coste real de la licencia?

La licencia oficial se cotiza alrededor de 30 dólares por usuario y mes en planes anuales, sujeta a variaciones por geografía y volumen. A ese coste hay que sumar SharePoint Advanced Management si se necesita y, sobre todo, el coste interno del proyecto de gobernanza: horas de arquitectos, administradores, propietarios de información y formación, que en organizaciones medianas puede igualar o superar al coste de licencia el primer año.

¿Qué alternativas hay si bloqueamos Copilot?

Bloquear Copilot 365 sin alternativa no es realista cuando los empleados ya usan ChatGPT, Gemini o Claude por su cuenta. Las alternativas razonables incluyen plataformas corporativas basadas en Azure OpenAI o Amazon Bedrock con datos confinados, asistentes especializados a medida, o esperar a un despliegue más maduro tras completar la gobernanza. La peor opción es prohibir sin sustituto, porque alimenta la shadow AI.

Recursos relacionados

• Seguridad de ChatGPT en empresas: riesgos, controles y políticas 2026
• OWASP Top 10 LLM explicado: las 10 vulnerabilidades de IA generativa
• Qué es prompt injection: ataques a LLMs
• Qué es DLP: prevención de fuga de datos
• Seguridad de agentes de IA autónomos: riesgos
• Auditoría NIS2 paso a paso

Audita tu despliegue de Copilot 365 con Secra

En Secra acompañamos a organizaciones que planifican o ya han iniciado el despliegue de Microsoft Copilot 365 con un servicio específico de pre deployment readiness assessment y post deployment hardening. La intervención cubre cuatro frentes: evaluación de oversharing en SharePoint, OneDrive y Teams; revisión del estado de Sensitivity Labels y políticas DLP orientadas a Copilot; evaluación del modelo de Conditional Access, audit logs y DSPM for AI; y diseño del plan de despliegue por fases alineado con RGPD, NIS2 y ISO 27001.

El objetivo: que Copilot 365 entregue valor al negocio sin convertirse en el canal de la próxima brecha. Contacta con nuestro equipo en Secra.