Cómo le explico Copilot al board sin tecnicismos

 

Esta es de las cosas que más he refinado el último año. Presentar Copilot al board, sin que se duerman ni se asusten. Cuesta más de lo que parece.

El error clásico, que cometí mis primeras dos veces: empezar por la tecnología. “Copilot es un sistema basado en LLMs que…”. Tres minutos después, el chair está mirando su teléfono. Cinco minutos después, el CFO pregunta qué tiene que ver esto con el budget.

El acercamiento que sí funciona: empezar por el riesgo de negocio.

Estructura que uso

Diapositiva 1. “Copilot está siendo usado por X% de nuestros empleados. En el último Q realizó N millones de operaciones”. Foto del estado, sin opinión. Datos.

Diapositiva 2. “El uso productivo está acelerando estos workflows: A, B, C. Estimamos un valor anualizado de Y”. Beneficio, en términos que el board entiende. Ahorro de tiempo, ingreso accelerado, costo evitado.

Diapositiva 3. “Los riesgos que estamos gestionando son tres: filtración de datos, decisiones automáticas mal supervisadas, dependencia operativa de proveedor”. Tres, no quince. Cada uno con un control primario y un KRI.

Diapositiva 4. “Estos controles tienen este performance en los últimos 6 meses”. Tendencia, con verde/amarillo/rojo. Sin números detallados.

Diapositiva 5. “Lo que vamos a hacer en los próximos 6 meses”. Tres iniciativas, con dueños y fechas.

Diapositiva 6. “Pregunta y respuesta”. Espacio para el board.

Total: 6 diapositivas. 12 minutos. Quedan 18 para Q&A.

Las preguntas reales del board

El board pregunta por dependencia. “¿Qué pasa si Microsoft tiene un outage de cuatro días?”. Es una pregunta legítima y hay que tener respuesta. La mía: BCP documentado, alternativas evaluadas, procesos críticos no enteramente dependientes de Copilot. El board duerme tranquilo si la respuesta es honesta.

El board pregunta por decisiones automáticas. “¿Tomamos decisiones que afectan a clientes con IA?”. La respuesta debe ser clara: dónde sí, dónde no, con qué supervisión. No alarmes, no minimices.

El board pregunta por reputación. “¿Qué pasa si Copilot dice algo público que nos dañe?”. Tiene que haber plan: detección, respuesta, comunicación. Un incidente reputacional sin plan es noticia.

Lo que evito decir

Jerga. “Prompt injection” no es palabra para el board. “Manipulación maliciosa de instrucciones a la IA” sí.

Falsa certeza. “Estamos completamente protegidos” miente. “Tenemos defensa en profundidad y los riesgos identificados están bajo control compensatorio” es honesto.

Detalles técnicos que no pidieron. Si me piden detalle técnico, lo doy. Pero no lo regalo sin pedir.

¿Funciona? La medida que uso: ¿el board hace mejores preguntas la siguiente vez? Si sí, está funcionando. Si la pregunta es la misma de hace seis meses, no entendieron. Hay que cambiar la presentación.

Mi métrica favorita: las preguntas del board sobre Copilot pasaron de “¿qué es esto?” hace 18 meses a “¿cómo evolucionamos nuestra postura ante el EU AI Act?” en la última. Esa es la curva de madurez del board, y es lo que más vale el ejercicio.

claves tecnológicas de 2026

 El nuevo informe de Gartner sobre las principales tendencias tecnológicas para 2026 confirma lo que muchas empresas ya intuían: la inteligencia artificial será el eje de transformación, pero también el principal desafío en términos de seguridad, gobernanza y ética. Desde plataformas de supercomputación para IA hasta sistemas multiagente y estrategias de ciberseguridad proactiva, el futuro exige una mirada integral y responsable.

Entre las tendencias destacadas se encuentran:

• AI Supercomputing Platforms: arquitecturas híbridas que combinan CPU, GPU y chips neuromórficos para procesar cargas masivas de IA.
• AI-Native Development Platforms: entornos de desarrollo donde agentes de IA colaboran con humanos para crear software en tiempos récord.
• Multi-Agent Systems (MAS) y Domain-Specific Language Models (DSLMs): modelos que cooperan entre sí y entienden el contexto del negocio para resolver problemas complejos.
• AI Security Platforms: soluciones que centralizan el control sobre modelos, datos y prompts, anticipando amenazas antes de que ocurran.
• Geopatriación de datos: migración hacia nubes soberanas para reducir riesgos políticos y regulatorios.

El Cambio de Paradigma en 2026 

El análisis de Cloud Legion identifica tres pilares donde la innovación y la responsabilidad convergen:

1. De la IA “Añadida” a la IA “Nativa”: Ya no basta con integrar herramientas de IA en procesos viejos. Las AI-Native Development Platforms implican que el software se diseñará pensando en que agentes autónomos lo operen y aseguren. Cloud Legion observa que esto reduce el “time-to-market”, pero aumenta la superficie de ataque si no hay una gobernanza clara sobre el código generado por máquinas.
2. La Crisis de la Verdad (Deepfakes y Procedencia): La saturación de contenidos sintéticos hará que la “confianza” sea el activo más caro. Cloud Legion analiza que las empresas deberán implementar sistemas de atestación digital para demostrar que sus datos y comunicaciones son legítimos, protegiendo así su reputación de marca.
3. Soberanía Tecnológica (Geopatriación): Ante la fragmentación geopolítica, el análisis sugiere que las empresas deben ser capaces de mover sus cargas de IA entre nubes soberanas rápidamente para evitar bloqueos regulatorios o riesgos de espionaje industrial.

“Las empresas ya no pueden limitarse a reaccionar ante los ataques. La ciberseguridad de 2026 será predictiva, contextual y colaborativa. En Cloud Legion estamos desarrollando soluciones que integran IA defensiva, monitoreo continuo y resiliencia en la nube para acompañar esta evolución”, afirmó Luciano Moreira da Cruz, Chief Transformation & Strategy Office (CTSO) de Cloud Legion.

El reporte también advierte sobre la necesidad de verificar la procedencia digital de los contenidos generados por IA, en un entorno saturado de deepfakes y código automatizado. La confianza será un activo estratégico.

Cloud Legion recomienda a las organizaciones: (una hoja de ruta dividida en tres niveles de urgencia)

Nivel Operativo: Blindaje de la IA (Capa de Seguridad)

• Implementar AI Security Platforms (AISPs): No trate a la seguridad de la IA como seguridad IT tradicional. Necesita herramientas que monitoreen el drift (desviación) de los modelos, eviten el “Prompt Injection” y aseguren que los datos de entrenamiento no sean contaminados.
• Inventario de Agentes: Documentar qué sistemas multiagente (MAS) están operando en la empresa y bajo qué permisos, para evitar “acciones en cascada” no autorizadas entre modelos.

Nivel Táctico: Evolución de la Infraestructura

• Prepararse para la Supercomputación Híbrida: Evaluar proveedores que ofrezcan chips neuromórficos o arquitecturas GPU escalables para no quedar rezagados en capacidad de procesamiento frente a la competencia.
• Estrategia de Datos “Limpia”: Antes de adoptar modelos de lenguaje específicos de dominio (DSLMs), asegúrese de que sus datos internos estén curados y etiquetados. La IA es tan buena como la calidad de su contexto.

Nivel Estratégico: Cultura y Gobernanza

• Comités de Ética Operativos: Crear células de decisión integradas por expertos en legal, ciberseguridad y negocio para validar cada nuevo despliegue de IA desde el diseño (Security & Ethics by Design).
• Capacitación en “Humano-en-el-Bucle” (HITL): Entrenar al personal no para que vigile a la IA, sino para que colabore con ella, manteniendo siempre la capacidad humana de intervenir y corregir decisiones automatizadas.

EU AI Act y Copilot: cómo me estoy preparando para no llegar tarde

 

Hay un reloj corriendo. EU AI Act tiene fechas de aplicación escalonadas, y para 2026 ya hay capítulos vinculantes. Si tu organización opera en la UE, ya estás dentro del scope. Y Copilot, tal y como lo usas, probablemente cae en categorías que tienen requisitos.

Voy a contar qué hago, no qué dice la ley en abstracto. Para eso ya hay miles de artículos.

Mi secuencia

Primero, clasifiqué cada uso de Copilot por categoría de riesgo del Act. La mayoría caen en “limited risk” (transparencia hacia usuarios) o “minimal risk” (sin requisitos específicos). Pero algunos casos cayeron en “high risk” — análisis de CVs en procesos de selección, evaluación de empleados, soporte en decisiones de crédito. Esos tienen obligaciones serias.

Segundo, documenté. EU AI Act exige documentación de sistemas. Para Copilot empresarial estándar, Microsoft te da buena parte. Pero para tus agentes custom (los que creas en Copilot Studio con conectores a tus sistemas), la documentación la haces tú. Cada agente custom tiene su ficha: propósito, datos que usa, modelo subyacente, límites, supervisión humana, métricas de calidad.

Tercero, transparencia. Marqué a usuarios cuándo están hablando con un agente y cuándo con un humano. Suena obvio. No lo era. Tenía agentes en Teams que respondían sin marca clara. Lo cambié en Q1.

Cuarto, supervisión humana donde toca. Para los casos high-risk, ningún agente decide sin revisión. La revisión es real, no rubber-stamp. Métricas: porcentaje de decisiones revisadas vs aprobadas automáticamente. Si la revisión es 100% aprobar, no es revisión.

Quinto, evaluación de impacto. Los Fundamental Rights Impact Assessments para sistemas high-risk son nuevo trabajo. No es opcional. Mi equipo de legal trabaja con seguridad para producirlos. La primera vez tomó tres semanas. La segunda, una.

Lo que me ayudó

In-country processing en EU. Cuando Microsoft anunció procesamiento dentro de territorio europeo, marcó una casilla importante de cumplimiento. No la única, pero importante.

Microsoft Purview Compliance Manager. Tiene templates específicos para EU AI Act que dan la línea base de controles. Útil como punto de partida, no como punto de llegada.

Lo que no me ayudó

Los proveedores que prometen “compliance EU AI Act in a box”. No existe la caja. Compliance es proceso, no producto.

¿Recomendación si estás empezando? No esperes. La documentación de sistemas existentes es lo más lento. Si arrancas hoy, llegas. Si arrancas en seis meses, no.

AI Security Posture Management: el secure score que necesitabas

 

Tenía claro hace un año que Defender for Cloud iba a evolucionar a cubrir cargas de IA. Lo que no esperaba era lo bien que iba a integrarse el AI-SPM (AI Security Posture Management) cuando llegara.

Antes de AI-SPM, gobernar la postura de IA en una organización mediana era un trabajo de patchwork. Tenía que sumar señales de Azure OpenAI (qué deployments, con qué configs, con qué key management), Copilot Studio (qué agentes, con qué connectors), Foundry (qué modelos custom, con qué evaluaciones), agentes locales (qué corre, con qué permisos) y frameworks custom (lo que tu equipo de dev haya montado). Cada uno con su consola, su lógica, su nomenclatura. Cinco fuentes, cinco hojas de Excel, una visión turbia.

AI-SPM lo unifica. Un dashboard. Un secure score. Una vista por workload de IA con severidades, recomendaciones, owners.

 

Lo que más me ayudó al activarlo

La visualización de dependencias. AI-SPM dibuja qué workloads de IA dependen de qué identidades, qué datos, qué APIs externas. Cuando vi por primera vez el grafo, encontré dos workloads que dependían de una API externa que el equipo había puesto sin pasar por el proceso de aprobación de proveedores. Conversación incómoda con el dev, pero corregido en la semana.

La detección de configuraciones débiles. Modelos sin rate limiting, deployments con keys que llevaban meses sin rotar, conectores con permisos sobredimensionados. El secure score no es solo número — es una lista accionable de cosas que arreglar.

La integración con incidents en Defender XDR. Cuando un ataque toca la superficie de un workload de IA, ya no es solo “alerta del modelo” en una consola y “alerta de identidad” en otra. Es un incidente único correlacionado.

 

Lo que me sorprendió en mal

El cobertura todavía es desigual entre workloads. Azure OpenAI lo cubre bien. Copilot Studio aceptable. Frameworks custom — depende mucho de cómo los hayas instrumentado. Si no instrumentas, AI-SPM no ve. Esto es razonable técnicamente, pero genera ilusión de cobertura cuando el dashboard se ve “verde”. Verde en lo que ve. No verde en lo que no ve.

Los benchmarks de “secure score” son a veces optimistas. Un workload con score 85% puede tener gaps que importan en tu contexto pero que no se ven en el score. El score es punto de partida, no la métrica final.

La latencia de los signals: algunos hits tardan minutos en aparecer en el dashboard. Para detección casi tiempo-real, todavía hay que ir a Defender XDR directo.

Mi rutina con AI-SPM

Semanalmente: review del secure score y de los hallazgos abiertos. Asignación a dueños. Tracking de cierre.

Al onboarding de un workload de IA nuevo: chequeo previo de cobertura. Si no aparece en AI-SPM, lo instrumento antes de promover. La instrumentación a posteriori siempre se queda a medias.

Trimestralmente: presentación al board. AI-SPM da las gráficas que necesito. Score por workload, evolución temporal, top 5 hallazgos críticos. Antes preparar esto era media semana de trabajo. Ahora son veinte minutos.

 

 

 

Para quién es

Si tienes 10 o más workloads de IA distribuidos, AI-SPM cambia tu vida. Si tienes 2 o 3, probablemente con dashboards de Azure OpenAI normales te bastaba. La inversión en gobernanza unificada se justifica con escala.

¿Sustituye al programa de seguridad? No. Es la consola, no el programa. Las decisiones, los procesos, las personas — eso no lo da AI-SPM. Lo que da es la vista para tomar mejores decisiones.

Mi métrica favorita después de seis meses con AI-SPM activo: tiempo medio entre el deploy de un workload nuevo y la primera revisión de seguridad sobre él. Bajó de 23 días a 4. Eso es lo que me dice que la herramienta vale.

Copilot Control System: el plano de control que llegó tarde pero llegó

 

Llamémoslo CCS, que ya hasta tiene siglas oficiales. Copilot Control System es el paraguas con el que Microsoft empaquetó en Ignite 2025 todas las consolas, settings y herramientas de governance de Copilot que vivían dispersas. La intención: una sola puerta de entrada para IT y seguridad. La realidad: lo es, parcialmente.

Voy a contar qué aprendí los primeros meses con CCS abierto en mi pestaña.

El problema que resuelve

Antes de CCS, gobernar Copilot era un viaje por cinco consolas. Microsoft 365 admin center para algunas configuraciones. Purview para sensitivity labels y DLP. Entra para identidades. Defender para alertas. SharePoint admin para SAM. Y a veces Copilot Studio aparte. Pasaba mucho tiempo recordando dónde estaba cada cosa. Mis screenshots de hace seis meses están llenos de capturas de “lo configuré en algún sitio que no recuerdo”.

 

CCS junta todo en una vista. Settings de Copilot, agentes registrados, políticas activas, alertas, reportes. No es que mueva lo que existía — sigue existiendo en sus consolas originales. Es que te da un agregador. Si quieres ir a la consola de origen, hay deep links. Si quieres operar desde CCS, las cosas más comunes están ahí.

 

Lo bueno

La adopción. Mi equipo de IT, que antes pateaba el tema de Copilot a otros, lo adoptó porque les bajó la fricción. Cuando algo se ve fácil de operar, se opera. Esa es la parte humana del problema.

La integración con Purview. Ver el dashboard de DLP de Copilot dentro de CCS, sin saltar, con los mismos filtros que estás usando, es una pequeña victoria. Pequeñas victorias suman.

El reporting agregado. Antes preparar un reporte mensual de “estado de Copilot” me llevaba dos días. Ahora tarde una mañana. CCS exporta gráficas decentes que pego directo en el deck.

Lo no tan bueno

Hay funciones que dicen estar “integradas en CCS” pero al hacer click te mandan al portal original. Engaño parcial. Lo más reportado: configuración de tenant settings avanzados que sigue forzándote a abrir el admin center clásico. Microsoft dice que están unificando. Mientras tanto, el deep link es lo que tienes.

Cargas lentas en algunas vistas. Cuando tienes muchos agentes registrados (yo tengo 60 ya), algunas listas tardan. Lo paliable, no bloqueante.

La curva de aprendizaje sigue siendo dura para alguien sin contexto. CCS no es una herramienta para principiantes en Copilot. Da por hecho que entiendes el modelo de licenciamiento, las identidades de agente, las políticas de DLP. Si llegas verde, te ahogas.

Lo que cambié en mi rutina

Reemplacé tres dashboards custom que tenía hechos en Power BI con vistas nativas de CCS. Los borré. Menos código que mantener.

Subí la frecuencia de mis check-ins. Cuando el dashboard está a un click, lo abres más. Antes lo miraba semanalmente. Ahora cada lunes y miércoles, mínimo.

Le pasé el acceso a CCS a dos managers que antes no entraban a herramientas de seguridad. La idea: que vean el estado de los agentes en sus áreas. Funcionó. Empezaron a hacer preguntas que antes no hacían. La governance distribuida pasa cuando la información se distribuye.

¿Es la solución definitiva? No. Es una capa de presentación encima de un stack que sigue siendo complejo. Si esperas que CCS te resuelva la complejidad de gobernar Copilot, vas a sentirte engañado. Si esperas que te baje la fricción operativa para administrar lo que ya entiendes, lo logras.

 

Mi puntuación honesta: 7 sobre 10. Le sobra trabajo. Pero es la dirección correcta y se ve que Microsoft le pone foco. Para Ignite 2026 espero un CCS más maduro. Por ahora, mejor con él que sin él.

Security Copilot incluido en E5: ¿regalo o cambio de modelo?

 

Cuando Microsoft anunció en Ignite 2025 que Security Copilot venía incluido para clientes de Microsoft 365 E5, mi primera reacción fue cinismo. La segunda, después de hacer cuentas, fue otra cosa.

La cínica primero. Microsoft estaba teniendo dificultades para vender Security Copilot como SKU separado. El precio por unidad de capacidad era alto, los pilotos tardaban en convertir, los CISOs miraban los números y dudaban. Incluirlo en E5 baja la barrera de entrada a cero — ya pagaste, úsalo.

Hasta ahí, marketing clásico.

Lo que cambia mi opinión es lo que viene con eso.

Security Copilot incluido no es la versión completa. Es un derecho de uso con un cupo de SCUs (Security Compute Units) razonable para casos de uso medianos. Si tu SOC corre operaciones grandes, te quedas corto rápido y vuelves al modelo de pago. Pero para muchas organizaciones — especialmente las que aún no tenían Security Copilot — el cupo incluido alcanza para empezar.

Y empezar es lo importante. Microsoft está apostando a que, una vez que pruebes los Security Copilot agents en Defender, Entra, Intune y Purview, no quieras volver atrás. Los agentes nuevos — los doce que anunciaron — atacan dolores reales del SOC.

Los que más he probado

El agente de phishing triage en Defender. Antes tenías a un analista de tier 1 dedicado a clasificar correos reportados. Ahora el agente preclasifica, y el analista mira los casos no triviales. En el equipo donde lo metí, el tiempo medio de resolución bajó del orden del 60%. No es magia. El agente comete errores. Pero la mayoría de su trabajo es bueno y los humanos pueden enfocarse arriba.

El agente de optimización de Conditional Access en Entra. Mira tus políticas, encuentra duplicaciones, sugiere consolidaciones. La primera vez que lo corrí en mi tenant, identificó cuatro políticas que se contradecían entre sí. Llevábamos meses con esa contradicción y nadie la había visto.

Si no tienes E5 todavía

Esta es la conversación interesante. Antes de Ignite 2025, justificar el upgrade a E5 era difícil para muchas empresas — el delta de funcionalidades sobre E3 más addons no siempre era claro. Con Security Copilot incluido, el balance cambia. Es una pieza más en la columna del “vale la pena”.

Mi cálculo aproximado para una empresa de 1,000 empleados: el ahorro en SCUs gratuitas más el valor de los agentes en SOC, si los usas, suele cubrir el delta de E5 contra E3. No siempre. Depende de tu uso. Pero ya no es claramente negativo, como sí lo era antes.

Si ya tienes E5 pero no habías tocado Security Copilot

Empezar con un piloto enfocado, no con toda la suite. Mi recomendación: arranca con dos agentes, no con doce. Phishing triage en Defender más uno relevante para tu mayor dolor (Conditional Access en Entra, Identity Risk en Entra, o el que sea). Mide. Después expande.

No prendas todos los agentes de un golpe. Te van a saturar con alertas y configuraciones. Y tu cupo de SCUs se gasta más rápido de lo que te imaginas si dejas todo corriendo.

Lo que no me gusta del cambio

Que Microsoft no fue claro sobre el cupo exacto incluido al principio. Costó leer la letra chica. Hoy está mejor documentado, pero al inicio había confusión sobre qué era “incluido” y qué era “consumido” en SCUs.

Que el reporting unificado de uso entre los distintos agentes todavía no es perfecto. Cuando llega final de mes, ver quién consumió qué requiere paciencia.

Que el modelo crea dependencia. Una vez que el SOC se acostumbra a tener agentes ayudando, sacarlos es doloroso. Microsoft sabe esto. Apuesta a que tu uso crezca y termines pagando SCUs adicionales. Es un negocio bien diseñado.

¿Recomendación final? Si tienes E5 y no has tocado Security Copilot, pruébalo este mes. No mañana. La curva de aprendizaje del equipo es lo más caro, y cuanto antes empieces, antes capitalizas.

El procesamiento en país: la pelea por la soberanía del prompt

 Cuando Microsoft anunció en Ignite 2025 que Copilot iba a procesar prompts y respuestas en 15 geografías, empezando por Australia, UK, India y Japón, mucha gente lo pasó por alto. Yo no.

Para mí es una de las decisiones más importantes del año en este espacio.

Dejame contar por qué.

La pelea regulatoria sobre dónde se procesan los datos no es nueva. EU Data Boundary, que existe desde 2023, ya garantizaba almacenamiento en territorio europeo para servicios de Microsoft 365. Pero los servicios de IA tienen una particularidad: el procesamiento puede salir del territorio aunque el almacenamiento no. La inferencia se hacía donde estuviera disponible la GPU. Y las GPUs estaban concentradas en pocos sitios.

 

Para muchos sectores regulados — banca, salud, gobierno, defensa — eso no era suficiente. “Tus datos se almacenan en mi país pero la IA piensa con ellos en otro”. Los reguladores empezaron a apretar. En 2025 vi RFPs con cláusula explícita: “el proveedor debe garantizar procesamiento de IA en territorio nacional”. Microsoft lo escuchó.

In-country processing no es un cambio de marketing. Es un cambio de infraestructura. Microsoft tuvo que desplegar capacidad de inferencia regionalizada — GPUs, modelos, redes de baja latencia — en cada uno de los 15 países anunciados. La ingeniería detrás es seria.

 

Qué cambia para mí como cliente

Cumplimiento más limpio. Si tu regulador local exige procesamiento doméstico, tienes una respuesta documentada. Antes era “tenemos almacenamiento en su jurisdicción y procesamiento en la región más cercana”. Ahora es “todo doméstico”. Eso ahorra meses de back-and-forth con compliance.

Latencia mejor en algunos casos. Si tu organización está físicamente lejos del datacenter principal, ver inferencia local es notable. En la prueba que corrí en India, la latencia bajó cerca de un 40% en prompts complejos.

Trazabilidad más simple. Logs de inferencia con jurisdicción explícita. Para auditorías, es oro.

 

Qué no cambia

El modelo sigue siendo el mismo. La calidad de respuestas no es distinta por región. Si esperabas un modelo “específico de tu país”, no es eso lo que pasa.

Las críticas justas

“Microsoft sigue siendo una empresa estadounidense, así que el CLOUD Act sigue aplicando aunque el dato se procese localmente”. Cierto. La soberanía completa solo la consigues con un cloud soberano completo (que existe, en algunos países, con acuerdos específicos). In-country processing es paso adelante, no fin del camino.

“15 países es poco”. Cierto. Si estás en Latinoamérica, África o partes de Asia, el roadmap todavía no te llega. Hay que seguir mirando. Microsoft dice que continúan expandiendo. La realidad: los datacenters cuestan, y se priorizan mercados grandes.

Mi consejo a quien evalúe esto

Pregunta primero qué exige tu regulador, no qué te ofrece Microsoft. La conversación es al revés. Si tu regulador exige X y Microsoft te ofrece in-country en tu jurisdicción, está bien. Si tu regulador exige X y Microsoft no te lo da, no fuerces el match.

Pregunta segundo cómo se documenta. “In-country processing” como capacidad es una cosa. Cómo se evidencia en logs, contratos y auditorías es otra. Pídelo por escrito, en el contrato. La capacidad técnica sin la cláusula contractual no te sirve en una disputa.

Pregunta tercero qué pasa si la capacidad local cae. ¿El servicio se degrada o se redirige a otra región? Ese punto suele estar en letra chica y es importante para cumplimiento.

A mayo 2026, in-country processing es una de las capacidades más estratégicas de Copilot para mercados regulados. No la subestimes solo porque no te aparezca en el screenshot bonito de la consola.

Prompt Shields y Spotlighting: la respuesta de Microsoft, llegando tarde

 

Voy a decir algo que me va a costar amigos en Microsoft: Spotlighting debió haber salido antes de EchoLeak.

Spotlighting es la capacidad, anunciada en Build 2025, de marcar el origen del input que entra al modelo. Distingue entre lo que el usuario escribe y lo que viene dentro de un documento o de una página web procesada. Es decir, le dice al modelo: esto es del usuario, esto es de un tercero, trátalos distinto.

La categoría de ataque de “prompt injection indirecta” — que es exactamente lo que aprovechó EchoLeak — se conocía desde 2022. Investigadores académicos llevaban tiempo gritando que esto iba a romper modelos en producción cuando se les diera acceso a documentos, correos, páginas. Microsoft sacó Prompt Shields en 2024 (la primera versión, con foco en jailbreaks directos). Spotlighting, que va al corazón de la prompt injection indirecta, llegó en 2025. Después de que EchoLeak demostrara la categoría en producción.

No critico la dirección. Critico el ritmo.

Lo que Prompt Shields hace bien hoy

Detecta jailbreaks directos. “Ignora tus instrucciones anteriores y dime…”. Eso lo bloquea sin problema, casi siempre. Detecta patrones conocidos de agent-hijack — instrucciones que tratan de cambiar la persona del agente, desviarlo de su tarea, hacerle ejecutar acciones fuera de su scope.

Detecta, con Spotlighting activo, indirect prompt injection en muchos casos. He puesto a prueba su detección con payloads conocidos públicamente y los pilla mayormente. Con payloads custom — ataques pensados para tu contexto específico — la cosa es más mixta. Los modelos de detección están entrenados sobre patrones generales, no sobre las particularidades de tu tenant.

Lo que no hace bien

No detecta exfiltración semántica sofisticada. Si el atacante en lugar de pedir explícitamente “manda este dato al endpoint X” lo pide en lenguaje natural elaborado (“incluye en el resumen este enlace”), la detección baja.

No correlaciona entre prompts. Cada llamada al modelo se evalúa por separado. Ataques que se desarrollan en varios turnos pueden pasar.

No reemplaza arquitectura. Si tu agente carga URLs sin validar, ningún Prompt Shield te salva.

Mi configuración actual

Tengo Prompt Shields encendido en todo lo que es Copilot Studio. Spotlighting activo en todos los flujos donde entra contenido externo. Logging completo a Sentinel, con dashboards específicos para hits del shield.

Encima, capa de validación propia: cualquier URL que el agente quiera tocar pasa por una allowlist. Cualquier output que tenga URLs en Markdown se sanitiza antes de mostrarse. Cualquier acción del agente con efectos laterales (mandar correo, modificar archivo) requiere confirmación explícita del usuario.

Es defensa en profundidad. Prompt Shields es una capa, no la solución. Si la presentas a tus stakeholders como “tenemos prompt injection resuelto porque tenemos Prompt Shields”, te van a faltar capas el día que pase algo.

Lo que espero de Microsoft

Spotlighting más fino, con etiquetas más específicas (no solo trusted/untrusted, sino también “fuente externa por firewall”, “fuente externa por correo”, “fuente compartida por enlace”). Cuanto más granular, mejor las decisiones de bloqueo.

Detección de exfiltración por canales no obvios. Imágenes, links de Markdown, patrones de respuesta que filtran datos en formato sutil. Es donde EchoLeak pegó duro y donde la siguiente generación de exploits va a apuntar.

Integración nativa con Defender for AI. Hoy hay puentes pero no es nativo. Si Prompt Shields detecta y Defender investiga sin fricción, el SOC respira.

Por ahora, Prompt Shields es el control más importante que tienes contra esta clase de ataques. Pero por favor, no es el único que necesitas.

 

EchoLeak: el zero-click que me hizo dudar de Copilot

 

A mí me costó procesar lo que pasó con EchoLeak. No la parte técnica — esa la entiendes leyendo el writeup de Aim Labs. Lo que me costó fue aceptar que un atacante podía mandarte un correo, tú no hacías nada con él, y aún así Copilot terminaba filtrándole datos de tu Outlook y tu Graph al de afuera. Cero clics. Cero interacción. El correo llegaba, Copilot lo procesaba en algún momento mientras hacías otra consulta, y ya estaba.

CVE-2025-32711, CVSS 9.3. Microsoft lo parcheó server-side rapidito y sin advisory ruidosa. Lo cual me parece bien y me parece mal a la vez. Bien porque la mitigación tiene que ser inmediata. Mal porque sospecho que muchos equipos de seguridad ni se enteraron de la magnitud hasta que los investigadores publicaron el detalle en arXiv unos meses después.

 

Lo que más me marcó del writeup es la elegancia del exploit. No es un bug. Es una cadena.

Primero, evade el clasificador XPIA (Cross Prompt Injection Attempt) usando lenguaje que no se ve como instrucción adversaria. Después esquiva la redacción de enlaces con Markdown reference-style (en lugar de poner el enlace con el dato sensible directo, lo separa en una referencia). Después usa imágenes que se auto-fetchean — el simple acto de cargar la imagen ya filtra el dato porque la URL lleva la información. Y el cierre de oro: abusa de un proxy de Teams que está permitido por la Content Security Policy. Filtración limpia.

Lo bauticé en mi cabeza como “el vector que demuestra que la CSP de tu app no es suficiente cuando metes un LLM en medio”. Porque eso es lo que es. La CSP estaba bien para una app tradicional. Para una app que tiene un agente que decide a qué dominio se conecta, la CSP es solo el principio.

Qué hago yo distinto desde EchoLeak

Lo primero, asumo que cualquier dato no estructurado que Copilot toque es input no confiable. No solo correos de fuera. También documentos compartidos por terceros, también notas pegadas de quién sabe dónde. Eso ya cambia cómo configuro las políticas de DLP.

Segundo, miro con otros ojos las funcionalidades de “auto-summarize”. Cualquier cosa donde Copilot procese contenido sin que yo le pida explícitamente que lo haga es vector. Es ahí donde EchoLeak metió la cuchilla.

Tercero, y esto es opinión: creo que Microsoft tardó en sacar Spotlighting. Lo anunciaron en Build 2025, pero la categoría de ataque ya se conocía. Spotlighting marca el origen del input para que el modelo distinga “esto me lo dijo el usuario” de “esto venía dentro de un documento”. Era un control que necesitábamos antes, no después.

Para mi equipo hicimos tres cosas concretas las semanas siguientes. Auditamos qué buzones tienen reglas de auto-procesado que terminen llegando a Copilot — apagamos varias. Forzamos sensitivity labels en todo lo que viene de invitados externos: si entra etiquetado como external, Copilot no lo procesa. Y activamos logging completo de prompts en Purview, aunque pesa un montón. Sin auditoría no hay forensia.

Lo último — y esto es lo que me sigue rondando — es que EchoLeak no fue un fallo en un modelo grande. Fue un fallo en cómo Microsoft pegó el modelo al resto del stack: identidades, permisos, cargas de URL, parsers de Markdown. La superficie de ataque del Copilot empresarial no es el LLM. Es la conexión del LLM con todo lo demás.

El día que entendí eso fue el día que dejé de ver a Copilot como un producto y empecé a verlo como una integración compleja. Y las integraciones complejas se rompen en las costuras.

 

 

 

 

 

El equipo rojo automatizado: AI Red Teaming Agent en Foundry

 

Antes, hacer red team a un agente de IA era trabajo artesanal. Un humano experto, pensando como atacante, probando payloads, observando comportamiento, iterando. Caro, lento, no escalable.

Microsoft sacó el AI Red Teaming Agent en Foundry para cambiar eso. La promesa: red team automatizado, escalable, repetible. La realidad: útil, no sustituto.

Lo probé en serio este trimestre, contra dos agentes de Copilot Studio que tengo en producción ligera. Voy a contar lo que vi.

Qué hace

El agente toma tu agente bajo prueba y le tira payloads adversarios desde una librería curada. Cubre prompt injection directa, indirecta, jailbreak, content harms, tool abuse, agent hijack. La librería se actualiza. También permite cargar payloads custom, así que si tienes tu propio dominio (financiero, salud, legal), puedes meter ataques específicos.

Te entrega un reporte: qué payload pasó, qué se bloqueó, qué generó respuestas problemáticas. Métricas, severidades, sugerencias de mitigación.

 

Lo bueno

Velocidad. Mil ataques en una hora. Un humano hace cien en un día bueno. La cobertura amplia es donde brilla. Si tu agente tiene un patrón de fallo conocido, casi seguro lo encuentra.

Repetibilidad. Cada nueva versión de tu agente la pasas por la misma batería. Detectas regresiones. CI/CD para seguridad de IA. Esto es lo que más me cambió: meter el red teaming en el pipeline, no como ejercicio anual.

Integración con Foundry. El reporting fluye al mismo lugar donde llevas el resto de tus pruebas y safety evaluations. Vista única.

Lo no tan bueno

Encuentra ataques conocidos. Brilla menos con ataques nuevos, sutiles, específicos a tu dominio. Si tienes un caso de negocio peculiar, los payloads genéricos no van a detectar todos los caminos. Necesitas un humano experto que escriba payloads específicos a lo tuyo. El agente automatiza lo conocido, no lo creativo.

La interpretación de resultados sigue requiriendo expertise. Reporte que te dice “12 ataques pasaron, 88 bloqueados”. OK. ¿Cuáles son los 12? ¿Cuáles importan más? Eso lo tienes que entender tú o alguien con criterio.

Falsos positivos pasan. A veces el agente clasifica un comportamiento como problemático cuando es esperado en tu caso. La triangulación con un humano es necesaria.

 

Cómo lo uso

Para regresiones: parte del pipeline. Cada cambio de prompt, cada nuevo conector, cada update del modelo, batería completa. Si la baseline empeora, alerta antes de promover a producción.

Para baseline en agentes nuevos: antes de meter un agente nuevo a producción, ejercicio completo. Si pasa los ataques conocidos, listo el primer filtro. Después le sigo con red team manual sobre lo específico de mi dominio.

Para auditoría: el reporte automatizado es excelente evidencia para auditores externos. “Aquí está el resultado de la batería de pruebas adversarias contra cada agente, ejecutada cada N días”. Antes esto era difícil de producir. Ahora es un export.

Lo que me gustaría que tuviera

Más payloads en español. La librería está fuerte en inglés y los modelos modernos transfieren razonablemente, pero los ataques en español tienen sutilezas. Espero que la librería se siga internacionalizando.

Soporte mejor para agentes multi-step complejos. Los ataques que se desarrollan a lo largo de varios turnos, con planificación, son más difíciles de automatizar. Hoy detecta lo turn-by-turn bien, lo multi-turno con menos profundidad.

Integración nativa con MCP. La capacidad de probar agentes que usan MCP servers externos. Esto es un gap. Hoy si tu agente usa MCP, la cobertura del red team baja porque no entiende del todo las superficies extra. Espero ver mejoras en los próximos meses.

 

¿Es suficiente? No. Es parte del programa de seguridad, no el programa entero. Pero es un avance gigante respecto a hace dos años, donde literalmente no existía esta categoría de herramienta.

Si tienes agentes en producción y no estás haciendo red teaming sistemático sobre ellos, es la pieza que más rápido te baja el riesgo. Hazlo ahora.

Sensitivity labels: la taxonomía que sí funciona con Copilot

 

Tres veces en mi carrera he tenido que rehacer el esquema de sensitivity labels de una organización. La tercera fue después de meter Copilot. Voy a explicar por qué.

Los esquemas que se diseñaron antes de Copilot tienen un sesgo: están pensados para humanos clasificando documentos. Cinco niveles, descripciones largas, instrucciones que el usuario teóricamente lee al elegir el label. En la práctica, el usuario clica el primero que ve y sigue. Cuando Copilot empieza a actuar sobre esas etiquetas, los problemas afloran.

Mi taxonomía actual, después de tres iteraciones

Cuatro niveles, no más. Más de cuatro y la gente se confunde. Public, Internal, Confidential, Restricted. Cada nivel con un sub-marcador opcional (“External-Allowed” o “External-Blocked”). El sub-marcador ataca el problema de “es confidencial pero el partner X sí lo puede ver”.

Reglas claras de procesamiento por Copilot. Cada label tiene una regla explícita: ¿Copilot puede leer? ¿Puede generar contenido derivado? ¿Puede compartir en la respuesta a un usuario externo invitado? La matriz cabe en una página.

Auto-labeling agresivo en lo trivial. SSN, números de tarjeta, IBANs, datos de RRHH conocidos — auto-label sin pedirle al usuario. La auto-classification de Purview es buena. Confío en ella para el 70% del corpus. El 30% restante lo etiqueta el usuario.

Defaults razonables. Si un sitio nuevo se crea sin label, hereda “Internal” por política. Antes era “Public” por descuido. Eso solo bajó mi superficie de exposición en un 12%.

Lo que aprendí en el camino

Que un label complicado se ignora. La gente no quiere leer. La gente quiere clicar.

Que los labels por sí solos no protegen. Un label sin DLP detrás es un papel en la pared. Yo combino label más DLP más Conditional Access. Las tres capas o ninguna.

Que migrar es doloroso. Tuve documentos con label viejo, documentos con label nuevo, documentos sin label. Tomó cuatro meses migrar el corpus crítico. Los demás documentos los seguimos limpiando. La perfección es enemiga del progreso.

Que Copilot acelera la limpieza. Cuando un usuario pregunta a Copilot por algo y la respuesta se bloquea por DLP, el usuario reporta. Cada bloqueo es feedback. Cada feedback me dice qué documentos tienen el label mal puesto. La operación de Copilot se vuelve auditoría continua del esquema de labels.

¿Lo recomendaría? Sí, pero con expectativas reales. Diseñar bien lleva semanas. Implementar lleva meses. Madurar lleva un año. Si tienes Copilot en piloto y sensitivity labels todavía sin definir, no demores. La complejidad solo crece.

Customer Lockbox y Copilot: ¿realmente aplica?

 Pregunta que me hicieron en una llamada con un cliente: “¿Customer Lockbox aplica a Copilot?”. Pregunta razonable. Respuesta corta: parcialmente. Respuesta larga: lee esto.

Customer Lockbox de Microsoft es el mecanismo por el cual, si un ingeniero de Microsoft necesita acceso a tus datos para soporte técnico, tú apruebas o rechazas la solicitud. Tu dato no se toca sin tu OK. Es una de las garantías que más vendí en los últimos años a clientes nerviosos por privacidad.

Qué pasa con Copilot

Para datos almacenados en Microsoft 365 (correo, archivos en SharePoint y OneDrive, mensajes de Teams), Customer Lockbox aplica como siempre. Si un ingeniero de Microsoft necesita revisar uno de esos datos para resolver un problema de Copilot, requiere tu aprobación.

Para los datos en tránsito en el procesamiento de Copilot — el prompt que el usuario manda, la respuesta generada — la situación es distinta. Esos datos viven en el plano de inferencia. Customer Lockbox no aplica de la misma forma. Microsoft documenta que prompts y respuestas no se usan para entrenar y se eliminan según retención. Pero el modelo de Customer Lockbox tradicional no se extiende todavía con el mismo rigor.

Para los logs de Copilot (qué pidió cada usuario, qué respondió el modelo) que se almacenan en Purview con tu retención — eso vuelve a ser dato tuyo y Customer Lockbox aplica.

Esto no es un gap de seguridad. Es un gap de garantía formal de control de acceso operativo.

¿Importa?

Depende de tu industria. Para banca o salud altamente regulado, el modelo “Microsoft no toca mis datos sin que yo apruebe” es importante. Si Customer Lockbox no cubre prompts en tránsito, tienes que documentar el gap y mitigarlo de otra forma — confidential compute, o aceptar el control compensatorio del acuerdo contractual con Microsoft.

Para la mayoría de empresas, no es un blocker. Microsoft tiene controles internos robustos, attestations independientes, y el modelo de procesamiento de Copilot no es de “ingenieros viendo prompts”. Es automatizado.

Qué hago yo

Primero, no vendo Customer Lockbox como garantía total para Copilot. Sería deshonesto. Vendo lo que aplica y soy claro sobre lo que no.

Segundo, para clientes muy regulados, busco alternativas: Confidential Compute donde está disponible, in-country processing donde aplique, contratos específicos donde el riesgo lo justifica.

Tercero, monitoreo. Microsoft mejora estas garantías con el tiempo. Customer Lockbox para AI services es área activa. Espero updates en los próximos 6 a 12 meses.

Resumen para no técnicos: Customer Lockbox es real para tus datos almacenados. Para el procesamiento de IA en sí, hay garantías distintas pero no Customer Lockbox como tal. Léelo en el contrato, no en el marketing.

SharePoint Advanced Management: el primer paso, no el último

 

Una de las cosas que cambió silenciosamente cuando Microsoft empezó a incluir SharePoint Advanced Management con Copilot fue que de repente todo el mundo tenía la herramienta para hacer un assessment serio. Antes era licencia aparte, costaba dinero adicional, y muchos equipos se la saltaban.

SAM no es nuevo. Lo que es nuevo es que ya no tienes excusa para no usarlo si tienes Copilot.

Para quien no lo conozca: SAM (SharePoint Advanced Management) es un paquete de capacidades de governance para SharePoint. Inactive sites detection, oversharing reports, data access governance reports, conditional access policies a nivel de site, restricted access control. Una colección de cosas que viven en distintos rincones del admin center pero apuntan al mismo problema: tu SharePoint creció sin gobierno y ahora hay que ordenarlo.

El primer reporte

Cuando lo activé por primera vez en mi tenant, el reporte inicial fue, cómo decirlo, humillante.

Sitios inactivos con datos sensibles: 1,247. Sitios con permisos rotos (heredados pero el padre se borró): 89. Sitios con “Everyone except external users” en el grupo de Members: 312. Sitios sin propietario asignado válido (el dueño ya no estaba en la empresa): 56.

Y eso solo en la primera pasada. La segunda, con filtros más finos, sacó otra capa.

 

Lo que hice con esos datos

Para sitios inactivos: política nueva. Si no se accede en 90 días, archive workflow. Si nadie reclama en 30 días más, archivado. Si nadie reclama en 180 días desde el archive, candidato a eliminación. SAM permite automatizar buena parte de eso con políticas. La parte humana — confirmar con dueños — la tienes que orquestar tú.

Para “Everyone except external users”: más doloroso. Cada uno requería un revisor. Lo que ayudó fue una matriz de criticidad de datos: qué tipo de contenido tiene cada sitio. Los críticos (legal, finanzas, RRHH) los atacamos primero, manualmente. Los menos críticos los atacamos en cohortes.

Para permisos rotos: SAM los identifica pero no los arregla. Hay que entrar uno por uno o usar PowerShell. Lo más eficiente para nosotros fue agruparlos por área y mandar un ticket por área al dueño funcional con la lista. Que ellos se hagan cargo. Y si en X días no se responde, escalado.

Lo que SAM no hace

No es DLP. SAM te dice quién tiene acceso. Purview DLP te dice qué se puede hacer con el contenido. Son complementarios.

No es scanning de contenido. SAM mira permisos y metadata. Si tienes un PDF con SSN dentro pero el archivo está en un sitio “limpio” en cuanto a permisos, SAM no te lo dice. Para eso, sensitivity labels más auto-labeling de Purview.

No es un sustituto de governance proactivo. SAM te ayuda a limpiar lo viejo. Si no cambias cómo se crean nuevos sitios — templates con permisos sensatos, dueños obligatorios, lifecycle defaults — vas a estar limpiando para siempre.

 

Mi flujo actual

Al inicio de cada quarter, corro reporte completo. Diff contra el quarter pasado. Métrica clave: ¿bajaron sitios con problemas, o subieron? Si subieron, política nueva no funcionó. Si bajaron, mantengo curso.

Mensualmente, alerta de nuevos sitios sin propietario. Estos son la fuente principal de problemas futuros. Reasignar al crear, no al limpiar.

Trimestralmente, review con cada área de sus sitios críticos. SAM da el dato, el área toma la decisión. La governance funciona si los dueños se sienten dueños.

Lo último que diría: SAM no resuelve nada por ti. Es luz, no acción. Si no asignas el tiempo a actuar sobre lo que la luz revela, mejor no la enciendas — porque entonces es solo evidencia documentada de que sabías y no hiciste nada. Y eso, en una auditoría, es peor que la ignorancia.