Saltar al contenido
IA6 min de lectura

La IA interpreta. El proceso ejecuta.

Un modelo es excelente leyendo una factura desordenada y malo garantizando que ese dato entre al ERP todas las veces. Confundir los dos trabajos es la razón más común de que un piloto de IA no llegue a producción.

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 IAEl proceso automatizado
NaturalezaProbabilísticaDeterminística
Buena enEntradas que nunca vioRepetir lo mismo sin variación
Mala enGarantizar el mismo resultado siempreCualquier cosa sin estructura fija
Debe encargarse deInterpretar, clasificar, extraer, resumirEntrar 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í:

  1. Llega el documento. Puede ser un PDF nativo, un escaneo o una hoja de cálculo. Esto es entrada desestructurada: es trabajo del modelo.
  2. 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.
  3. Cada campo llega con una confianza. Lo que no alcanza el umbral no se adivina: se va a una cola de revisión humana.
  4. 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.
  5. 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.

¿Aplicamos esto a un proceso tuyo?

La primera conversación es de diagnóstico. Si el proceso no conviene tocarlo, también lo decimos.

Hablemos