Conditional Access con agentes de Security Copilot: lo que cambió de mi configuración

 

Conditional Access en Entra siempre fue donde se decidían los detalles. Quién entra, en qué condiciones, con qué autenticación. Cuando llegó el agente de Conditional Access en Security Copilot, tenía expectativas mixtas. Pasados varios meses con él en producción, voy a contar la experiencia.

Qué hace el agente

Tres cosas principales. Analiza tus políticas de Conditional Access existentes para encontrar contradicciones, redundancias, gaps. Sugiere optimizaciones — consolidar, simplificar, fortalecer. Y, opcionalmente con tu aprobación, las aplica.

Mi tenant tenía 47 políticas de Conditional Access. Acumuladas a lo largo de tres años, con dueños distintos, criterios distintos, niveles de comprensión distintos. El estándar de muchos tenants medianos.

El agente, primer scan: marcó 4 contradicciones, 11 redundancias, 6 gaps. Total 21 hallazgos de los 47 policies.

Los hallazgos

Las contradicciones eran graves. Una política bloqueaba acceso desde geografía X. Otra, más reciente, lo permitía con condición Y. La interacción entre ambas dejaba un escenario donde acceso desde X con Y pasaba sin la fricción que la política original quería. Yo no había detectado esa interacción.

Las redundancias eran ruido. Tres políticas hacían lo mismo con criterios ligeramente distintos. Consolidamos en una con criterios bien definidos.

Los gaps eran lo más útil. Casos donde “esperarías” tener una política y no había. Por ejemplo: ningún policy bloqueaba tokens de OAuth obtenidos desde aplicaciones de tercer país no aprobado. Lo cubrimos.

Lo que el agente hace bien

Volumen de análisis. Yo no tengo el tiempo de revisar 47 policies con detalle cada quarter. El agente sí.

Patrones conocidos. Microsoft ha visto millones de configuraciones. El agente conoce los antipatterns. Los marca.

Sugerencias razonadas. No solo dice “cambia X por Y”. Dice “X tiene problema A, te sugiero Y porque resuelve A sin abrir gap B”.

Lo que el agente no hace bien

Lo específico de tu negocio. El agente no sabe que tu sucursal en X tiene una excepción legítima por razones que no están documentadas. Las sugerencias en esos casos pueden empujar hacia una simplicidad que rompe operación. Hay que filtrar.

Lo político. “Reducir esta política afecta al departamento de Y, que va a quejarse”. El agente no ve esa dinámica. Tú sí.

Cómo lo opero

Reviso al agente quincenalmente. No diariamente — me satura. No mensualmente — me pierdo cosas. Quincenal funciona.

Apruebo cambios solo si los entiendo. La tentación de “auto-aprobar todo lo que sugiera” es real. La resisto. Cada cambio que aprueba, lo entiendo. Si no lo entiendo, no lo apruebo. Eso me ha bajado la velocidad pero subido la confianza.

Roto el dueño de las revisiones. Antes era yo siempre. Ahora roto entre dos personas del equipo. Eso me da double-check humano sobre el agente.

Mi métrica: número de incidents de identidad relacionados con misconfiguration de CA. Bajó 40% el primer trimestre con el agente activo. Suficiente para justificar el costo de SCUs.

 

¿Recomendación? Si tu tenant tiene más de 20 policies de CA, el agente vale la pena. Si tienes menos, probablemente no necesitas la herramienta. La complejidad escala el valor.

Shadow AI: los agentes que ya están en tu casa

 

Una mañana hace un par de meses, encendí el dashboard nuevo de Defender que muestra agentes locales detectados en endpoints. Esperaba ver dos o tres.

Vi treinta y siete.

OpenClaw en máquinas de marketing. Claude Code en máquinas de desarrollo. GitHub Copilot CLI en varias laptops de ingeniería. Algún agente custom que ni siquiera pude identificar al primer intento — resultó ser un script con un MCP server montado por alguien del equipo de data science.

Esto es shadow AI. Y a febrero 2026, es probablemente el riesgo más subestimado de las organizaciones medianas y grandes.

Defino shadow AI como cualquier agente o herramienta de IA que opera en endpoints o en la nube de la empresa sin estar registrada, gobernada o auditada por el equipo de seguridad. La parte “sin gobierno” es la importante. No es que sea malicioso — la mayoría no lo es. Es que está fuera del radar.

Por qué importa

Primera razón: estos agentes operan con permisos del usuario que los corre. Si el usuario tiene acceso a tu CRM, el agente local también. Y el agente no sigue las mismas reglas que tú aplicas a Copilot empresarial. No tiene Prompt Shields, no tiene DLP de Purview, no tiene logging unificado. Lo que filtre, ya está filtrado.

Segunda: muchos de estos agentes mandan datos a APIs de terceros. Cada query hecha a un agente local que se conecta a la API de Anthropic, OpenAI, o cualquier otro proveedor, manda contexto fuera. Si ese contexto incluye texto sensible — y casi siempre incluye algo — tienes flujo de datos no inventariado.

Tercera: al ser locales, sobreviven a apagones de servicios cloud y a controles de red. Si tu firewall corporativo bloquea el dominio del proveedor, el agente local que ya tenía credenciales y caché puede operar offline parcialmente. Hay menos puntos de control que con servicios SaaS.

 

 

Lo que está dando Microsoft

Microsoft empezó a atacar esto en serio con Defender más Intune. La capacidad de descubrir agentes locales — empezó con OpenClaw y se expandió a GitHub Copilot CLI y Claude Code — es el primer paso. Te dice qué tienes. Después tú decides qué hacer.

Las opciones

Bloquear todo. Política dura: ningún agente local en endpoints corporativos. Ventaja: simple. Desventaja: matas productividad real, y la gente buscará caminos. Le pasó a una empresa amiga: bloquearon Claude Code, los devs lo siguieron usando desde laptops personales conectadas a recursos de la empresa por VPN. Empeoraron el problema.

Permitir todo. Política blanda: la gente usa lo que quiera. Ventaja: nadie protesta. Desventaja: no sabes qué pasa. No me parece responsable.

Permitir con governance. Lo que yo hago. Lista permitida de agentes locales aprobados (Claude Code y GitHub Copilot CLI están en mi lista hoy). Configuración obligatoria que registra el agente con identidad de Entra Agent ID. Logging activado. Restricciones por destinos web y por tipos de datos.

Esto último es lo que hace posible la combinación de Agent 365 más Defender más Intune. Hace doce meses, ni siquiera tenía la capacidad técnica de hacer governance sobre estos agentes. Ahora sí.

 

 

Lo que aprendí en el camino

No subestimes el número. Vas a encontrar más de lo que esperas. Si tu primer escaneo te encuentra dos, mira mejor — probablemente hay diez.

No subestimes el valor que la gente le saca. Hay quien usa Claude Code seriamente para trabajo crítico. Bloquearlo sin alternativa es romper el flujo de alguien que está aportando. Habla con los usuarios antes de cortarles.

Sí subestima la conciencia que tienen sobre los riesgos. Mucha gente buena, talentosa, técnica, no tiene la menor idea de que su prompt se manda a un servidor externo. Lo da por hecho. Las charlas de awareness siguen siendo importantes.

 

¿Hacia dónde va esto? A mi juicio, hacia un modelo de “AI runtime” empresarial donde los agentes locales son ciudadanos de primera clase pero con governance. Microsoft está apostando a que sea su control plane (Agent 365) el que orquesta. Otros proveedores tienen visiones distintas. La pelea por el control plane de los agentes va a ser una de las grandes en el 2027.

Por ahora, escanea. Inventariа. Decide. No mires hacia otro lado.

ISO 42001 y Copilot: lo que aprendí intentando certificarme

 

Mi organización decidió ir por ISO 42001 en Q3 del año pasado. Estamos en proceso. Voy a contar lo que aprendí intentando alinear nuestro uso de Copilot con el estándar.

ISO 42001 es el primer estándar internacional de Sistema de Gestión de IA. Annex A tiene 38 controles agrupados. La estructura es similar a ISO 27001 pero el enfoque es distinto: gobernar el ciclo de vida de sistemas de IA.

El alcance importa más de lo que parece

Si declaras “todos los sistemas de IA de la empresa” en tu alcance, te metes en un berenjenal. Yo declaré “sistemas de IA con impacto en clientes externos y procesos críticos internos”. Eso me dejó fuera del scope pilotos experimentales y herramientas internas de bajo riesgo. La auditora aceptó.

Copilot 365 es complicado de encajar

Es un sistema de IA, está dentro del alcance de cualquier organización con uso empresarial. Pero el control no es solo tuyo. Es de Microsoft. ¿Cómo justificas controles sobre algo que no controlas tú?

Lo que hice. Documenté el contrato con Microsoft como evidencia primaria de controles compartidos. DPA, EDP, attestations. Cada control de Annex A donde Microsoft es responsable principal, lo apoyé con documentación contractual.

Para los controles donde la responsabilidad es mía (configuración, supervisión, uso adecuado), construí mi documentación. Políticas internas de uso, capacitaciones, monitoreo, incident response.

Para los controles donde es responsabilidad compartida, documenté el split: qué hace Microsoft, qué hago yo, dónde está la frontera. Esto fue lo más laborioso.

El AI System Impact Assessment de cada caso de uso significativo de Copilot. Cada agente custom tiene su AIAS. Plantilla común, contenido específico.

Lo que me sorprendió

Que la auditoría no exigió evidencia técnica profunda de Copilot — Microsoft ya tiene certificaciones que la auditora aceptó como base. Mi trabajo fue probar mi gobierno encima de eso, no replicar la auditoría de Microsoft.

Que la madurez del programa importa más que la cantidad de documentos. La auditora preguntó cómo decido aprobar un nuevo caso de uso de Copilot. Le mostré el comité, las plantillas, las decisiones recientes con sus rationales. Eso convenció más que mil páginas estáticas.

Lo que está mal en muchos programas que vi después

Sobredocumentación. Mil páginas de políticas que nadie ha leído. Nadie aprueba un programa con políticas estáticas que no se aplican.

Subimplementación. Mucha política, poca evidencia operativa. La política dice “revisamos riesgos trimestralmente” pero no hay actas trimestrales. La auditora lo huele.

Si te pones a esto: empieza por el alcance honesto, después los AIAs de tus casos de uso principales, después la política. La política sin casos no protege a nadie.

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.