¿Quién responde cuando la IA informa mal en el soporte?

Conclusiones principales

• OLG Hamm, sentencia de 12 de mayo de 2026, núm. 4 UKl 3/25: quien opera el sistema responde de las afirmaciones falsas del chatbot, incluso con datos correctamente cargados
• Air Canada tuvo que pagar 812,02 dólares canadienses porque el chatbot prometió una tarifa por duelo con efecto retroactivo que la política no preveía. El argumento de que el bot era autónomo no prosperó.
• El art. 50(1) del Reglamento de IA exige, desde el 2 de agosto de 2026, que las personas reconozcan cuándo hablan con un sistema de IA y no con una persona.
• Las infracciones del art. 50 del Reglamento de IA pueden sancionarse con hasta 15 millones de euros o el 3 por ciento del volumen de negocios anual mundial.
• Una aprobación solo es eficaz si quien revisa dispone de tiempo y de la fuente. El sesgo de automatización deja sin valor la confirmación a ciegas.

Tres clases de error. Tres consecuencias distintas.

No todos los errores de la IA son iguales. En la práctica se distinguen tres clases, y la clase decide lo caro que sale el error y cuánta revisión merece. La primera clase: una característica de producto inventada. El Tribunal Regional Superior de Hamm (OLG Hamm) tuvo que resolver sobre el chatbot de una clínica que presentaba a los dos médicos de la empresa demandada como especialistas en cirugía plástica y estética y como especialistas en medicina estética. Esos títulos de especialidad no existen con esa forma o los médicos no los ostentan. El tribunal valoró las respuestas como prácticas comerciales ilícitas de la empresa conforme al § 5 Abs. 1, Abs. 2 Nr. 3 UWG (sentencia de 12 de mayo de 2026, núm. 4 UKl 3/25)¹.

La segunda clase: una información errónea sobre plazos o precios. El Tribunal Regional de Kiel (LG Kiel) tuvo que resolver sobre un servicio de información empresarial cuyo análisis automatizado comunicó por error que la demandante sería dada de baja por falta de patrimonio. La información falsa vulneró el derecho al honor de la empresa y fundamentó una acción de cesación contra quien la operaba (LG Kiel, sentencia de 29 de febrero de 2024, núm. 6 O 151/23)². La tercera clase: una promesa que nadie puede cubrir. El chatbot de Air Canada dio a entender a un cliente que podía solicitar la tarifa por duelo con posterioridad, algo que la política real no preveía. El Civil Resolution Tribunal de la Columbia Británica condenó a la aerolínea al pago de 650,88 dólares canadienses de indemnización más 36,14 dólares de intereses y 125 dólares de costas, 812,02 dólares canadienses en total³.

Por qué importa la distinción: una simple información puede ser falsa y aun así no vincular a nadie. Una promesa, en cambio, te vincula de inmediato, porque hacia fuera actúa como una declaración de tu empresa. Justo por eso las tres clases de error exigen distinta intensidad de revisión. Una característica inventada es sobre todo un riesgo de competencia y de inducción a error. Una información errónea sobre un plazo o un precio repercute en las relaciones contractuales. Una promesa sin cobertura es el caso más caro, porque hay que cumplirla de inmediato.

• Característica inventada: riesgo de inducción a error y de competencia, como en el caso de los títulos de especialidad no ostentados ante el OLG Hamm¹.
• Información errónea sobre plazos o precios: incide en relaciones contractuales existentes y puede vulnerar derechos ajenos, como en el caso de Kiel².
• Promesa sin cobertura: vincula a la empresa de inmediato, como la promesa de tarifa del chatbot de Air Canada³.

Para tu día a día en el soporte eso significa: cuanto más cerca esté una respuesta de un precio, un plazo o una promesa vinculante, más alto es el nivel de aprobación. Los cuatro niveles vienen más abajo.

El principio: el bot trabaja para ti.

Ninguno de los tres tribunales exigió responsabilidad a la IA misma. No es casualidad. Un sistema de IA no es una persona jurídica y no puede soportar derechos ni deberes. La responsabilidad recae siempre en quien opera el sistema bajo su propia responsabilidad. Justo así lo vieron, de forma independiente, tres decisiones de dos ordenamientos, dos en Alemania y una en Canadá.

El OLG Hamm trató las respuestas del chatbot como prácticas comerciales de la propia demandada. La empresa había alegado que las respuestas defectuosas no le eran imputables como práctica comercial propia. El tribunal no lo siguió: aunque la demandada hubiera hecho programar el bot exclusivamente con conjuntos de datos correctos, respondería de las indicaciones falsas. El chatbot tampoco es un tercero en el sentido de la ley, por lo que quedaba vedado recurrir a los requisitos de un deber de seguridad en el tráfico¹.

El LG Kiel atendió a la decisión empresarial previa: quien se sirve voluntariamente de su propio software para generar informaciones responde como perturbador directo del resultado plenamente automatizado. El tribunal escribió literalmente que la demandada no podía escudarse en no haber participado en ese proceso automático, porque se había servido conscientemente de una inteligencia artificial².

Y el tribunal de la Columbia Británica rechazó el argumento de que el chatbot fuera un sujeto de derecho separado, responsable de sus propios actos. En la resolución se lee que un chatbot tiene ciertamente un componente interactivo, pero sigue siendo solo una parte del sitio web de Air Canada, y que no hay diferencia entre que la información proceda de una página estática o de un chatbot³.

¿Qué de todo esto es texto legal y qué interpretación? El texto legal dice: § 280 Abs. 1 BGB: si el deudor incumple un deber derivado de la relación obligatoria, el acreedor puede exigir la indemnización del daño causado por ello. Esto no rige si el deudor no responde del incumplimiento⁴. Esa norma es el fundamento contractual típico de la pretensión cuando una información errónea del soporte perjudica a la clientela. Que una información de la IA se impute a quien la opera como declaración propia es, en cambio, interpretación derivada de las resoluciones citadas, no texto legal literal. Y un apunte previo: este artículo no es asesoramiento jurídico, sino una orientación para el día a día del soporte.

Identificación. Obligatoria desde agosto de 2026.

Desde el 2 de agosto de 2026 rige en la UE un deber de transparencia que muchos equipos de soporte tienen presente demasiado tarde. El artículo 50(1) del Reglamento de IA exige que los sistemas de IA destinados a interactuar directamente con personas físicas se diseñen de modo que esas personas sean informadas de que interactúan con un sistema de IA. El deber no rige cuando esto resulta evidente por las circunstancias para una persona razonablemente informada, atenta y perspicaz⁵. La fecha de aplicación se desprende del artículo 113 del Reglamento⁶.

La IHK de Schleswig-Holstein da al respecto una indicación práctica: el aviso debería aparecer justo al inicio de la comunicación y no solo en las condiciones generales o en la política de privacidad. Como formulaciones posibles, la IHK menciona frases como: está comunicándose con un sistema de IA. O bien: este chatbot responde a su consulta con ayuda de inteligencia artificial⁶.

Las infracciones del artículo 50 pueden sancionarse con multas de hasta 15 millones de euros o, en el caso de empresas, hasta el tres por ciento del volumen de negocios anual mundial. Se aplica el importe más alto; en el caso de las pymes, el más bajo⁷⁶.

• El aviso, al principio de la conversación, no en las condiciones generales⁶.
• Excepción solo cuando la participación de la IA resulta evidente para quien usa el servicio⁵.
• Multas de hasta 15 millones de euros o el tres por ciento del volumen de negocios anual mundial; se aplica el importe más alto⁶.

En la práctica eso significa: el aviso de identificación va en la propia ventana de chat, visible en el primer contacto. Un aviso en el pie de la web no basta. La identificación, por cierto, no protege frente a la responsabilidad por contenidos falsos. Cumple un deber propio y aclara de quién es la declaración que constituye la respuesta: tuya.

Sin registro no hay defensa.

Cuando ocurre un error, lo decisivo no es si ocurrió. Lo decisivo es si puedes reconstruirlo. Solo con un registro de la conversación, de la fuente citada y del traspaso puedes comprobar qué respondió la IA, cuándo y sobre qué base. Sin ese registro, en un litigio te apoyas en afirmaciones, y las afirmaciones no son una defensa.

Tres cosas tienen que quedar reconstruibles. Primero, la conversación misma: qué pregunta se hizo, qué respuesta se dio y cuándo. Segundo, la fuente: de qué artículo de conocimiento o documento respondió la IA, o si no hubo fuente alguna. Tercero, el traspaso: cuándo y por qué el sistema pasó el caso a una persona, o si justamente no lo hizo aunque debiera.

A ello se suma la aprobación misma. La IHK recomienda documentar quién revisó los contenidos y quién asume la aprobación final⁶. Trasládalo al soporte: en cada respuesta aprobada por una persona debería estar claro quién revisó y con qué fuentes. En un litigio, esa es la diferencia entre un proceso reconstruible y una laguna.

• Registra la conversación completa: pregunta, respuesta, momento.
• Guarda con ella la fuente citada: qué artículo de conocimiento, qué documento, o ninguna fuente.
• Documenta los traspasos: cuándo, por qué, a quién.
• Documenta las aprobaciones: quién revisó y dio el visto bueno⁶.

Una palabra sobre los plazos de conservación: cuánto tiempo debes guardar conversaciones y registros depende de tus obligaciones legales y contractuales, por ejemplo de la normativa de protección de datos y del derecho mercantil. Aquí no damos a propósito ningún plazo concreto, porque la duración correcta depende del caso. Regúlalo de forma consciente, por escrito, y acuérdalo con tu responsable de protección de datos. Conservar poco tiempo te cuesta la defensa; conservar demasiado te cuesta en protección de datos.

La base de conocimiento es la palanca de la responsabilidad.

La fuente de error más frecuente no es el modelo. Es el conocimiento desactualizado o contradictorio. Un agente de IA que responde desde una base de conocimiento vale lo que valen los artículos, los PDF y las páginas que le das. Un precio de 2023 en un PDF que nadie ha actualizado es para la IA una fuente tan válida como tu página de precios actual. El error no nace, pues, en el modelo, sino en tu mantenimiento.

Justo por eso la cita de la fuente es la segunda palanca en importancia. Cada respuesta que nombra su fuente hace localizables los errores: tu equipo ve al momento qué artículo produjo la afirmación falsa y puede corregirlo. El daño queda limitado a las respuestas alimentadas por esa única fuente. Las respuestas sin fuente, en cambio, no son comprobables, y son justamente las que no deberías permitir.

La lección de Air Canada muestra lo que la cita de la fuente no puede salvar. Air Canada alegó que la política correcta podía leerse en el sitio web. El tribunal lo rechazó: para Air Canada resultaba evidente que la empresa es responsable de toda la información de su sitio web, provenga de una página estática o de un chatbot³. Traducido: un enlace correcto junto a una respuesta falsa no te protege. La respuesta misma tiene que ser correcta.

• Nombra responsables: quién mantiene precios, plazos y condiciones contractuales en la base de conocimiento.
• Versiona los artículos críticos: mantén reconstruibles los cambios en precios, plazos y contratos.
• Retira activamente las fuentes obsoletas: un PDF antiguo en la base de conocimiento es una información falsa en diferido.
• Revisa las contradicciones: si dos artículos responden distinto a lo mismo, la IA elige uno de ellos, no el correcto.

Un proceso de mantenimiento no necesita una gran organización. Necesita responsables, un ritmo y una priorización. Los artículos críticos son todos los que afectan a un precio, un plazo, un contrato o una promesa. Esos van al principio de tu lista de revisión, no al final.

Cuatro niveles de aprobación para el día a día.

De todo lo dicho se sigue una pregunta sencilla para cada respuesta del soporte: ¿cuánta revisión necesita este contenido antes de salir? La respuesta se deja resumir en cuatro niveles. No son una norma jurídica, sino una traducción práctica de la situación de responsabilidad al día a día.

1. 01Nivel 1: respuesta totalmente automática con fuente. Para temas no críticos en los que la fuente da la respuesta de forma inequívoca: preguntas de navegación, información general de producto, remisiones a documentos. La IA responde directamente, citando la fuente.
2. 02Nivel 2: borrador de la IA, una persona revisa y envía. Para temas de riesgo medio: la IA presenta un borrador con fuente, una persona lo lee, lo ajusta y lo envía. Nada sale de forma automática.
3. 03Nivel 3: siempre una persona en precio, plazo, contrato y cualquier promesa. Estas respuestas no salen nunca de forma totalmente automática. Las redacta o las revisa y aprueba una persona, con la fuente a la vista.
4. 04Nivel 4: traspaso al equipo cuando la fuente no da para responder. Si la IA no encuentra una fuente fiable, no responde, sino que traspasa a una persona. Eso no es un fallo, es el nivel más seguro.

La asignación de temas típicos queda así: estado del pedido, descarga de facturas y acceso a la cuenta van al nivel 1, mientras la fuente sea inequívoca. Devoluciones y cancelaciones van al nivel 2 o 3, según si hay plazos en juego. Precios, plazos de preaviso, condiciones contractuales y cualquier forma de promesa, descuento, gesto comercial o condición especial van al nivel 3. Y todo lo que la base de conocimiento no responde de forma inequívoca va al nivel 4.

Una palabra de advertencia sobre el sesgo de automatización. El Instituto Alexander von Humboldt de Internet y Sociedad señala que las personas tienden a confiar en exceso en las decisiones previas de las máquinas, algo conocido como sesgo de automatización⁸. Trasladado al soporte, eso significa: un clic en aprobar, sin haber leído la fuente, no es una revisión. Es una confirmación. La diferencia es justo la que cuenta en un litigio.

Por eso quien revisa necesita dos cosas: tiempo y la fuente a la vista. Un borrador sin cita de la fuente no es comprobable; una persona sin tiempo no es un control. Si tus procesos de aprobación están construidos de modo que revisar va más rápido que leer, entonces nadie revisa de verdad. Reserva el tiempo, o la aprobación no vale nada.

Un ejemplo de nuestra propia configuración.

Para terminar, un ejemplo del propio taller, no un argumento de venta. ComLayer es una plataforma de soporte con IA con widget, Centro de ayuda, bandeja de entrada compartida y un agente de IA que responde exclusivamente a partir del conocimiento propio de la empresa. El agente solo responde preguntas cuando el conocimiento almacenado da la respuesta, y respalda cada respuesta con la fuente. Si el conocimiento no basta, no adivina, sino que traspasa a una persona.

Cómo se refleja eso en los cuatro niveles de aprobación: el nivel 1 es la respuesta automática con cita de la fuente, tal como la entrega el agente por defecto. El nivel 2 es el borrador de la IA en la bandeja de entrada compartida: para las preguntas abiertas hay listo un borrador de respuesta con fuente, tu equipo lo lee, lo ajusta y lo envía. Los niveles 3 y 4 son reglas de proceso de tu lado: las cuestiones de precio, plazo y contrato las configuras en tu espacio de trabajo de modo que pasen siempre por el borrador, y el traspaso cuando falta la fuente es el mecanismo técnico que refleja el nivel 4.

Lo que ComLayer tampoco puede hacer: quitarle a quien lo opera la revisión del contenido. Ninguna herramienta puede decidir por ti si tu artículo de precios está al día o si una promesa está cubierta. Eso sigue siendo tu responsabilidad, y justo por eso importan tanto el registro, la cita de la fuente y los niveles de aprobación. Cómo se evitan técnicamente las alucinaciones se explica en evitar las alucinaciones en el soporte; el lado de la protección de datos lo trata IA conforme al RGPD en la atención al cliente.

Preguntas frecuentes