Cómo construir un conjunto de evaluación por escenarios para un sistema de IA empresarial

Un conjunto útil de evaluación parte de un flujo de negocio acotado, no de una colección de preguntas llamativas. Imagine un asistente interno que recibe una solicitud de compra aparentemente completa, encuentra identificadores de proveedor contradictorios, no logra recuperar la política vigente y descubre instrucciones dirigidas al sistema dentro de una cotización adjunta. El caso solo sirve como evidencia si reproduce ese contexto, define qué puede hacer el asistente y permite verificar tanto una respuesta aceptable como cualquier acción prohibida.

¿Qué debe cubrir una evaluación de IA basada en escenarios?

Debe cubrir el trabajo ordinario en relación con las condiciones observadas y, además, incluir de manera deliberada fronteras importantes, fallas conocidas y conductas prohibidas. Primero delimite una versión del sistema, los usuarios permitidos, las entradas, el conocimiento, las herramientas y la decisión que respaldará la evaluación. Después trace las familias de tareas y las variaciones relevantes con evidencia autorizada: registros de trabajo, casos de soporte, investigación con usuarios, incidentes y recorridos con expertos del dominio.

No trate los registros de producción como verdad automática: pueden ser incompletos, estar mal etiquetados o no contar con autorización para reutilizarse. Cuando no haya tráfico confiable, declare que la mezcla ordinaria es una hipótesis previa al lanzamiento. Defina también, antes de generar respuestas, los segmentos que reportará y los controles que condicionarán la decisión. Así evita escoger después las métricas o agrupaciones que favorezcan al sistema evaluado.

En el asistente de solicitudes de compra, el mapa podría incluir paquetes completos, documentos faltantes, montos o proveedores contradictorios, evidencia insuficiente, recuperación de política no disponible, intentos de saltarse una aprobación e instrucciones incrustadas en archivos. También incluiría reproducciones minimizadas de fallas verificadas. Estas reglas son ilustrativas: cada organización debe definir sus permisos, políticas y consecuencias con los responsables autorizados.

¿Cómo se registra un escenario para que otra persona pueda reproducirlo?

Cada escenario debe convertirse en un registro versionado que permita recrear la configuración y calificarla sin adivinar intenciones. Asigne un identificador estable, responsable, familia de cobertura, familia de tarea, segmentos, consecuencia, procedencia, autorización e incorporación prevista al conjunto de desarrollo o a la prueba protegida. Registre por separado el actor y su objetivo, el estado inicial, las entradas, la historia pertinente, los permisos, el conocimiento disponible, las herramientas y los resultados que estas devuelven.

• Configuración: solicitud, archivos, instrucciones, estado del flujo, condiciones ambientales y versiones del sistema, modelo, prompt, corpus de recuperación, herramientas, política y arnés.
• Resultados aceptables: hechos obligatorios, cambios de estado permitidos, alternativas válidas y condiciones que exigen preguntar, abstenerse, rechazar o escalar.
• Resultados prohibidos: divulgaciones, acciones, llamadas a herramientas, aprobaciones o cambios de estado que nunca deben ocurrir.
• Operación: tipo de evaluador, rúbrica, controles, solución de referencia cuando corresponda, cantidad de ensayos si la variabilidad importa y regla previa para agregarlos.
• Revisión: cualificación requerida, versión de calibración, ruta de arbitraje, desacuerdos pendientes, limitaciones y motivo de modificación o retiro.

Una solución conocida puede probar que el caso es resoluble y ayudar a detectar un evaluador defectuoso, pero no debe convertir una redacción en la única salida correcta. Para el asistente de compras, puede ser válido pedir el documento faltante o escalar la inconsistencia por caminos diferentes, siempre que la respuesta conserve los hechos obligatorios, no invente una política y no ejecute una aprobación. El registro completo es una síntesis editorial que debe adaptarse al control documental de la organización.

Un buen caso no solo plantea una dificultad: recrea trabajo acotado y vuelve inspeccionables el éxito, la variación aceptable y la conducta prohibida.

¿Cómo calificar cada escenario sin premiar la conducta equivocada?

Califique cada caso con el método más estrecho que pueda distinguir válidamente el éxito del fracaso. Use verificaciones determinísticas para esquemas, cálculos, argumentos de herramientas, estados de registros o acciones prohibidas objetivamente observables. Use hechos o soluciones de referencia cuando el resultado esté acotado, pero admita varias redacciones o trayectorias. Reserve las rúbricas con anclas observables para cualidades abiertas y el juicio experto para interpretaciones que una comprobación automática no pueda resolver válidamente.

• Compruebe que cada regla automática sea completa y que el caso tenga una solución alcanzable; una prueba precisa también puede estar mal diseñada.
• Separe dimensiones como exactitud, completitud, fundamentación y utilidad, en lugar de esconderlas dentro de una impresión general.
• Calibre cualquier evaluador basado en modelos contra juicios humanos cualificados en el contexto pertinente; el acuerdo sobre casos visibles no demuestra objetividad.
• Conceda crédito parcial cuando los componentes representen progreso significativo, pero muestre cuál falló.
• Mantenga las acciones y divulgaciones prohibidas como controles no compensables definidos por responsables de producto y riesgo.

Fije antes de comparar respuestas la versión de la rúbrica, la lógica de los controles, los segmentos, la forma de agregar ensayos y la regla de decisión. Si el equipo modifica cualquiera de ellos después de ver los resultados, registre una nueva versión y vuelva a interpretar la evidencia bajo esa definición. OpenAI, por ejemplo, informó que el evaluador automatizado empleado en GDPval no era suficientemente confiable para reemplazar a evaluadores ocupacionales experimentados; esa observación invita a validar, no a descartar automáticamente, cada método.

¿Cómo lograr que los revisores apliquen los criterios de manera consistente?

Los revisores necesitan una guía breve, concreta y calibrada antes de recibir resultados reales. Presente el propósito del flujo, el actor, la evidencia disponible, el comportamiento permitido, el límite del producto y la versión de la rúbrica. Defina anclas observables para cada nivel y muestre ejemplos positivos, negativos y fronterizos. Incluya una opción de evidencia insuficiente o imposibilidad de calificar para que un caso defectuoso no se convierta artificialmente en una falla del sistema.

1. Ejecute casos de calibración antes de la revisión y repítalos cuando cambien la política, la rúbrica, la mezcla de tareas o el grupo de revisores.
2. Oculte la identidad del sistema y alterne el orden de las respuestas cuando sea práctico y la comparación pueda verse afectada.
3. Capture puntuaciones y razones independientes antes de abrir la discusión entre revisores.
4. Investigue el desacuerdo como señal de un umbral confuso, contexto faltante, caso defectuoso, pluralidad legítima o decisión de producto pendiente.
5. Nombre un responsable de arbitraje y conserve etiquetas, razones, versiones y resultados para revisiones posteriores.

El objetivo del arbitraje no es fabricar unanimidad. Si dos respuestas son legítimas, el registro debe admitir ambas; si falta una decisión de política o producto, debe escalarse a quien tenga autoridad para tomarla. Una referencia profesional como GDPval demuestra que es posible combinar revisión experta en varias etapas, comparación ciega y rúbricas detalladas, pero no establece un protocolo universal. La cualificación y el número de revisores dependen del trabajo y de sus consecuencias.

¿Cómo mantener útil la evidencia durante el desarrollo y el lanzamiento?

Mantenga un conjunto visible para iterar y una prueba de lanzamiento protegida para comparaciones finales o decisiones de liberación. El primero puede ejecutarse repetidamente mientras se ajustan prompts, recuperación, herramientas, políticas y flujo; por eso sus resultados son evidencia de desarrollo. Asigne la pertenencia de cada caso al registrarlo, antes de la ejecución rutinaria o de inspeccionar respuestas. La prueba protegida solo aporta evidencia diferente mientras sus casos, respuestas, rúbricas y resultados no hayan orientado cambios materiales.

Revise duplicados exactos y cercanos, registros de origen compartidos, paráfrasis y casos hermanos creados con la misma plantilla. Controle el acceso tanto al contenido como a las soluciones, rúbricas y resultados. Una falla que ya ayudó a diagnosticar o corregir el sistema pertenece a desarrollo o regresión. La prueba protegida puede cubrir la misma clase de falla mediante un caso independiente que no haya guiado la solución. Si un caso protegido influye en un cambio, reclasifíquelo y cree un reemplazo versionado.

• Registre responsable, procedencia, autorización, segmento, consecuencia, conjunto, exposición, versiones, historial de revisión y motivos de cambio o retiro.
• Agregue fallas verificadas después de minimizar información sensible y confirmar cuál era el comportamiento esperado.
• Reevalúe cobertura cuando cambien usuarios, flujo, política, conocimiento, modelo, prompts, herramientas, permisos o entorno operativo.
• Reporte por familia de tarea, familia de cobertura, segmento, consecuencia y control, además de cualquier resumen agregado.
• Conserve evidencia estable para comparar versiones y documente puentes cuando una renovación impida contrastarlas directamente.

El conjunto es evidencia para una decisión, no un certificado de seguridad o preparación. Los responsables de producto y riesgo deben definir previamente los controles sensibles a las consecuencias; los expertos del dominio deben validar el realismo y los resultados esperados. Cuando intervengan datos o juicios gobernados, deben participar las funciones autorizadas de privacidad, seguridad, asuntos legales, cumplimiento u otras áreas pertinentes. Mantenga las decisiones reguladas con personas cualificadas y complemente la prueba sin conexión con monitoreo, investigación con usuarios, revisión de incidentes y evidencia operativa.