Antes de darle un agente de IA a su operación, decida qué puede tocar

Cuando una empresa nos plantea automatizar algo con un agente de IA, la conversación suele arrancar por el modelo: cuál usar, cuánto cuesta, qué tan bueno es. Es la parte menos determinante. La pregunta que decide si el proyecto sale bien o termina en un susto es mucho más aburrida: ¿qué tiene permitido hacer este agente?

Leer y escribir no son el mismo riesgo

Un agente que solo consulta información puede equivocarse y darle una respuesta imprecisa. Molesto, corregible. Un agente que escribe en sus sistemas puede generar un archivo de pago, modificar un límite de crédito o cerrar un caso que no debía cerrarse. Ahí el error deja de ser una molestia y pasa a ser un asiento contable.

Por eso la primera línea que trazamos en el diseño no es técnica: es el inventario de lo que el agente puede leer y lo que puede escribir, sistema por sistema y campo por campo.

Tres decisiones antes de la primera línea de código

• Alcance: a qué sistemas entra, con qué usuario y a qué datos concretos. No "al ERP", sino a qué módulos y a qué campos.
• Reversibilidad: qué acciones se pueden deshacer sin consecuencias y cuáles no. Un correo enviado y una transferencia ejecutada no se deshacen.
• Aprobación: qué acciones requieren que una persona dé el visto bueno antes de ejecutarse.

Lo irreversible se aprueba, siempre

Nuestra regla es simple: si una acción no se puede deshacer, el agente la prepara y una persona la confirma. Pagos, comunicaciones a clientes, cambios de configuración, borrado de información.

No es desconfianza hacia la tecnología. Es el mismo principio por el que un cheque de cierto monto lleva dos firmas, y nadie lo interpreta como desconfianza hacia el gerente de finanzas.

Si no queda registrado, no ocurrió

Cada acción del agente tiene que quedar en la misma bitácora que las de una persona: quién la solicitó, qué información consultó, qué decidió y qué ejecutó. Sin ese rastro no hay manera de auditar un resultado extraño ni de corregir el comportamiento, porque no se sabe qué lo produjo.

Dónde se rompen en la práctica

• Datos desordenados: el agente hereda el desorden. Si sus clientes están cargados de tres maneras distintas, va a tratarlos como tres clientes.
• Casos borde que nadie escribió: las excepciones que su equipo resuelve por costumbre y no están en ningún procedimiento.
• Ausencia de un plan para la duda: qué debe hacer el agente cuando no está seguro. Si no se define, inventa.

Ese tercer punto es el que más problemas causa y el que menos se conversa. Un agente bien diseñado sabe cuándo detenerse y preguntar.

Cómo ayuda ABCDesarrollos

Empezamos por el proceso, no por el modelo: qué hace hoy una persona, qué parte conviene delegar, qué debe seguir pasando por aprobación humana. Después construimos el agente con esos límites escritos en el sistema, no en un documento de buenas intenciones.

¿Tiene un proceso repetitivo que sospecha que podría delegarse? Le decimos qué parte sí y qué parte no, en 30 minutos.