Cambiar de modelo exige revisar también su comportamiento

Un adaptador de modelos común puede simplificar la conexión técnica. Por ejemplo, traduce formatos de proveedores a un protocolo interno de herramientas. Así se define cómo llega una llamada. La aplicación debe seguir comprobando si el modelo nuevo interpreta correctamente una consulta fallida.

Misma llamada de herramienta, continuación diferente

En este ejemplo totalmente ficticio, un asistente consulta el estado de un proyecto. Ambas variantes solo pueden usar la herramienta de lectura prevista para ello. El nombre de herramienta, el argumento y el código de error son valores propios del ejemplo, no la interfaz de un proveedor identificado.

La tabla muestra dos continuaciones supuestas de la misma consulta denegada. No informa de observaciones en modelos reales.

El adaptador puede traducir ambas llamadas de la misma forma. Aun así, la segunda continuación afirma un estado que la herramienta no proporcionó. En el ejemplo se bloqueó el acceso; la respuesta inventada sigue siendo un error de tarea. No debe servir como prueba de que la consulta tuvo éxito.

La aplicación mantiene sus límites

OWASP recomienda limitar las facultades de las herramientas y aplicar los permisos en los sistemas posteriores. Tras un cambio de modelo, cada consulta debe seguir verificándose en el contexto de usuario adecuado. Un argumento sintácticamente válido no autoriza el acceso ni eludir una denegación.

El ejemplo requiere un tratamiento claro del acceso denegado, los datos ausentes y los fallos temporales. Estos casos pueden exigir pasos siguientes distintos. Un fallo no debe provocar automáticamente una consulta más amplia ni permisos adicionales.

Qué facilita realmente el adaptador

Una interfaz acotada y documentada puede limitar las modificaciones. Si el alcance de las herramientas, el modelo de datos y el contrato de errores son estables, tras el cambio de modelo quizá solo haya que adaptar la conexión específica del proveedor y sus instrucciones. No necesariamente hace falta reconstruir todo.

En un flujo que muestra directamente datos de herramienta comprobados sin generar una continuación libre, el punto de fallo mostrado aquí puede ser menor. Las demás comprobaciones de entradas, permisos y resultados siguen siendo pertinentes. Lo decisivo es el flujo realmente utilizado.

Evaluar el cambio mediante el comportamiento

Microsoft describe comparaciones con los mismos casos y atención separada a los fallos individuales. Incluya denegaciones de herramientas y resultados ausentes. Registre si un error lleva a una limitación correcta, una acción posterior no autorizada o una afirmación sin respaldo.

Una conexión funcional es una parte útil de la intercambiabilidad. La puesta en servicio también depende de que la configuración nueva respete los límites y decisiones previstos en el flujo de aplicación.

Fuentes

• OWASP 2025 — Excessive Agency

• Microsoft — Evaluate models, prompts, and agents