Una demostración de inteligencia artificial puede resultar convincente con cinco preguntas bien elegidas. El problema aparece cuando la solución recibe cientos de entradas reales, documentos incompletos, instrucciones contradictorias o pedidos que nunca estuvieron contemplados.
Probar una solución de IA no consiste solamente en preguntar si una respuesta parece correcta. Hay que definir qué tarea debe resolver, qué errores son aceptables, qué situaciones requieren intervención humana y qué evidencia permitirá autorizar su lanzamiento.
El enfoque puede resumirse en tres acciones: especificar el resultado esperado, medirlo con casos representativos y mejorar a partir de los errores. Esta lógica coincide con la guía empresarial sobre evaluaciones publicada por OpenAI y puede aplicarse sin depender de un proveedor o modelo determinado.
Una buena demostración no equivale a una buena evaluación
En una demo, el equipo conoce las preguntas y puede elegir ejemplos favorables. En producción, los usuarios escriben con errores, omiten contexto, solicitan excepciones y combinan objetivos que el sistema no esperaba.
También es importante diferenciar el modelo del sistema completo. La calidad final puede depender de las instrucciones, las fuentes consultadas, los permisos, la búsqueda de documentos, las integraciones, la interfaz y las reglas de derivación. Cambiar cualquiera de estos componentes puede alterar el resultado aunque el modelo sea el mismo.
El núcleo del AI Risk Management Framework de NIST recomienda realizar pruebas antes del despliegue, documentar métricas y métodos, evaluar condiciones similares a las reales y continuar la supervisión durante el funcionamiento.
1. Definir la tarea y las consecuencias del error
El primer paso no es crear preguntas, sino escribir una definición concreta de la tarea. “Ayudar al equipo” es demasiado ambiguo. “Clasificar consultas recibidas por tema y prioridad, sin responderlas ni modificar datos” permite diseñar una evaluación.
Para delimitar el trabajo, conviene responder:
- Entrada: ¿qué información recibirá el sistema?
- Salida: ¿qué debe producir y en qué formato?
- Fuentes: ¿qué documentos o datos puede utilizar?
- Límites: ¿qué consultas debe rechazar o derivar?
- Impacto: ¿qué ocurre si se equivoca?
- Responsable: ¿quién revisa los fallos y autoriza cambios?
No todas las equivocaciones tienen la misma gravedad. Un resumen algo extenso puede ser corregible; inventar una condición contractual, exponer información privada o ejecutar una acción sin permiso exige controles mucho más estrictos. El perfil de NIST para inteligencia artificial generativa propone relacionar las medidas con el contexto, los objetivos y la tolerancia al riesgo de cada organización.
2. Crear un conjunto de pruebas representativo
Un conjunto de evaluación es una colección de entradas acompañadas por el resultado esperado o por criterios que permitan juzgar la respuesta. No necesita empezar con miles de casos. Una primera versión pequeña, revisada por personas que conocen el proceso, puede revelar fallos importantes.
La colección debería combinar:
- Casos frecuentes: tareas habituales y formuladas con claridad.
- Variaciones reales: errores ortográficos, expresiones regionales, mensajes breves y datos desordenados.
- Situaciones límite: campos vacíos, documentos extensos, información contradictoria o solicitudes fuera de alcance.
- Casos sensibles: datos personales, decisiones relevantes o contenido que requiere autorización.
- Casos adversariales: intentos de ignorar reglas, obtener información restringida o manipular las herramientas conectadas.
- Casos de abstención: situaciones en las que la respuesta correcta es reconocer que falta información o derivar a una persona.
Los casos deberían provenir, cuando sea posible y legalmente adecuado, del flujo de trabajo real. Antes de utilizarlos, hay que retirar datos personales innecesarios, secretos y contenido que no debería entrar en un entorno de pruebas.
Los benchmarks generales permiten comparar capacidades, pero no reemplazan las evaluaciones propias. La guía de Google sobre evaluación responsable recomienda complementarlos con conjuntos que reflejen el uso concreto y con consultas adversariales capaces de revelar debilidades.
3. Establecer cómo se calificará cada resultado
Los criterios deben definirse antes de ejecutar la prueba. De lo contrario, el equipo puede aceptar respuestas atractivas aunque incumplan el objetivo original.
Según el caso, la evaluación puede revisar:
- Exactitud: los datos y conclusiones son correctos.
- Fundamentación: la respuesta se apoya en las fuentes autorizadas y no inventa información.
- Cumplimiento: respeta instrucciones, permisos y formato.
- Integridad: incluye los elementos necesarios para completar la tarea.
- Relevancia: responde lo solicitado sin agregar contenido que genere confusión.
- Seguridad y privacidad: no revela datos ni facilita acciones prohibidas.
- Derivación: reconoce correctamente cuándo debe detenerse y pedir intervención humana.
Algunos resultados admiten controles automáticos, como verificar un formato o comparar una clasificación. Otros requieren revisión humana, especialmente cuando intervienen contexto, tono, ambigüedad o conocimiento especializado. También puede utilizarse otro modelo como evaluador auxiliar, pero no debería tratarse como una verdad independiente: su criterio debe compararse periódicamente con revisores humanos.
Una solución de IA no está lista cuando impresiona en una demo; está lista cuando sabemos dónde acierta, dónde falla y qué ocurre cuando falla.
4. Probar el flujo completo y no solo las respuestas
Las pruebas funcionales comprueban si el sistema completa la tarea normal. Las pruebas adversariales intentan descubrir cómo podría fallar, ser manipulado o actuar fuera de sus permisos.
Entre los escenarios que conviene simular se encuentran:
- Un usuario pide ignorar las instrucciones internas.
- Un documento consultado contiene órdenes maliciosas dirigidas al modelo.
- La fuente necesaria está desactualizada, ausente o en conflicto con otra.
- La salida del modelo contiene código, enlaces o instrucciones que otro sistema podría ejecutar.
- Una integración devuelve un error o datos incompletos.
- El usuario solicita información para la que no tiene autorización.
- La solución intenta repetir una acción que ya fue realizada.
El OWASP Top 10 para aplicaciones con modelos de lenguaje destaca riesgos como la inyección de instrucciones y el manejo inseguro de salidas. Incorporar documentos propios o ajustar un modelo puede mejorar la relevancia, pero no elimina automáticamente estas vulnerabilidades.
Si la solución puede enviar mensajes, modificar registros, realizar compras o ejecutar otras acciones, las pruebas deben incluir límites de permisos, confirmaciones, entornos aislados, registro de actividad y mecanismos para evitar operaciones duplicadas.
5. Fijar criterios de lanzamiento y supervisión humana
El resultado de una evaluación no debería reducirse a un promedio. Una tasa general aceptable puede ocultar un fallo grave en una categoría sensible. Conviene definir condiciones separadas para los distintos riesgos.
Una decisión de lanzamiento puede organizarse con tres estados:
- Aprobado: alcanza los criterios previstos y los errores residuales tienen controles adecuados.
- Aprobado con límites: puede utilizarse para determinados usuarios, tareas o volúmenes, siempre con revisión humana.
- No aprobado: presenta fallos críticos, carece de evidencia suficiente o no dispone de una respuesta segura ante incidentes.
La revisión humana debe tener una función concreta. No alcanza con indicar que “una persona supervisará”. Hay que establecer qué resultados revisará, qué información recibirá, cuánto tiempo tendrá, qué puede corregir y cómo registrará un incidente.
6. Convertir los errores reales en nuevas pruebas
La evaluación continúa después del lanzamiento. Las fuentes cambian, aparecen usos no previstos, se actualizan modelos y los usuarios encuentran formas nuevas de interactuar con el sistema.
Para sostener la calidad conviene:
- Registrar entradas, respuestas, fuentes y acciones con las medidas de privacidad correspondientes.
- Ofrecer un mecanismo sencillo para reportar respuestas incorrectas o inseguras.
- Revisar por separado los incidentes de mayor impacto.
- Agregar cada fallo relevante al conjunto de pruebas.
- Ejecutar nuevamente las evaluaciones cuando cambien el modelo, las instrucciones, las fuentes o las integraciones.
- Conservar versiones de casos, resultados y decisiones de lanzamiento.
Este proceso transforma los incidentes en aprendizaje acumulado. Con el tiempo, el conjunto de evaluación se convierte en una descripción práctica de lo que la organización espera de la solución.
Conclusión: lanzar con evidencia, no con intuición
Antes de poner una solución de IA frente a usuarios reales, la organización debería poder explicar qué tarea resuelve, con qué información trabaja, cómo se mide, dónde debe abstenerse y qué controles actúan cuando se equivoca.
El punto de partida es sencillo: seleccionar una tarea concreta, reunir casos normales y difíciles, definir criterios de aprobación y registrar los errores. A partir de allí, cada cambio puede compararse con una base común en lugar de depender de impresiones aisladas.
Si necesitás diseñar, integrar y evaluar un sistema aplicado a un proceso concreto, Ideasweb desarrolla soluciones de inteligencia artificial con fuentes definidas, controles, pruebas y supervisión acordes al uso previsto.
