Cuando alguien nos pide "un agente de IA" para clasificar correos, extraer datos de facturas o conciliar información entre sistemas, casi nunca la primera pregunta que hacen es "¿qué NO va a poder hacer este agente?". Debería ser la primera, la verdad, porque ahí está la diferencia entre una herramienta en la que su equipo puede confiar y una que nadie se atreve a dejar sola.

Un agente sin límites no es más inteligente, es más impredecible

Es tentador pensar que entre más autonomía tenga un agente, mejor funciona. En la práctica pasa lo contrario. Un agente al que nadie le definió qué puede hacer y qué no, tarde o temprano va a intentar resolver situaciones para las que no lo prepararon, y lo va a hacer con la misma confianza con la que resuelve las que sí conoce. La diferencia entre un agente útil y uno peligroso casi nunca está en el modelo que usa por debajo. Está en si alguien se sentó a decidir, antes de encenderlo, hasta dónde llega.

Un ejemplo concreto: un agente que concilia facturas entre un ERP y un banco puede tener acceso de lectura a ambos sistemas. Eso no significa que también deba aprobar pagos por su cuenta. Esa distinción (leer versus actuar, sugerir versus ejecutar) es justamente lo que llamamos un límite operativo, y se define antes de construir el agente, no después de que algo salga mal.

Qué es, en la práctica, un límite operativo

No es una casilla de "modo seguro" que se activa y listo. Son decisiones concretas, documentadas antes de que el agente toque un sistema real. Qué sistemas puede leer y cuáles está autorizado a modificar, para empezar: no son lo mismo, y confundirlos es el error más común. También qué decisiones toma solo y cuáles necesitan que una persona las apruebe, porque clasificar un correo no carga el mismo riesgo que aprobar un pago o rechazar una solicitud. Y qué hace cuando se topa con un caso que no reconoce: un buen agente se detiene y avisa; uno mal diseñado improvisa una respuesta con la misma seguridad que si supiera lo que está haciendo.

Falta un cuarto punto, el que más se subestima: qué queda registrado de cada acción. Si el agente hizo algo hace tres semanas y alguien pregunta por qué, tiene que haber una respuesta que no dependa de la memoria de nadie. Un agente sin registro de auditoría no es solo un riesgo técnico, es un problema el día que un cliente, un auditor o un regulador pregunten por qué el sistema hizo lo que hizo y la única respuesta disponible sea "no sabemos, el modelo decidió".

Por qué esto no se negocia después

Construir un agente sin pensar primero en sus límites es más rápido. Más barato también, al menos al principio. El costo llega después: cuando toma una decisión que nadie autorizó, cuando nadie logra explicar por qué actuó como actuó, o cuando la única forma de corregirlo es apagarlo entero porque no hay manera de ajustar solo la parte que falló.

Por eso cada agente que entregamos viene con esos límites definidos desde el diseño, no pegados al final como una capa de seguridad. No es una restricción que le resta capacidad. Es, a fin de cuentas, lo que le permite a su equipo dejarlo trabajar sin vigilarlo línea por línea, que es la razón por la que alguien contrata un agente, para empezar.