Microsoft Copilot leyó tus correos confidenciales durante semanas. Qué falló y cómo solucionarlo.

Durante semanas, Microsoft 365 Copilot estuvo leyendo, resumiendo y mostrando correos electrónicos que las organizaciones habían marcado explícitamente como confidenciales. Informes legales. Acuerdos comerciales. Correspondencia gubernamental. Información de salud protegida. Todo procesado por una IA que nunca debió acceder a esos datos.

Puntos clave

1. Los controles de IA a nivel de aplicación son un único punto de fallo. Las etiquetas de sensibilidad y las políticas de Prevención de Pérdida de Datos (DLP) de Microsoft residían en la misma plataforma que Copilot. Cuando ocurrió un error de código, todos los controles fallaron al mismo tiempo. Las organizaciones no tenían una capa de defensa independiente para evitar que la IA procesara contenido confidencial, incluidos comunicaciones legales, acuerdos comerciales e información de salud protegida.
2. Las organizaciones no tenían ninguna visibilidad independiente sobre lo que Copilot accedía. Del 21 de enero a principios de febrero de 2026, Copilot leyó y resumió correos confidenciales sin activar ninguna alerta independiente. Las organizaciones se enteraron de la filtración cuando Microsoft la reveló, semanas después. Sin registros de auditoría independientes, los equipos de seguridad no tenían visibilidad sobre el procesamiento no autorizado de IA dentro de sus propios entornos.
3. La respuesta de Microsoft no abordó la verdadera cuestión de cumplimiento. Microsoft afirmó que los usuarios solo accedieron a información para la que ya estaban autorizados. Pero la cuestión de cumplimiento no es si el usuario tenía permisos, sino si la IA estaba autorizada para ingerir, procesar y resumir contenido confidencial. Bajo HIPAA, GDPR y la Ley de IA de la UE, esa distinción es fundamental.
4. La defensa en profundidad para la gobernanza de IA ya no es opcional. Este incidente valida lo que los arquitectos de seguridad llevan tiempo defendiendo: la gobernanza de IA requiere controles independientes y centrados en los datos que operen por separado de la plataforma de IA. La arquitectura de confianza cero, el purpose binding y el acceso de IA con privilegios mínimos no son aspiracionales, son necesidades operativas. Kiteworks ofrece esta capa de gobernanza independiente, asegurando que cuando los controles del proveedor fallan, las defensas a nivel de datos permanecen intactas.
5. La exposición regulatoria es real y sigue sin resolverse. Si Copilot procesó correos con PHI, PII u otros datos regulados, las organizaciones podrían enfrentar obligaciones de notificación de filtraciones bajo HIPAA, el Artículo 33 del GDPR y leyes estatales de filtración de datos. Microsoft no ha revelado cuántas organizaciones se vieron afectadas, dejando a los equipos de cumplimiento evaluando la exposición con información incompleta.

El error—identificado como CW1226324—fue reportado por clientes el 21 de enero de 2026. Microsoft comenzó a implementar una solución a principios de febrero, pero a mediados de febrero la remediación aún no estaba completa en todos los tenants afectados. El Servicio Nacional de Salud del Reino Unido detectó el problema internamente. Microsoft no ha revelado cuántas organizaciones estuvieron dentro del alcance del incidente.

Aquí está la parte que debería detener a cualquier responsable de seguridad: las etiquetas de sensibilidad estaban activas. Las políticas de DLP estaban correctamente configuradas. Todo estaba en regla. Y nada de eso importó.

No fue una mala configuración. No fue un error de administrador. Fue un bug en el código de la plataforma—y derribó todas las protecciones que debían mantener a la IA alejada de los datos confidenciales. No es un caso de «parchear y seguir». Es un problema fundamental de arquitectura.

¿Qué ocurrió realmente?

Un error de código en la función «pestaña de trabajo» de Copilot Chat permitió a la IA extraer correos de las carpetas Elementos enviados y Borradores de los usuarios, incluso cuando esos correos tenían etiquetas de confidencialidad y reglas DLP configuradas explícitamente para bloquear el procesamiento por IA. Las etiquetas decían «no tocar». Copilot las ignoró.

Microsoft confirmó el problema en un aviso de servicio, indicando que los correos con etiqueta de confidencialidad estaban siendo «procesados incorrectamente» por Microsoft 365 Copilot Chat. La compañía atribuyó la causa a un problema de código y comenzó a implementar una solución del lado del servidor a principios de febrero.

La respuesta pública de Microsoft fue cuidadosamente redactada: los usuarios solo accedieron a información para la que ya estaban autorizados. Técnicamente, eso es defendible—Copilot opera dentro del contexto del buzón del usuario. Pero elude por completo la verdadera cuestión.

La cuestión nunca fue si el usuario tenía permisos. La cuestión es si la IA estaba autorizada para ingerir, procesar y resumir contenido confidencial. Las etiquetas de sensibilidad y las políticas DLP existían por una sola razón: evitar que eso ocurriera. Cuando esos controles fallaron, los datos confidenciales fueron procesados por un sistema de IA de una forma que la organización había prohibido explícitamente. Esa es la filtración relevante para efectos de cumplimiento.

El problema de arquitectura del que nadie quiere hablar

No es una historia sobre un bug. Los bugs ocurren. El código se publica con errores. Se lanzan parches. Así es el ciclo de vida.

La verdadera historia es estructural. Todos los controles de seguridad que debían evitar el procesamiento no autorizado por IA—etiquetas de sensibilidad, DLP, restricciones de acceso—residían en la misma plataforma que la propia IA. Cuando la plataforma falló, todo falló. Sin segunda capa. Sin verificación independiente. Sin respaldo.

Piénsalo así: imagina un banco donde la puerta de la bóveda, la alarma y las cámaras de seguridad dependen del mismo interruptor. Si ese cable se cae, tienes la bóveda abierta, sin alarma y sin grabaciones. Eso es lo que ocurrió aquí.

No es una categoría de riesgo teórica. El Global Cybersecurity Outlook 2026 del Foro Económico Mundial encontró que las filtraciones de datos a través de IA generativa son ahora la principal preocupación de ciberseguridad entre CEOs a nivel mundial, citada por el 30% de los encuestados. Entre profesionales de ciberseguridad en general, la preocupación subió del 21% en 2024 al 34% en 2026. Mientras tanto, cerca de un tercio de las organizaciones aún no tiene procesos para validar la seguridad de la IA antes de su implementación.

El incidente de Copilot es la manifestación de esa brecha cuando llega a producción.

Por qué «Confiar pero verificar» falla cuando el verificador también es el proveedor

Microsoft es al mismo tiempo el proveedor de IA, el proveedor de controles de seguridad y la entidad responsable de auditar si esos controles funcionan. Cuando los controles fallaron, las organizaciones no tenían forma independiente de saberlo. Se enteraron cuando Microsoft se los comunicó—semanas después de que comenzara.

No hubo registro de auditoría independiente que capturara el acceso de Copilot a contenido confidencial. Ninguna detección de anomalías identificó patrones inusuales de procesamiento. Ninguna alerta en tiempo real se activó cuando la IA empezó a resumir correos que nunca había estado autorizada a tocar. La única señal fue un aviso de servicio, publicado después del hecho.

Esta es la brecha de gobernanza que Kiteworks está diseñado para cerrar. El argumento—y el bug de Copilot lo hace difícil de refutar—es que los controles de gobernanza de IA deben operar en una capa separada de la plataforma de IA. No como una opción de política dentro del mismo ecosistema. Como un plano de control independiente.

Así es como se ve en la práctica:

Capa independiente de gobernanza de datos. Kiteworks opera como un plano de control separado. Las plataformas de IA acceden a los datos a través de las API de Kiteworks con políticas aplicadas—no mediante acceso directo a los repositorios de correo o sistemas de archivos. Incluso si una plataforma de IA tiene un bug, no puede eludir controles que no administra.

Purpose binding y acceso de privilegio mínimo. Restringe el acceso de la IA a clasificaciones y usos específicos de datos. En vez de dar a Copilot acceso a todo el buzón, el purpose binding permite a las organizaciones especificar que la IA puede acceder a correos generales de negocio pero no a correos etiquetados como confidenciales, PHI o CUI. Cada solicitud se evalúa frente a las políticas vigentes—no es «autentícate una vez y accede a todo para siempre».

Detección de anomalías y monitoreo en tiempo real. Kiteworks identifica cuando los agentes de IA muestran patrones inusuales de acceso a datos. Si un sistema de IA comienza a procesar grandes volúmenes de contenido confidencial, las alertas automáticas llegan al equipo de seguridad en tiempo real—no semanas después a través de un aviso de servicio.

Registros de auditoría inmutables e independientes. Registros integrales que documentan qué datos accedió la IA, cuándo, bajo qué autorización y qué acciones realizó. Estos registros los controla la organización—no el proveedor de IA. Cuando un regulador pregunta qué ocurrió, la organización tiene su propia evidencia, independiente de la versión del proveedor.

La exposición de cumplimiento que las organizaciones deben evaluar ahora

Las implicaciones regulatorias del bug de Copilot van más allá de la solución técnica. Si Copilot procesó correos con información de salud protegida, datos personales u otro contenido regulado, las organizaciones pueden enfrentar obligaciones de cumplimiento que aún no han considerado.

HIPAA. Bajo § 164.308(b)(1), las entidades cubiertas deben tener contratos escritos con asociados comerciales que establezcan los usos y divulgaciones permitidos de PHI. Si Copilot procesó PHI marcada como confidencial de formas no cubiertas por el acuerdo existente, las organizaciones deben evaluar si esto constituye una filtración notificable. La afirmación de Microsoft de que los usuarios estaban autorizados para ver los datos no responde a si la IA estaba autorizada para procesarlos—una distinción que los reguladores de HIPAA examinarán cuidadosamente.

GDPR. El Artículo 32 exige «medidas técnicas y organizativas apropiadas» para garantizar la seguridad del procesamiento de datos personales. Las organizaciones que confiaron únicamente en las etiquetas de sensibilidad de Microsoft como salvaguarda técnica tienen un argumento difícil cuando esas salvaguardas fallaron durante semanas. El Artículo 33 exige notificar a las autoridades de control en un plazo de 72 horas tras tener conocimiento de una filtración de datos personales. Si los correos confidenciales contenían datos personales de la UE, ese plazo ya podría haber comenzado.

Ley de IA de la UE. El Artículo 12 exige que los sistemas de IA de alto riesgo mantengan registros detallados de sus operaciones. Las organizaciones que usan Copilot para procesar datos sensibles pueden estar clasificadas bajo las disposiciones de alto riesgo. Si sus únicos registros operativos provienen de los logs de Microsoft—el mismo proveedor que tuvo la falla—carecen de la documentación independiente que exige la regulación.

Leyes estatales de privacidad de datos. Varios estados de EE. UU. tienen requisitos de notificación activados por el acceso no autorizado a información personal. Si Copilot procesó correos confidenciales con información cubierta por estatutos estatales de notificación de filtraciones, las organizaciones pueden tener obligaciones que el aviso de servicio de Microsoft no resuelve.

Kiteworks responde directamente a estos requisitos de cumplimiento. Los registros de auditoría independientes proporcionan la evidencia que las organizaciones necesitan para evaluar la notificación de filtraciones. Los informes de cumplimiento exportables demuestran los controles de gobernanza de IA ante los reguladores. Los acuerdos de procesamiento de datos y los acuerdos de asociado comercial se aplican a nivel de datos—no solo mediante promesas contractuales que dependen de que los controles del proveedor funcionen correctamente.

Qué deben hacer las organizaciones ahora

Evalúa tu exposición. Determina si tu organización fue afectada por CW1226324. Revisa las alertas del centro de administración de Microsoft 365 y los logs de uso de Copilot desde el 21 de enero hasta la fecha en que tu tenant recibió la confirmación de remediación. Exporta los metadatos de cualquier correo confidencial en Elementos enviados y Borradores durante ese periodo. Si Microsoft no puede proporcionar logs de acceso que muestren lo que procesó Copilot, documenta formalmente esa brecha.

Evalúa las obligaciones de notificación de filtraciones. Si los correos confidenciales contenían PHI, PII u otros datos regulados, consulta con tu asesor legal sobre posibles obligaciones bajo HIPAA § 164.408, el Artículo 33 del GDPR o leyes estatales de notificación de filtraciones aplicables. No asumas que la caracterización del incidente por parte de Microsoft resuelve tus obligaciones de cumplimiento.

Implementa gobernanza de IA independiente. No confíes solo en los controles de la plataforma de IA para proteger los datos sensibles del procesamiento por IA. Implementa una capa independiente de gobernanza de datos—como Kiteworks—que haga cumplir las políticas de acceso sin importar los bugs del proveedor. El purpose binding, el acceso de privilegio mínimo y la verificación continua deben aplicarse a nivel de datos, no de aplicación.

Establece registros de auditoría independientes. Asegúrate de que tu organización cuente con logs de acceso a datos por IA que no estén únicamente bajo control del proveedor de IA. Kiteworks proporciona registros de auditoría inmutables que documentan cada interacción de la IA con los datos de la organización, dando a los equipos de seguridad y cumplimiento evidencia que no depende de los reportes del proveedor.

Revisa la arquitectura de acceso de IA. Evalúa si tus herramientas de IA tienen acceso amplio a los repositorios de datos o si el acceso está restringido por propósito y clasificación. El bug de Copilot afectó Elementos enviados y Borradores porque Copilot tenía acceso al contexto completo del buzón. El purpose binding y los controles de acceso basados en atributos habrían restringido el procesamiento solo a las clasificaciones autorizadas, incluso cuando los controles propios de la plataforma fallaron.

Exige transparencia a los proveedores. Solicita a Microsoft un informe post-incidente que detalle el alcance del impacto, los tenants afectados, la retención de datos para el contenido procesado por Copilot durante el incidente y el cronograma para la remediación completa. Si el proveedor no puede ofrecer esa transparencia, eso en sí mismo es una señal de gobernanza que debe influir en tus decisiones de arquitectura en el futuro.

La lección que la industria debe aprender

El bug de Microsoft Copilot no es un incidente aislado. Es un caso de estudio de lo que ocurre cuando las organizaciones confían en que las plataformas de IA se supervisen a sí mismas.

El Global Cybersecurity Outlook 2026 del WEF advirtió que, a medida que los agentes de IA se adopten más ampliamente, gestionar sus credenciales, permisos e interacciones será tan crítico—y probablemente más complejo—que gestionar los de los usuarios humanos. El informe pidió verificación continua, registros de auditoría y estructuras de rendición de cuentas robustas basadas en principios de confianza cero que traten cada interacción de IA como no confiable por defecto.

El bug de Copilot demuestra exactamente por qué. Las etiquetas de sensibilidad eran un mecanismo de confianza. Confiaban en que la plataforma las respetara. La plataforma no lo hizo—no por mala intención, sino por un error de código. Y sin una capa de gobernanza independiente, no había nada que detectara el fallo.

Kiteworks proporciona esa capa independiente. Su arquitectura de intercambio de datos de confianza cero exige que las plataformas de IA se autentiquen a través de Kiteworks para acceder a datos sensibles, con políticas aplicadas a nivel de datos—no de aplicación. El purpose binding restringe lo que la IA puede acceder. La verificación continua evalúa cada solicitud. Y los registros de auditoría integrales demuestran qué ocurrió, cuándo y bajo qué autorización.

Las organizaciones que navegarán la era de la IA sin convertirse en el próximo aviso de servicio son las que están construyendo gobernanza independiente ahora. No comités. No etiquetas. No promesas del proveedor. Infraestructura operativa que aplica políticas a nivel de datos—donde no puede ser eludida por un bug en la propia plataforma que debe gobernar.

Las etiquetas estaban activas. Las políticas configuradas. La IA leyó tus correos confidenciales de todos modos. Si eso no cambia tu perspectiva sobre la gobernanza de IA, ¿qué lo hará?