Un chatbot de atención al cliente no es un empleado que puedas despedir cuando dice algo que no debía. Es tu empresa hablando, con las mismas consecuencias legales que si lo dijera un gerente.

Eso fue exactamente lo que un tribunal de Columbia Británica confirmó en febrero de 2024, y es el punto de partida real para cualquiera que esté por poner un agente de IA frente a sus clientes.

El día que un tribunal trató al chatbot como parte de la empresa

Un pasajero de Air Canada consultó al chatbot de la aerolínea sobre una tarifa por duelo, la que se aplica cuando alguien viaja por el fallecimiento de un familiar. El chatbot le dio información incorrecta.

Cuando el pasajero reclamó, Air Canada argumentó algo que suena a excusa de otra época: que el chatbot era “una entidad legal separada” responsable de sus propias respuestas.

El tribunal no lo aceptó. Resolvió que Air Canada debía compensar al pasajero, porque lo que el chatbot dice, la empresa lo dice, según reportó CanLII.

La sentencia no trata sobre filtración de datos ni sobre seguridad técnica. Trata sobre algo más básico y más incómodo: nadie va a creerte que tu bot es un tercero.

Es tan tuyo como tu página de precios o tu contrato de servicio. Y ese es el error de diseño que más cuesta caro, porque no ocurre en el código, ocurre en la cabeza de quien decide implementarlo.

Tratar al agente como una caja que responde sola, en vez de como una extensión de la empresa que hay que vigilar con el mismo rigor que a cualquier persona que atiende clientes. Esa distinción cambia por completo qué preguntas hay que hacerse antes de encenderlo.

Cómo implementar un agente de IA para atención al cliente sin exponer datos de clientes empieza por delimitar una tarea

La tentación es lanzar un agente que “entienda de todo”: pedidos, reembolsos, cuentas, políticas, quejas. Es la misma tentación de contratar a alguien sin definirle el puesto y esperar que resuelva cualquier cosa.

No funciona con personas y no funciona con un modelo.

El punto de partida no es técnico, es de alcance: elegir una tarea concreta, con un canal definido, un tipo de usuario claro y un límite explícito de lo que el agente puede y no puede hacer.

Consultar el estado de un pedido es una tarea acotada. Aprobar un reembolso, modificar una cuenta o negociar una compensación no lo es, al menos no al principio.

El marco de gestión de riesgos de IA del Instituto Nacional de Estándares y Tecnología de Estados Unidos, conocido como NIST, propone organizar esta fase alrededor de cuatro funciones: gobernar, mapear, medir y gestionar.

Es un marco de orientaciones voluntarias, no una certificación de seguridad, y su versión actual está en revisión. Pero la lógica de fondo sirve incluso sin certificación de por medio.

Antes de construir nada, alguien tiene que documentar qué hace el agente, quién es el dueño de esa decisión y quién autoriza cambiarla después. Esa documentación no es burocracia decorativa.

Es lo que le permite a la empresa, meses después, explicar por qué el agente hizo lo que hizo, en vez de encogerse de hombros como hizo Air Canada.

¿Cuánto acceso necesita el agente para hacer su trabajo?

Aquí está la pregunta que más se salta, porque suena técnica y en realidad es una decisión de negocio: ¿qué información necesita ver el agente para resolver la tarea que le diste?

Y, más importante todavía, ¿qué información puede consultar aunque no la necesite?

La respuesta correcta casi siempre es menos de lo que el equipo de sistemas quiere darle. Un agente que consulta el estado de un pedido no necesita acceso al historial completo de compras de un cliente.

Tampoco a sus datos de pago, ni a su información de contacto más allá de lo indispensable para identificar el pedido en cuestión. Cada permiso adicional que le das al agente es una puerta que, si algo sale mal, se abre también.

Esto no es una cifra de un estudio ni una advertencia de un proveedor de software. Es sentido común aplicado con disciplina, un criterio que en IA Aplicada repetimos cada vez que el tema es adopción empresarial de IA.

Nadie le da a un practicante recién llegado acceso a la nómina completa de la empresa el primer día. El mismo criterio aplica a un sistema que todavía está en fase de prueba, aunque hable con fluidez y responda rápido.

Vale la pena anotar la objeción que probablemente ya te hiciste: ¿por qué gastar en diseñar todo esto cuando hay tutoriales gratis para montar un chatbot en una tarde?

Porque un tutorial te enseña a conectar un modelo a un canal de chat. No te enseña a decidir qué no debería poder hacer ese modelo, y esa es la parte que termina en un tribunal o en una nota de prensa incómoda.

¿Cómo se prueba un agente antes de ponerlo frente a clientes reales?

Antes de publicar un agente, hay que someterlo a algo más que una demostración bonita con preguntas fáciles.

Hay que probarlo con lo que un cliente real, y también un usuario malintencionado, le harían pasar: pedir un dato ajeno, insistir con instrucciones contradictorias, intentar que revele información que no le corresponde entregar.

Una prueba concreta y medible: de cien conversaciones de prueba que piden información de otra persona, ¿cuántas bloquea correctamente el agente, y cuántas bloquea por error cuando el cliente sí tenía derecho a esa información?

Esa pregunta obliga a medir dos cosas al mismo tiempo, protección y utilidad, en vez de declarar “seguro” a un sistema que solo superó tres preguntas amables en una demostración interna.

Y antes de encenderlo para todos los clientes, alguien tiene que poder apagarlo. No como metáfora: un procedimiento real, documentado, que diga quién decide pausar el agente y devolver el flujo a un humano si algo empieza a salir mal.

El agente que no tiene un botón de apagado claro es el mismo que, si comete un error como el de Air Canada, va a costarle a la empresa exactamente lo mismo. La excusa de “no fui yo, fue el bot” ya no le sirve a nadie desde 2024.

Esta es la parte que separa a una empresa que implementó un agente de IA con criterio, de una que instaló un Clippy con esteroides.

Aquel asistente de Microsoft Office que aparecía sin que nadie se lo pidiera a “ayudarte” con una carta, entendía poco del contexto real y nunca tuvo un plan claro para cuando se equivocaba.

La diferencia entre aquello y un agente bien implementado no es la tecnología. Es que alguien, esta vez, sí se sentó a decidir qué podía hacer y qué no.

Si un director de recursos humanos ya trae esta conversación encima y nadie le ha dicho quién responde cuando el agente se equivoca, más vale que lo resuelva antes de que se lo resuelva un tribunal — de eso hablamos justo en el mail de LuisGyG.

Supervisado por Santiago González y Musi.