Una respuesta convincente todavía necesita comprobaciones
Una respuesta de inteligencia artificial puede ser clara, ordenada y útil, pero esas cualidades no demuestran por sí solas que sus datos sean correctos. Una fecha puede estar desactualizada, una referencia puede no respaldar lo afirmado y un fragmento de código puede funcionar con el ejemplo sencillo mientras falla al recibir una entrada inesperada.
Por eso, aprender cómo evaluar las respuestas de una IA generativa no consiste en buscar una puntuación universal de confianza. Consiste en definir qué se esperaba, descomponer la salida en elementos comprobables y reunir evidencia suficiente para decidir si puede utilizarse.
La profundidad de esa revisión debe ser proporcional a las consecuencias del error. Una lista privada de ideas puede utilizarse como borrador con una comprobación ligera. Una configuración de seguridad, un informe profesional, una publicación o una acción que modifica datos exige controles más estrictos.
La referencia de datos.gob.es sobre validación de IA generativa organiza la evaluación en cuatro dimensiones: ética y equidad, seguridad y robustez, consistencia y fiabilidad, y transparencia y explicabilidad. Esta clasificación ayuda a mirar más allá de la redacción y comprobar también el comportamiento, los posibles daños y los límites del resultado.
Qué significa evaluar una respuesta de IA
Evaluar no es pedir al mismo sistema que relea su texto y confirme que todo está bien. Esa segunda respuesta puede ayudar a encontrar puntos dudosos, pero no constituye una verificación independiente.
Una evaluación práctica debe responder, como mínimo, a cuatro preguntas:
- ¿Resuelve la tarea correcta? La salida responde a la necesidad real, al destinatario y al formato solicitado.
- ¿Se puede sostener? Los hechos, cálculos, citas y conclusiones importantes disponen de evidencia adecuada.
- ¿Es segura? No expone información innecesaria ni propone acciones desproporcionadas, irreversibles o fuera de los permisos autorizados.
- ¿Están claros sus límites? Se distinguen los datos confirmados, las inferencias, las suposiciones y las cuestiones pendientes.
Una salida puede superar algunas preguntas y fallar en otras. Un script podría resolver la tarea solicitada, por ejemplo, pero sobrescribir archivos sin pedir confirmación. Un resumen podría reproducir correctamente la idea general y, al mismo tiempo, convertir una propuesta pendiente en una decisión aprobada.
Conviene entender también qué tipo de sistema se está revisando. La guía sobre qué es la inteligencia artificial y cómo funciona ofrece una introducción general, mientras que el análisis de los agentes de IA y sus posibles acciones ayuda a diferenciar un texto generado de un sistema que además puede utilizar herramientas o modificar recursos.
Método para evaluar una respuesta de IA en ocho pasos
El siguiente procedimiento puede aplicarse a textos, resúmenes, correos, código, análisis y tareas de productividad. No garantiza que desaparezcan todos los errores. Su finalidad es convertir una impresión subjetiva en una revisión documentada y proporcional al riesgo.
1. Define la tarea y sus límites
No se puede juzgar una respuesta con precisión si la petición original era ambigua. Antes de revisar la salida, escribe qué resultado se necesitaba, quién lo utilizará y qué restricciones debía respetar.
La definición debería aclarar:
- el objetivo concreto de la tarea;
- el destinatario y sus conocimientos previos;
- el formato y la extensión necesarios;
- los datos que puede utilizar la herramienta;
- las acciones que no está autorizada a realizar;
- el contexto temporal o la versión aplicable;
- las consecuencias previsibles de un error.
«Escribe sobre copias de seguridad» deja demasiadas decisiones abiertas. «Prepara para una pequeña empresa una checklist que diferencie copia, sincronización y recuperación, sin recomendar marcas ni asumir que existe almacenamiento externo» permite comprobar el resultado con más precisión.
Si el encargo sigue siendo ambiguo después de leerlo, no conviene rellenar los huecos mediante suposiciones. La salida debería pedir el contexto que falta o declarar las condiciones bajo las que formula su propuesta.
2. Convierte la petición en criterios de aceptación
Los criterios de aceptación describen qué debe cumplirse para considerar aprovechable la respuesta. Deben poder comprobarse mediante la lectura del material original, una fuente, una operación o una prueba.
Para resumir una reunión, los criterios podrían ser:
- recoger únicamente decisiones presentes en las notas;
- distinguir las propuestas de los acuerdos definitivos;
- mantener sin cambios las fechas y cantidades;
- asignar responsables solo cuando consten expresamente;
- identificar los asuntos pendientes;
- no incluir datos que el destinatario no deba recibir.
Para evaluar código generado por IA harían falta criterios diferentes: salida esperada, validación de entradas, gestión de errores, límites de permisos, ausencia de operaciones destructivas no autorizadas y posibilidad de diagnosticar o revertir un fallo.
Conviene fijar estos criterios antes de dejarse influir por el estilo de la respuesta. De lo contrario, un texto bien presentado puede parecer válido aunque haya resuelto una tarea distinta.
3. Separa hechos, inferencias, recomendaciones y opiniones
No todas las frases se comprueban de la misma forma. Clasificar las afirmaciones importantes permite asignar a cada una la evidencia adecuada:
- Hecho verificable: fecha, versión, requisito, función, límite, cifra, cita o característica concreta.
- Inferencia: conclusión obtenida a partir de uno o varios datos.
- Recomendación: acción propuesta según unos objetivos, restricciones y riesgos.
- Opinión o preferencia: valoración que depende de criterios personales y no se demuestra como un dato factual.
«La documentación se publicó el 12 de marzo» necesita una fuente que confirme esa fecha. «Esta opción puede ser más adecuada para un equipo pequeño» es una recomendación y debe explicar los criterios utilizados, como la complejidad, los permisos o la capacidad de mantenimiento. «Es la mejor herramienta» apenas aporta información si no define qué significa «mejor».
Cuando una respuesta mezcla las categorías, puede reescribirse con una estructura explícita: «La fuente confirma X; a partir de ese dato se infiere Y; antes de actuar todavía debe comprobarse Z».
4. Contrasta las afirmaciones con fuentes y fechas
Solicitar referencias a una IA facilita la revisión, pero no la completa. Hay que abrir cada enlace relevante y comprobar si respalda la afirmación exacta. Una página puede existir y tratar el mismo tema sin confirmar el dato concreto utilizado en la respuesta.
Para cada hecho que pueda cambiar la decisión, revisa:
- si la fuente existe y puede consultarse;
- quién es responsable de su contenido;
- si es una fuente primaria o remite al documento original;
- si confirma exactamente la afirmación;
- qué fecha, versión, territorio o condiciones cubre;
- si contiene excepciones que la respuesta ha omitido;
- si otra fuente fiable presenta información incompatible.
La prioridad habitual debe ser la documentación oficial, la normativa, los organismos públicos, el fabricante, el repositorio original o la entidad responsable del dato. Una fuente secundaria puede orientar la búsqueda, pero no sustituye a una fuente primaria accesible.
Los datos cambiantes necesitan una precaución adicional. Una captura o una consulta acredita lo observado en un momento determinado; no garantiza que una versión, una función, un precio o una política sigan iguales más adelante. Cuando la vigencia resulte importante, registra la fecha de consulta y vuelve a comprobar el dato antes de actuar.
5. Comprueba la lógica y los cálculos de forma independiente
Confirmar los datos de partida no demuestra que la conclusión sea correcta. También hay que revisar las operaciones y el razonamiento que conectan esos datos con el resultado.
Si aparecen cifras, repite los cálculos con una herramienta independiente. Comprueba la base utilizada para los porcentajes, las unidades, el redondeo, los impuestos, los periodos y el tratamiento de valores vacíos. Un porcentaje puede estar bien calculado y haberse aplicado sobre la cantidad equivocada.
En un razonamiento, busca problemas como estos:
- presentar una correlación como si demostrara una causa;
- generalizar a partir de un solo ejemplo;
- ignorar una condición que invalida la conclusión;
- comparar cantidades expresadas con unidades diferentes;
- convertir la falta de evidencia en una prueba de que algo no existe;
- suponer que una acción es segura solo porque finalizó sin mostrar errores.
Una comprobación aislada tiene un alcance limitado. El mismo principio aparece al comprobar SHA256 en Windows: una coincidencia permite validar una propiedad concreta del archivo, pero no demuestra por sí sola todas las propiedades de seguridad que podrían interesar. Al evaluar una IA, cada prueba debe acompañarse de una explicación sobre qué acredita y qué deja sin comprobar.
6. Diseña casos normales, fronteras y entradas erróneas
Una respuesta técnica no queda validada porque funcione con el ejemplo más cómodo. La prueba debe cubrir el uso normal, los límites razonables y los errores previsibles.
Para una función que calcula descuentos podrían utilizarse:
- un importe habitual y un porcentaje válido;
- un importe igual a cero;
- los valores mínimo y máximo permitidos;
- decimales que obliguen a definir el redondeo;
- un porcentaje negativo o superior al límite esperado;
- texto, campos vacíos o datos ausentes.
En un correo generado, las pruebas cambian: destinatario incorrecto, ausencia del adjunto mencionado, promesas que nadie ha autorizado, tono inadecuado o inclusión de información confidencial.
Para un resumen, compara la salida con una muestra del documento original que incluya una cifra, una fecha, una negación, una excepción y una condición. Perder un «no» o un «pendiente de aprobación» puede alterar el significado aunque el resto del resumen sea correcto.
La guía de diseño y realización de pruebas de software amplía la idea de comprobar resultados con casos planificados en lugar de limitarse a observar si el programa parece funcionar.
7. Revisa privacidad, permisos y acciones posteriores
La evaluación comienza antes de enviar la petición. Si el contenido incluye información personal, documentación interna, datos de clientes o secretos de acceso, primero debe comprobarse si está autorizado introducirlo en ese servicio y bajo qué condiciones.
No existe una regla única válida para cualquier herramienta u organización. Antes de utilizar datos reales, consulta la política vigente del servicio, las condiciones de la cuenta, las normas internas y las obligaciones legales aplicables al caso. Si falta esa información, utiliza datos ficticios o detén la tarea hasta aclararla.
Como lista de precauciones:
- elimina los datos que no sean necesarios para resolver la tarea;
- sustituye identificadores reales por ejemplos ficticios cuando resulte viable;
- no introduzcas contraseñas, tokens, claves privadas ni secretos de acceso;
- comprueba quién puede conservar, consultar o reutilizar la información;
- verifica que la herramienta está autorizada para ese tipo de datos;
- revisa también qué información sensible podría aparecer en la salida.
El riesgo aumenta cuando el sistema no se limita a redactar, sino que puede leer documentos, ejecutar código, enviar mensajes o modificar recursos. El recurso de OWASP sobre riesgos y mitigaciones para LLM y aplicaciones de IA generativa sitúa la seguridad a lo largo del desarrollo, despliegue y gestión de estas aplicaciones.
Los documentos, páginas web y correos utilizados como contexto deben tratarse como entradas no confiables. Una orden incrustada en ese material no adquiere permisos por el hecho de que el modelo pueda leerla. Hay que separar el contenido que se analiza de las instrucciones que el sistema está autorizado a ejecutar.
Para acciones externas o difíciles de revertir, aplica permisos mínimos, simulación previa, registro, posibilidad de recuperación y aprobación proporcional al riesgo. Una lluvia de ideas interna no necesita el mismo proceso que borrar datos, desplegar software o enviar mensajes en nombre de una organización.
8. Documenta incertidumbres y toma una decisión
Una revisión útil termina con una decisión comprensible. No basta con acumular comentarios: hay que registrar qué se comprobó, qué se corrigió y qué continúa pendiente.
Registro mínimo recomendado: tarea; fecha; herramienta o modelo indicado por el servicio; datos de entrada relevantes; criterios de aceptación; fuentes consultadas; pruebas ejecutadas; errores detectados; cambios realizados; incertidumbres pendientes y decisión final.
Si se necesita reproducibilidad, conserva también la petición, los parámetros disponibles, la salida original y la versión corregida. Si cualquiera de esos elementos cambia, el resultado anterior no debe darse por válido automáticamente para la nueva situación.
La decisión puede expresarse mediante tres estados:
- Aceptada: supera los criterios y las comprobaciones proporcionales al uso previsto.
- Aceptada con condiciones: puede utilizarse después de corregir o verificar puntos concretos.
- Rechazada: contiene errores graves, carece de evidencia suficiente o presenta un riesgo que no se puede controlar.
Tabla de decisión para elegir la profundidad de la revisión
La siguiente tabla es una guía práctica para adaptar el control al uso previsto. No representa un estándar externo ni asigna una confianza automática. Si una tarea encaja en varias filas, conviene aplicar el nivel más exigente.
| Tipo de uso | Ejemplo | Comprobación mínima | Decisión prudente |
|---|---|---|---|
| Bajo impacto e interno | Lista inicial de ideas | Relevancia, duplicados y adecuación al objetivo | Usar como borrador sin presentarlo como información verificada |
| Contenido público | Artículo o presentación | Hechos, fuentes, fechas, citas, coherencia y derechos de uso | Publicar únicamente la versión revisada |
| Decisión profesional | Informe, presupuesto o recomendación | Datos originales, cálculos, supuestos, excepciones y responsabilidad | Solicitar la aprobación adecuada al riesgo y al ámbito |
| Acción técnica reversible | Crear un archivo de prueba | Entorno aislado, entradas normales, errores y salida esperada | Probar antes de incorporarla al flujo real |
| Acción externa o destructiva | Borrar datos, desplegar o enviar mensajes | Permisos mínimos, simulación, registro, reversión y autorización | No ejecutar automáticamente sin controles específicos |
| Ámbito sensible | Salud, derecho, seguridad o datos personales | Fuentes autorizadas, normativa, privacidad y revisión competente | No sustituir el criterio profesional por la respuesta generada |
Ejemplo práctico: revisar el resumen de una reunión
Supongamos que una herramienta recibe las notas de una reunión y devuelve esta frase: «El equipo aprobó migrar el servicio el viernes y Ana enviará las credenciales al proveedor».
La evaluación puede seguir este recorrido:
- Tarea: resumir acuerdos, responsables y fechas sin añadir información.
- Criterios: cada decisión debe figurar en las notas, las propuestas deben diferenciarse de los acuerdos y no se deben inferir responsables.
- Clasificación: la aprobación, el viernes y la asignación a Ana son tres hechos que necesitan confirmación.
- Contraste: las notas originales dicen «se propone migrar el viernes, pendiente de validar con operaciones».
- Resultado: la primera salida ha transformado una propuesta en un acuerdo y ha añadido un responsable que no constaba.
- Corrección: «Se propuso migrar el viernes, pendiente de validación con operaciones. Falta definir quién coordinará el acceso seguro del proveedor».
- Decisión: rechazar la primera salida y conservar la versión corregida como borrador pendiente de confirmación.
El problema no se encontraba en la gramática. La redacción resultaba natural, pero dos de sus afirmaciones no estaban respaldadas por el material original.
Ejemplo técnico: revisar código generado por IA
Supongamos ahora que se solicita un script para ordenar documentos por extensión. Ejecutarlo una vez sobre una carpeta pequeña no demuestra que sea seguro para datos reales.
Una revisión prudente podría ser:
- localizar en el código todas las operaciones de escritura, movimiento y borrado;
- sustituir temporalmente las acciones reales por una simulación que muestre el plan;
- crear archivos ficticios con nombres duplicados, extensiones inesperadas y subcarpetas;
- comprobar que ninguna ruta sale del directorio autorizado;
- probar qué ocurre cuando faltan permisos o un archivo está en uso;
- interrumpir la ejecución para comprobar si deja un estado incoherente;
- guardar un registro de los cambios previstos y realizados;
- probar la recuperación antes de utilizar documentos importantes.
Estas pruebas no demuestran que el programa sea correcto bajo cualquier circunstancia. Acreditan únicamente el comportamiento observado con esos casos, en ese entorno y con esa versión. Si cambia el código, el sistema o los requisitos, deben repetirse las comprobaciones pertinentes.
Errores frecuentes al comprobar respuestas generadas
Dar por válida una respuesta porque contiene enlaces
Un enlace puede no existir, estar desactualizado o tratar un tema relacionado sin confirmar la afirmación. Es necesario abrirlo y localizar la evidencia concreta.
Pedir a la misma IA una puntuación de confianza
La puntuación puede orientar hacia fragmentos dudosos, pero no sustituye una fuente primaria, un cálculo independiente ni una prueba ejecutada en un entorno controlado.
Comparar únicamente dos modelos
La coincidencia entre herramientas puede servir como señal, pero ambas pueden repetir el mismo error. Para validar hechos y acciones siguen siendo necesarias evidencias independientes.
Probar solo el ejemplo proporcionado
Los fallos suelen aparecer en límites, entradas vacías, formatos inesperados, permisos insuficientes o estados que el ejemplo inicial no incluye.
Corregir el resultado sin conservar el motivo
Si no se registra qué se modificó y por qué, resultará difícil reproducir la decisión o detectar que una nueva versión ha introducido el mismo problema.
Compartir datos reales para conseguir más precisión
Antes de utilizar información real debe comprobarse si el tratamiento está permitido y es necesario. Cuando no pueda confirmarse, la alternativa prudente es emplear datos ficticios o retirar los campos sensibles.
Confundir utilidad con exactitud
Una propuesta puede ser útil para generar ideas aunque todavía no esté verificada. Un dato que se presentará como cierto necesita otro nivel de evidencia. La revisión depende del propósito de cada parte de la salida.
Checklist antes de aceptar, compartir o publicar
- La tarea, el destinatario y el uso previsto están definidos.
- Existen criterios de aceptación comprobables.
- Los hechos están separados de las inferencias, recomendaciones y opiniones.
- Las afirmaciones importantes se han contrastado con fuentes adecuadas.
- Las fuentes se han abierto y respaldan exactamente lo escrito.
- Las fechas, versiones, territorios y condiciones siguen siendo aplicables.
- Los cálculos se han repetido de forma independiente.
- Se han probado casos normales, fronteras y entradas erróneas.
- Cada prueba indica qué demuestra y qué deja sin verificar.
- Se han revisado omisiones, sesgos y posibles consecuencias del error.
- No se han introducido secretos ni datos innecesarios.
- Las acciones externas cuentan con permisos, registro y posibilidad de recuperación.
- Las incertidumbres y correcciones han quedado documentadas.
- La decisión final es aceptar, aceptar con condiciones o rechazar.
Saber cómo evaluar las respuestas de una IA generativa no implica descartar todo lo que produce. Implica asignar a cada salida el nivel de confianza que realmente ha demostrado. La herramienta puede acelerar un borrador, proponer alternativas y ayudar a localizar problemas; la aceptación debe apoyarse en criterios visibles, fuentes pertinentes, pruebas con un alcance definido y una decisión documentada.
Preguntas frecuentes
¿Cómo puedo saber rápidamente si una respuesta de IA es fiable?
Localiza primero las afirmaciones que cambiarían tu decisión. Contrástalas con fuentes primarias, revisa sus fechas y repite los cálculos importantes con otra herramienta. Si no puedes verificar esos elementos, utiliza la respuesta únicamente como borrador.
¿Pedir fuentes a la IA evita que invente información?
No. Pedir referencias facilita la revisión, pero cada enlace debe abrirse para confirmar que existe, que corresponde a la fecha y versión necesarias y que respalda exactamente la afirmación asociada.
¿Es suficiente comparar la respuesta en dos herramientas de IA?
No. Dos modelos pueden coincidir y repetir el mismo error. La comparación puede descubrir diferencias útiles, pero no sustituye las fuentes ni las pruebas independientes.
¿Qué respuestas necesitan una revisión más estricta?
Las que afectan a salud, derecho, seguridad, dinero, datos personales, decisiones profesionales, publicaciones públicas o acciones difíciles de revertir. La intensidad de la revisión debe aumentar con las consecuencias del error.
¿Se puede automatizar la evaluación de respuestas?
Solo en parte. Pueden automatizarse el formato, determinados cálculos, pruebas de código o la presencia de campos obligatorios. La validez de las fuentes, el contexto, las consecuencias y la decisión final requieren controles adicionales.
¿Una respuesta sin errores aparentes se puede publicar directamente?
No necesariamente. La ausencia de errores visibles no demuestra que las fuentes sean correctas, que no falten excepciones o que los datos sigan vigentes. Antes de publicar deben revisarse las afirmaciones relevantes para el lector y el posible impacto de una equivocación.
Fuentes oficiales para comprobar la configuración
Estas referencias oficiales permiten contrastar los pasos, límites y recomendaciones técnicas descritos.
