Respuesta corta
¿Salen los datos de la región Azure del recurso Foundry?
Sí, si activas “Send logs to Microsoft Agent 365” (propiedad a365LoggingEnabled=true). Los datos pasan del modelo de residencia por región Azure al modelo de residencia por geografía del tenant de Entra. Si el tenant Entra está fuera del EEE, los datos cruzan fronteras. Microsoft lo confirma en su documentación oficial: “Microsoft Foundry and Agent 365 follow different data residency models, hence data processing and storage may happen across geographical regions.”
¿Se incumple el GDPR?
No automáticamente. Si el tenant Entra está en el EEE no hay transferencia internacional. Si está fuera del EEE, la transferencia está cubierta legalmente por el DPA de Microsoft (SCCs + EU-U.S. Data Privacy Framework). Incumples el GDPR solo si: (a) no lo documentas en tu Registro de Actividades de Tratamiento (RAT), (b) no informas a los interesados, o (c) tienes una obligación contractual o normativa de residencia local sanidad, finanzas, ENS y lo activas igualmente.
Microsoft Agent 365 alcanzó disponibilidad general el 1 de mayo de 2026 y se integra de serie con Azure AI Foundry. La propuesta es sólida: un panel centralizado para gobernar, observar y securizar todos los agentes de IA de la organización. Pero hay un detalle crítico de residencia del dato que no aparece en los titulares de lanzamiento. Cuando activas la integración entre Foundry y Microsoft Agent 365, los datos de actividad de tus agentes pueden salir de la región Azure que elegiste para tu recurso y seguir un modelo de residencia diferente, el de la geografía del tenant de Microsoft Entra. Para proyectos sujetos a GDPR transferencia internacional, compliance, obligaciones contractuales de localización ese cambio tiene implicaciones concretas que conviene entender antes de tocar el switch. Este artículo desglosa qué ocurre exactamente, qué dice la documentación oficial de Microsoft y qué deberías hacer antes de activar Microsoft Agent 365 en entornos con clientes europeos.
¿Qué es Microsoft Agent 365 y por qué importa ahora?
Microsoft Agent 365 (A365) es el plano de control empresarial para agentes de inteligencia artificial. Alcanzó disponibilidad general el 1 de mayo de 2026 y su propuesta es clara: centralizar en un único lugar la gestión de todos los agentes de una organización, independientemente de dónde se hayan construido. Eso incluye agentes creados en Foundry, en Copilot Studio, o registrados manualmente por el administrador de IT.
La plataforma pivota sobre tres capacidades nucleares. La primera es la observabilidad: un registro unificado con inventario de todos los agentes activos, métricas de uso y señales de riesgo en tiempo real. La segunda es la gobernanza: ciclo de vida del agente, control de acceso basado en Microsoft Entra ID y políticas de acceso condicional. La tercera es la seguridad: integración con Microsoft Defender, Microsoft Purview y el stack de seguridad de Microsoft para detectar comportamientos anómalos y prevenir filtraciones de datos.
La integración con Foundry sucede en dos planos complementarios. Por un lado, los agentes publicados en Foundry aparecen automáticamente en el registro de A365 cuando la suscripción está habilitada, lo que da a los administradores visibilidad cross-tenant sin necesidad de registro manual. Por otro, los agentes alojados (Hosted Agents) pueden publicarse como ‘digital workers’, recibir su propio Entra Agent ID y conectarse a Teams u otras superficies de Microsoft 365 previo proceso de aprobación.
Figura: Los tres pilares de Microsoft Agent 365: observar, gobernar y securizar (fuente: learn.microsoft.com)
¿Qué gana Azure AI Foundry al integrarse con Microsoft Agent 365?
Sin A365, la observabilidad de los agentes de Foundry pasa por las herramientas habituales de Azure: Application Insights, Azure Monitor, Log Analytics. Son potentes, pero se quedan en el ámbito del recurso. No te dan visibilidad de qué agentes tiene activos toda la organización, ni permiten comparar comportamientos entre proyectos o entornos.
Agent 365 cambia eso. Cuando la integración está activa, los datos de actividad de los agentes de Foundry fluyen hacia el plano de control de A365 y alimentan tres cosas: el registro centralizado de agentes (quién usa qué, con qué frecuencia, qué recursos toca), los dashboards analíticos con métricas de rendimiento y adopción, y las detecciones de seguridad de Defender y Purview. En términos prácticos, los administradores de IT pasan de ver ‘el agente X de este proyecto’ a tener una vista consolidada de toda la flota de agentes.
La tabla de soporte por tipo de agente en la documentación oficial es relevante aquí. Los Prompt Agents tienen soporte completo: sincronización con el registro, publicación como digital worker y recopilación de datos de actividad. Los Hosted Agents también sincronizan y pueden publicarse, pero la recopilación de actividad requiere configuración manual del SDK de A365 en el propio código del agente. Los Workflow Agents, por su parte, solo sincronizan con el registro sin publicación como digital worker ni recogida de actividad.
El switch que lo controla todo: a365LoggingEnabled
La opción que ves en el portal de Azure como ‘Send logs to Microsoft Agent 365’ corresponde a la propiedad a365LoggingEnabled del recurso Foundry (tipo Microsoft.CognitiveServices/accounts). Tiene dos valores posibles: true o false. Junto a ella, el sistema expone una propiedad de solo lectura, a365Status, que puede tomar tres estados: Enabled, Disabled o NotLicensed.
Hay una trampa conceptual importante: habilitar a365LoggingEnabled en el recurso de Azure Resource Manager no es suficiente para que los datos fluyan. Hacen falta tres condiciones simultáneas: que el tenant Entra tenga licencia válida de Agent 365, que un administrador global haya aceptado los términos del servicio en el centro de administración de Microsoft 365, y que a365LoggingEnabled esté a true. Si falta cualquiera de las tres, a365Status queda en Disabled o NotLicensed y no sale ningún dato.
Importante: cuando Agent 365 se habilita para un tenant, todos los recursos Foundry quedan con a365LoggingEnabled=true de forma automática. El opt-out es explícito, no el opt-in. El ajuste aplica a nivel de recurso completo, sin granularidad por proyecto ni por agente individual.
Para deshabilitar el envío de logs a A365 desde CLI, el comando es el siguiente:
az resource update \
–resource-group <resource-group> \
–name <foundry-resource-name> \
–resource-type Microsoft.CognitiveServices/accounts \
–api-version 2026-03-15-preview \
–set properties.a365LoggingEnabled=false
También se puede gestionar con Azure PowerShell, REST API, Bicep o Terraform (AzAPI). Y para aplicar la restricción de forma centralizada a toda una suscripción o management group, la documentación oficial describe cómo usar Azure Policy para negar el valor true en entornos donde la compliance lo exija.
¿Salen los datos de Foundry de la región Azure al activar Agent 365?
Aquí está el punto que más atención merece si trabajas con datos de clientes europeos. Foundry y Agent 365 siguen modelos de residencia del dato completamente distintos, y eso tiene consecuencias directas.
Foundry sigue el modelo de región Azure. Cuando creas un recurso Foundry en, por ejemplo, Sweden Central o West Europe, todos los datos del agente conversaciones, embeddings, logs de inferencia, datos almacenados se quedan en esa región. Es el comportamiento estándar que los arquitectos conocen y el que suelen documentar en sus análisis de impacto.
Agent 365 funciona de otra manera. Su residencia del dato no sigue la región del recurso Azure: sigue la ubicación geográfica del tenant de Microsoft Entra. En términos prácticos, si el tenant de tu cliente tiene su storage location en Estados Unidos algo habitual en empresas multinacionales que crearon su tenant antes de que existiera la opción de elegir geografía los datos de actividad de los agentes que fluyen a A365 pueden acabar almacenados y procesados fuera de la UE.
Aviso literal de la documentación oficial: «Agent 365 logging data may be stored and processed outside the Azure region of this resource.» Este aviso aparece tanto en la conceptual de integración como en el propio portal de Azure al configurar la opción.
La documentación oficial reconoce explícitamente esta diferencia: ‘Microsoft Foundry and Agent 365 follow different data residency models, hence data processing and storage may happen across geographical regions.’ No es ambiguo. Es una transferencia de datos del modelo de residencia por región Azure al modelo de residencia por tenant Entra.
Implicaciones GDPR concretas para arquitectos y partners
El GDPR es exigente con las transferencias internacionales de datos personales. Si los logs de actividad de los agentes contienen datos personales y en muchos despliegues empresariales los contienen, aunque sea de forma indirecta a través de identificadores de usuario, fragmentos de conversación o metadatos de sesión el flujo de datos de Foundry hacia Agent 365 puede constituir una transferencia internacional si el tenant Entra tiene su almacenamiento fuera del Espacio Económico Europeo.
Residencia del dato y Capítulo V del GDPR
El Capítulo V del GDPR regula las transferencias de datos personales a terceros países. La base legal habitual para transferencias hacia Estados Unidos es la que proporcionan las Cláusulas Contractuales Tipo (SCCs, Standard Contractual Clauses) de la Comisión Europea, que Microsoft incorpora en su Data Protection Addendum (DPA). El EU-U.S. Data Privacy Framework, vigente desde julio de 2023 y que Microsoft acepta, ofrece una vía adicional. Sin embargo, ambas opciones tienen requisitos: el responsable del tratamiento (tu cliente) debe conocer que la transferencia se produce, bajo qué base legal y con qué salvaguardas. No es suficiente con que Microsoft lo cubra contractualmente si el cliente no lo ha documentado en su Registro de Actividades de Tratamiento.
La clave práctica es esta: si activas A365 para un recurso Foundry y el tenant Entra del cliente tiene su geografía fuera del EEE, estás introduciendo una transferencia internacional que puede no estar contemplada en la documentación de privacidad existente. Eso no significa que sea ilegal el DPA de Microsoft cubre el encargo de tratamiento pero sí significa que necesita ser documentada y justificada.
Microsoft como encargado del tratamiento
En la arquitectura jurídica del GDPR, Microsoft actúa como encargado del tratamiento (processor) cuando procesa datos en Azure por instrucción del cliente. El DPA de Microsoft (disponible en aka.ms/DPA) regula esta relación y cubre los servicios de Azure, incluyendo Foundry. Agent 365, al ser también un servicio de Microsoft, debería quedar bajo el mismo paraguas contractual, pero conviene verificarlo con el equipo legal o el DPO, especialmente si Agent 365 comparte datos con componentes como Microsoft Defender o Microsoft Purview, que tienen sus propios términos y ubicaciones de procesamiento.
Nota: este artículo no constituye asesoramiento legal. Para determinar el impacto exacto en el marco de cumplimiento de tu cliente, consulta con el DPO de la organización y revisa el DPA de Microsoft vigente en aka.ms/DPA.
El RAT y cómo documentar esta integración si se activa
Si la decisión es activar A365, hay que reflejarlo en el Registro de Actividades de Tratamiento (RAT) del responsable del tratamiento. Los campos clave: finalidad (gobernanza y observabilidad de agentes de IA), categorías de datos (identificadores de usuario, metadatos de sesión, fragmentos de interacción con mención explícita si hay datos de categorías especiales), base legal (interés legítimo o ejecución de contrato, con evaluación documentada si se usa interés legítimo) y encargado del tratamiento (Microsoft Corporation, bajo el DPA de Microsoft en aka.ms/DPA).
Si el tenant Entra tiene su geografía fuera del EEE, el RAT debe recoger la base legal de la transferencia internacional SCCs o EU-U.S. Data Privacy Framework con referencia al DPA de Microsoft. En medidas técnicas y organizativas: control de acceso vía Entra ID, cifrado en tránsito y en reposo, y Azure Policy para restringir a365LoggingEnabled en entornos sensibles.
Recomendaciones prácticas para partners y arquitectos
Antes de activar A365 para un cliente, lo primero es averiguar dónde está el almacenamiento del tenant Entra. Si el tenant se creó en Europa y la geografía está en la UE, la transferencia de datos se produce dentro del EEE y la situación es más sencilla desde el punto de vista GDPR. Si el tenant tiene su geografía en Estados Unidos o en otra región fuera del EEE, hay que evaluar si el flujo de datos a A365 está cubierto por el DPA y si el cliente lo ha contemplado en su documentación de privacidad.
Para proyectos con requisitos estrictos de residencia del dato sector sanitario, financiero, administración pública la recomendación conservadora es mantener a365LoggingEnabled a false y usar las herramientas nativas de Azure (Application Insights, Log Analytics) para la observabilidad. Pierdes la vista centralizada cross-tenant de A365, pero los datos no salen del scope de residencia que has comprometido.
Si quieres activar A365 de forma selectiva, aprovecha que el ajuste se aplica por recurso Foundry. Puedes tener un recurso de producción con a365LoggingEnabled a false y un recurso de desarrollo o staging con A365 activado para beneficiarte de la observabilidad centralizada sin afectar a los datos de producción. Para aplicar esta restricción de forma sistemática, usa Azure Policy para denegar el valor true en las suscripciones de producción.
Un detalle operativo importante: el momento en que el administrador global acepta los términos de Agent 365 en el centro de administración de Microsoft 365 es el punto de no retorno. Antes de que eso ocurra, verifica que todos los recursos que deben estar excluidos ya tienen a365LoggingEnabled=false. Para los Hosted Agents hay una capa adicional: si el SDK de A365 está configurado en el código del agente, ese agente puede enviar datos a A365 aunque el recurso Foundry padre tenga el logging deshabilitado. Revisa siempre el código de los agentes alojados antes de asumir que el opt-out a nivel de recurso los cubre.
¿Cuándo activar Microsoft Agent 365 y cuándo dejarlo deshabilitado?
La integración tiene sentido cuando el tenant Entra tiene geografía en el EEE, los agentes no procesan datos de categorías especiales, y el cliente está dispuesto a documentar la activación en su RAT. En ese escenario, la visibilidad centralizada de Agent 365 y la integración con Defender y Purview son un activo real de gobernanza.
Mantén el switch deshabilitado si el tenant Entra tiene geografía fuera del EEE sin evaluación previa, si los agentes tocan datos de categorías especiales, o si el cliente opera en sectores con obligación de residencia del dato verificada sanidad, finanzas, administración pública, ENS. En esos casos, Application Insights y Log Analytics cubren la observabilidad sin traspasar el perímetro de residencia comprometido.
Conclusión
Microsoft Agent 365 es una herramienta de gobernanza genuinamente útil. Un registro centralizado de agentes, visibilidad en tiempo real, integración con Defender y Purview: todo eso tiene valor real para organizaciones que están escalando su uso de agentes de IA. El problema no es la herramienta es el switch que la activa y lo que implica.
La diferencia entre el modelo de residencia de Foundry (por región Azure) y el de Agent 365 (por geografía del tenant Entra) es la pieza que más fácilmente se pasa por alto en un despliegue. Y para clientes europeos bajo GDPR, esa diferencia puede suponer la introducción de una transferencia internacional no documentada.
La buena noticia es que la documentación oficial de Microsoft es transparente al respecto y proporciona mecanismos de control claros: opt-out por recurso vía a365LoggingEnabled, Azure Policy para aplicarlo sistemáticamente, y granularidad para decidir qué entornos envían datos a A365 y cuáles no. La pregunta no es si usar A365 o no — es cuándo, con qué recursos y con qué documentación de respaldo.
Como siempre en estos casos: antes de activarlo en producción, habla con el DPO del cliente, revisa el DPA de Microsoft vigente en aka.ms/DPA, y documenta la decisión en el RAT. Si lo haces así, A365 puede ser un activo de gobernanza sólido. Si no, puede convertirse en una deuda de compliance silenciosa.
Por si te tienes dudas, aquí tienes Q&As
¿Qué es Microsoft Agent 365?
Microsoft Agent 365 es el plano de control empresarial para agentes de inteligencia artificial de Microsoft. Centraliza en un único panel la gobernanza, observabilidad y seguridad de todos los agentes de una organización, independientemente de si se construyeron en Azure AI Foundry, Copilot Studio o se registraron manualmente. Alcanzó disponibilidad general el 1 de mayo de 2026.
¿Activar Agent 365 en Foundry incumple el GDPR?
No de forma automática. Si el tenant de Microsoft Entra tiene su geografía dentro del EEE, no se produce transferencia internacional de datos. Si el tenant está fuera del EEE, la transferencia está cubierta por el DPA de Microsoft mediante SCCs y el EU-U.S. Data Privacy Framework, pero el responsable del tratamiento debe documentarla en el RAT e informar a los interesados. El incumplimiento del GDPR surge si esto no se documenta o si existe una obligación normativa de residencia del dato que se ignora.
¿Cómo desactivo el envío de logs a Agent 365 en un recurso Foundry?
Establece la propiedad a365LoggingEnabled=false en el recurso Foundry (tipo Microsoft.CognitiveServices/accounts). Puedes hacerlo desde Azure CLI con az resource update –set properties.a365LoggingEnabled=false, o mediante Azure PowerShell, REST API, Bicep o Terraform (AzAPI). Para aplicarlo a escala, usa Azure Policy para denegar el valor true en suscripciones o management groups completos.
¿Dónde se almacenan los datos de actividad de Microsoft Agent 365?
Los datos de actividad de Agent 365 se almacenan según la geografía del tenant de Microsoft Entra, no según la región Azure del recurso Foundry. Si el tenant Entra tiene su almacenamiento en EE.UU., los logs de actividad pueden procesarse y almacenarse allí aunque el recurso Foundry esté en West Europe o Sweden Central. Microsoft lo advierte explícitamente: “Agent 365 logging data may be stored and processed outside the Azure region of this resource.”
¿Qué diferencia hay entre la residencia de datos de Foundry y la de Agent 365?
Foundry sigue el modelo de región Azure: los datos del agente permanecen en la región donde creaste el recurso. Agent 365 sigue el modelo de geografía del tenant Entra: los datos de actividad van al almacenamiento asociado al tenant de Microsoft Entra del cliente, que puede estar en una región o país diferente. La documentación oficial lo define así: “Microsoft Foundry and Agent 365 follow different data residency models, hence data processing and storage may happen across geographical regions.”
¿Puedo usar Azure Policy para impedir que un recurso Foundry envíe datos a Agent 365?
Sí. La documentación oficial de Microsoft describe cómo crear una Azure Policy que denégue el valor a365LoggingEnabled=true en los recursos Microsoft.CognitiveServices/accounts. Esto permite aplicar la restricción de forma centralizada a toda una suscripción o management group, garantizando que ningún recurso Foundry en ese scope active el envío de logs a Agent 365, incluso si alguien intenta habilitarlo manualmente desde el portal.