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

Un buen conjunto de evaluación no empieza con una carpeta de prompts ingeniosos, sino con un flujo empresarial acotado y una decisión concreta. Imagine un asistente interno que recibe una solicitud de compra aparentemente correcta, pero encuentra un identificador de proveedor contradictorio, no logra recuperar la política vigente y descubre instrucciones dirigidas a la IA dentro de una cotización adjunta. El caso exige comprobar si el sistema reconoce la falta de evidencia, respeta sus permisos y entrega el trabajo a la persona autorizada. Para obtener evidencia reproducible, el equipo debe definir de antemano la cobertura, el registro de cada escenario, la forma de calificarlo y las barreras que ninguna buena respuesta puede compensar.

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

Debe cubrir el trabajo ordinario en relación con el flujo esperado y, además, incluir de forma deliberada los límites importantes, las fallas confirmadas y las conductas prohibidas. Antes de recopilar casos, fije una versión del sistema, los usuarios permitidos, las entradas aceptadas, el conocimiento y las herramientas disponibles, y la decisión que respaldará la evaluación. Una evaluación útil necesita casos claramente definidos, realistas y representativos de las condiciones previstas, además de un método documentado; un asistente general sin límites claros no ofrece una base estable para medir.

Construya un mapa de familias de tareas y variaciones relevantes con evidencia autorizada: registros operativos, expedientes históricos, atención a usuarios, investigación, recorridos con especialistas o escenarios sintéticos revisados. Ninguna fuente es automáticamente verdad de terreno. Los registros pueden estar incompletos o no contar con autorización de reutilización, y los casos sintéticos pueden representar bien un límite sin reflejar su frecuencia. Cuando falte evidencia, registre la incertidumbre como tal. Defina también los segmentos que reportará y las barreras de liberación antes de generar salidas.

• Trabajo representativo: tareas, roles, documentos y condiciones habituales, ponderados según evidencia confiable sobre el flujo.
• Casos límite importantes: ambigüedad, información faltante o contradictoria, permisos restringidos, formatos inusuales y fallas de herramientas.
• Fallas conocidas: reproducciones minimizadas y autorizadas de defectos, incidentes o reclamos cuyo comportamiento esperado ya fue verificado.
• Conductas prohibidas: acciones, revelaciones o atajos que contradicen permisos, políticas o límites definidos por responsables autorizados.

En el asistente de solicitudes de compra, el trabajo normal puede ser un expediente completo y coherente. Los límites incluyen un documento faltante, montos o proveedores contradictorios, evidencia insuficiente y una política inaccesible. También hacen falta intentos de saltarse la aprobación, instrucciones incrustadas en una cotización y reproducciones desidentificadas de fallas previas. Estas reglas son ilustrativas y dependen de cada organización. Conviene probar ambos lados de un límite: cuándo el asistente debe avanzar y cuándo debe detenerse, para no premiar una negativa indiscriminada.

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

Cada escenario debe registrarse como una ficha capaz de reconstruir el mismo trabajo para otro evaluador. Una tarea necesita entradas y criterios de éxito definidos, y el calificador puede inspeccionar la salida, el estado final o la traza de ejecución. La ficha propuesta combina prácticas respaldadas por las fuentes en una estructura editorial adaptable; no es un formulario universal. Su propósito es impedir que información decisiva quede escondida en la memoria del autor del caso o se modifique después de ver una respuesta.

• Identidad: código estable, responsable, versión, historial, familia de cobertura, tarea, segmentos, consecuencia, procedencia, autorización y conjunto asignado.
• Configuración: actor, objetivo, estado inicial, solicitud, archivos, antecedentes, conocimiento autorizado, herramientas, permisos, resultados de herramientas e instrucciones del sistema.
• Expectativas: hechos o cambios requeridos, alternativas aceptables, condiciones para aclarar, abstenerse, rechazar o escalar, y resultados expresamente prohibidos.
• Operación: tipo de calificador, rúbrica, barreras, solución de referencia, número de intentos cuando corresponda, regla de agregación, revisión, arbitraje y versiones técnicas.

No reduzca una tarea abierta a una sola frase ideal. Una solución de referencia que funciona puede demostrar que el caso es resoluble y ayudar a revisar el calificador, pero no invalida otras rutas correctas. Para el ejemplo de compras, el resultado aceptable podría identificar un documento ausente, distinguir el texto de la política de un hecho todavía incierto y preparar una nota para el responsable. Aprobar el gasto, inventar un umbral o exponer información ajena debe registrarse por separado como resultado prohibido.

Un caso útil no solo plantea una dificultad: reconstruye trabajo acotado y vuelve inspeccionables el éxito, la variación aceptable y lo prohibido.

¿Cómo se califica un escenario sin premiar la conducta equivocada?

Use el método más estrecho que pueda distinguir válidamente el éxito del fracaso. Una comprobación determinista sirve para esquemas, cálculos, argumentos de herramientas, estados de registros y acciones vedadas que sean objetivamente verificables. Los hechos o soluciones de referencia funcionan cuando el resultado está acotado, pero admite varias redacciones o rutas. Para cualidades abiertas, separe dimensiones observables en una rúbrica; si la interpretación exige conocimiento del dominio, conserve el juicio en manos de personas calificadas y autorizadas.

• Compruebe que cada caso sea resoluble y que una regla automática no sea precisa pero incompleta o vulnerable a atajos.
• Califique el resultado y las restricciones materiales, no una secuencia incidental, salvo cuando el flujo exija un orden, permiso o aprobación específicos.
• Permita crédito parcial solo para componentes significativos y muestre cuál falló, sin esconderlo dentro de un promedio.
• Calibre los calificadores basados en modelos contra juicios humanos pertinentes; la coincidencia en casos de desarrollo no demuestra validez general.

OpenAI informó que el calificador automatizado de GDPval no era suficientemente confiable para sustituir a evaluadores ocupacionales experimentados; el hallazgo no condena toda automatización, pero sí descarta tratarla como objetiva por defecto. Además, una divulgación prohibida o una acción no autorizada debe fallar una barrera no compensable, aunque la respuesta sea clara y útil en otros aspectos. Los responsables de producto y riesgo deben fijar esas barreras, los segmentos, la agregación de intentos y la regla de decisión antes de comparar candidatos.

¿Cómo pueden los revisores aplicar los criterios de manera consistente?

Los revisores necesitan una guía breve, criterios observables y calibración antes de evaluar resultados reales. Presente primero el propósito del flujo, el actor, la evidencia disponible, la conducta permitida, el límite del producto y la versión de la rúbrica. Para cada nivel de calificación, incluya anclas que puedan observarse, ejemplos positivos, negativos y fronterizos, además de una opción de evidencia insuficiente o imposible de calificar. Esa salida evita convertir un caso defectuoso en una supuesta falla del sistema.

1. Ejecute casos de calibración y repítalos cuando cambien la rúbrica, la política, la mezcla de tareas o el grupo revisor.
2. Oculte la identidad del sistema y alterne el orden de las salidas cuando sea práctico en comparaciones.
3. Recoja calificaciones y razones independientes antes de cualquier discusión.
4. Investigue desacuerdos como posibles señales de contexto faltante, umbrales ambiguos, casos defectuosos o alternativas legítimas.
5. Nombre a una persona responsable del arbitraje y conserve etiquetas, razones, versiones y decisiones.

La revisión experta por etapas, la comparación ciega y las rúbricas detalladas utilizadas en GDPval muestran que estas prácticas son viables, no que formen un protocolo obligatorio. Revisar trazas y calificaciones ayuda a separar una falla real del sistema de un problema en el caso, el calificador o el entorno. Tampoco se debe forzar consenso cuando varias respuestas son legítimas o cuando falta una decisión de producto: en esos casos, el registro debe conservar el desacuerdo y señalar quién tiene autoridad para resolverlo.

¿Cómo se mantiene útil el conjunto durante el desarrollo y la liberación?

Mantenga un conjunto visible para desarrollar y otro protegido para aportar evidencia de liberación. El primero puede usarse repetidamente al ajustar prompts, recuperación, herramientas, políticas y pasos del flujo; como el equipo conoce esos casos, sus resultados son evidencia de desarrollo. El conjunto protegido debe asignarse antes de la ejecución rutinaria, emplearse con moderación y permanecer fuera de la iteración. Usar reiteradamente una prueba para orientar cambios crea riesgo de ajustar el sistema a esa prueba y desgasta su valor como evidencia independiente.

• Asigne el conjunto cuando el caso entre al registro, antes de inspeccionar salidas usadas para seleccionar soluciones.
• Busque duplicados exactos y cercanos, registros fuente compartidos, paráfrasis y escenarios hermanos creados desde la misma plantilla.
• Controle el acceso a casos, respuestas de referencia, rúbricas y resultados protegidos.
• Mueva a desarrollo cualquier caso protegido que haya influido materialmente en un cambio y cree un reemplazo nuevo, versionado y no duplicado.
• Mantenga las fallas ya diagnosticadas como evidencia de desarrollo o regresión; pruebe su clase en liberación solo con casos independientes.

Un registro conciso debe conservar responsable, procedencia, autorización, conjunto, exposición, versiones, historial de revisión, razones de cambio y retiro. También debe versionar juntos el contenido del caso, las etiquetas, la rúbrica, la política fuente y el arnés de evaluación; cambiar silenciosamente una pieza vuelve incomparables los resultados. No existe un porcentaje universal para dividir los conjuntos ni un intervalo fijo de renovación. El tamaño y la composición dependen de la decisión, la variabilidad del flujo, los segmentos relevantes, las consecuencias y la evidencia autorizada disponible.

Agregue fallas verificadas y señales de soporte únicamente después de confirmar el comportamiento esperado, minimizar información sensible y comprobar la autorización. Revise la cobertura cuando cambien materialmente los usuarios, el flujo, la política, el corpus de conocimiento, el modelo, los prompts, las herramientas, los permisos o el entorno. Reporte por familia de tarea, cobertura, segmento, consecuencia y barrera, no solo mediante una media. Los métodos y métricas también deben reevaluarse durante el ciclo de vida según el propósito, los datos disponibles y los riesgos relevantes.

Trate el resultado como evidencia para una decisión, no como certificado. Aprobar una evaluación fuera de producción no demuestra por sí solo valor empresarial, seguridad, equidad, cumplimiento ni preparación operativa. Complemente los casos con monitoreo, investigación con usuarios, revisión de incidentes y evidencia adecuada al sistema. Cuando un escenario implique privacidad, seguridad, empleo, finanzas, salud, asuntos jurídicos u otros juicios regulados, deben intervenir funciones calificadas y autorizadas; la evaluación puede iluminar el comportamiento del sistema, pero no asumir la decisión profesional.