Una demo de un agente de IA se arma en una tarde: un chat que responde con los documentos de la empresa o que resume los correos del día. Convence a todos. El problema aparece después, cuando tiene que funcionar con datos reales, todos los días, sin que nadie lo vigile.
Los datos de verdad. En la demo, el agente lee tres PDF ordenados. En el día a día, lee el sistema de la empresa: pedidos, clientes, inventario. Hay que conectarlo a la fuente, con permisos, y decidir qué puede leer y qué no.
Un registro de cada respuesta. Cada vez que el agente responde o hace algo, queda guardado qué recibió, qué consultó y qué devolvió. Sin eso, cuando algo sale mal no hay manera de saber por qué.
Límites claros. Un agente que consulta no es lo mismo que uno que actúa. Si va a enviar un correo, cambiar un pedido o cobrar, lo sensato es que al principio proponga y una persona apruebe, y que el permiso se amplíe con el tiempo.
Cuándo pasa a una persona. Hay preguntas que no le tocan: un reclamo, un caso raro, un cliente molesto. El agente tiene que reconocerlas y derivarlas a alguien del equipo, con todo el contexto.
Medir. Cuántas consultas resolvió solo, cuántas derivó, cuánto tardó y cuánto cuesta cada una. Con esos números se decide si el agente se queda, se ajusta o se apaga.
Empezar por un solo proceso. El error más común es querer un agente que haga todo. Funciona mejor elegir una tarea repetitiva y medible, como responder el estado de un pedido, clasificar los correos que entran o leer las facturas de los proveedores, y hacerla bien.
La parte menos vistosa es la que más trabajo lleva: conectar sistemas. En Feniz, por ejemplo, MetaTrader 5 no ofrecía una forma de sacar las operaciones, así que escribimos un programa que corre dentro de la plataforma y las envía cada cinco segundos. Con los agentes pasa lo mismo: la IA es una pieza, y lo que la vuelve útil es todo lo que la rodea.