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

Empiece con un solo flujo de negocio acotado y convierta sus condiciones reales, límites y fallas en casos reproducibles. Imagine un asistente interno que recibe una solicitud de compra aparentemente completa, pero encuentra un identificador de proveedor contradictorio, no puede recuperar la política vigente y ve instrucciones dirigidas al sistema dentro de una cotización. Un puñado de prompts impecables no demuestra si resolverá correctamente esa combinación. La evaluación debe precisar qué trabajo puede realizar, qué evidencia tiene disponible, cuándo debe pedir aclaración o escalar y qué acciones tiene prohibidas. También debe fijar segmentos, reglas de calificación y barreras antes de observar resultados, para que una puntuación agregada atractiva no oculte la falla que determinaría una decisión de lanzamiento.

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

Debe cubrir el trabajo representativo en relación con el flujo observado y, además, incluir deliberadamente límites importantes, fallas conocidas y conductas prohibidas. Primero fije una versión del sistema, los actores autorizados, las entradas, el conocimiento y las herramientas disponibles, y la decisión que la evaluación apoyará. NIST relaciona una medición válida con pruebas claramente definidas y realistas bajo condiciones de uso previstas; la evaluación de un “asistente general” sin frontera operativa no ofrece esa precisión. Dibuje después las familias de tareas y las variaciones que podrían cambiar el desempeño, como ambigüedad, información ausente, permisos, idioma, resultado de una herramienta o consecuencia del error.

Use evidencia autorizada: registros de trabajo, casos de soporte, investigación con usuarios, incidentes y recorridos con expertos de dominio. Los registros de producción no son automáticamente representativos, legales para reutilizar ni correctamente etiquetados; los escenarios sintéticos tampoco son inválidos por definición. Documente la procedencia, minimice información personal o confidencial y marque la incertidumbre cuando falten datos operativos. Para el asistente de compras, las reglas son ilustrativas y específicas de cada organización: conviene probar solicitudes completas, documentos faltantes, identificadores contradictorios, evidencia insuficiente, recuperación de política no confiable, intentos de omitir aprobación e instrucciones incrustadas en archivos.

• Estime la mezcla ordinaria con evidencia confiable y conserve los subgrupos que puedan revelar diferencias materiales.
• Pruebe ambos lados de cada límite para evitar que el sistema siempre actúe o siempre se niegue.
• Reproduzca fallas confirmadas con contenido minimizado, sintético o desidentificado y procedencia conservada.
• Defina antes de ejecutar los casos qué segmentos se reportarán y qué prohibiciones funcionarán como barreras.

¿Cómo debe registrarse cada escenario de evaluación?

Cada escenario debe ser un expediente reproducible que permita a otra persona recrear la configuración, reconocer resultados aceptables, detectar prohibiciones y aplicar el mismo método de calificación. Asigne una identidad estable, propietario, historial de cambios, familia de cobertura, familia de tarea, etiquetas de segmento, consecuencia, procedencia, autorización y división prevista. Registre el actor y su objetivo; el estado inicial; la solicitud, archivos e historial pertinentes; el conocimiento autorizado; las herramientas, permisos y resultados disponibles; y las instrucciones y condiciones ambientales. Las evaluaciones profesionales pueden basarse en productos de trabajo siempre que incluyan el contexto y los archivos necesarios.

Separe las expectativas de calidad de las acciones prohibidas. Describa los hechos o cambios de estado requeridos, las rutas alternativas aceptables y cuándo corresponde aclarar, abstenerse, negarse o escalar. Luego enumere aparte las divulgaciones, llamadas de herramientas, acciones y cambios de estado vedados. Una solución de referencia puede demostrar que el caso es resoluble y ayudar a comprobar el calificador, pero no debe convertir una redacción ideal en la única respuesta válida. Si la variabilidad del sistema exige varios intentos, declare de antemano cuántos se harán y cómo se agregarán, sin presentar ese número como regla universal.

• Identidad: caso, versión, propietario, estado, procedencia, autorización, cobertura, segmentos y división.
• Configuración: actor, objetivo, estado inicial, entradas, contexto, permisos, herramientas y condiciones.
• Expectativas: hechos requeridos, alternativas válidas, aclaración o escalamiento y resultados prohibidos.
• Operación: calificador, rúbrica, barreras, pruebas, adjudicación y versiones del modelo, prompt, corpus, herramientas, política y arnés.

Un buen caso no solo plantea una pregunta difícil: recrea trabajo acotado y vuelve inspeccionables el éxito, la variación aceptable y lo prohibido.

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

Use el método de calificación más estrecho que pueda distinguir válidamente entre éxito y falla. Una comprobación determinista sirve para un cálculo, esquema, argumento de herramienta, estado de registro o acción prohibida objetivamente verificable, pero aun una comprobación precisa puede estar incompleta o premiar un atajo. Use hechos o una solución de referencia cuando el resultado esté acotado y admita varias rutas. Reserve las rúbricas por dimensiones para cualidades genuinamente abiertas, con anclas observables para utilidad, integridad o fundamentación. Cuando un modelo califique esas cualidades, calíbrelo contra juicios humanos pertinentes; la coincidencia en casos de desarrollo no prueba objetividad.

Califique el resultado y las restricciones materiales, no una ruta incidental, salvo que el proceso exija una herramienta, secuencia o aprobación específica. Puede dar crédito parcial a componentes con una progresión significativa, pero debe mostrar cuál falló. Una divulgación o acción no autorizada debe quedar fuera del promedio de calidad y actuar como barrera no compensable definida previamente por los responsables de producto y riesgo. Esta es una recomendación editorial sensible a las consecuencias, no un umbral universal. OpenAI informó que el calificador automatizado de GDPval no era suficientemente confiable para reemplazar a evaluadores ocupacionales experimentados, una advertencia útil contra la automatización sin validación contextual.

• Fije la versión de la rúbrica, las barreras, los segmentos y la regla de decisión antes de comparar resultados.
• Compruebe que cada caso sea resoluble y que cada verificación capture todo el resultado material.
• Ancle cada dimensión abierta con conductas observables, no con adjetivos vagos como “bueno” o “profesional”.
• Reserve la interpretación regulada o de consecuencias materiales para personas calificadas y autorizadas.

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

Los revisores necesitan una guía breve con contexto, anclas observables, calibración, calificación independiente y una ruta clara para los casos que no pueden puntuarse. Antes de presentar una salida, explique 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. Defina cada nivel con ejemplos positivos, negativos y fronterizos. Incluya una opción de “evidencia insuficiente” o “no calificable” cuando el expediente sea defectuoso; obligar a puntuarlo transforma un problema de diseño en aparente desempeño del sistema.

Ejecute casos de calibración antes de la revisión activa y repítalos cuando cambien la mezcla de tareas, la política, la rúbrica o el grupo de revisores. En comparaciones, oculte la identidad del sistema y alterne el orden cuando sea práctico, como control contra influencias ajenas al resultado. Capture primero puntuaciones y razones independientes. Después investigue los desacuerdos: pueden revelar un caso defectuoso, un umbral ambiguo, contexto ausente, alternativas legítimas o una decisión de producto pendiente. No fuerce consenso en los dos últimos supuestos; asigne un responsable de adjudicación y conserve etiquetas, razones, versiones y resoluciones.

• Entregue contexto suficiente sin revelar información protegida que el sistema evaluado no debería conocer.
• Use anclas concretas para cada dimensión y explique qué evidencia debe observar el revisor.
• Revise trazas y calificaciones cuando sea necesario para separar una falla real de un entorno defectuoso.
• Documente desacuerdos antes de discutirlos y distinga corrección técnica de decisión de política.
• Conserve las decisiones para revisar etiquetas y recalibrar calificadores automatizados posteriormente.

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

El conjunto sigue siendo útil si separa los casos visibles de desarrollo de una prueba de lanzamiento protegida y registra toda exposición. El equipo puede reutilizar el conjunto de desarrollo para ajustar prompts, recuperación, herramientas, políticas y flujo; su puntuación es evidencia de desarrollo porque el sistema se ha optimizado conociendo esos casos. Asigne la división al incorporar cada expediente, antes de la ejecución rutinaria o la inspección selectiva de resultados. Use la prueba protegida con moderación para comparaciones finales o decisiones de lanzamiento, sin permitir que sus casos, respuestas, rúbricas o resultados orienten la iteración.

Busque duplicados exactos y cercanos, registros fuente compartidos, paráfrasis y escenarios hermanos generados con la misma plantilla. Una falla que ya sirvió para diagnosticar o corregir el sistema pertenece a desarrollo o regresión. La prueba protegida puede cubrir la misma clase mediante un caso creado independientemente, no duplicado y todavía no expuesto. Si un caso protegido influye materialmente en un cambio, muévalo a desarrollo y agregue un reemplazo versionado. No existe un porcentaje universal para dividir los conjuntos: el tamaño y la composición dependen de la decisión, la variabilidad, los segmentos, las consecuencias y la evidencia autorizada disponible.

• Registre propietario, procedencia, autorización, división, exposición, versiones, revisiones, cambios y retiro de cada caso.
• Versione juntos casos, etiquetas, rúbricas, política fuente y arnés; no altere silenciosamente resultados anteriores.
• Agregue fallas verificadas solo después de confirmar la conducta esperada y minimizar información sensible.
• Reevalúe cobertura cuando cambien usuarios, flujo, política, conocimiento, modelo, prompts, herramientas, permisos o entorno.
• Reporte por familia de tarea, cobertura, segmento, consecuencia y barrera, además de cualquier resumen general.

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 de antemano las barreras y el uso del resultado; los expertos de dominio deben validar el realismo y los resultados esperados. Privacidad, seguridad, asuntos legales, cumplimiento y otras funciones calificadas deben revisar los casos que involucren material bajo su gobierno. Mantenga las decisiones legales, médicas, financieras, laborales, de seguridad, privacidad u otros ámbitos regulados en manos autorizadas. Combine la evaluación fuera de producción con monitoreo, investigación de usuarios, revisión de incidentes y la evidencia adicional adecuada al sistema.