Prototipo, trazado, evaluación, red team: un flujo de trabajo para agentes de IA en Microsoft Foundry.

Obtener unas pocas respuestas decentes de un agente de IA lleva minutos. Decidir si es adecuado publicarlo toma mucho más tiempo, ya que el equipo primero debe averiguar si el modelo elegido justifica su costo, si el agente utiliza los datos correctos, qué herramientas ha empleado, cómo califican sus respuestas y cómo se comporta frente a alguien que intenta activamente sabotearlo.

Microsoft Foundry reúne una gran parte de este proceso en un único espacio de trabajo en el navegador que incluye comparación de modelos, instrucciones, herramientas y conocimientos, seguimiento, evaluación, datos de prueba generados y pruebas automatizadas de tipo “red teaming”. Su verdadero valor no radica en poder posponer indefinidamente la escritura del código, sino en permitir tomar decisiones de diseño costosas mientras el proyecto aún es fácil de modificar, antes de que el código en producción establezca restricciones estrictas al respecto.

Lo que sigue sigue la trayectoria de un agente desde un proyecto en blanco hasta un prototipo basado en datos, el cual es monitoreado, evaluado y sometido a pruebas, marcando además el momento en que el trabajo pasa del portal al SDK. El escenario es el entorno de agentes comerciales de Microsoft Build dentro de la nueva experiencia Foundry, alojado en la región Sweden Central. El portal funciona como plataforma para iteraciones rápidas, y el camino hacia la producción se mantiene dentro del mismo proyecto Foundry, por lo que no es necesario reconstruir nada desde cero.

Comience con algo que ya funcione

Un proyecto nuevo de Foundry es un espacio de trabajo que contiene agentes, modelos, herramientas, conocimientos, sistemas de evaluación y capacidades de observabilidad. Los pasos exactos de configuración, los valores predeterminados y las funciones disponibles varían según la región y evolucionan con el tiempo, por lo que el portal en sí debe considerarse como la fuente definitiva sobre las posibilidades de un proyecto.

Una vez creado un agente, es en el entorno de pruebas donde comienza el trabajo real. Allí se definen el modelo e instrucciones, se adjuntan herramientas o conocimientos, y los resultados se prueban en el panel de chat. También es aquí donde un prototipo revela por primera vez cuán deficiente es. Si se le plantea a un agente apenas configurado una pregunta relacionada con un producto complejo, la respuesta suele ser insípida. Puede sonar seguro aunque no sepa nada sobre el catálogo, las políticas ni el contexto empresarial. Considere esa respuesta como punto de referencia, ya que toda modificación posterior debe evaluarse en comparación con ella.

Elegir un modelo basándose en pruebas

Un modelo predeterminado sólido no es necesariamente el más adecuado para producción. Algunas tareas requieren un razonamiento profundo, mientras que otras valoran la velocidad o un precio bajo; por lo tanto, la selección debe basarse en una evaluación y no en intuiciones. Foundry ofrece varias herramientas para filtrar el catálogo:

• Un ranking que clasifica a los modelos según las medidas de calidad, seguridad, rendimiento y costos disponibles.
• Gráficos de equilibrio que representan dos dimensiones en un mismo gráfico, como la calidad frente al precio.
• Una vista lado a lado que reduce la lista a modelos adecuados para la carga de trabajo.
• Un enrutador de modelos que asigna cada solicitud a un modelo adecuado según una política de relación costo-calidad, de modo que un solo modelo no necesite responder a todo.

Los puntajes de las pruebas de referencia por sí solos son una evidencia débil. Ejecutar la misma carga de trabajo en cada modelo candidato es más fiable. El enrutador resulta útil cuando las solicitudes difieren mucho en dificultad. Actualmente ofrece modos Equilibrado, Costo y Calidad, y las versiones actuales cambian automáticamente a otro modelo disponible si el asignado deja de funcionar.

El siguiente paso es enviar los mismos prompts a cada configuración de candidato y comparar la calidad de las respuestas, la latencia y el costo. Los puntos de referencia reducen el abanico de opciones, y su propio volumen de trabajo elige al ganador. Microsoft Learn describe tanto el flujo de trabajo de los puntos de referencia como el router en su documentación de Foundry.

Las instrucciones son la herramienta más económica

Cambiar de modelo no siempre es el primer paso adecuado. Instrucciones vagas pueden reducir un modelo costoso a un chatbot genérico. El Prompt Optimizer de Foundry reescribe y reestructura las instrucciones, explica los motivos de las ediciones en secciones específicas y permite realizar varias pasadas antes de aplicar cualquier cambio. De esta manera, las instrucciones se convierten en una entrada versionada para el equipo de ingeniería, en lugar de un párrafo sin estructura que se vuelve a redactar hasta que la respuesta parezca mejor.

Una reescritura superficial no demuestra mucho. La forma más eficaz de verificarlo consiste en probar un conjunto de datos de evaluación con tanto la versión antigua como la nueva. Cualquier persona, formato de respuesta, comportamiento de respaldo o límite en las solicitudes fuera de tema que el agente debe seguir debe estar incluido tanto en sus instrucciones como en los evaluadores que califican su salida.

Asociar respuestas a datos aprobados

Las instrucciones determinan cómo se comporta el agente, mientras que el conocimiento determina qué puede responder. En casos sencillos, adjuntar archivos y exponerlos a través de herramientas de recuperación permite que las respuestas citen el material de origen.

Las instalaciones empresariales más grandes pueden utilizar Foundry IQ, una capa de conocimiento compartida que integra múltiples fuentes. Una base de conocimientos puede vincular Azure Blob Storage, SharePoint, OneLake, índices de búsqueda existentes y contenido web público, y los planes de recuperación del agente organizan las consultas, eligen las fuentes, las buscan y devuelven resultados fundamentados y citados.

Existe una advertencia relacionada con el control de acceso. Los permisos a nivel de documento solo se respetan en fuentes y configuraciones que los soporten, por lo que nadie debería describir una base de conocimientos como capaz de reconocer permisos antes de que los permisos de la fuente y el flujo de identidad estén realmente configurados.

Para observar el efecto, haga una pregunta dos veces, antes y después de activar la funcionalidad. La primera respuesta revela el conocimiento general del modelo, mientras que la segunda debería mostrar la diferencia que generan sus datos.

Active el seguimiento temprano

La observabilidad es de gran ayuda mientras el agente sigue fallando. El seguimiento de Foundry sigue las convenciones de OpenTelemetry y se integra con Azure Monitor Application Insights, registrando el camino seguido por un agente o aplicación para que posteriormente se puedan examinar las llamadas al modelo, el uso de herramientas, las entradas, las salidas y los tiempos de ejecución.

Tres capas se basan en esa imagen operativa compartida, cada una respondiendo a su propia pregunta:

• El seguimiento le indica qué ocurrió en una ejecución específica.
• La evaluación le muestra si el comportamiento cumplió con los estándares.
• El monitoreo le permite conocer la tendencia de las ejecuciones a lo largo del tiempo.

Tenga en cuenta que la telemetría de Application Insights tiene un costo relacionado con el volumen y el período de retención de los datos. Asigne un presupuesto para la capacidad de observación como parte de la arquitectura de producción y no como un beneficio adicional gratuito para depurar.

Mida el comportamiento, no las conjeturas

Las pruebas prácticas son útiles para explorar, pero no pueden determinar si un cambio mejoró al agente. Foundry incluye evaluadores listos para usar en varias dimensiones del comportamiento: calidad, riesgo y seguridad, además de métricas específicas del agente, como si se siguió la tarea, si se completó, si se comprendió la intención y qué tan bien se llamaron las herramientas.

Los evaluadores personalizados suelen adoptar una de dos formas. Los basados en rúbricas o indicaciones utilizan un modelo como juez para criterios subjetivos o que dependen del contexto. Los deterministas son funciones simples para criterios que se pueden calcular directamente. La amabilidad de una respuesta podría requerir una rúbrica, mientras que un límite de longitud nunca lo hace. La evaluación añade costos y ruido propios, por lo que cuando una función puede tomar la decisión de manera fiable, invocar otro modelo es un derroche de dinero.

Los conjuntos de datos hacen que la iteración sea rigurosa

Una sola indicación muestra que una función funciona, pero un conjunto de datos revela patrones. Foundry puede calificar un archivo JSONL o CSV que hayas preparado, registros que ya poseas o datos de prueba sintéticos. Los datos sintéticos son útiles antes del lanzamiento y cuando el tráfico real es demasiado escaso como para abarcar los casos límite de interés.

El resultado es un bucle que se puede repetir:

1. Corregir un conjunto de pruebas representativo para que permanezca constante.
2. Ejecutar la versión actual del agente en él.
3. Modificar exactamente una variable, ya sea el modelo, las instrucciones, la configuración de la herramienta o los parámetros de anclaje.
4. Evaluar nuevamente en el mismo conjunto.
5. Comparar las puntuaciones, los tiempos de respuesta y el consumo.
6. Aceptar o descartar el cambio.

Aquí el trabajo deja de parecerse a la ajuste de prompts y comienza a asemejarse a las pruebas de regresión para software.

El equipo rojo detecta lo que las puntuaciones normales pasan por alto

Las pruebas de calidad habituales buscan determinar si el agente realiza bien su tarea asignada. El red teaming, en cambio, analiza qué hace el sistema cuando alguien le proporciona intencionadamente datos hostiles. El Agente de Red Teaming para IA incluido en Foundry combina el proyecto de código abierto PyRIT con la evaluación de riesgos y seguridad de Foundry. Prueba los modelos y agentes compatibles con métodos de ataque diseñados para eludir las medidas de protección estándar, y reporta una Tasa de Éxito en los Ataques (ASR).

Los métodos soportados incluyen transformaciones como Flip y Tense, así como técnicas de jailbreak y otros trucos adversariales. Los escenarios de riesgo actuales abarcan contenido dañino, fugas de datos sensibles, acciones prohibidas e inyección indirecta de instrucciones. Este ejercicio rinde frutos cuando su informe impulsa otra ronda de trabajo técnico, y no cuando termina siendo solo una captura de pantalla para cumplir con requisitos. Considérelo como un ciclo:

1. Ejecute un escaneo en un lugar que no sea de producción.
2. Analice qué categoría de riesgo y método de ataque lograron pasar.
3. Corrija la causa, ya sea una instrucción, un límite de herramienta, un control de contenido o un permiso.
4. Ejecute otro escaneo.
5. Observe si la tasa de éxito de los ataques disminuye con el tiempo.

Vigile toda la flota

Una vez que los agentes están en funcionamiento, la pregunta deja de ser si una instrucción funcionó y pasa a ser cómo se comporta el sistema a lo largo de las semanas. Las vistas de monitoreo y operación muestran indicadores para toda la carga de trabajo, como el número de llamadas, el uso de tokens, los fallos y métricas basadas en costos, con la posibilidad de profundizar en agentes y modelos específicos cuando esté disponible.

Pensar en microservicios es útil aquí, dentro de ciertos límites. Un agente puede considerarse como una unidad de comportamiento con su propia versión, compuesta por instrucciones, herramientas, conocimientos, una política de modelo y resultados que se pueden observar. No es necesario que cada agente se convierta en un servicio desplegado por separado. Lo importante es establecer límites para que se pueda editar, evaluar y promover a un agente sin tener que reescribir todo lo que está cerca de él.

El ciclo detrás del portal

En la práctica, el ciclo consta de construir, medir, optimizar, gestionar y volver al inicio cada vez que las pruebas indican que el agente aún no está listo. Se avanza porque los registros y las puntuaciones superan un umbral establecido de antemano, y nunca porque una demostración haya sido buena. Las pantallas del producto cambian, pero la rutina permanece: prototipar, registrar, evaluar, reforzar, monitorear y repetir.

Una advertencia por ahora: Microsoft planea dejar de utilizar Foundry Workflows el 1 de diciembre de 2026 y dirige los nuevos flujos de trabajo hacia Microsoft Agent Framework. No se debe crear un diseño nuevo sobre la base de lo que está siendo eliminado.

De prototipo en el navegador a código de producción

El portal debería acortar el camino hacia el código y no sustituirlo. Necesidades como la orquestación personalizada, CI/CD, una integración más profunda o código de agente alojado requieren el Foundry SDK y sus herramientas, actualmente disponibles para Python, C#, JavaScript y Java. Arquitectónicamente, los recursos y puntos de extremo del proyecto siguen siendo centrales. El portal, el SDK y las herramientas son simplemente diferentes vías de acceso a un mismo proyecto Foundry y sus recursos; por lo tanto, imagine un proyecto con un punto de extremo unificado, sin una plataforma de prototipos y otra de producción separadas. La guía rápida del SDK en Microsoft Learn es donde comienza esa transición.

Siguientes experimentos

A continuación se presentan dos temas. El primero es la orquestación de múltiples agentes, en la cual agentes que pueden probarse de forma independiente, cada uno con un contrato claro y una línea de referencia de evaluación, se combinan mediante un marco de orquestación moderno en lugar de ser incluidos en una sola instrucción extensa. El otro es la personalización de modelos, que solo merece ser evaluada después de que la generación de instrucciones, el anclaje en datos reales, la redirección de tareas y el diseño de herramientas hayan fallado en su función. Cada uno de estos temas corresponde a la disciplina de evaluación descrita aquí.

Pensamiento final

La primera respuesta funcional de un agente inicia el proceso pero no lo concluye. Un candidato a versión final necesita pruebas en varios aspectos: una elección de modelo que resista la comparación con cargas de trabajo, elementos que afecten visiblemente las respuestas, llamadas a herramientas que se puedan ver, una evaluación reproducible, y un número de riesgo del equipo rojo que disminuya con el tiempo. El portal proporciona el ciclo rápido, mientras que el proyecto y el SDK llevan el trabajo hacia la ingeniería de producción real. Construya rápidamente, agregue instrumentación desde temprano, pruebe cada cambio con la misma carga de trabajo, analice su propio sistema antes que terceros lo hagan, y pase al código una vez que el navegador haya respondido adecuadamente a lo que se le solicita.