El paisaje del phishing en Q1 2026: AI contra AI

 Microsoft publicó su reporte de Q1 2026 sobre el threat landscape de email a finales de abril. Lo recomiendo leer entero, pero voy a contar lo que más me marcó.

Los volúmenes de phishing siguen subiendo. Eso era predecible. Lo nuevo es la calidad. Microsoft reporta crecimiento sustancial en correos generados con LLMs. La gramática perfecta, el tono profesional, la personalización por información pública del target — todo lo que antes era pista para detectar phishing, hoy es nivel base.

El problema con eso: los entrenamientos de awareness de hace tres años están obsoletos. “Busca errores ortográficos” ya no es señal. El correo phishing de hoy no tiene errores. “Busca tono extraño” ya no es señal. El correo phishing está bien escrito.

Lo que sí sigue funcionando como señal

Análisis de origen. Headers, dominios sutilmente alterados, infraestructura de envío. Defender for Office hace este trabajo bien. La pieza humana se reduce a “verifica antes de actuar en cosas inusuales”.

Análisis de contexto. ¿El CEO realmente te pide a ti, en este formato, en este momento, por este canal? Si rompe patrón, sospecha. La regla “si rompe patrón, valida por canal alterno” sigue válida.

Análisis de intent. Defender XDR ahora marca correos por intent — financial fraud attempt, credential theft, etc. La clasificación por intent es más útil que por superficie.

Lo que cambió en mi operación

Bajé las expectativas de que el usuario detecte el phishing. La línea de defensa principal ya no es “el usuario que duda”. Es la pila de detección automatizada: anti-spoofing, sandboxing, intent analysis, link rewriting con análisis dinámico. Si llega al inbox un phishing decente, asumo que un porcentaje de usuarios va a caer.

Subí la inversión en respuesta rápida post-click. Cuando un usuario hace click en un link malicioso, ¿qué pasa? La velocidad entre click y contención es lo que marca la diferencia. Defender XDR más Security Copilot reduce esto.

Capacitación distinta. Ya no enseño a “detectar phishing por errores”. Enseño a “validar por canal alterno cualquier solicitud financiera o de credenciales no esperada”. Es regla simple. La gente la sigue.

Para dónde va esto

La carrera entre phishing generado por IA y detección por IA va a definir el panorama de email security los próximos años. Es asimétrica — el atacante necesita pasar uno, el defensor necesita parar todos. Pero las herramientas defensivas están mejorando rápido también.

Mi predicción: en 2027 el email puro como vector va a perder relevancia frente a vectores multi-canal (email más SMS más voz, con IA orquestando los tres). La defensa va a tener que cubrir el customer journey completo, no solo el inbox.

Agent 365 ya está GA: lo que pagas con esos 15 dólares al mes

 

 

El 1 de mayo arranca la disponibilidad general de Agent 365. Quince dólares por usuario al mes. He visto comentarios mixtos en LinkedIn — unos dicen que es un robo, otros que es regalado. Como casi siempre, depende.

Voy a tratar de ser concreto sobre qué te dan por ese precio. Lo escribo aprovechando que estuve dos semanas haciendo el piloto en uno de los tenants donde tengo manos.

Lo primero: Agent 365 no es un producto, es un control plane. Esa distinción importa. No te da más capacidad de Copilot. Te da más visibilidad y control sobre los agentes que ya existen y los que vienen. Si tu organización no tiene aún muchos agentes desplegados, el ROI es difícil de defender el primer trimestre. Si tienes Copilot Studio en uso o gente experimentando con agentes locales, la cosa cambia.

Lo que viene en la caja a mayo 2026

Runtime Protection (preview). Esto es lo que más me interesa. Monitorea al agente en tiempo de ejecución. Si el agente hace algo raro — accede a un origen no esperado, llama un API que no debería, mueve un archivo a un lugar improbable — lo flaggea. Y, si tú lo configuras así, le revoca permisos automáticamente. Es la primera vez que veo a Microsoft tratar a un agente como tratan a un endpoint con Defender. Misma filosofía: comportamiento, no firma.

Network-Layer monitoring. Extiende los controles de Entra Internet Access a los agentes. Esto significa que las conexiones del agente pasan por la misma inspección que ya tienes para los usuarios. Lo más valioso es restringir destinos web aprobados. Si tu agente solo puede hablar con APIs de tu lista, los exfil exploits a la EchoLeak pierden el destino.

Shadow AI discovery. La pieza que más me sorprendió en el piloto. Defender + Intune detectan agentes locales corriendo en endpoints Windows. Empezó con OpenClaw. La hoja de ruta menciona explícitamente GitHub Copilot CLI y Claude Code. Es decir, Microsoft está poniendo en su radar a los agentes que corren fuera de su stack. Pragmático. Honesto. Necesario.

Centralización en una consola. Registro de agentes, permisos, propietarios, telemetría, alertas. Antes esto vivía repartido entre Entra, Defender, Purview y la consola de Copilot Studio. Ahora hay un sitio único. Que funciona razonablemente bien — algunos paneles aún cargan lentos, pero mejor que pelearse con cuatro pestañas.

¿15 dólares por usuario al mes vale la pena?

Mi cálculo. Si tienes más de 500 usuarios con Copilot Studio activo y agentes en producción, el incidente que evitas con Runtime Protection paga el año completo. Si tienes menos de 100 y solo agentes “experimentales”, probablemente puedas esperar al refresh de cuatro o seis meses. El upside del precio es que escala sin que pagues por agente — pagas por usuario humano. Para una empresa donde un humano tendrá pronto seis o siete agentes ejecutándose en su nombre, es un modelo razonable.

Lo que me incomoda del precio: te obliga a pagar por usuarios que ni tocan agentes. No hay tier para “solo licenciar a quienes los usan activamente”. Microsoft sabe que la curva de adopción va hacia arriba, así que apuesta por cobrar todo el rebaño. Aceptable, pero opaco.

¿Qué hago si fuera tú? Lo que hice yo: piloto de 90 días con un grupo controlado, métricas claras antes de empezar (cuántos agentes registrados, cuántas anomalías detectadas, cuántos shadow agents encontrados), y decisión basada en datos. Si el shadow AI discovery te encuentra en el primer mes diez agentes que no sabías que existían, el precio se justifica solo. Si te encuentra cero, igual te dice algo importante: o estás muy maduro o no estás mirando bien.

Ya veremos cómo evoluciona. Por ahora, prefiero tenerlo activo a no tenerlo.

Identity Risk Scoring en Defender XDR para identidades de agentes

 

Defender XDR estrenó en abril identity risk scoring extendido a identidades de agentes. Antes el risk scoring se aplicaba solo a humanos. Lo de los agentes era un patch. Ahora es ciudadano de primera clase del modelo.

Voy a explicar qué cambia.

El risk scoring funciona como en humanos. Defender mira señales: ubicación geográfica anormal, accesos fuera de horario, acciones desviadas del patrón histórico, conexiones a destinos sospechosos. Combina señales en un score. Te alerta cuando un agente se comporta raro.

Diferencias con humanos

Los patrones son distintos. Un humano tiene ritmos circadianos. Un agente puede estar activo 24/7. La ausencia de ritmo circadiano no es señal sospechosa para un agente. Defender lo aprende.

La velocidad es distinta. Un agente puede legítimamente hacer 1000 acciones por minuto. La señal “muchas acciones rápidas” no aplica igual. Lo que sí aplica: cambio brusco respecto a la baseline del propio agente.

El contexto es distinto. Un humano tiene “manager”, “departamento”, “rol”. Un agente tiene “sponsor”, “scope autorizado”, “tipo de tarea”. El risk scoring de Defender ahora incorpora estos atributos en su modelo.

Lo que se ve en mi tenant

Detectó tres anomalías en el primer mes. Una era benigna — un agente cambió de comportamiento porque cambió su tarea, no estaba mal. Dos eran problemáticas — un agente que empezó a tocar datos fuera de su scope (mala configuración después de un update), y otro que empezó a fallar en patrones que sugerían que su modelo subyacente había sido cambiado sin aviso.

Ese segundo caso me marcó. Era un agente custom de Copilot Studio. Alguien del equipo de IA cambió el modelo subyacente sin avisar a seguridad. Defender lo detectó por el cambio en el patrón de respuestas. Me dio visibilidad sobre algo que estaba mal gobernado. Pude presentarle al equipo de IA evidencia técnica de por qué el cambio sin aviso no es OK.

Lo que ajusté en operación

Subí los thresholds para alertas críticas. Por defecto, Defender es ruidoso para agentes nuevos hasta que aprende la baseline. Las primeras dos semanas tuve más alertas que las que mi equipo podía triagear. Microsoft documenta esto, hay que esperar.

Conecté las alertas con tickets automáticos al sponsor del agente. Si un agente de María entra en risk alto, María recibe ticket. La accountability es del sponsor.

Empecé a usar el risk score en políticas de Conditional Access. “Si un agente está en risk alto, requiere re-autenticación de su sponsor humano antes de continuar acciones críticas”. Esto añade fricción a un agente comprometido, sin parar a los buenos.

Lo que me gustaría que mejoraran

Más explicabilidad en las alertas. A veces Defender dice “risk alto” sin explicar qué señales pesaron. Para investigación, necesito saber el por qué.

Integración con Entra Agent ID más profunda. Hoy hay puente, pero algunos atributos del agente no se reflejan en el modelo de risk. Espero que cierren ese gap.

Mi conclusión: risk scoring para identidades de agentes era el control que faltaba. Lo tienes activo, vas mucho más tranquilo. Si tienes agentes en producción y no estás monitoreando con risk scoring, es la pieza que más rápido te baja el riesgo de identidad de agente.

La ventana de chat de Security Copilot dentro de Defender XDR

 

En el update de abril, Microsoft metió una ventana de chat de Security Copilot dentro de Defender XDR. Suena a feature pequeña. No lo es.

Antes, cuando un analista del SOC tenía un incidente abierto, vivía con dos pestañas: la del incidente y la de Security Copilot. Copiaba contexto entre ambas. Pegaba IDs, hashes, IPs, nombres de host. La fricción era constante. Yo medí un día cuántos clicks gastaba un analista L2 en una hora de triage cruzando Defender con Copilot. 437 clicks. Cuatrocientos treinta y siete.

Ahora el chat vive dentro del incidente. Le preguntas al modelo sobre el incidente abierto, sin copiar nada. El contexto ya está cargado.

Las preguntas que más se hacen mis analistas

“Qué dispositivos están afectados”. Te lo da con confidencias por dispositivo.

“Cuáles son las identidades comprometidas”. Lista, con riesgo asignado.

“Compárame este incidente con los tres últimos parecidos”. Aquí brilla. Antes esto era un script de búsqueda ad-hoc en KQL. Ahora una pregunta.

“Qué acciones recomendarías en orden”. Te las prioriza con justificación. No siempre acierta. Pero la lista te ahorra el primer borrador.

Lo que está mejor de lo que esperaba

La calidad de las respuestas con contextos largos. Defender tiene incidentes con cientos de eventos. La ventana de chat los resume bien. No vi alucinaciones graves en mis tres semanas. Vi imprecisiones — un par de veces dijo “endpoint X” cuando era “endpoint Y” — pero detecto bien con un segundo de revisión.

Lo que está peor de lo que esperaba

La latencia. Para incidentes grandes, la primera respuesta tarda 8 a 12 segundos. Después es más rápido. Los analistas se quejan del primer paso. Microsoft sabe, está prometido bajar.

Lo que cambió en mi operación

Bajé el tier 1 a la mitad. No despedí a nadie — los moví a tier 2. El modelo hace el triage inicial de muchos incidentes. Los analistas humanos validan y deciden las acciones complejas. Mi MTTD bajó algo. Mi MTTR bajó más.

Subí los criterios de las cosas que Security Copilot puede ejecutar autónomamente. Antes era todo “sugerir, humano ejecuta”. Ahora hay un puñado de acciones (aislar dispositivo confirmado, bloquear IP en blocklist conocida, deshabilitar cuenta en lista de acciones aprobadas) que el modelo ejecuta solo, con notificación. La auditoría duerme tranquila porque cada acción tiene log y razón.

Subió mi consumo de SCUs. Esto es importante. La ventana de chat es seductora. Los analistas la usan más. Y cada query gasta. Si no metes cost caps por usuario, el final del mes te va a sorprender. Yo los puse en la segunda semana después de que un analista corrió 600 queries en un turno. Útil. Caro.

¿Lo recomendaría? Sí. Es de las cosas que justifican Security Copilot por sí solas, si tu SOC tiene volumen. Si tu SOC trabaja 5 incidents por día, no se nota. Si trabaja 50, cambia tu vida.

Una cosa que pediría a Microsoft: poner el chat también en Sentinel con el mismo nivel de integración. Hoy la experiencia entre ambos es desigual. Mismo motor, distinta integración. Espero que en próximos updates lo cierren.

Al final, esto es lo que compras con Security Copilot incluido en E5: que esté ahí donde el analista ya está mirando. La integración es la mitad del valor del modelo.

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

 

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

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

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

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

Riesgo 1 — Filtración de datos por respuestas inapropiadas

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

Riesgo 2 — Prompt injection y exfiltración asistida

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

Riesgo 3 — Identidades de agente sin governance

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

Riesgo 4 — Shadow AI en endpoints

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

Riesgo 5 — Dependencia de proveedor y continuidad

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

Riesgo 6 — Cumplimiento regulatorio

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

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

Lo que aprendí presentando esto

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

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

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

 

 

Lo que más me costó

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

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

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

 

Mi consejo

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

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

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

 

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

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

 

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

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

 

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

Recorrido por los 10

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

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

 

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

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

 

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

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

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

 

 

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

 

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

 

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

Cómo lo opero

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

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

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

La pieza que faltaba: DLP de Purview para Copilot

 

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

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

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

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

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

Qué tan bien funciona

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

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

 

Mi orden recomendado

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

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

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

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

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

 

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