Introducción
Microsoft ha publicado una nota de transparencia para Foundry Agent Service, dentro de Microsoft Foundry, orientada a explicar cómo debe entenderse y evaluarse el uso de agentes de IA en aplicaciones reales.
La idea central de una nota de transparencia no es presentar una característica aislada del producto, sino ayudar a quienes diseñan, despliegan o gobiernan sistemas de IA a comprender tres aspectos clave:
- cómo funciona la tecnología a alto nivel;
- qué capacidades y limitaciones deben tenerse en cuenta;
- qué decisiones del propietario del sistema pueden influir en el comportamiento, rendimiento y riesgos del agente.
En el caso de Foundry Agent Service, Microsoft lo describe como un servicio administrado para crear, desplegar y escalar agentes de IA extensibles, sin que los equipos tengan que gestionar directamente toda la infraestructura subyacente de cómputo y almacenamiento. Aun así, el hecho de que el servicio esté administrado no elimina la responsabilidad del equipo que diseña el sistema: las decisiones sobre datos, herramientas, permisos, supervisión y experiencia de usuario siguen siendo críticas.
Nota: En este artículo se utiliza el nombre del servicio según la documentación oficial consultada: Foundry Agent Service. En algunos contextos puede aparecer asociado al ecosistema de Azure y Microsoft Foundry, pero conviene respetar la denominación oficial de la documentación.
Qué es una nota de transparencia
Una Transparency Note de Microsoft es un documento diseñado para explicar de forma práctica cómo debe evaluarse una tecnología de IA antes de integrarla en un sistema mayor.
Microsoft insiste en una idea importante: un sistema de IA no está formado únicamente por el modelo o por el servicio técnico. También incluye:
- las personas que lo utilizan;
- las personas afectadas por sus resultados;
- los procesos donde se integra;
- las fuentes de datos disponibles;
- las herramientas a las que puede acceder;
- el entorno operativo y regulatorio donde se despliega.
Esta aproximación es especialmente relevante en sistemas basados en agentes, porque un agente no se limita necesariamente a generar texto. Según su diseño, puede razonar sobre una petición, consultar información, utilizar herramientas externas o producir una respuesta que influya en una decisión posterior.
Por tanto, la transparencia debe abordarse como una propiedad del sistema completo, no solo como una etiqueta añadida a la interfaz.
Foundry Agent Service: visión general
Foundry Agent Service está orientado a ayudar a los desarrolladores a construir agentes de IA que puedan integrarse con modelos, herramientas y conocimiento empresarial. La documentación oficial lo presenta como un servicio completamente administrado, pensado para simplificar la construcción, despliegue y escalado de agentes extensibles.
Desde una perspectiva de arquitectura, esto implica separar varias responsabilidades:
- La plataforma administrada, que proporciona capacidades para ejecutar y escalar agentes.
- Los modelos utilizados, que condicionan la calidad, estilo y límites de las respuestas.
- Las herramientas y datos conectados, que amplían lo que el agente puede consultar o hacer.
- El diseño del sistema, que define permisos, instrucciones, controles, evaluación y experiencia de usuario.
- La supervisión operativa, que permite detectar errores, usos indebidos o comportamientos no deseados.
La nota de transparencia debe leerse precisamente desde esa óptica: no como una garantía automática de comportamiento seguro, sino como una guía para diseñar, evaluar y desplegar agentes con mayor responsabilidad.
Por qué la transparencia es especialmente importante en agentes de IA
Los agentes de IA introducen retos distintos a los de una aplicación tradicional de búsqueda o de un chatbot simple. En un sistema agentivo, el comportamiento puede depender de múltiples factores:
- la solicitud del usuario;
- las instrucciones del sistema;
- el contexto conversacional;
- las fuentes de información disponibles;
- las herramientas habilitadas;
- las restricciones de permisos;
- la forma en que se gestionan errores o incertidumbre.
Esto hace que la transparencia sea necesaria en varios niveles.
Transparencia para usuarios finales
Los usuarios deben entender cuándo están interactuando con un sistema de IA, qué tipo de ayuda pueden esperar y qué límites tiene. En escenarios empresariales, también es recomendable que puedan distinguir entre:
- información recuperada de una fuente corporativa;
- inferencias generadas por el modelo;
- acciones sugeridas pero no ejecutadas;
- acciones realmente ejecutadas por el sistema.
No siempre será necesario mostrar todos los detalles técnicos, pero sí ofrecer suficiente contexto para que el usuario no atribuya al agente una autoridad o precisión que no tiene.
Transparencia para equipos técnicos
Los equipos de arquitectura, desarrollo, seguridad y operaciones necesitan trazabilidad sobre el diseño del agente:
- qué modelos se usan;
- qué herramientas están disponibles;
- qué datos pueden consultarse;
- qué permisos tiene el agente;
- qué registros se generan;
- qué controles existen para prevenir acciones no deseadas;
- cómo se evalúa la calidad de las respuestas.
Esta transparencia técnica es esencial para depurar incidentes, mejorar el sistema y cumplir requisitos internos de gobierno.
Transparencia para responsables de negocio y cumplimiento
Los responsables de producto, legal, compliance o riesgo necesitan comprender dónde se está utilizando IA, con qué finalidad y bajo qué controles.
En este punto, la nota de transparencia ayuda a formular preguntas relevantes antes del despliegue:
- ¿Cuál es el propósito previsto del agente?
- ¿Qué decisiones puede influir?
- ¿Qué usuarios estarán expuestos al sistema?
- ¿Qué impacto puede tener una respuesta incorrecta?
- ¿Existen revisiones humanas en los puntos críticos?
- ¿Qué mecanismos de mitigación se han previsto?
Capacidades y límites: cómo interpretarlos correctamente
Una nota de transparencia no debe interpretarse como una promesa de que el sistema será siempre correcto, seguro o adecuado para cualquier caso de uso. Su función es ayudar a comprender las capacidades y los límites de la tecnología.
En agentes de IA, algunos límites habituales que conviene considerar son:
- posibilidad de respuestas incompletas o incorrectas;
- dependencia de la calidad y actualidad de las fuentes conectadas;
- sensibilidad a instrucciones ambiguas o contradictorias;
- riesgo de que el usuario sobreconfíe en la respuesta;
- necesidad de validar acciones sensibles antes de ejecutarlas;
- dificultad para anticipar todos los comportamientos en conversaciones abiertas.
La mitigación de estos riesgos no depende de una única configuración. Requiere diseño de producto, evaluación técnica, controles de acceso, monitorización y formación de usuarios.
Decisiones de diseño que afectan al comportamiento del agente
La documentación de transparencia de Microsoft pone el foco en las decisiones que los propietarios del sistema pueden tomar y que influyen en el rendimiento y comportamiento del agente.
En la práctica, estas decisiones suelen agruparse en varias áreas.
1. Propósito y alcance
Antes de desplegar un agente, conviene definir con precisión para qué sirve y para qué no sirve.
Un agente interno para ayudar a localizar documentación técnica no tiene el mismo perfil de riesgo que un agente que asiste en procesos financieros, sanitarios, legales o de recursos humanos. Cuanto mayor sea el impacto potencial, mayor debe ser el nivel de control, evaluación y supervisión humana.
Una definición clara del alcance ayuda a:
- limitar expectativas;
- diseñar instrucciones más robustas;
- restringir herramientas innecesarias;
- reducir superficies de riesgo;
- crear métricas de evaluación adecuadas.
2. Datos y conocimiento disponible
Los agentes pueden ser más útiles cuando trabajan con información relevante para el dominio. Pero conectar datos al agente también introduce riesgos:
- exposición de información sensible;
- uso de datos desactualizados;
- mezcla de fuentes con distintos niveles de confianza;
- respuestas basadas en contenido no validado;
- problemas de permisos si el agente accede a información que el usuario no debería ver.
Una buena práctica es documentar qué fuentes puede utilizar el agente, bajo qué permisos y con qué mecanismos de actualización o validación.
También conviene diseñar la experiencia para que, cuando sea apropiado, el usuario pueda ver referencias, citas o indicaciones sobre la procedencia de la información. Esto no convierte automáticamente una respuesta en correcta, pero facilita su verificación.
3. Herramientas y acciones habilitadas
Un agente puede tener acceso a herramientas externas para consultar sistemas, preparar tareas o iniciar acciones. Desde el punto de vista de transparencia y seguridad, no todas las herramientas tienen el mismo nivel de riesgo.
No es lo mismo una herramienta de solo lectura que una herramienta capaz de modificar datos, enviar comunicaciones, crear recursos o iniciar flujos de negocio.
Para herramientas con impacto operativo, es recomendable aplicar controles como:
- mínimo privilegio;
- separación entre lectura y escritura;
- confirmación explícita antes de acciones sensibles;
- registros de auditoría;
- límites de alcance;
- validaciones previas;
- posibilidad de revisión humana.
La transparencia aquí no consiste solo en registrar que una acción ocurrió, sino en que el sistema pueda explicar de forma comprensible qué se intentó hacer, con qué parámetros relevantes y cuál fue el resultado.
4. Instrucciones y comportamiento esperado
Las instrucciones del agente condicionan su estilo, límites y forma de actuar. Deben ser coherentes con el propósito del sistema y evitar ambigüedades innecesarias.
Es recomendable especificar, por ejemplo:
- qué debe hacer el agente si no tiene información suficiente;
- cuándo debe pedir aclaraciones;
- cuándo debe negarse a responder;
- cuándo debe derivar a una persona;
- cómo debe tratar información sensible;
- cómo debe comunicar incertidumbre.
Un diseño responsable no busca que el agente responda siempre, sino que responda adecuadamente dentro de su ámbito.
5. Evaluación y supervisión
La transparencia también implica poder evaluar el sistema antes y después del despliegue.
Algunas prácticas recomendables son:
- pruebas con casos representativos;
- pruebas con casos límite;
- revisión de respuestas incorrectas o incompletas;
- evaluación de seguridad y privacidad;
- análisis de comportamiento ante instrucciones maliciosas;
- monitorización de uso real;
- canales de feedback para usuarios;
- procesos de mejora continua.
Los agentes deben tratarse como sistemas vivos: su comportamiento puede cambiar al modificar instrucciones, herramientas, modelos, datos o patrones de uso.
Ejemplo conceptual: agente de soporte interno
Imaginemos un agente de soporte interno diseñado para ayudar a empleados a encontrar documentación corporativa y resolver dudas frecuentes sobre procedimientos técnicos.
Un diseño transparente debería responder a preguntas como las siguientes.
Propósito
El agente sirve para orientar a empleados en la búsqueda de información interna y resumir procedimientos existentes. No sustituye a los responsables de cada proceso ni toma decisiones vinculantes.
Datos disponibles
El agente puede consultar fuentes documentales autorizadas. Los permisos deben respetar el acceso del usuario y evitar que una persona reciba información para la que no tiene autorización.
Respuestas
Cuando el agente responde, debe indicar si la respuesta se basa en documentación disponible, si existe incertidumbre o si recomienda consultar a un responsable humano.
Un ejemplo de respuesta transparente podría ser:
{
"respuesta": "Según la documentación interna disponible, el procedimiento de solicitud debe iniciarse desde el portal corporativo. No he encontrado una referencia actualizada sobre excepciones para este caso.",
"fuentes_consultadas": [
"Manual interno de procedimientos",
"Guía de soporte corporativo"
],
"acciones_realizadas": [],
"recomendacion": "Revisar con el equipo responsable si se trata de una excepción no documentada."
}
Este ejemplo es conceptual y no representa una API concreta del servicio. Su objetivo es ilustrar el tipo de información que puede mejorar la comprensión del usuario y facilitar la revisión posterior.
Acciones
Si el agente pudiera crear un ticket de soporte, enviar una solicitud o actualizar un registro, el diseño debería exigir confirmación previa y registrar la acción.
Por ejemplo:
{
"accion_propuesta": "Crear ticket de soporte",
"requiere_confirmacion": true,
"motivo": "El usuario indicó que no puede completar el procedimiento con la información disponible.",
"datos_relevantes": {
"categoria": "Soporte interno",
"prioridad": "Normal"
}
}
De nuevo, se trata de un patrón de diseño, no de una llamada real a un SDK.
Buenas prácticas para adoptar Foundry Agent Service con responsabilidad
A partir de los principios de la nota de transparencia, los equipos que evalúen Foundry Agent Service deberían considerar las siguientes prácticas.
Definir el caso de uso con precisión
Evita desplegar agentes de propósito excesivamente amplio sin controles claros. Cuanto más abierto sea el ámbito, más difícil será evaluar calidad, seguridad y cumplimiento.
Aplicar mínimo privilegio
El agente solo debería tener acceso a los datos y herramientas estrictamente necesarios para su función. Esta regla es especialmente importante cuando existen acciones de escritura o sistemas con información sensible.
Diseñar para la incertidumbre
El agente debe poder reconocer cuándo no sabe, cuándo la información es insuficiente o cuándo la petición queda fuera de su alcance.
Una respuesta honesta como “no tengo información suficiente para confirmarlo” suele ser preferible a una respuesta aparentemente segura pero no verificable.
Separar sugerencias de acciones
En muchos escenarios, el agente puede sugerir una acción sin ejecutarla automáticamente. Cuando una acción tenga impacto real, conviene solicitar confirmación explícita o intervención humana.
Registrar eventos relevantes
La trazabilidad ayuda a investigar errores, revisar decisiones y mejorar el sistema. Los registros deben diseñarse respetando requisitos de privacidad y seguridad, evitando almacenar más información sensible de la necesaria.
Informar al usuario
El usuario debe saber que interactúa con un sistema de IA y entender sus límites principales. En sistemas internos, esto puede complementarse con guías de uso, mensajes en la interfaz y formación básica.
Evaluar antes de producción
Antes del despliegue, conviene probar el agente con ejemplos reales, casos límite y escenarios de fallo. La evaluación debe cubrir no solo precisión, sino también seguridad, privacidad, robustez y experiencia de usuario.
Riesgos que no deben ignorarse
La transparencia no elimina los riesgos, pero ayuda a identificarlos y gestionarlos. En agentes de IA, algunos riesgos habituales son:
- respuestas incorrectas presentadas con apariencia de seguridad;
- uso de fuentes no autorizadas o poco fiables;
- exposición accidental de información sensible;
- ejecución de acciones no deseadas;
- dependencia excesiva del usuario en la respuesta del agente;
- dificultad para auditar decisiones si no se registran eventos relevantes;
- falta de claridad sobre quién es responsable del resultado final.
Estos riesgos deben analizarse según el contexto. Un agente de ayuda documental puede requerir controles distintos a un agente integrado en procesos críticos de negocio.
Implicaciones para arquitectos y responsables técnicos
Para arquitectos cloud, equipos de plataforma y responsables técnicos, la nota de transparencia de Foundry Agent Service refuerza una conclusión importante: desplegar agentes de IA no es solo una cuestión de consumir un servicio administrado.
También requiere diseñar una arquitectura de control alrededor del agente:
- identidad y permisos;
- gobierno de datos;
- selección y evaluación de modelos;
- gestión de herramientas;
- observabilidad;
- auditoría;
- experiencia de usuario;
- revisión humana en puntos críticos;
- procesos de mejora continua.
La madurez del sistema dependerá tanto de la plataforma como de estas decisiones de diseño.
Conclusión
La nota de transparencia para Foundry Agent Service debe leerse como una guía para entender y gobernar mejor los sistemas basados en agentes de IA. Microsoft presenta el servicio como una plataforma administrada para construir, desplegar y escalar agentes extensibles, pero la responsabilidad de diseñar un sistema adecuado al contexto sigue recayendo en quienes lo implementan.
La transparencia no consiste únicamente en mostrar información técnica. Implica explicar el propósito del agente, sus límites, las fuentes que utiliza, las herramientas que puede emplear, las acciones que realiza y los controles que existen para reducir riesgos.
Para equipos técnicos, la recomendación práctica es clara: antes de llevar un agente a producción, conviene documentar su alcance, restringir sus permisos, evaluar su comportamiento, registrar eventos relevantes y comunicar sus límites a los usuarios.
Fuente principal: Transparency Note for Foundry Agent Service — Microsoft Learn.