Empieza por la decisión, no por el modelo
Documenta el resultado operativo, las personas afectadas, los datos que el flujo puede usar, las acciones que puede ejecutar y quién responde por el resultado. Un modelo puede rendir bien en una prueba abstracta y aun así no ser adecuado para un flujo concreto por su contexto, herramientas o consecuencias.
Elige una línea base útil: el proceso manual actual, una regla determinista, recuperación sin generación u otro sistema existente. La pregunta relevante es si el flujo propuesto mejora el resultado dentro de sus límites de costo, latencia, seguridad y control.
- Define el uso permitido y los usos expresamente excluidos.
- Nombra al responsable y a quienes pueden detener el despliegue.
- Describe los fallos inaceptables aunque el promedio sea bueno.
Construye el conjunto de evaluación desde el trabajo real
Incluye la variedad que el sistema encontrará: casos rutinarios, extremos, solicitudes ambiguas, datos incompletos, entradas adversariales y fallos de integración. Elimina o protege información sensible y registra por qué se incluye cada caso.
Mantén un conjunto estable y reservado para decidir lanzamientos, separado del material de desarrollo. Versiona juntos prompts, modelo, índice de recuperación, herramientas, políticas y datos de evaluación para poder rastrear cada resultado.
Mide el flujo en varias capas
Combina calidad de tarea y comportamiento del sistema. Según el caso, pueden servir la finalización de tareas, la tasa de errores críticos, el respaldo en fuentes, el uso correcto de herramientas, la escalación, la latencia, el costo y la posibilidad de reconstruir una acción desde los registros.
No reduzcas todo a un promedio. Un flujo puede lograr una precisión general aceptable y aun así vulnerar un límite de seguridad o ejecutar mal una acción irreversible. Informa los fallos críticos por separado y revisa explícitamente las compensaciones.
- Prueba salidas, llamadas a herramientas, permisos y cambios de estado posteriores.
- Comprueba que la incertidumbre provoque abstención o escalación cuando corresponda.
- Segmenta los resultados para no ocultar casos raros pero importantes.
Define el criterio de lanzamiento y el monitoreo
Fija los umbrales antes de la prueba final. Señala qué fallos impiden lanzar sin importar el promedio, quién revisa la evidencia y qué riesgo residual se acepta. En flujos relevantes, empieza en un entorno aislado, en modo sombra o con un piloto muy acotado.
Producción cambia la distribución de entradas y el sistema que rodea al modelo. Monitorea las medidas críticas tras el lanzamiento y define rutas de retroalimentación, incidentes, reversión, reducción de permisos y nueva evaluación.
Lista de lanzamiento de un flujo de IA
- El resultado, alcance, responsable y usos prohibidos están documentados.
- El conjunto representa casos rutinarios, extremos, adversariales y de fallo.
- Se prueba el flujo completo, incluidas herramientas, permisos e integraciones.
- Los fallos críticos y umbrales se definen antes de la evaluación final.
- Registros, escalación, reversión y monitoreo tienen responsables claros.
La evidencia debe viajar con el sistema
La evaluación no es una puntuación única. Trata el conjunto de pruebas, la configuración, los resultados, las limitaciones y la decisión de lanzamiento como artefactos operativos versionados. Así cada cambio puede evaluarse y los operadores tienen una base concreta para continuar, escalar o detener el flujo.
