domingo, 1 de marzo de 2026

Por qué a cada agente le tengo que poner nombre y apellido

 

Una de las cosas que me costó más vender internamente este año fue la idea de tratar a cada agente como una identidad de primera clase. La cara del CFO cuando le dije “oye, vamos a tener miles de identidades nuevas, y todas van a costarnos gobernarlas” no fue de las mejores reuniones del trimestre.

Pero es lo que toca.

Microsoft Entra Agent ID, todavía en preview a mayo de 2026, es la pieza estructural. La idea es simple: el agente no es un script anónimo que corre con el token de un humano. El agente tiene su propia identidad, sus propios permisos, su propio dueño accountable, y entra al ciclo de vida de IGA igual que un empleado.

 

The image is a digital dashboard interface displaying a user log with actions for accessing SharePoint, showing user information and status.

El contenido generado por IA puede ser incorrecto.

Lo que cambia en la práctica

Antes, si el agente “robot-X” hacía algo raro, el log decía “user: maria.gonzalez”. Tenías que preguntarle a María si era ella o su agente. Ahora el log dice “agent: robot-x | sponsor: maria.gonzalez”. Forensia más limpia, accountability sin ambigüedad.

Antes, cuando María se iba de la empresa, el agente seguía corriendo con su identidad heredada hasta que alguien se acordara. Ahora hay sponsor tasks en Lifecycle Workflows: si el sponsor humano sale, hay un workflow que pide reasignar o suspender al agente. No es perfecto — la implementación a veces requiere intervención manual — pero existe el carril.

Antes, no podías hacer access reviews sobre lo que un agente puede ver. Ahora sí. Y aquí va lo importante: la primera vez que corrí un access review sobre un agente de Copilot Studio que llevaba ocho meses corriendo, encontré que tenía acceso a SharePoint sites que ya nadie usaba. Permisos que se habían heredado de la cuenta de servicio que el agente reemplazó. Limpiamos casi 200 permisos huérfanos en una tarde.

The image depicts a diagram illustrating the lifecycle of an agent and governance, with key points such as sponsor activation, operational status, disconnection, and access review, including tasks and alerts for reassignment.

El contenido generado por IA puede ser incorrecto.

 

Lo que no me gusta

Que sigue siendo preview. Quiero esto en GA ya. Las features de governance de identidades de máquina nunca van rápido en el roadmap, y entiendo por qué (es complicado hacerlo bien), pero el problema ya está aquí.

Que la integración con Copilot Studio aún tiene gaps. No todos los agentes legacy se migran solos. Tienes que ir uno por uno reasignando, lo cual con una empresa con cientos de agentes pequeños es trabajo manual.

Que el billing de las identidades de agente no está claro todavía. Microsoft dice que se factura como parte de Agent 365, pero la documentación todavía es ambigua sobre cuándo cuenta como identidad facturable y cuándo no. He visto facturas con sorpresas.

Para empezar

Define la política primero, antes de tocar el portal. ¿Qué agentes requieren sponsor? ¿Cuántos sponsors mínimos necesita un agente crítico, uno o dos? ¿Cómo defines “crítico” para empezar? ¿Qué pasa si el sponsor está de vacaciones, sigue corriendo el agente o se pausa? Sin estas definiciones, te vas a meter en un lío político con managers que se sienten responsables de algo que no entienden.

Inventario antes que governance. Si no sabes cuántos agentes corren ya en tu tenant, el primer ejercicio es contarlos. Yo hice un script básico de exportar todo lo que Copilot Studio reporta y crucé contra lo que Defender ya estaba viendo. Aparecieron varios que no estaban en mi lista. Eso solo ya valió el ejercicio.

The image depicts a diagram with a dual focus on governmental policy planning and a cloud infrastructure setup, featuring agents, dashboards, and various metrics such as sponsorship levels and gap detection percentages.

El contenido generado por IA puede ser incorrecto.

Y por último — y esto es opinión personal — no esperes a que GA salga para empezar a pensar en esto. La gobernanza de identidades de agente va a ser el control compensatorio más importante del 2026 y 2027. Si llegas tarde, no hay forma de retro-encajarlo limpiamente.

viernes, 6 de febrero de 2026

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.

The image illustrates a security dashboard within the Entra ID portal, displaying various alerts and statuses related to policy assessments, application vulnerabilities (e.g., CVE-2025-32711), and different levels of auditability, with a focus on data loss prevention and semantic detection.

El contenido generado por IA puede ser incorrecto.

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í.

The image depicts a diagram showcasing a cybersecurity defense strategy, including elements such as a robotic agent, various security measures, and patches for vulnerabilities.

El contenido generado por IA puede ser incorrecto.

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.

The image depicts a digital dashboard in a corporate setting, showcasing various cybersecurity alerts and actions, including threat assessments, policy suggestions, and user confirmations.

El contenido generado por IA puede ser incorrecto.

 

¿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.

Auditable is no-negociable

El contenido generado por IA puede ser incorrecto.

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.

 

The image depicts a complex diagram illustrating various components and processes related to software, including a server, cache bypass, data flow, and security measures, with annotations for potential semantic challenges and behaviors.

El contenido generado por IA puede ser incorrecto.

¿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.

domingo, 1 de febrero de 2026

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.

martes, 30 de diciembre de 2025

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.

sábado, 27 de diciembre de 2025

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.


domingo, 21 de diciembre de 2025

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.