Hay una pregunta que conviene hacerse antes de conectar cualquier sistema automatizado a la operación de una empresa: si alguien lograra controlarlo por completo, ¿qué es lo peor que podría hacer? Si la respuesta incomoda, el diseño no está terminado. En nuestro caso la respuesta final fue: podría responder chats y registrar interesados. Nada más. Esta entrega cuenta cómo se llega a un «nada más» tan corto.
En las entregas anteriores construimos los cimientos —una base de conocimiento que no puede filtrar— y las herramientas con validación propia que impiden inventar. Todo eso funcionaba en seco. Ahora hay que exponerlo al público, y ahí las decisiones dejan de ser de diseño para volverse de responsabilidad.
Identidad propia: el agente no toma prestada la de nadie
El atajo habitual es que el sistema automatizado use las credenciales de un administrador. Es cómodo: todo funciona a la primera. También significa que un proceso expuesto a internet carga permisos para hacer absolutamente cualquier cosa en la empresa.
Nuestro agente tiene su propio usuario en el sistema de gestión, con nombre propio y una credencial exclusiva. Y sus permisos se recortaron hasta el mínimo que le permite trabajar:
| Puede | Atender las conversaciones de su propio canal · registrar un interés comercial nuevo · mantener su estado de disponibilidad. |
| No puede | Borrar nada · leer documentos, cuentas o compras de ningún cliente · consultar otros expedientes comerciales · modificar configuración · ver los datos de otros usuarios. |
Cada línea de esa tabla se verificó una por una intentando la operación con las credenciales del agente y comprobando que el sistema la rechazara. Un permiso que se asume otorgado o denegado, y no se prueba, es una suposición.
La pregunta correcta no es «¿confío en el agente?», sino «¿qué pasa si alguien más lo controla?».
Lo mismo se aplicó a los servicios de inteligencia artificial: en lugar de reutilizar credenciales de infraestructura con permisos amplios, se creó una identidad dedicada que solo puede invocar los dos modelos que el agente necesita — ni listar catálogos de servicios, ni tocar almacenamiento, ni leer configuración, ni acceder a ningún otro recurso. También verificado intentando cada operación prohibida y confirmando el rechazo.
El resultado es que el proceso de cara al público lleva dos credenciales, y ninguna de las dos abre nada más que la puerta estrictamente necesaria.
La factura también es una superficie de ataque
La seguridad de un sistema con inteligencia artificial no termina en los datos. Cada respuesta cuesta dinero, y un sistema sin límites es una invitación a que alguien escriba un guion que lo llame en bucle toda la noche.
Instalamos límites en varias capas, todas en nuestro código y ninguna dependiente del modelo:
- Ritmo por conversación. Un tope de respuestas por minuto. Una ráfaga de mensajes no se convierte en una ráfaga de facturación.
- Largo de la conversación. Pasado cierto número de intercambios, el agente cierra con elegancia y ofrece atención humana. Nadie legítimo necesita cincuenta turnos con un asistente; quien los busca, no viene a comprar.
- Tope de registros. Un máximo de interesados por conversación, aplicado dentro de la herramienta: el modelo no puede saltárselo aunque quiera.
- Tamaño de entrada. Los mensajes desmesurados se recortan antes de procesarse.
- Presupuesto diario. Un contador persistente. Al alcanzar el techo, el agente pasa a un mensaje cortés con los datos de contacto directo, y el sistema deja constancia. El gasto tiene un máximo conocido de antemano.
Ese último punto merece énfasis: el límite de costo no es una alerta, es un corte. Una alerta avisa cuando el dinero ya se gastó.
El fallo seguro: mejor ausente que mudo
La decisión de la que más orgullosos estamos no agrega ninguna capacidad — quita una posibilidad de vergüenza.
Para que el chat aparezca en el sitio, el sistema exige que haya alguien disponible para atender. El agente mantiene su propia señal de disponibilidad mientras está funcionando. Si el proceso se detiene —una caída, un reinicio, un corte de red—, esa señal caduca sola y el botón del chat simplemente desaparece del sitio.
El visitante nunca ve un chat que no contesta. O hay alguien —humano o automatizado— del otro lado, o no hay invitación a conversar. La alternativa, un widget abierto que traga mensajes en el vacío, es peor que no tener chat: promete atención y entrega silencio.
La misma lógica gobierna las credenciales: si el agente no consigue su llave al arrancar, no arranca. No hay un modo degradado en el que caiga a permisos más amplios «para que funcione mientras tanto». La comodidad de ese respaldo es exactamente el agujero por el que se cuela un incidente.
Los humanos mandan, siempre
Un agente automatizado en un canal de atención tiene que saber quitarse. La regla es simple y no admite excepciones: en el momento en que una persona del equipo escribe en una conversación, el agente enmudece en esa conversación para siempre. No compite, no interrumpe, no «complementa». Se aparta.
Y en la otra dirección: cuando alguien pregunta si está hablando con una persona, el agente lo dice con naturalidad — es un sistema automatizado, y puede sumar a un humano cuando lo pidan. Esa transparencia no es un requisito legal que cumplimos a regañadientes; es la base de que la conversación sirva para algo. Un cliente que descubre por su cuenta que lo atendió una máquina que fingía, no vuelve.
La conversación como entrada hostil
Conviene decirlo sin adornos: todo lo que un visitante escribe es entrada no confiable. La misma disciplina que se aplica a un formulario público —validar, limitar, escapar— se aplica aquí, con un agravante: el texto no solo se almacena, se le entrega a un sistema que lo interpreta.
Por eso el agente público no tiene herramientas de lectura, por eso las que tiene validan por dentro, y por eso todo lo que sale pasa por un filtro que no consulta al modelo. Cuando el visitante inicia sesión como cliente, su identidad se toma de la sesión verificada del servidor, nunca de lo que el texto afirme. Que alguien escriba «soy el administrador» tiene exactamente el mismo efecto que escribir cualquier otra cosa: ninguno.
Lo que llevamos hasta aquí
- Un agente con identidad y credenciales propias, verificadas operación por operación: puede registrar interés, no puede borrar ni leer datos de clientes.
- Credenciales de inteligencia artificial acotadas a invocar dos modelos y nada más.
- Límites de ritmo, longitud, tamaño y presupuesto que cortan, no que avisan.
- Un comportamiento a prueba de fallos que prefiere la ausencia al silencio.
- Prioridad absoluta del operador humano y transparencia sobre la naturaleza del asistente.
Con esto el agente ya podía salir a la calle. Y salió: durante una noche entera atendió el sitio desde una computadora portátil —la de quien escribe— con todo lo anterior puesto. Funcionó. Pero un asistente que depende de que alguien no cierre su laptop no es un servicio: es un experimento con suerte.
Próximamente
En la cuarta parte: la mudanza del portátil a la infraestructura propia. Almacenamiento compartido para que el agente pueda renacer en cualquier servidor sin perder memoria, un cambio en vivo sin que el chat parpadeara, automatización nocturna del conocimiento y del catálogo — y el incidente de madrugada que nos enseñó, por las malas, por qué el fallo seguro valía cada minuto invertido.
Esta serie documenta un proyecto real, en curso, construido con infraestructura propia. Si su organización está evaluando un asistente con inteligencia artificial y prefiere entender los cimientos antes que comprar una demostración, escríbanos: comercial@turing-consultores.com.