Dónde dejo decidir a un agente de IA, y dónde no

En su día escribí aquí cómo automaticé el procesamiento de facturas que llegan por correo: qué entra, qué pasos hay, qué sale. Era un artículo honesto, pero contaba la parte fácil.

La parte difícil no fue montarlo. Fue conseguir que alguien se fiara de lo que salía por el otro lado. Ahí se me fue la mayor parte del trabajo, y de ahí salió todo lo que he aprendido sobre agentes.

Una factura no es el problema

Le enseñas una factura a un modelo, le pides el CIF, el número, el importe y las líneas de artículos, y te los da. Funciona a la primera y te vienes arriba.

El problema aparece cuando ya no es una factura, sino las que van entrando cada día, de proveedores distintos, cada una maquetada a su manera. Unas llegan como PDF decente, otras son una foto torcida del papel. En una encuentra todos los campos sin despeinarse. En la siguiente, solo porque el proveedor coloca las cosas de otra forma, se lía con un campo o interpreta mal un dato.

Ahí entendí que no podía coger lo que decía el modelo y volcarlo en la hoja como si fuera verdad.

El fallo que no da error

Un fallo que revienta se ve enseguida y se arregla. El problema aquí era otro: el sistema devolvía un resultado con buena pinta.

Cuando un dato no estaba claro, o directamente no aparecía, el modelo intentaba deducirlo. Que es lo que haría cualquier persona leyendo una factura rara, y justo lo que no quiero de una máquina. No saltaba ningún error. Salía un número, en su casilla, con su formato.

Me enteré a la antigua: abriendo el PDF original y comparándolo con lo extraído, campo por campo, durante un buen rato.

De ahí salió el primer control serio. Si un dato no está claro, déjalo vacío o márcalo para revisión. No lo rellenes nunca.

Le quité decisiones, no inteligencia

Al principio quería que el agente fuese bastante autónomo: que mirase el documento, entendiera qué tenía delante y decidiera qué sacar de ahí.

Luego caí en que había cosas que no necesitaba que decidiera nadie, y menos un modelo. Qué campos quiero obtener lo tengo claro desde el primer día: CIF, número de factura, importe, líneas de artículos. Eso no es una decisión difícil, es mi especificación. Dejarla a criterio del modelo solo añade maneras de equivocarse.

Lo que sí quería que hiciera es lo difícil de verdad: coger una factura de un proveedor que no ha visto nunca, encontrar dónde está cada dato aunque esté colocado de otra manera, y devolverlo con una estructura común.

Así que fui recortando. Estos son los campos, este es el formato, estas son las condiciones que se cumplen sí o sí, y si no encuentras algo, me lo dices.

Lo que no me esperaba es cómo acabó la cosa: el sistema funcionaba mejor cuanta menos libertad tenía para decidir qué devolverme, y toda la que necesitaba para interpretar el documento. Son dos libertades distintas y yo las tenía mezcladas en el mismo saco.

No todo necesitaba un agente

Una vez tienes los datos extraídos, buena parte de lo que queda es procesamiento normal y aburrido. Validar que un CIF tiene la estructura que tiene que tener. Comprobar formatos. Hacer cuentas. Montar la hoja.

Nada de eso necesita inteligencia artificial. Ahí prefiero código de toda la vida, porque va más rápido, cuesta menos y sé exactamente qué va a hacer cada vez. El flujo lo orquesto con n8n, y dentro de ese flujo el agente ocupa un trozo pequeño: el de entender un documento distinto cada vez.

Meter IA en todo el recorrido no mejora un sistema. Lo encarece y lo vuelve impredecible, que es justo lo contrario de lo que buscas cuando automatizas algo. De esto ya escribí en su momento hablando de cuándo no usar n8n, y con los agentes pasa igual, solo que más caro.

Qué pregunto ahora antes de montar uno

Últimamente, para cualquier problema, la respuesta parece ser ponerle un agente. Así que cuando alguien me lo plantea, empiezo por otro lado.

Primero: qué problema quieres resolver. Luego, cómo se hace hoy, quién lo hace, cuánto tiempo se le va, y qué decisiones toma esa persona mientras lo hace. Y qué ocurre cuando se equivoca, que suele ser la pregunta que nadie ha contestado todavía.

Al final llego siempre a la misma: ¿qué parte de este trabajo necesita de verdad interpretar o decidir algo?

Si lo que queda se resuelve con una regla, una condición o veinte líneas de código, no hace falta un agente.

De dónde sale la confianza

Al principio yo vendía el sistema por el lado equivocado. «Mira qué bien, saca todos estos datos él solo». Y la respuesta era siempre la misma, y era razonable: ya, ¿y si se equivoca?

Hoy, quien trabaja con esos datos no se fía porque el modelo sea bueno. Se fía porque hay unos campos definidos, unos controles, y porque sabemos qué pasa cuando el sistema no está seguro. Cuando duda, lo dice. El dato queda marcado, alguien lo mira, y se acabó. El error no se queda escondido en una casilla con buena pinta.

Esa fue la lección, y me ha servido para todo lo que he montado después: la confianza no la consigues haciendo que la IA parezca infalible. La consigues haciendo que, cuando se equivoque, el sistema se comporte bien.