Conectar un agente a AI Server: comprobar todo el ciclo de llamada a herramientas

AI Server proporciona una API compatible con OpenAI para aplicaciones en infraestructura controlada por la organización. Una integración de agente necesita una prueba de aceptación más específica que una respuesta exitosa de chat: el modelo elegido debe proponer la operación prevista, y la aplicación anfitriona debe manejar correctamente esa propuesta. Nuestra página del producto AI Server describe el rol de despliegue; el siguiente procedimiento describe cómo recomendamos verificar una integración individual.

La documentación del benchmark edge agentic de MLCommons de julio de 2026 ilustra la distinción. Sus ejemplos envían definiciones de herramientas a un endpoint de Chat Completions e inspeccionan llamadas estructuradas devueltas por el modelo.[1] Solo el nombre de un endpoint no garantiza que cada combinación de modelo, runtime y framework complete el mismo flujo de trabajo.

Comience con una solicitud que no pueda modificar datos comerciales

Elija un espacio de trabajo de prueba desechable y un modelo destinado a la tarea. Registre la versión del servidor, runtime, identificador del modelo y versión del framework del agente. Incluya el endpoint efectivo y la configuración de transporte, pero mantenga las credenciales fuera del informe. El registro debe distinguir la instalación probada de un modelo con nombre similar o un servidor antiguo aún en ejecución en otro lugar.

Comience con una solicitud de texto ordinaria. Confirme qué endpoint la recibió, qué modelo la procesó y si el llamador recibió una respuesta completa. Repita a través del framework que se usará en el piloto. Un éxito HTTP directo y un éxito a través del framework son observaciones separadas; mantenga ambos resultados.

Use una entrada corta con una respuesta predecible para que las fallas de conexión sean fáciles de distinguir de la dificultad de la tarea. Un saludo generado establece muy poco sobre un flujo de compra, pero es una primera comprobación útil de la ruta. No añada credenciales comerciales solo para hacer esta prueba inicial más realista.

Verifique una propuesta de herramienta inofensiva antes de la ejecución

Defina una operación de prueba limitada, como buscar un artículo en un inventario fabricado. Proporciónele un esquema pequeño con campos obligatorios y un conjunto explícito de valores permitidos. En esta etapa, capture la operación propuesta por el modelo sin ejecutarla. Verifique el nombre de la operación, los argumentos analizados y el tratamiento del framework de campos faltantes o inesperados.

Mantenga el conjunto de prueba lo suficientemente simple para que una persona pueda inspeccionar cada resultado. Un modelo que devuelve prosa plausible sobre un artículo no ha producido necesariamente una llamada a herramienta utilizable. Por el contrario, una llamada bien formada puede nombrar el artículo incorrecto. Registre la aceptación del formato y la corrección de la tarea por separado.

Si la aplicación de producción transmite respuestas en streaming, realice la misma verificación mediante streaming. Verifique que el consumidor espere hasta que el valor estructurado relevante esté completo antes de interpretarlo. Trate cualquier diferencia entre el manejo con y sin streaming como un hallazgo de integración que requiere resolución, en lugar de asumir que el camino exitoso cubre ambos.

Complete el ciclo con un resultado controlado

Después de que la propuesta pase la validación, permita que el anfitrión llame al inventario fabricado y devuelva su resultado al modelo. Inspeccione la respuesta subsecuente. Debe usar el resultado suministrado y preservar la identidad del artículo solicitado. Incluya una búsqueda que no devuelva coincidencias para que la aplicación tenga que representar la ausencia de forma honesta.

Luego realice una secuencia corta que requiera una segunda búsqueda. Verifique cómo el framework asocia cada resultado con su llamada de origen y cómo la siguiente solicitud avanza la conversación. Guarde un rastro saneado que muestre la secuencia sin conservar documentos reales de clientes.

Este es el punto en el que una demostración de un solo turno se convierte en una prueba de flujo de trabajo. El rastro debe exponer una asociación incorrecta, una repetición innecesaria o una tarea abandonada. El artículo de referencia de octubre explica por qué los límites de carga de trabajo son importantes al evaluar estas interacciones más largas.

Mantenga las verificaciones de permisos fuera del juicio del modelo

OWASP identifica la funcionalidad excesiva, los permisos y la autonomía como causas de agencia excesiva. Su guía sitúa las verificaciones de autorización en los sistemas que ejecutan acciones y recomienda la aprobación humana para operaciones de alto impacto.[2] Para esta integración, pruebe esos controles independientemente de si el modelo normalmente solicita acciones sensatas.

Extienda el conjunto de datos de inventario fabricado con una operación que el llamante no está autorizado a realizar. Verifique que el host o servicio descendente la rechace incluso cuando los argumentos propuestos parezcan válidos. El rechazo debe seguir siendo comprensible para el usuario y no debe hacer que el framework sustituya una credencial con más privilegios.

Incluya un documento de prueba recuperado que contenga una instrucción irrelevante. OWASP describe la inyección indirecta de indicaciones a través de contenido externo y señala que la generación aumentada por recuperación no elimina completamente la vulnerabilidad.[3] El criterio de aceptación aquí es concreto: la prosa recuperada no debe otorgar permisos adicionales a la aplicación. Esta prueba es una verificación útil, no una prueba de que todos los intentos de inyección serán bloqueados.

Finalice con interrupción y un alcance registrado

Interrumpa la herramienta de prueba, cancele una solicitud y haga que una dependencia esté temporalmente no disponible. Observe lo que el usuario ve y qué reintenta el framework. Antes de introducir una herramienta que modifique registros, acuerde cómo un reintento evitará duplicar una acción ya completada. Esa decisión pertenece al diseño de la aplicación y al contrato del servicio descendente.

Nuestro registro de aceptación propuesto lista las operaciones exactas probadas, las identidades permitidas y cualquier comportamiento no resuelto. Una búsqueda de inventario exitosa debe autorizar solo el alcance piloto acordado. Un nuevo conector, permiso más amplio o modelo diferente debe provocar una revisión de las verificaciones afectadas.

Para una discusión de despliegue, lleve ese registro a una revisión de integración de Software Tailor, junto con un ejemplo fallido redactado si existe. El siguiente paso útil es una brecha reproducible con un responsable. La transferencia operativa debe preservar esos responsables después de que termine el trabajo inicial de integración.

Referencias

[1] MLCommons. Convocatoria de presentación: Benchmark de Inferencia Agente en el Borde para MLPerf Inference v6.1. Julio de 2026. Consultado el 2026-09-26.

[2] Proyecto de Seguridad OWASP Gen AI. LLM06:2025 Agencia Excesiva. Edición 2025. Consultado el 26-09-2026.

[3] Proyecto de Seguridad OWASP Gen AI. LLM01:2025 Inyección de Prompt. Edición 2025. Consultado el 26-09-2026.