Toda empresa que trabaja con IA llega tarde o temprano al mismo momento: el sistema responde con un tono seguro y esa respuesta es incorrecta.
Eso no significa que el sistema se haya estropeado. Los modelos de lenguaje trabajan con probabilidades; cuando la información disponible no alcanza, pueden componer la frase más plausible en lugar de callar. La cuestión de fondo no es que una respuesta pueda ser errónea, sino que una respuesta errónea llega con el mismo tono que una correcta.
Este artículo explica por qué aparecen las respuestas erróneas, cuándo importan de verdad y dónde colocar los controles durante la implantación.
🔍 Tenga esto en cuenta: Llevar la IA a una empresa no consiste en dar el error por inexistente, sino en decidir de antemano dónde va a caer. Si una respuesta llega al cliente, a la pantalla de un empleado o a una casilla de aprobación es una decisión de la implantación.
¿Por qué la IA responde mal?
Rara vez hay una sola causa. Estas cuatro son las que más aparecen en las implantaciones.
La información falta o está desfasada
El modelo lee de la fuente que se le ha dado. Si la lista de precios no está al día, si un artículo retirado sigue en el catálogo o si un cambio de norma vive solo en la cabeza de alguien, la respuesta se construye sobre esa información antigua. Lo defectuoso aquí es la fuente, no el modelo.
La pregunta es ambigua
Una pregunta como "¿qué hago con este pedido?" admite varias respuestas correctas cuando llega sin contexto. El modelo elige una y justifica su elección. Un colega humano repreguntaría; un sistema puede seguir adelante con una suposición.
Rellenar el hueco
Si la fuente no contiene la respuesta, el modelo puede producir una siguiendo patrones aprendidos de textos parecidos. Ese comportamiento suele llamarse alucinación. La frase resultante es impecable como lengua e inventada como contenido. Este es el error que se esconde.
Fuente correcta, contexto equivocado
La información es cierta pero pertenece a otro caso. Una condición pensada para un grupo de clientes se le cuenta a todos porque en el sistema no se definió la distinción. Estos errores parecen correctos vistos de uno en uno, así que pueden notarse tarde.
No todos los errores pesan igual
Tratar todos los errores con la misma gravedad vuelve pesada la implantación, y ese peso no lo sostiene nadie. La distinción sigue a lo que el error toca.
- Errores que quedan dentro: un empleado ve la respuesta equivocada, la corrige y el trabajo continúa. El coste es bajo.
- Errores que llegan al cliente: la información equivocada sale fuera. Ya no es un asunto técnico sino de confianza.
- Errores con dinero o derecho: precio, descuento, condición contractual, datos personales. En este grupo conviene que la respuesta no salga directamente.
Sin esa distinción, las implantaciones acaban en uno de los dos extremos: o toda respuesta espera aprobación y el sistema se vuelve lento, o no se construye ninguna puerta de aprobación y el primer error serio ocurre a la vista de todos.
¿Dónde va la aprobación humana?
La aprobación va donde un error podría salir caro, no en cada paso del sistema. En la práctica pueden funcionar tres ubicaciones.
La puerta de aprobación
Las respuestas de un tipo definido caen en la pantalla de una persona antes de enviarse. Esa persona aprueba, corrige o rechaza. La puerta actúa solo en los flujos elegidos y el resto avanza sin esperar.
Detenerse ante la duda
Un sistema puede configurarse para ceder la pregunta en lugar de contestarla cuando la fuente no tiene correspondencia. "Se lo paso a un compañero" es mejor que una respuesta inventada. Ese comportamiento se escribe durante la implantación y no surge por sí solo.
El límite de la autoridad
Lo que el sistema puede hacer por su cuenta debería estar por escrito: puede informar y abrir un registro, pero no cambiar un precio ni aprobar una devolución. Si el límite no está escrito, no hay límite.
Apoyar la respuesta en fuentes propias
La vía más directa frente a las respuestas erróneas es que el modelo conteste desde los documentos de la propia empresa y no desde su conocimiento libre. El sistema toma la pregunta, localiza el documento pertinente y apoya la respuesta en él.
De ahí pueden salir dos beneficios laterales. El primero, poder mostrar la fuente junto a la respuesta: se ve en qué documento se apoya y la comprobación se vuelve sencilla. El segundo, que la fuente se quede en la empresa. Dónde reposan los datos y hacia dónde viajan es otro asunto, tratado en a dónde van sus datos.
Apoyarse en la fuente convierte a la fuente misma en una responsabilidad. Si el documento está desfasado, la respuesta también lo estará. Por eso se decide pronto qué documento cuenta como vigente y quién lo mantiene.
¿Qué se hace cuando aparece una respuesta errónea?
No basta con corregirlas de una en una; hay que llegar a la causa para que el mismo error no vuelva. El orden puede ser este:
- El caso se guarda con su registro: qué se preguntó, en qué fuente se apoyó, quién lo vio.
- Se separa la causa: fuente desfasada, pregunta ambigua o un hueco rellenado.
- Si la fuente está desfasada, se actualiza el documento y se nombra a su responsable.
- Si la pregunta era ambigua, se configura el sistema para que repregunte.
- Si se están rellenando huecos, ese tema pasa a la puerta de aprobación o a la cesión.
Sin este flujo por escrito, los errores se comentan uno a uno y el mismo vuelve varias veces. Dónde se atascan los proyectos lo tratamos aparte en por qué fracasan los proyectos de automatización.
¿Por qué importa guardar registro?
Si el sistema no recuerda lo que dijo, del error no se saca lección. Visto después, el registro debería responder a estas preguntas: cuándo llegó la pregunta, qué se respondió, en qué documento se apoyó, si pasó por aprobación y quién aprobó.
Ese registro es además una prueba. Cuando un cliente dice "su sistema me dijo otra cosa", la conversación se apoya en el archivo y no en la memoria.
¿Qué se le dice al cliente?
Saber que se habla con un sistema no daña la confianza; enterarse después sí. Una frase de presentación clara y una salida hacia una persona van al principio de la conversación.
Cuando un error sí llega fuera, el mejor camino es corregir sin demora y decir con sencillez qué salió mal. Cómo se construyen los flujos de cara al cliente se explica en automatización de atención al cliente.
Preguntas antes de la implantación
Si estas preguntas se plantean al inicio de un proyecto de IA, buena parte del debate posterior puede sobrar.
- ¿De qué fuente construirá el sistema sus respuestas?
- ¿Quién actualiza esa fuente y con qué frecuencia se revisa?
- ¿Qué respuestas pueden salir sin pasar por una persona?
- ¿Qué hace el sistema cuando duda?
- ¿A quién se avisa cuando se detecta una respuesta errónea?
- ¿Dónde se guardan los registros de conversación y quién puede verlos?
Las respuestas cambian de una empresa a otra. Si prefiere trabajar el levantamiento de procesos de forma práctica, nuestra serie de formación aborda estos temas paso a paso.
Cómo trabajamos
Empezamos por fijar de qué fuente se construirán las respuestas. Después escribimos juntos qué respuestas pasan por aprobación y qué hace el sistema cuando duda.
No proponemos una implantación que dé el error por inexistente. En su lugar decidimos dónde va a caer, guardamos su registro y metemos la vía de corrección dentro de la propia implantación.
Preguntas frecuentes
¿Cómo notamos que la IA ha respondido mal?
Notarlo solo con la lectura es difícil, porque una respuesta errónea está escrita en la misma lengua que una correcta. En la práctica ayudan tres cosas: mostrar la fuente junto a la respuesta, la aprobación humana en temas delicados y leer los registros de conversación por muestreo a intervalos fijos. Las reacciones de clientes del tipo "a mí me consta otra cosa" también deberían recogerse como canal aparte.
¿Tiene que aprobar una persona cada respuesta?
Por lo general no, y hacer pasar toda respuesta por aprobación puede volver el sistema inservible. La distinción sigue al tipo de respuesta: las que informan, abren un registro o derivan pueden salir directamente en la mayoría de las empresas. Las que tocan precio, descuento, condición contractual, devolución o datos personales pueden ir a la puerta de aprobación. Esa lista se escribe durante la implantación y se revisa con el tiempo.
¿Puede el sistema aprender a decir "no lo sé"?
Es menos una cuestión de aprendizaje que de configuración. Cuando la fuente no tiene correspondencia, el sistema puede construirse para ceder el tema a una persona en lugar de producir una respuesta. La redacción de esa cesión, a quién va y en cuánto tiempo debería esperar respuesta el cliente se deciden en la misma implantación. Ese comportamiento no viene por defecto, hay que escribirlo.
¿Quién responde por el daño de una respuesta errónea?
La responsabilidad mira a quien opera el sistema y no al sistema mismo, por eso los límites de la implantación deben constar en el contrato. Si se acuerda de antemano qué respuestas pasan por aprobación humana, cuánto tiempo se guardan los registros y cómo se comunica un error detectado, la discusión no se aplaza. Si su sector está regulado, estas cláusulas deberían redactarse con su asesoría jurídica.
¿Un sistema apoyado en nuestros documentos puede responder mal igualmente?
Sí, pero cambia el tipo de error. En un sistema apoyado en fuentes, las respuestas inventadas se vuelven escasas; lo que pasa a primer plano es elegir el documento equivocado o llevar un documento correcto a un contexto que no le corresponde. Estos errores son más fáciles de ver, porque el documento en el que se apoya la respuesta queda a su lado. Mantener la fuente al día es por eso una parte permanente de la implantación.
Fijemos Juntos de Dónde Vienen Sus Respuestas
Antes de proponer una implantación hablamos de la fuente, de los puntos de aprobación y del camino que sigue el sistema cuando duda.
💬 Pide presupuesto por WhatsAppConclusión
Que la IA responda mal no es una avería, es una consecuencia de su forma de trabajar. Por eso la pregunta de la implantación no es "¿puede haber un error?", sino dónde va a caer.
Apoyar las respuestas en las fuentes propias de la empresa, llevar las respuestas delicadas a la puerta de aprobación, escribir que el sistema se detiene ante la duda y registrar las conversaciones. Con esas cuatro piezas puestas, el error no desaparece, pero se vuelve visible y corregible.