Documentos en papel a base estructurada, sin tipeo.
Cada empresa con operación tiene una pila de documentos que entran por email, escaneo o portal y alguien los lee, los interpreta y los carga a un sistema. Es trabajo necesario pero invisible — y errores de tipeo cuestan caro: pago equivocado, dato regulatorio mal cargado, contrato vencido sin alertar.
Rangos referenciales para implementaciones estándar de OCR + extracción. Dependen de la calidad del input (PDF nativo vs escaneado), variabilidad de formatos y completitud del ground-truth para validar.
El problema
El input es heterogéneo: PDFs nativos del SII, facturas escaneadas con el celular, contratos firmados a mano, pólizas con formato de cada aseguradora. Un OCR genérico no alcanza — confunde campos, lee mal los nombres propios, pierde el contexto.
El equipo termina haciendo "OCR humano" — leer y tipear con cuidado. Cada error que se filtra cuesta horas de revisión río abajo.
Qué hace el agente
1. Clasifica el tipo. Factura, boleta, contrato, póliza, certificado. Cada tipo va a un pipeline específico — no se trata igual una factura DTE que un contrato de arriendo.
2. Extrae con confidence por campo. OCR + LLM combinados. Cada campo (RUT, monto, fecha, nombre) sale con un score. El score determina si el campo se usa directo o si hay que validar con humano.
3. Rutea baja confianza a humano. No se inventa data. Si el OCR no llega al umbral (típicamente 0.85 por campo), el documento entra a una cola de revisión con la imagen original y el campo dudoso highlighted. El humano corrige una cosa, no transcribe todo.
4. Sincroniza al sistema destino. ERP, CRM, DMS, base propia. Vía API o handoff. Los datos llegan validados, con trazabilidad al documento original.
Cuándo tiene sentido
Volumen. Sobre 500 documentos/mes. Bajo eso, el tipeo manual es más barato que el setup."
Variedad acotada. Idealmente 1–10 plantillas reconocibles por tipo. Si cada documento es un copo de nieve, el setup se vuelve interminable."
Sistema destino claro. Sabes exactamente qué campos se necesitan y dónde van. Si el proyecto termina en 'una planilla', falta el destino."
Toleras revisión humana parcial. Esperar 100% accuracy sin humano no es realista en OCR aún. El valor está en que el humano pasa de tipear a validar excepciones — un orden de magnitud menos trabajo.
Qué necesitamos de tu lado
Entre 100 y 500 documentos reales representativos de la variedad. Ejemplos con datos ya ingresados correctamente (ground truth) para calibrar accuracy. Esquema del sistema destino (qué campos esperás). Política de retención y privacidad de los documentos.
Preguntas que te haremos en discovery
- ¿Qué tipo de documento es el principal: facturas, contratos, pólizas, boletas?
- ¿Volumen mensual aproximado?
- ¿Qué tan variados son: 1–3 plantillas, varios proveedores, muy variados, manuscritos?
- ¿Cómo llegan: PDF nativo, escaneados, mezcla?
- ¿Cuál es el sistema destino: ERP, CRM, DMS, base propia?
- ¿Ya probaron algún OCR (Tesseract, AWS Textract, Azure, Google Document AI)?
- ¿Hay workflow de revisión humana hoy y cuánto tiempo consume?
Preguntas frecuentes
¿Qué OCR usan ustedes?
El que mejor funcione para tu mix de documentos. Probamos AWS Textract, Azure Document Intelligence y Google Document AI en la muestra que nos das, y elegimos en base a accuracy real, no a marca.
¿Y los documentos manuscritos?
Es posible pero más caro y con accuracy menor. Si parte del flujo tiene manuscrito, lo seteamos como excepción que escala — no como auto-aprobado.
¿Funciona con documentos en otros idiomas?
Español, inglés y portugués son nativos. Otros idiomas requieren validación específica en discovery.
¿Qué pasa con la retención de los documentos originales?
La defines tú según política regulatoria. Por defecto guardamos el original junto al extracto, ambos cifrados, con la retención que corresponda al tipo de documento (típico: 5 años para tributario).