La IA que cita también puede equivocarse: cómo evaluar respuestas con evidencia
Una respuesta de IA puede traer tres citas y seguir estando equivocada. Quizá el enlace existe, pero no respalda la frase. Quizá el modelo omitió una excepción decisiva. O quizá la pregunta no tenía respuesta en los documentos y el sistema prefirió sonar seguro. Si una organización va a usar esa respuesta para atender clientes, analizar expedientes o decidir una compra, «incluye fuentes» no es un criterio suficiente.
En 2026, NIST describe tres comprobaciones de evidencia para los resultados de agentes: fidelidad (la fuente sí sustenta la afirmación), integridad (no se omite contexto relevante) y suficiencia (la evidencia alcanza para la conclusión). Es una forma útil de transformar una intuición —«la IA parece confiable»— en pruebas repetibles.
Propongo un método ligero para equipos de producto, datos y tecnología. No pretende sustituir una evaluación estadística formal; sirve para detectar fallas antes de ampliar un piloto.
El error que revela una cita
Imagine que un asistente responde: «El proveedor garantiza entrega en 24 horas» y cita una propuesta. Al abrirla, la propuesta dice: «Entrega estimada en 24 a 72 horas, sujeta a disponibilidad». La cita es real. La conclusión no es fiel ni suficiente. Un contador automático de enlaces daría una señal positiva justo donde el negocio necesita una alerta.
La unidad de evaluación debe ser la afirmación comprobable, no solamente la respuesta completa. Una respuesta con cinco frases correctas y una recomendación final injustificada puede fallar la tarea.
Construya un conjunto de 50 casos que se parezcan al trabajo real
Empiece con preguntas tomadas de solicitudes reales, anonimizadas. Si aún no hay historial, pida a quienes harán el trabajo que redacten ejemplos. Una distribución inicial práctica es:
- 10 preguntas rutinarias con respuesta clara en una fuente.
- 10 que requieren combinar dos documentos.
- 10 con una excepción, fecha o condición que cambia la conclusión.
- 10 sin evidencia suficiente, donde la respuesta correcta es reconocer el límite.
- 10 situaciones sensibles que deben escalar a una persona.
Son 50 casos de arranque, no un tamaño de muestra universal. Documente para cada uno la pregunta, los documentos permitidos, la respuesta esperada, las afirmaciones críticas, el comportamiento de abstención y la gravedad de un error. Mantenga separado un pequeño grupo de casos nuevos que el equipo no use para ajustar prompts: así podrá comprobar si las mejoras se trasladan a preguntas no ensayadas.
Use una rúbrica que dos personas puedan aplicar
Para cada respuesta, puntúe de 0 a 2 estas dimensiones:
| Dimensión | 0 | 1 | 2 |
|---|---|---|---|
| Resultado de la tarea | No responde o decide mal | Responde parcialmente | Resuelve la solicitud dentro del alcance |
| Fidelidad de las citas | Fuentes ausentes o contradictorias | Apoyo parcial | Cada afirmación crítica está respaldada |
| Contexto y suficiencia | Omite una condición decisiva | Conserva parte del contexto | Incluye límites, fechas y excepciones relevantes |
| Abstención y escalamiento | Inventa o actúa fuera de alcance | Expresa duda sin orientar | Reconoce límites y escala cuando corresponde |
La escala es editorial y debe adaptarse al riesgo de cada caso. Una respuesta que obtiene 2 en estilo pero 0 en fidelidad no debe aprobarse. Para acciones sensibles, defina además fallas críticas binarias: revelar datos ajenos, ejecutar sin autorización o presentar una decisión inexistente como final.
Ejecute la prueba y registre lo necesario
- Congele la configuración: versión del modelo, instrucciones, índice de documentos y conectores.
- Corra cada caso más de una vez: las salidas pueden variar. Tres ejecuciones por pregunta muestran inconsistencias sin volver impracticable el primer piloto.
- Revise las afirmaciones críticas: abra el documento citado y marque el fragmento exacto que apoya o contradice la respuesta.
- Haga revisión cruzada: una segunda persona puntúa una muestra de casos, especialmente los desacuerdos y errores graves.
- Reporte por tipo de caso: muestre numerador y denominador de respuestas aceptadas, no solo un promedio global.
Registre también tiempo de respuesta, costo por solicitud y frecuencia de escalamiento humano. Son dimensiones operativas distintas de la exactitud. No reduzca todo a un único «score de IA» que oculte dónde falla.
Cómo leer el resultado sin prometer más de lo medido
Si el sistema acierta 45 de 50 casos elegidos, sabemos algo sobre esos 50 casos. No sabemos automáticamente que acertará el 90 % de todas las futuras preguntas. NIST separa la exactitud en un benchmark fijo de la exactitud generalizada sobre preguntas similares no observadas y pide declarar la incertidumbre y los supuestos.
Para un piloto pequeño, la honestidad más útil es reportar por categoría: «8/10 preguntas rutinarias correctas; 4/10 con excepciones correctas; 2/10 abstenciones apropiadas». Ese desglose señala qué corregir. Aumente la muestra y diseñe la evaluación estadística si necesita afirmar una tasa de desempeño con confianza para una población más amplia.
Convierta cada fallo en una prueba de regresión
Etiquete el origen del error: recuperación equivocada, documento obsoleto, síntesis infiel, instrucción ambigua, permiso excesivo o ausencia de una ruta de escalamiento. Corrija la capa correspondiente y vuelva a ejecutar tanto el caso fallido como el conjunto congelado. Mejorar el prompt no arregla un documento incorrecto; cambiar de modelo no arregla un permiso mal configurado.
Mi criterio para dirección de tecnología es sencillo: antes de ampliar un asistente, quiero ver una tabla de casos reales, evidencia revisable y fallas críticas explícitas. Esa disciplina complementa los controles de protección de documentos frente a prompt injection. La seguridad evita ciertos abusos; la evaluación demuestra si la respuesta es útil y está sustentada.
Fuentes: NIST, evaluación de evidencia en agentes; NIST AI 800-3, medición e incertidumbre; OWASP AI Testing Guide.
