El reporte que genera la IA se ve impecable. Y varias cifras están mal

Por qué un dato extraído con IA puede tener formato perfecto y aun así estar equivocado, y qué capa de validación evita que llegue así a una decisión

Alguien en el equipo de administración configuró un proceso para que la IA lea las facturas de proveedores y las cargue al sistema. Funciona: lo que antes tomaba una tarde ahora tarda diez minutos. El reporte que sale se ve impecable — columnas alineadas, cada campo lleno, fechas con el formato correcto, cero errores de tipeo. Y tres de cada diez facturas tienen al menos un dato mal.

Nadie se dio cuenta, porque el reporte se ve mejor que cuando lo hacía una persona a mano. No hay tachones, no hay celdas en rojo, no hay “pendiente de confirmar”. La prolijidad del resultado se lee como una señal de que está bien revisado. No lo está.

El problema no es la IA, es en qué punto se confía en ella

Este patrón aparece en cualquier empresa que empezó a usar IA para sacar datos de documentos: facturas, órdenes de compra, remitos, formularios de clientes, contratos. La tecnología para hacerlo mejoró mucho y es tentador: se conecta, lee el PDF aunque esté mal escaneado, y devuelve una tabla lista para cargar. El ahorro de tiempo es real y visible desde el primer día.

Lo que no se ve desde el primer día es la tasa de error. Y como el volumen sube — de cuarenta documentos por semana a cuarenta por día — revisarlos todos a mano deja de ser una opción, justo cuando más haría falta. El proceso se vuelve una caja negra rápida en la que se confía porque nunca dio un problema evidente.

¿Por qué un dato bien formateado puede estar mal?

Los modelos de IA modernos, sobre todo con los modos de “salida estructurada”, garantizan la forma del resultado: que cada campo exista, que el tipo de dato sea el correcto, que una fecha tenga estructura de fecha y un monto sea un número. Eso es lo que hace que el output se vea profesional.

Pero la forma no dice nada sobre el contenido. Un monto puede ser un número perfectamente válido y aun así no cuadrar con la suma de los ítems del documento. Una fecha puede tener el formato correcto y ser la de vencimiento cuando el sistema esperaba la de emisión. El modelo cumple con el molde; que lo que puso adentro sea cierto es otra cosa.

¿Cómo se equivoca exactamente?

Los errores de una extracción automática no son aleatorios. Se repiten en patrones:

• Omisión silenciosa. Una factura con doce ítems vuelve con once, perfectamente formateados. Nada indica que falta uno.
• Sustitución plausible. Un campo borroso o ambiguo se completa con el valor más probable en vez de marcarse como dudoso. Un “7” mal escaneado se convierte en un “1” con total seguridad.
• Campo equivocado. El documento tiene dos fechas o tres montos; el modelo elige uno de forma consistente, y no siempre es el que corresponde.
• Normalización no pedida. Un valor escrito como “1.500,00” se interpreta como 1,5. Una moneda se asume sin que el documento la aclare.
• Relleno de lo que no está. Un campo que no aparece en el documento se infiere del contexto en vez de devolverse vacío.

Ninguno de estos errores deja rastro en el formato. Todos pasan cualquier control que solo mire “¿está completo y bien tipeado?”.

Lo que la extracción con IA resuelve bien	Lo que puede romper en silencio
Formato: cada campo presente, tipo correcto, fecha válida	Contenido: la fecha extraída es la de vencimiento, no la de emisión
Velocidad: cientos de documentos en minutos	Completitud: un ítem de doce se perdió y nada lo marca
Consistencia de estructura entre documentos distintos	Valores dudosos completados con el dato “más probable”
Texto legible aunque el original esté mal escaneado	Normalización no pedida: “1.500,00” leído como 1,5
Campos que siempre están en el mismo lugar	Datos ausentes rellenados por inferencia en vez de quedar vacíos

¿Por qué es peor que el error humano?

Una persona cargando datos a mano también se equivoca, pero de formas conocidas. Transpone dígitos cuando está cansada, se saltea una línea cuando la interrumpen. El equipo aprende esos patrones y sabe dónde mirar dos veces: los totales al final del día, las cargas de después de un feriado.

Los errores de la IA son más raros en frecuencia y más raros en forma. Aparecen una vez cada tanto, en lugares donde nadie está mirando, y con una presentación que invita a no revisar. El resultado es una falsa sensación de haber resuelto el control de calidad, cuando en realidad se lo movió a un punto ciego.

Un caso típico (compuesto, no de un cliente puntual)

Una empresa mediana de distribución recibe unas 300 facturas de proveedores por semana. Antes, dos personas del área de compras las cargaban al ERP a mano; les llevaba buena parte de la semana y de vez en cuando se colaba un error de tipeo que se detectaba al conciliar a fin de mes.

Montaron una extracción con IA y el tiempo de carga bajó de días a un par de horas. Durante cuatro meses nadie revisó nada, porque el reporte semanal se veía perfecto y los proveedores no reclamaban. En el quinto mes, una auditoría interna encontró que alrededor del 8% de las facturas tenían el monto de impuestos mal cargado: el modelo estaba tomando un subtotal intermedio en un formato de factura que un proveedor grande había cambiado sin avisar. Cuatro meses de datos contables con un sesgo que nadie vio, porque el error entraba bien formateado.

Con una regla de conciliación — impuesto más subtotal igual a total, y total igual a la suma de los ítems — esa factura no habría pasado la carga. Se habría detenido en el primer registro con el formato nuevo, no cuatro meses después.

¿Qué tiene que existir para confiar en la extracción?

La extracción es la parte fácil. La parte que hace que el ahorro de tiempo sea real y no aparente es la capa que valida lo que salió:

• Conciliación contra una fuente de verdad. El total extraído tiene que cuadrar con la suma de los ítems extraídos y con el dato que ya vive en otro sistema — la orden de compra, el contrato, el ERP. Si no concilia, no pasa: va a una persona.
• Reglas de validación en cada carga. Claves que no se repiten (no cargar dos veces la misma factura), campos obligatorios que no pueden venir vacíos, valores dentro de una lista permitida (la moneda es una de las que uso), cantidades y fechas dentro de un rango plausible. La carga se detiene y avisa antes de que el dato llegue a un tablero o a un asiento contable.
• Señal de confianza y checkpoint humano. Cuando el modelo reporta baja confianza en un campo, o cuando un registro falla una regla, ese registro va a revisión manual. El resto fluye. La persona deja de revisar todo y pasa a revisar solo lo que el sistema marcó.
• Muestreo periódico. Incluso los registros que pasaron: una vez por semana se toma un 2-5% al azar y se compara a mano contra el documento original. Eso da una tasa de error real y, sobre todo, muestra si esa tasa se mueve — cuando se mueve, algo cambió aguas arriba (una plantilla de factura nueva, un proveedor distinto, una actualización del modelo).

En un datalake que operamos, alrededor de 45 de estas reglas corren automáticamente en cada ejecución del pipeline — unicidad, obligatoriedad, valores permitidos, integridad referencial — y una carga que falla una regla se detiene antes de contaminar lo que ve el usuario final. El paso de aprobación humana es explícito: el flujo se frena y espera el visto bueno de una persona antes del tramo final. No es lo sofisticado del proceso; es lo aburrido y sistemático lo que lo hace confiable.

¿Cuándo aplica y cuándo no?

Poner una capa de validación completa tiene sentido cuando los datos extraídos alimentan decisiones o registros que importan: lo que se carga a contabilidad, lo que va a un tablero que mira gerencia, lo que dispara un pago. También cuando el volumen ya es lo bastante alto como para que nadie revise documento por documento.

No hace falta todo este aparato si un humano igual va a mirar cada documento como parte de otro proceso — y la IA es solo un primer borrador que agiliza esa mirada —, si el costo de un error puntual es trivial y fácil de corregir después, o si el documento de origen ya viene estructurado (un archivo del proveedor, una exportación de otro sistema), en cuyo caso no hace falta IA para leerlo: alcanza con un conector.

Y al revés: si la extracción con IA alimenta algo crítico y no hay conciliación encima, el problema no es que falte automatizar más. Es que lo que ya se automatizó no se puede auditar.

El takeaway de esta semana

Si tu empresa ya usa IA para cargar datos de documentos, hazte una pregunta concreta: ¿cuál es la tasa de error de ese proceso? Si nadie tiene ese número, toma treinta documentos ya procesados al azar y compáralos a mano contra el original. Ese ejercicio de una hora te dice más sobre si el proceso funciona que seis meses sin quejas — porque los errores de una extracción automática no se quejan.

Preguntas frecuentes

¿Los modos de “salida estructurada” o “JSON schema” no resuelven este problema?

No. Garantizan que el resultado tenga la forma correcta — todos los campos, los tipos de dato, el formato de fecha — pero no que el contenido sea cierto. Un total puede ser un número válido y aun así no cuadrar con los ítems del documento.

¿Cómo sé si mi proceso de extracción tiene este problema hoy?

Toma entre treinta y cincuenta documentos ya procesados, al azar, y compáralos a mano contra el original. Cuenta cuántos tienen al menos un dato mal. Si nunca hiciste ese conteo, no sabes si tu proceso funciona; solo sabes que es rápido.

¿Esto significa que no conviene usar IA para leer documentos?

Conviene, en muchos casos. Pero con una capa de conciliación y validación encima. Extracción sin conciliación es una forma más rápida de llegar a un dato equivocado, y encima con más confianza.

¿Cuánto trabajo es montar la capa de validación?

Menos que el proyecto de extracción en sí. Las reglas se definen una vez, con la gente que conoce el negocio, y corren en cada carga sin intervención. Es lo que convierte el ahorro de tiempo en algo real en vez de aparente.

¿Qué pasa cuando se actualiza el modelo de IA?

Puede cambiar el comportamiento en los casos borde, para bien o para mal. Por eso el muestreo periódico no es opcional: es la única forma de notar que la tasa de error se movió antes de que ese movimiento llegue a una decisión.

---

Si estás evaluando dónde puede fallar la confianza en tus datos, el problema de la extracción automática es primo del que contamos en migrar a la nube no es tener una estrategia de datos: tener el dato no es lo mismo que poder confiar en él. Y si el proceso que quieres automatizar todavía vive en una planilla, vale la pena leer antes tu hoja de cálculo para monitorear a la competencia funcionaba hasta que dejó de funcionar.