«¿Puede equivocarse su asistente?» En una demostración comercial, la pregunta a veces enfría el ambiente. Acabamos de ver una síntesis impecable, una respuesta instantánea, un documento redactado en pocos segundos. Reconocer los límites parece entonces deshacer la promesa. Sin embargo, el riesgo empieza sobre todo cuando nadie sabe qué verificar. Para los equipos que despliegan la IA, el reto de este inicio de curso de 2026 no es tanto tranquilizar a toda costa como construir una confianza aplicable en la práctica: saber cuándo seguir la herramienta, cuándo supervisarla y cuándo ceder el control.
La confianza no se decreta en una demostración
Los asistentes generativos han introducido una ambigüedad en la relación con el cliente. Su soltura verbal parece dominio del tema, incluso cuando producen información falsa. Una formulación clara, un tono profesional, unas cuantas referencias: todo invita a leer la respuesta como si fuera la de un especialista. Sin embargo, la calidad de la presentación no garantiza la solidez del contenido. Para un usuario con prisas, esta diferencia sigue siendo difícil de percibir.
El caso de Air Canada lo demostró de forma concreta en 2024. Un cliente había recibido, a través del chatbot de la compañía, información errónea sobre una tarifa por duelo. El tribunal civil de Columbia Británica consideró responsable a la compañía de esa información. La lección va más allá del transporte aéreo: ofrecer una interfaz automatizada no basta para trasladar la responsabilidad a la herramienta o a su usuario.
Los hechos mencionados aquí son precedentes documentados; las propuestas para septiembre de 2026 pertenecen al análisis prospectivo. No obstante, una evolución parece fundamental: a medida que la IA interviene en procesos comerciales, documentales o administrativos, explicar sus condiciones de uso pasa a formar parte del servicio. Ya no es solo una precaución jurídica ni una tarea reservada a los ingenieros.
Decir qué puede fallar, no solo que la IA es imperfecta
«La IA puede cometer errores» es una frase cierta, pero poco útil. No dice cuáles, ni en qué circunstancias, ni con qué consecuencias. Repetida debajo de cada respuesta, corre el riesgo de convertirse en ruido de fondo. El cliente escucha una advertencia general; sin embargo, sigue teniendo que descubrir por sí solo las situaciones peligrosas.
Una explicación eficaz distingue tres dimensiones. El alcance: ¿qué fuentes, qué idiomas y qué documentos están cubiertos? Las debilidades: ¿qué ocurre si falta un documento, hay una norma reciente o la solicitud es ambigua? La actuación recomendada: ¿qué comprobación debe realizarse antes de decidir? Este desglose transforma una debilidad abstracta en una instrucción concreta.
Para un asistente que analiza contratos, es preferible indicar: «Identifica cláusulas en los documentos facilitados, pero puede pasar por alto una excepción repartida entre varios anexos. Pida a su asesor jurídico que valide los puntos que impliquen compromisos». Esta formulación no elimina el riesgo. Establece un límite comprensible, asociado a una acción y a un interlocutor.
Convertir la incertidumbre en una conversación
Empezar por el uso del cliente
Antes de explicar el modelo, hay que comprender la decisión que debe ayudar a tomar. Elaborar un primer borrador y confirmar un derecho a indemnización no requieren el mismo nivel de fiabilidad. La pregunta adecuada pasa a ser: «¿Qué hará con esta respuesta?». Así se revela lo que realmente está en juego, sin imponer al cliente una clase sobre probabilidades o sobre la arquitectura de las redes neuronales.
Aquí es donde cuentan las habilidades interpersonales: escucha, reformulación y capacidad para plantear una pregunta incómoda. Un responsable de despliegue debe poder decir: «Si esta respuesta desencadena un pago, nuestro sistema actual no basta sin un control adicional». No está saboteando la venta. Está evitando vender un uso cuya seguridad el sistema no puede garantizar.
Explicar sin abrumar
Comunicarlo todo de golpe tampoco ayuda. Un aviso interminable a veces protege a la organización sobre el papel, pero deja al usuario sin recursos a la hora de actuar. Un enfoque más sólido consiste en distribuir la información: los límites esenciales antes de la adopción, las alertas contextuales durante el uso y los detalles técnicos en documentación accesible. La transparencia adecuada llega en el momento oportuno.
También hay que tener cuidado con los porcentajes de confianza. Una puntuación solo es útil si su significado está claro y su fiabilidad se ha evaluado en el contexto correspondiente. De lo contrario, reviste la incertidumbre de una precisión engañosa. Indicar que falta una fuente, que un documento es antiguo o que dos referencias se contradicen puede ser mucho más esclarecedor que un indicador verde.
Mostrar los límites durante la demostración
Una demostración compuesta únicamente de éxitos enseña un mal hábito: creer que el sistema siempre sabe responder. También hay que mostrar un caso incompleto, una pregunta fuera de su ámbito y una situación en la que el asistente debería abstenerse. El cliente descubre entonces no solo lo que produce la herramienta, sino cómo se comporta cuando las condiciones empeoran.
Este enfoque exige una coordinación interna. Si el comercial promete una autonomía total, el producto muestra una advertencia discreta y el servicio de soporte exige después una validación humana, el cliente recibe tres versiones del servicio. Un vocabulario común debe conectar la promesa comercial, la interfaz, la formación y el contrato. Las salvedades no pueden aparecer solo después del incidente.
- Antes del uso: presentar las tareas adecuadas y las exclusiones importantes.
- Durante el uso: señalar la información que falta y permitir consultar las fuentes cuando existan.
- Después de un error: ofrecer una corrección, la posibilidad de recurrir a una persona y una explicación verificada.
Después del error, reconocer antes de justificar
Cuando un cliente señala una respuesta falsa, explicar de inmediato que los modelos son probabilísticos suena a evasiva. La primera respuesta debe reconocer el problema y su impacto: ¿qué información era incorrecta, qué trámite se ha visto afectado y qué se puede reparar? El análisis técnico viene después, con una distinción clara entre la causa demostrada y la hipótesis.
También hay que resistirse a la promesa automática: «Esto no volverá a ocurrir». Corregir una base documental no demuestra que todas las respuestas futuras vayan a ser exactas. Es preferible describir la medida adoptada, las pruebas realizadas y el riesgo residual. Esta precisión puede parecer menos tranquilizadora en ese momento, pero evita una segunda ruptura de la confianza.
El Reglamento europeo de IA, adoptado en 2024, incluye en su calendario de aplicación obligaciones de transparencia para determinadas interacciones con sistemas de IA. Pero identificar un chatbot como tal no basta para explicar su fiabilidad. Para los equipos, el trabajo en la relación con el usuario sigue pendiente: formar a los usuarios, organizar la derivación a instancias superiores y comprobar que las advertencias se entienden, no simplemente que se muestran.
¿Y ahora qué? A partir de septiembre de 2026, una ventaja competitiva podría depender de esta capacidad para delimitar el uso con honestidad. Los equipos más creíbles no serán necesariamente los que prometan menos errores, sino los que hagan que los errores se puedan detectar, debatir y reparar. Siempre que lo conviertan en una práctica colectiva: la confianza no descansa en una advertencia bien redactada, sino en lo que ocurre cuando el modelo alcanza realmente su límite.
