IDP: procesamiento inteligente de documentos (sacar datos de PDFs con IA)

En casi todos los proyectos que arrancamos aparece, tarde o temprano, la misma planilla. Alguien del equipo la llena a mano mirando facturas, remitos o PDFs que llegaron por correo, muchos escaneados y torcidos, y de ahí los datos pasan al ERP. El robot sabe abrir SAP y cargar los campos sin problema. El cuello de botella está siempre un paso antes: en leer el documento y convertirlo en datos limpios.

IDP, por sus siglas en inglés (Intelligent Document Processing), es el nombre que se le puso a resolver esa parte con inteligencia artificial en lugar de con una persona tipeando. Como pasa con casi todo lo que lleva "inteligente" en el nombre, hay una versión que funciona y una que se vende mejor de lo que rinde. Este artículo es sobre distinguirlas antes de firmar.

Qué hace un IDP que un OCR no hacía

El OCR clásico convierte una imagen en texto. Le pasas un PDF escaneado y te devuelve las letras que había en la página, en el orden en que aparecían. Útil, pero tonto: no sabe cuál de esos números es el total y cuál el número de factura. Si el proveedor rediseña su factura, el OCR sigue leyendo bien las letras y mal los campos, porque las coordenadas donde estaba el total ahora tienen otra cosa.

IDP agrega la capa que faltaba: entender el documento, no solo transcribirlo. Combina el OCR con un modelo que sabe qué es una factura, dónde suele estar cada dato y cómo se relaciona con el resto, aunque el layout no lo haya visto nunca. Por eso funciona con documentos de cientos de proveedores distintos sin armar una plantilla para cada uno, que era el techo real del enfoque anterior.

La regla para saber si tu caso necesita IDP es la variedad. Si tus documentos vienen todos del mismo sistema, con el mismo formato exacto, no hace falta IA para leerlos: un parser de plantilla fija es más barato, más rápido y más confiable, porque siempre busca el dato en el mismo lugar y nunca "interpreta". IDP se justifica cuando cada documento llega distinto y una plantilla por formato sería un trabajo infinito.

La categoría ya tiene ranking, y todos dicen lo mismo

En septiembre de 2025, Gartner publicó su primer cuadrante dedicado a IDP y ungió como líderes a ABBYY, UiPath, Hyperscience y compañía. Cada uno tiene su fuerte real: ABBYY pega bien en escaneos degradados, Rossum se apoya en no depender de plantillas cuando hay mucha variedad, UiPath lo vende pegado a su RPA. Pero en el folleto todos anuncian entre 90% y 99% de precisión, y a esta altura esas cifras son casi indistinguibles.

Lo que casi ninguno explica, y menos en español, es qué significa ese número cuando el documento entra sucio. Ahí es donde se juega el proyecto, no en el porcentaje de la portada.

El número que te muestran en la demo

Cuando te dicen "99% de precisión", casi siempre es precisión a nivel de campo aislado. Suena impecable. El problema es que a nadie le sirve un campo suelto, le sirve el documento entero cargado sin errores.

Y la cuenta cambia feo. Si una factura tiene, digamos, quince campos que importan y cada uno se extrae con 98% de acierto, la probabilidad de que los quince salgan perfectos en el mismo documento es 0,98 elevado a la quince, alrededor del 74%. O sea que uno de cada cuatro documentos necesita que un humano lo toque, con un sistema que en el papel tiene "98% de precisión". Ese es el número que tienes que pedir en la demo: no acierto por campo, sino porcentaje de documentos que pasan enteros sin intervención (lo que en la jerga llaman straight-through processing). Es más bajo que el de la portada y es el que define si el proyecto ahorra horas o solo las mueve de lugar.

Hay un error peor, además, y es silencioso. El campo que el modelo extrae con alta confianza y está mal igual: un 8 que leyó como 3, un total que tomó del subtotal. Ese no lo frena la confianza del modelo, porque el modelo está convencido. Por eso la validación no puede apoyarse en la confianza que reporta la IA.

Cómo se arma para que el error caro no pase

Nosotros implementamos IDP sobre Rocketbot, del que somos partner, apoyándonos en su capa de IA (AI Studio). En la práctica se combinan dos piezas: el OCR y el reconocimiento de imágenes para los documentos escaneados, y Documents GPT, que toma el PDF y devuelve los campos estructurados con procesamiento de lenguaje natural. Rocketbot publica para esa capa números de 88% menos tiempo de procesamiento y 98% menos errores humanos. Son sus cifras, y como toda cifra de folleto, marcan el potencial del techo, no lo que vas a obtener el primer mes.

Lo que separa un proyecto que rinde de uno que no es lo que hace el robot con lo que leyó. El flujo tiene cuatro tramos y el orden importa.

Primero clasificar: saber si el documento es una factura, un remito o una nota de crédito, porque cada tipo se extrae y se valida distinto. Después extraer los campos con el modelo. Hasta ahí es lo que todos muestran en la demo.

El tercer tramo es el que casi nadie enseña y el que decide: la validación que no le cree al modelo. Que los ítems sumen el subtotal y el subtotal más el impuesto dé el total. Que el identificador fiscal del emisor exista y esté activo. Que la fecha sea posible y que el número no esté ya cargado. Esas reglas atrapan justamente el error silencioso, porque un dato mal leído casi siempre rompe una de esas cuentas aunque el modelo lo haya dado por bueno.

Y el cuarto: lo que no pasa la validación, o lo que el modelo devuelve con baja confianza, no se inventa ni se descarta. Va a una persona con el documento y el campo dudoso resaltado, se corrige en segundos y esa corrección queda registrada. Con Rocketbot Monitor ese pendiente humano se ve y se mide en producción, que es como te enteras de qué proveedor o qué tipo de documento te está generando el 80% de las revisiones. Suele ser un puñado, y cuando lo atiendes puntual, la tasa de intervención baja de golpe.

Los casos donde de verdad cierra el número

Los que más veces se pagaron son de recepción de documentos de terceros, justamente porque ahí no controlas el formato de entrada.

Cuentas por pagar es el más común: entran facturas de muchos proveedores, cada uno con su diseño, y alguien las carga a mano en el ERP cotejándolas contra la orden de compra. El IDP extrae emisor, número, fechas, ítems, impuestos y total; el robot valida y carga. La lógica de cruce es la misma que ya contamos en cómo automatizar cuentas por pagar, solo que ahora la entrada no es un XML limpio sino un PDF que puede venir escaneado.

En los proyectos de creación masiva de materiales en SAP vimos el mismo patrón del otro lado del mostrador: la planilla de entrada nunca llega perfecta. El robot que funciona da por hecho que viene sucia. Aparta las filas con datos faltantes o sin mapear, sigue con el resto del lote y deja esas pocas para que una persona las resuelva, en vez de frenar todo por una celda vacía. Ese detalle, que parece menor, es la diferencia entre un robot que corre desatendido y uno que se cuelga a la primera excepción.

Y en los bots de ventas que cargan pedidos en SAP, el que manda es el diccionario de datos: si el producto o el cliente del PDF no está mapeado al código del ERP, la IA no lo adivina. Por eso el IDP se apoya en una tabla de equivalencias, que en nuestros proyectos vive en una base local, y deriva a una persona lo que no reconoce. Si trabajas con SAP, la carga final se conecta con lo que ya cubrimos en qué procesos de SAP se pueden automatizar con RPA.

Dónde IDP es plata tirada

Lo dije arriba y lo repito porque es la conversación que más presupuesto ahorra: si tus documentos vienen todos iguales, del mismo emisor y el mismo sistema, no compres IDP. Una extracción por plantilla fija hace el trabajo mejor y no se equivoca de forma creativa. Meter un modelo de IA ahí es pagar de más por una interpretación que no necesitas.

Tampoco cierra con volumen chico. Con treinta o cuarenta documentos al mes, una persona los carga en un rato y el desarrollo no se paga nunca. El caso donde el número da es el de varios cientos de documentos mensuales con formatos variados, o el de varias sociedades repitiendo el mismo trabajo en paralelo. Los criterios completos, con la cuenta de por medio, están en cuánto cuesta automatizar un proceso. Si además dudas entre un robot y una integración directa, lo tratamos en RPA vs desarrollo a medida.

Preguntas frecuentes

Danilo Toro, fundador de Robotipy, desarrolló Rocketbot durante seis años antes de fundar la consultora.