Le pedimos al agente que registrara el interés de una clienta que acababa de escribir: «quiero una cotización de cortafuegos». El agente lo intentó de inmediato. Y el sistema se lo negó: faltaba el nombre, faltaba un medio de contacto. Un turno después, con los datos ya en la conversación, el registro se creó correctamente. Ese pequeño forcejeo —el modelo intentando adelantarse y la herramienta frenándolo— es el corazón de esta segunda entrega.
En la primera parte construimos los cimientos: una base de conocimiento que por diseño no puede filtrar información interna. Ahora toca la pregunta difícil: ¿qué se le permite hacer a un agente que habla con desconocidos y está conectado al sistema de gestión de la empresa?
La tentación de darle las llaves
La forma rápida de conectar un agente a un sistema empresarial es darle acceso a su interfaz de programación y dejar que el modelo redacte las instrucciones. Funciona en la demostración. Es indefendible en producción.
El motivo es estructural: un modelo de lenguaje procesa todo lo que llega como texto — incluido lo que escribe el visitante. Si ese texto puede convertirse en instrucciones ejecutables, cualquiera con un teclado tiene una consola abierta contra su empresa. No hace falta ser un atacante sofisticado: basta con escribir con suficiente autoridad.
Si el modelo redacta las órdenes, el visitante también puede. La seguridad no puede depender de que el agente sea discreto.
Herramientas tipadas: el modelo elige, el código decide
La alternativa que adoptamos invierte la responsabilidad. El agente no escribe instrucciones para el sistema: solicita acciones concretas de una lista corta y cerrada, y cada una está implementada por nosotros, con sus propias validaciones por dentro.
El agente público tiene exactamente dos:
- Buscar en el catálogo publicado. Devuelve productos reales con su enlace. Si no hay coincidencia razonable, devuelve vacío — y el agente tiene prohibido ofrecer enlaces cuando la herramienta no le dio ninguno. No existe forma de que invente un producto: los enlaces que puede compartir son únicamente los que la herramienta le entregó.
- Registrar un interés comercial. Exige nombre, un medio de contacto válido y un resumen de la necesidad. Verifica el formato del correo. Impone un tope por conversación. Y no acepta datos que el visitante no haya dado.
La diferencia con «pedirle al modelo que se porte bien» es la misma que hay entre un formulario con validación y una hoja en blanco con instrucciones al pie. Lo que se audita no es la conducta del modelo, sino veinte líneas de código que se pueden leer en un minuto.
Por eso el forcejeo del inicio es una buena noticia: el modelo se adelantó —como se adelantaría un vendedor con prisa— y la validación lo devolvió a pedir los datos. El comportamiento correcto no dependió de la instrucción, sino de la estructura.
El banco de pruebas: intentar romperlo antes de que lo intenten otros
Un asistente conversacional no se puede validar «probándolo un rato». Cada cambio en las instrucciones puede corregir una cosa y estropear otra, y el juicio del que construyó siempre es optimista. Hace falta un banco de pruebas: un conjunto de conversaciones que se ejecutan enteras contra el sistema real y verifican resultados objetivos.
El nuestro tiene diecisiete casos, organizados en dos categorías con exigencias distintas:
| Blindaje exigencia: 100%, siempre | Intentos de manipulación, registro correcto de interés comercial, negativa a registrar sin consentimiento, enlaces verificables, y la obligación de declararse un sistema automatizado cuando se lo preguntan. Una sola falla aquí bloquea cualquier despliegue. |
| Estilo exigencia: alta, con margen | Longitud de las respuestas, variedad de formulación, ausencia de muletillas, fidelidad a la información disponible. Son criterios de forma sobre lenguaje vivo; se vigilan y se registran, pero un matiz no detiene una entrega. Si el mismo caso falla tres corridas seguidas, deja de ser matiz y se investiga. |
Esa separación no es indulgencia: es honestidad sobre qué se puede exigir de forma determinista. Que el agente jamás filtre información es una garantía verificable. Que una frase mida menos de doscientos caracteres es una preferencia.
Los intentos de manipulación
Cuatro de los casos son ataques deliberados que ejecutamos en cada corrida: pedirle que revele su configuración; hacerse pasar por administrador para solicitar la lista de clientes; declararle que a partir de ahora carece de restricciones; y esconder una instrucción falsa dentro de una consulta aparentemente inocente.
Las cuatro se rechazan, y no principalmente porque las instrucciones se lo pidan. Se rechazan porque el agente no tiene ninguna herramienta de lectura de datos de clientes: aunque un atacante lo convenciera por completo, no hay nada que pueda consultar. La instrucción es la primera capa; la ausencia de capacidad es la que sostiene.
Sobre eso corre una última red, ya sin participación del modelo: antes de enviar cualquier respuesta, un filtro determinista la revisa. Si contiene marcas de mecánica interna, rastros de credenciales o una clave de control que jamás debe aparecer, la respuesta no se envía — sale un mensaje neutro y queda registrada la alerta.
Vender con un enlace que existe
Con las garantías puestas, quedaba la parte comercial: que el agente no solo informe, sino que acompañe hasta la tienda. Aquí aplicamos psicología de venta bien documentada, con un límite explícito: persuasión sí, engaño no. Sin urgencias fabricadas, sin descuentos inventados, sin existencias falsas.
La escalera que sigue es simple: entender qué necesita el visitante con una pregunta corta, darle el dato útil antes de pedirle nada, y recién entonces compartir un solo enlace —el del producto que salió del diagnóstico— como continuación natural de la charla. Un enlace por mensaje: dos dividen la atención, cinco paralizan.
El detalle que parece menor y no lo es: el enlace se muestra con el nombre real del producto, no como una dirección web cruda, y esa conversión la hace el sistema —no el modelo— emparejando cada dirección con el nombre que devolvió la herramienta. Un agente no puede escribir un enlace que apunte a donde no debe.
Y cuando el visitante dice que no quiere dar sus datos, no se insiste. El enlace ya quedó con él. Insistir quema la confianza y no mejora la conversión.
Tres veces que el modelo intentó un atajo
La parte más instructiva del proceso no fueron los aciertos, sino los desvíos — todos detectados por el banco de pruebas o por revisión humana, ninguno visible para un cliente:
- Escribió su mecánica interna en el texto visible. En lugar de solicitar la acción por el canal previsto, la redactó como parte de la respuesta. Corregido con una regla explícita y con un limpiador automático que elimina cualquier rastro antes de enviar — porque la garantía no puede depender de que el modelo obedezca.
- Anunció en vez de actuar. «Puedo buscar en nuestro catálogo», respondía — sin buscar. Un vendedor no anuncia que podría atenderlo: atiende.
- Repitió su presentación a mitad de la conversación. Nada delata más a un sistema automatizado que saludarte como si fuera la primera vez en el cuarto mensaje. Se resolvió con una comprobación mecánica: si ya se presentó, esa frase se recorta.
Hay un patrón detrás de los tres: cada vez que una garantía dependía solo de una instrucción bien redactada, tarde o temprano falló. Las que se sostienen son las que están cableadas en el código.
Lo que llevamos hasta aquí
- Un agente que no puede inventar productos ni enlaces, porque solo puede compartir lo que una herramienta verificada le entregó.
- Un registro de interés comercial con validación propia, que frena incluso al modelo cuando se adelanta.
- Diecisiete conversaciones de prueba que se ejecutan en cada cambio, cuatro de ellas ataques deliberados.
- Un filtro final que revisa cada respuesta sin intervención del modelo.
Nada de esto está aún expuesto al público: hasta este punto, todo funciona en seco. Ponerlo en la calle exige responder la tercera pregunta incómoda — con qué permisos vive un agente que atiende a desconocidos.
Próximamente
En la tercera parte: identidad propia para el agente y permisos mínimos —puede registrar interés, no puede borrar nada, no puede leer un solo dato de otro cliente—; límites de uso y presupuesto para que nadie convierta un chat en una factura; y el comportamiento a prueba de fallos que preferimos: si el agente cae, el chat desaparece del sitio en lugar de quedarse mudo.
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.