Cambiar un modelo de IA y probarlo en el mismo flujo

Al cambiar de modelo, examine todo el flujo de aplicación afectado. Un nuevo identificador de modelo en la configuración no constituye prueba suficiente. Utilice un conjunto de evaluación existente y registre qué cambio está comparando realmente.

Registrar claramente ambas configuraciones

Documente el identificador de modelo, la versión del prompt, las fuentes facilitadas, las herramientas y los ajustes de cada variante. Si las entradas, reglas y procesamiento siguen iguales, podrá investigar el cambio de modelo de forma más directa. Si también debe cambiar el prompt, el adaptador o la evaluación, estará comparando dos configuraciones de aplicación; no atribuya la diferencia solo al modelo.

Microsoft describe la comparación de variantes guardadas con los mismos casos y la revisión de fallos individuales. Las decisiones esperadas de la tarea deben fijarse antes de la comparación.

Hacer visibles las diferencias de cada caso

El siguiente ejemplo es totalmente ficticio. Una aplicación debe extraer un identificador de proyecto de un mensaje o solicitar revisión manual. No concede acceso al proyecto. Los nombres de campo pertenecen a nuestro esquema interno, no a una API de proveedor.

La tabla contiene salidas supuestas para la explicación. No es una prueba de modelo ejecutada. Las descripciones de los casos no sustituyen las entradas originales versionadas de una comparación real.

En el segundo caso, la variante nueva elige un proyecto pese a la ambigüedad. En el tercero incumple el contrato de campos. Una valoración agregada podría ocultar estas causas de error diferentes. Las salidas formalmente válidas también deben ser correctas para la tarea.

Tratar los errores antes de continuar

OWASP recomienda validar las salidas del modelo antes de pasarlas a componentes posteriores. En el ejemplo, la falta de un campo obligatorio no debe continuar como una extracción correcta. La aplicación debe rechazar la salida o enviarla a la vía de revisión prevista. La presencia de un campo de proyecto sigue sin autorizar el acceso.

Además de estos casos de tarea y formato, compruebe los idiomas realmente necesarios, las indisponibilidades y los reintentos. Una sola ejecución no establece una frecuencia de error estable. Si se usan errores conocidos para ajustar la variante nueva, hacen falta casos adicionales reservados para una comprobación independiente.

Planificar la puesta en servicio y la vuelta conjuntamente

Antes de la puesta en servicio, defina qué errores impiden el cambio y quién evalúa las diferencias pendientes. En el ejemplo deben resolverse primero la asignación precipitada de proyecto desde un mensaje ambiguo y el campo obligatorio ausente.

Conserve la configuración anterior de la aplicación y una vía de vuelta comprobada. Aclare también si el modelo anterior sigue disponible y si los datos almacenados mantienen la compatibilidad. Tras el cambio, observe los resultados reales del flujo afectado; tres casos ilustrativos no prueban una preparación general para producción.

Fuentes

• Microsoft — Evaluate models, prompts, and agents

• OWASP 2025 — Improper Output Handling