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

Un conjunto de evaluación útil empieza por un flujo empresarial acotado, no por una colección de preguntas ingeniosas. Para saber si un asistente de solicitudes de compra funciona, hay que recrear quién lo usa, qué documentos recibe, qué política puede consultar, qué herramientas tiene disponibles y qué decisión debe apoyar. Esa precisión permite combinar trabajo cotidiano con límites difíciles, fallas confirmadas y conductas prohibidas. También evita que un promedio atractivo esconda, por ejemplo, una aprobación no autorizada o una instrucción maliciosa insertada en una cotización.

¿Qué debe cubrir un conjunto de evaluación por escenarios?

Debe cubrir el trabajo representativo en relación con el flujo observado y, además, incluir de manera deliberada límites relevantes, fallas conocidas y conductas prohibidas. Primero fije una versión del sistema, los actores autorizados, las entradas admitidas, el conocimiento y las herramientas disponibles, y la decisión que la evaluación respaldará. Luego describa familias de tareas y variaciones pertinentes mediante evidencia autorizada: registros operativos, casos de soporte, investigación con usuarios, incidentes y recorridos con especialistas del dominio. Si la evidencia es incompleta o el sistema aún no opera, registre la incertidumbre en vez de inventar precisión.

La mezcla ordinaria merece cobertura proporcional a condiciones observables, pero la frecuencia no debe gobernar todo el conjunto. Una condición rara puede justificar casos propios si su consecuencia es importante; una conducta expresamente prohibida debe probarse aunque nunca aparezca en una muestra aleatoria. Defina de antemano los cortes que reportará —por tarea, rol, tipo de documento, permiso, idioma, resultado de herramienta o consecuencia— y las barreras que afectarán la decisión de lanzamiento. Esta estructura de cuatro familias es una síntesis editorial adaptable, no una taxonomía universal.

En el asistente ilustrativo de solicitudes de compra, el mapa puede incluir una solicitud completa, otra sin un documento requerido, importes o identificadores de proveedor contradictorios, evidencia insuficiente para determinar el siguiente paso y una consulta de política que falla o devuelve material inconsistente. También debe probar pedidos para saltarse la aprobación humana e instrucciones incrustadas en una cotización. Las reglas concretas dependen de cada organización: el asistente del ejemplo revisa, recupera información y redacta una nota, pero no aprueba gastos, crea órdenes ni inventa condiciones.

¿Cómo se registra cada escenario para poder reproducirlo?

Cada escenario se registra como una ficha versionada que permite a otra persona reconstruir la prueba, reconocer resultados válidos y detectar acciones prohibidas. La identidad debe incluir un código estable, responsable, historial, familia de cobertura, tarea, cortes, consecuencia, procedencia, autorización y conjunto asignado. La configuración reúne el actor y su objetivo, el estado inicial, la solicitud, los archivos, el historial pertinente, el conocimiento autorizado, los permisos, las herramientas, sus resultados, las condiciones del entorno y las instrucciones que recibirá el sistema.

• Resultado requerido: hechos, cambios de estado o próximos pasos que deben aparecer.
• Variaciones aceptables: redacciones o rutas distintas que satisfacen las mismas restricciones.
• Respuesta condicionada: aclarar, abstenerse, rechazar o escalar cuando falte evidencia.
• Resultados prohibidos: divulgaciones, acciones, llamadas a herramientas o cambios de estado no autorizados.
• Operación: evaluador, rúbrica, barreras, solución de referencia, número de intentos cuando corresponda y regla de agregación.
• Trazabilidad: versiones del modelo, prompt, corpus, herramientas, política y arnés de evaluación.

No reduzca una tarea abierta a una respuesta ideal. Una solución de referencia puede demostrar que el caso es resoluble y ayudar a comprobar el evaluador, pero no invalida otras rutas correctas. En sistemas no deterministas o de varios pasos, el número de intentos y su regla de agregación deben declararse antes de revisar salidas. Registre además las competencias requeridas del revisor, la ruta de arbitraje y cualquier limitación pendiente. El esquema completo es una síntesis editorial y debe ajustarse a la gobernanza de evidencia 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 un escenario sin premiar la conducta equivocada?

Se debe usar el método más estrecho que distinga válidamente el éxito del fracaso. Aplique verificaciones deterministas a esquemas, cálculos, argumentos de herramientas, estados de registros y acciones prohibidas que puedan comprobarse objetivamente. Use hechos o soluciones de referencia cuando el resultado esté acotado, aunque admita varias redacciones o rutas. Reserve rúbricas con dimensiones y anclas observables para cualidades abiertas, como utilidad, integridad o sustento. Cuando la interpretación del dominio o sus consecuencias no puedan automatizarse válidamente, mantenga el juicio en revisores calificados y autorizados.

• Compruebe que cada caso sea resoluble y que la verificación no omita una condición material.
• Califique resultados y restricciones relevantes, sin exigir una trayectoria incidental.
• Separe dimensiones como integridad, sustento y claridad para evitar una impresión general imprecisa.
• Calibre los evaluadores basados en modelos frente a juicios humanos pertinentes al contexto.
• Permita crédito parcial solo para componentes significativos y muestre cuál falló.
• Mantenga las conductas prohibidas fuera del promedio como barreras definidas previamente.

Una respuesta pulida no debe compensar una divulgación confidencial ni una acción sin permiso. Esa barrera es una recomendación editorial: los responsables de producto y riesgo deben definir antes de comparar salidas qué conducta está prohibida y qué consecuencia tendrá. También deben fijar la versión de la rúbrica, los cortes, la lógica de barreras, la agregación de intentos y la regla de decisión. Si después cambian un criterio, corresponde crear una nueva versión de la evaluación. OpenAI informó, además, que su evaluador automatizado de GDPval no reemplazaba de forma confiable a evaluadores ocupacionales experimentados.

¿Cómo lograr que los revisores apliquen criterios consistentes?

Los revisores necesitan una guía breve con contexto, anclas observables, calibración y una ruta explícita para los casos que no pueden calificarse. Antes de mostrar una salida, presente el propósito del flujo, el actor, la evidencia disponible, las acciones permitidas, el límite del producto y la versión de la rúbrica. Defina qué se observa en cada nivel y acompañe los criterios con ejemplos positivos, negativos y fronterizos. Incluya la opción «evidencia insuficiente» cuando el caso, la referencia o el entorno estén defectuosos.

1. Ejecute casos de calibración antes de la revisión activa y repítalos cuando cambien la rúbrica, la política, las tareas o el grupo revisor.
2. Oculte la identidad del sistema y alterne el orden de las salidas cuando una comparación pueda verse influida por esas señales.
3. Recoja calificaciones y fundamentos independientes antes de abrir la discusión.
4. Investigue si el desacuerdo proviene de un caso defectuoso, un umbral ambiguo, contexto faltante, pluralidad legítima o una decisión pendiente.
5. Nombre a la persona responsable del arbitraje y conserve etiquetas, fundamentos, versiones y resoluciones.

El desacuerdo no es ruido que deba eliminarse automáticamente. Puede mostrar que dos respuestas son aceptables, que el criterio no distingue bien sus niveles o que el equipo aún no ha decidido cómo debe comportarse el producto. La persona a cargo del arbitraje debe separar la corrección de un defecto de evaluación de una nueva decisión de política. GDPval demuestra que es posible combinar revisión especializada, comparación ciega y rúbricas detalladas, pero no establece un protocolo universal. La guía completa aquí propuesta sigue siendo una síntesis que cada equipo debe calibrar.

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

El conjunto permanece útil si separa los casos visibles de desarrollo de una prueba protegida y registra toda exposición relevante. El conjunto de desarrollo puede ejecutarse repetidamente para ajustar prompts, recuperación, herramientas, políticas y pasos del flujo; por eso sus resultados describen progreso durante la iteración, no una estimación independiente de lanzamiento. La prueba protegida debe asignarse antes de la ejecución rutinaria, usarse con moderación y mantenerse fuera del circuito de cambios. No existe un porcentaje universal: la composición depende de la decisión, la variabilidad, los cortes, las consecuencias y la evidencia autorizada.

La separación nominal no basta. Busque duplicados exactos y cercanos, registros fuente compartidos, paráfrasis y casos hermanos creados con la misma plantilla. Controle quién o qué accedió al contenido, las respuestas, las rúbricas y los resultados. Una falla que ya orientó el diagnóstico o la corrección pertenece al conjunto de desarrollo o regresión. La prueba protegida puede cubrir la misma clase mediante un caso independiente y no duplicado. Si un caso protegido influye materialmente en un cambio, muévalo y cree un reemplazo versionado.

• Registre responsable, procedencia, autorización, conjunto, exposición, versión y última revisión de cada caso.
• Versione en conjunto el contenido, las etiquetas, la rúbrica, la política fuente y el arnés.
• Añada fallas verificadas solo después de minimizar información sensible y confirmar el comportamiento esperado.
• Revise la cobertura cuando cambien el flujo, los usuarios, la política, el conocimiento, el modelo, los prompts, las herramientas, los permisos o el entorno.
• Conserve el motivo de cada cambio, reemplazo, retiro o desacuerdo no resuelto.
• Reporte resultados por tarea, familia, corte, consecuencia y barrera, además de cualquier resumen.

Trate el conjunto como evidencia para una decisión, no como certificado de seguridad o preparación. Los responsables de producto y riesgo deben definir barreras sensibles a las consecuencias; los especialistas del dominio deben validar el realismo y los resultados esperados. Cuando un caso implique material o decisiones gobernadas, incorpore a las funciones calificadas de datos, privacidad, seguridad, legal, cumplimiento u otras pertinentes. Las decisiones legales, médicas, financieras, laborales, de seguridad o de privacidad deben permanecer en personas autorizadas. Combine la evaluación fuera de línea con monitoreo, investigación con usuarios, revisión de incidentes y evidencia operativa adecuada.