Hay una demo que sale siempre bien: se le pasa a un modelo la factura más fea que se encuentre y el modelo extrae los campos correctamente. Todo el mundo aplaude. Seis meses después el proyecto no está en producción.
La razón no es que el modelo sea malo. Es que la demo respondió a la pregunta equivocada. La pregunta no era «¿puede leer esta factura?». Era «¿puede leer 4,000 facturas al mes de 100 proveedores distintos y garantizar que el dato entra al ERP correctamente, todas las veces, y que cuando no pueda, alguien se entere?».
Dos trabajos, dos naturalezas
Un modelo de lenguaje es probabilístico por diseño: eso es lo que le permite manejar entradas que nunca vio. Un proceso de negocio es determinístico por necesidad: el pago se ejecuta o no se ejecuta.
| La IA | El proceso automatizado |
|---|
| Naturaleza | Probabilística | Determinística |
| Buena en | Entradas que nunca vio | Repetir lo mismo sin variación |
| Mala en | Garantizar el mismo resultado siempre | Cualquier cosa sin estructura fija |
| Debe encargarse de | Interpretar, clasificar, extraer, resumir | Entrar al sistema, capturar, validar, cerrar |
Poner al modelo a hacer el trabajo del proceso es lo que produce un sistema que funciona el 94 % de las veces. Suena bien hasta que se traduce: son 240 facturas al mes mal capturadas, y nadie sabe cuáles.
Cómo se reparte en la práctica
En un proceso de cuentas por pagar, el reparto queda así:
- Llega el documento. Puede ser un PDF nativo, un escaneo o una hoja de cálculo. Esto es entrada desestructurada: es trabajo del modelo.
- El modelo extrae los campos por significado, no por posición. Es lo que permite que un rediseño de factura no rompa el proceso.
- Cada campo llega con una confianza. Lo que no alcanza el umbral no se adivina: se va a una cola de revisión humana.
- Lo que sí alcanza se valida contra la fuente de verdad — el catálogo de proveedores, el RFC, la orden de compra. Esto ya es determinístico.
- El proceso captura en el ERP y deja bitácora. Si falla, reintenta; si sigue fallando, avisa.
El modelo no decide si el pago se ejecuta. Propone una lectura; el proceso la verifica y actúa.
El umbral de confianza no es opcional
Un sistema que adivina en silencio es peor que uno que pregunta. Es la diferencia entre una cola de veinte casos que alguien revisa en veinte minutos y un error que aparece en el cierre del mes, cuando ya hay que reconstruir qué pasó.
Fijar el umbral es una decisión de negocio, no técnica: depende de cuánto cuesta un error frente a cuánto cuesta una revisión. En cuentas por pagar el error es caro, así que el umbral va alto. En clasificación de correos entrantes el error es barato, así que puede ir más bajo.
Dónde sí conviene meter IA
Lo que tiene una regla clara no necesita un modelo. Meter IA donde bastaba una condición añade costo, latencia e incertidumbre — tres cosas que nadie pidió.
Los cuatro casos donde sí aporta, en nuestra experiencia:
- Documentos sin plantilla fija: facturas de muchos proveedores, tickets, estados de cuenta que cada institución representa a su manera.
- Clasificación por intención: un correo entrante que hay que rutear según de qué se trata.
- Extracción de un escaneo: donde no hay texto, hay una imagen de texto.
- Consulta conversacional sobre la operación: preguntar en lenguaje natural lo que antes exigía armar un reporte.
El proceso corre determinístico. La IA entra sólo donde hace falta interpretar.
Es la frase con la que abrimos cualquier conversación de IA aplicada. Suena restrictiva y es justo lo contrario: es lo que permite que el proyecto llegue a producción.