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.