Extraer datos de documentos con IA: el gap de producción

El demo siempre funciona. Pegas un PDF en el chat, pides los campos estructurados, y el modelo responde con un JSON perfecto. "¿Por qué no hacemos esto a escala?", pregunta alguien en la reunión.

La respuesta corta: porque escalar el procesamiento no es automatizar el demo. Es construir la infraestructura que hace que ese demo funcione de forma confiable, a volumen, integrado con tu sistema, sin errores silenciosos. Y esa infraestructura es más compleja de lo que parece. Nosotros mismos usamos LLMs — actualmente principalmente Gemini — para extraer datos de documentos con IA. Pero sobre un sistema que resuelve exactamente los problemas que encontrarás si llamas al API directamente.

Procesamiento de documentos con IA: lo que el demo no muestra

Los modelos de lenguaje son buenos extrayendo información de documentos. Realmente buenos. Entienden contexto, toleran variaciones de formato, manejan layouts complejos. El problema no es la extracción en sí — es todo lo que rodea esa llamada al API cuando lo haces en producción.

Hay cuatro fricciones que aparecen sistemáticamente cuando alguien intenta escalar esto por su cuenta.

Los límites de contexto no son solo de input. Los modelos actuales tienen ventanas de entrada enormes — GPT-5 acepta 400K tokens, GPT-5.4 llega a 1.05M, Gemini 3.1 Pro a 1M. Pero el output sigue siendo el cuello de botella real: GPT-5 tiene un máximo de 128K tokens de salida, Gemini 3.1 Pro de 64K. Eso suena a mucho hasta que procesas un contrato de 40 páginas con 200 líneas de tabla y quieres el JSON completo de cada campo. Un contrato denso puede generar fácilmente una respuesta estructurada de 30,000-50,000 tokens. Hay que partir el documento, priorizar qué extraer primero, y reconstruir el resultado final. Lógica no trivial que tienes que escribir y mantener.

Hay otro problema más sutil: el "Lost in the Middle". Investigación de Stanford en TACL 2024 mostró que la performance de los LLMs cae más de un 30% cuando la información relevante está en el medio del contexto — no al principio ni al final. Para un contrato de 25 páginas donde las condiciones de pago están en la página 12, esto importa.

Llamar un LLM directo: lo que tienes que construir tú

El dev que llama al API de OpenAI, Anthropic, o Google directamente para automatización de documentos tiene que resolver una lista larga:

Rate limits. Todos los proveedores usan sistemas de tiers medidos en tokens por minuto. Los tiers bajos tienen límites que se satiran rápido: una factura promedio consume ~800 tokens de entrada, procesar 1,000 facturas son 800,000 tokens — a límites de Tier 1, eso puede representar decenas de minutos de tiempo puro de API, asumiendo que no hay otro tráfico. Subir de Tier requiere demostrar uso y gasto histórico. Mientras tanto, implementas exponential backoff, manejo de 429s, y colas de procesamiento.

Costo real. GPT-5 cuesta $1.25 por millón de tokens de entrada y $10.00 por millón de salida. Claude Opus 4.6 cuesta $5/$25. Gemini 3.1 Flash-Lite es el más económico del mercado a $0.25/$1.50. Un contrato de 10 páginas (~15,000 tokens de entrada) con GPT-5 cuesta ~$0.019 solo en input — pero la respuesta estructurada en output puede costar 8x más por token. A 10,000 documentos al mes, los tokens de salida fácilmente dominan la factura. A eso súmale el costo de tu infraestructura de colas, reintentos, y almacenamiento.

Alucinaciones silenciosas. Los LLMs se equivocan. No mienten con mala intención, pero pueden inventar. Un estudio de 2025 sobre document Q&A encontró que el 68% de los errores de extracción en documentos financieros son valores numéricos alucinados — montos, totales, cifras de impuestos. Lo más peligroso: el modelo devuelve "total": 12500.00 en vez de 12050.00 con total confianza, en JSON válido, pasando cualquier validación de presencia de campo. El error llega silenciosamente a tu ERP.

Versiones de modelos. Los proveedores actualizan modelos con poco aviso. GPT-5.1, GPT-5.2, GPT-5.4 se lanzaron en meses consecutivos. Gemini 3.1 Pro deprecó a Gemini 3 Pro en cuestión de semanas. Un prompt afinado para una versión puede comportarse diferente — o directamente peor — en la siguiente. Sin un sistema de evaluación continua, nunca sabes si tu pipeline degradó.

Estructura fija. Tu ERP, tu CRM, o tu base de datos no acepta respuestas en lenguaje natural. Necesita el mismo campo, en el mismo formato, siempre. JSON Schema predefinido, valores normalizados, fechas en el formato esperado. Implementar eso con prompts —y mantenerlo estable entre modelos— es trabajo de ingeniería real.

Comparar herramientas de procesamiento de documentos: especialización vs generalización

La distinción relevante no es "LLM vs no-LLM". Es cuánta infraestructura construyes tú versus cuánta ya está construida.

En DocuTray usamos Gemini para la extracción. La diferencia está en lo que va alrededor: manejamos los límites de tokens (partición de documentos largos, reconstrucción de respuestas), operamos la infraestructura de colas y orquestación para procesar volumen, y ejecutamos validaciones sobre los datos extraídos antes de que salgan por la API. Los schemas de salida son predefinidos — defines qué campos necesitas, en qué formato, y nosotros chequeamos que la respuesta cumpla esa estructura antes de entregártela.

El resultado: llamas a un endpoint, mandas tu documento, recibes JSON estructurado. Sin gestionar rate limits, sin implementar reintentos, sin escribir validadores, sin rastrear degradación de modelos.

Lo que esto significa en práctica

Supón que procesas órdenes de compra. Cada orden tiene número de OC, proveedor, líneas de ítem con código, descripción, cantidad, precio unitario, y total. Algunos documentos tienen 3 líneas, otros tienen 80.

Llamar al API directamente: escribes el prompt, defines el schema en el prompt, implementas el retry logic, validas manualmente que las líneas casen con el total declarado, y construyes la cola para procesar 500 OCs diarias sin saturar los rate limits. Cuando el proveedor actualiza el modelo, alguien tiene que verificar que todo siga funcionando.

Con DocuTray: defines el schema una vez en la plataforma, mandas el documento al endpoint /convert, recibes el JSON validado. El volumen, los reintentos, y la consistencia del schema son problema nuestro.

La extracción con IA es la parte fácil. La infraestructura que la hace confiable es la parte que demora.

Si estás evaluando cómo escalar el procesamiento de documentos en tu operación, puedes explorar la API de DocuTray en docutray.com. También aceptamos casos de uso específicos para piloto — si tienes un tipo de documento con volumen, conversemos.