Qué hacer cuando la IA se equivoca

Introducción

Se va a equivocar. No es una posibilidad remota que convenga mencionar por prudencia: es una certeza operativa. Cualquier sistema que procese lenguaje, clasifique documentos o proponga decisiones producirá resultados incorrectos con alguna frecuencia, igual que los produce una persona.

La pregunta útil, entonces, no es cómo evitar todos los errores, sino qué ocurre cuando llega el primero. Si la respuesta es "no lo sé", el sistema no está listo para producción por muy bien que funcione en las pruebas.

Este artículo trata de eso: cómo se detecta un error, cómo se deshace, quién responde de él y qué se le cuenta al cliente afectado.

No todos los errores son el mismo problema

Antes de preparar nada conviene distinguir, porque las medidas son distintas.

Visible frente a silencioso. Un error visible es el que alguien nota: una respuesta absurda, un dato que no cuadra, un documento mal clasificado que salta a la vista. Es molesto y es barato. El peligroso es el silencioso: el importe que se traspasa con un decimal cambiado, la factura que se archiva en el proveedor equivocado, el correo que se responde con una condición que ya no está vigente. Nadie lo ve, y el daño crece con el tiempo.

Puntual frente a sistemático. Un fallo aislado en un caso raro es tolerable y se corrige. Un fallo sistemático (todos los documentos de un formato, todos los clientes de una provincia, todo lo que ocurre a fin de mes) indica un problema de diseño y no se arregla revisando caso por caso.

Recuperable frente a irreversible. Un borrador mal redactado se reescribe. Un correo enviado a un cliente no se recupera, y un asiento contable propagado a un cierre tampoco sin coste. La distinción determina cuánta verificación previa merece la pena.

Esta clasificación no es académica: dice dónde poner el esfuerzo. Un sistema que solo produce errores visibles, puntuales y recuperables puede funcionar con supervisión ligera. Uno que puede producir errores silenciosos e irreversibles necesita controles antes de cada acción, no después.

Cómo se prepara la respuesta

Detección: que el error no dependa de que alguien lo note

Confiar en que el equipo detecte los fallos funciona con los visibles y no funciona con el resto. Hacen falta comprobaciones automáticas sobre lo que el sistema produce: rangos plausibles para los importes, formatos esperados, coherencia con el histórico del cliente, señales de que el volumen de casos "resueltos sin intervención" ha cambiado de golpe.

Una revisión por muestreo, aunque sea de veinte casos a la semana, detecta problemas sistemáticos mucho antes que esperar a que alguien se queje. Los marcos de gestión de riesgo de sistemas de IA insisten en que la medición y la vigilancia continuada forman parte del funcionamiento normal, no de la puesta en marcha (NIST, 2023).

Reversibilidad: poder deshacer sin drama

Antes de dar a un sistema la capacidad de escribir en algún sitio, conviene responder a una pregunta: si esto hace mil operaciones equivocadas esta noche, ¿cómo las deshago mañana?

Si la respuesta implica revisar mil registros a mano, hay que cambiar el diseño. Las salidas conviene marcarlas de forma que se puedan identificar y revertir en bloque, y en procesos delicados es preferible que el sistema deje la operación preparada y que sea una persona quien la confirme. Cuesta algo de eficiencia y ahorra el incidente que se recuerda durante años.

Trazabilidad: saber qué pasó y por qué

Cuando aparece el error, la pregunta inmediata es de dónde salió. Sin registro de qué datos usó el sistema, qué produjo y en qué momento, la investigación se convierte en conjeturas.

Esto no es solo higiene técnica. La normativa española de protección de datos exige poder acreditar cómo se tratan los datos personales, y la AEPD subraya la necesidad de trazabilidad y de medidas que permitan revisar y corregir los tratamientos que incorporan inteligencia artificial (AEPD, 2024).

Escalado: que el sistema sepa cuándo callarse

Un sistema bien diseñado reconoce sus límites y se detiene. Es preferible que derive el 20 % de los casos a una persona y acierte en el 80 % restante, a que responda a todo con un porcentaje de acierto peor y sin avisar de cuándo duda.

Ese umbral es una decisión de negocio, no técnica: depende de cuánto cuesta un error frente a cuánto cuesta una revisión humana.

Quién responde

Conviene tenerlo claro antes de que ocurra: responde la empresa. Si un sistema envía una comunicación equivocada a un cliente, el cliente no reclama al proveedor de la tecnología ni al fabricante del modelo. Reclama a quien le prestó el servicio.

En materia de protección de datos, la empresa que decide para qué y cómo se tratan los datos es la responsable del tratamiento, y esa condición no se traslada por contratar a un tercero: el proveedor actúa como encargado y responde ante la empresa, no ante el cliente final. El marco europeo de inteligencia artificial refuerza esa lógica al exigir supervisión humana y gestión de riesgos proporcionales al impacto del sistema (Parlamento Europeo y Consejo, 2024).

De ahí se deriva una consecuencia práctica: el contrato con el proveedor tiene que decir qué ocurre cuando algo falla. Quién investiga, en cuánto tiempo, quién asume el coste de rehacer el trabajo y cómo se comunica. Un proveedor que evita esa conversación está anticipando cómo se comportará el día del incidente.

Errores frecuentes en la gestión del error

Apagarlo todo al primer fallo. La reacción instintiva es desconectar el sistema. A veces es lo correcto, pero muchas veces el fallo afecta a un tipo de caso concreto y basta con desviarlo a revisión manual mientras se corrige. Apagar entero convierte un problema acotado en una interrupción general.

Corregir el caso y no la causa. Se arregla el expediente que falló, se da por cerrado el incidente y el mismo error reaparece a las tres semanas en otro expediente.

No avisar al cliente afectado. Cuando el error ha salido de la empresa, ocultarlo multiplica el daño. Un cliente al que se le explica que hubo un fallo, que se ha corregido y qué se ha hecho para que no se repita suele reaccionar mucho mejor que uno que lo descubre solo.

No registrar los incidentes. Sin un registro de qué falló y con qué frecuencia, no hay forma de saber si el sistema está mejorando o empeorando, ni de decidir con criterio si compensa seguir.

Conclusión

Un sistema en producción no se juzga por su comportamiento cuando todo va bien, sino por lo que ocurre el día que falla. Y falla.

Las tres preguntas que conviene poder responder antes de conectar nada son sencillas. ¿Cómo me entero de que se ha equivocado, si nadie lo nota? ¿Cómo deshago lo que haya hecho? ¿Quién responde ante el cliente y en qué plazo?

Si las tres tienen respuesta escrita, el sistema está listo. Si alguna se contesta con un "bueno, ya veríamos", queda trabajo por hacer, y hacerlo antes cuesta bastante menos que improvisarlo con un cliente enfadado al teléfono.

Referencias

Agencia Española de Protección de Datos [AEPD]. (2024). Tratamientos que incluyen inteligencia artificial (IA). https://www.aepd.es/documento/tratamientos-inteligencia-artificial.pdf

NIST. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1

Parlamento Europeo y Consejo. (2024). Reglamento (UE) 2024/1689 por el que se establecen normas armonizadas en materia de inteligencia artificial. Diario Oficial de la Unión Europea. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=OJ:L_202401689