Lento y costoso
Un operador tarda entre 20 y 40 segundos por documento. A escala de miles de documentos diarios, el costo operativo es significativo.
Caso de estudio · AI Engineering
Procesamiento Inteligente
de Documentos
Transformación de documentos bancarios no estructurados (DNI, recibos, estados de cuenta, contratos) en datos estructurados y validados mediante un pipeline OCR + LLM de producción.
0%
Precisión en
campos clave
campos clave
~2s
Por documento
(vs. ~30s manual)
(vs. ~30s manual)
0%
Reducción de
trabajo manual
trabajo manual
4
Tipos de documento
soportados
soportados
* Cifras referenciales del caso de estudio (~). Los valores exactos dependen del entorno, calidad del documento y configuración del modelo.
Ingreso manual de datos en banca: un cuello de botella crítico
Las operaciones bancarias que dependen de la digitación manual de documentos generan cuellos de botella operativos, errores de compliance y costos crecientes. El crecimiento en volumen de documentos no puede resolverse solo contratando más personal.
Propenso a errores
Las tasas de error en digitación manual superan el 3–5%. En datos financieros, un campo incorrecto puede tener consecuencias legales y regulatorias.
Sin trazabilidad automática
El proceso manual dificulta el audit trail exigido por reguladores. Reconstruir el origen de un dato requiere revisar registros físicos o correos.
Comparación: proceso manual vs. pipeline automatizado
| Dimensión | Proceso Manual | Pipeline Automatizado |
|---|---|---|
| Tiempo por documento | ~20–40 segundos | ~1–3 segundos |
| Tasa de error | 3–5% (digitación) | ~1–2% (con validación) |
| Trazabilidad | Parcial (registro manual) | Completa (audit trail automático) |
| Escalabilidad | Lineal con headcount | Horizontal, sin límite práctico |
| Disponibilidad | Horario laboral | 24/7 |
| Costo marginal | Alto (por documento) | Bajo (compute cost) |
De documento a datos estructurados en 5 etapas
Selecciona una etapa o usa "Reproducir" para ver la transformación completa de un documento bancario ficticio a través del pipeline de extracción inteligente.
Etapa 1 de 5
Banco Ejemplo S.A.
Estado de Cuenta — Cuenta Corriente
Cliente:Juan Pérez García
N° Cuenta:0012-3456-78
Período:01/03/2024 – 31/03/2024
DNI:12.345.678
Movimientos del período
Dep. 05/03:S/ 3.500,00
Ret. 12/03:-S/ 800,00
Dep. 20/03:S/ 1.200,00
Comisión:-S/ 15,00
Saldo Final: S/ 3.885,00
Documento ficticio — solo ilustrativo
Ingesta del documento Etapa 1
El documento llega al sistema a través de una API REST o un bucket S3. Se registra en la cola de procesamiento con un document_id único y metadatos de origen.
- Formatos soportados: PDF, JPEG, PNG, TIFF
- Validación de tamaño y tipo MIME
- Clasificación automática del tipo de documento
Banco Ejemplo S.A.
Estado de Cuenta — Cuenta Corriente
Cliente:
Juan Pérez García
N° Cuenta:
0012-3456-78
Período:
01/03/2024 – 31/03/2024
DNI:
12.345.678
Movimientos del período
Dep. 05/03:S/ 3.500,00
Ret. 12/03:-S/ 800,00
Dep. 20/03:S/ 1.200,00
Comisión:-S/ 15,00
Saldo Final: S/ 3.885,00
Texto extraído por OCR — valores resaltados
OCR — Extracción de texto Etapa 2
El motor OCR (AWS Textract en producción, Tesseract como fallback local) convierte el documento en texto crudo con coordenadas de cada token.
"ocr_raw": {
"confidence": 0.97,
"page_count": 1,
"blocks": [
{ "text": "Juan Pérez García", "conf": 0.99 },
{ "text": "0012-3456-78", "conf": 0.98 },
{ "text": "S/ 3.885,00", "conf": 0.96 }
// ... más bloques
]
}
Extracción con LLM Etapa 3
El texto OCR se envía al LLM con un JSON Schema estricto. El modelo extrae campos semánticos con sus valores y un confidence_score por campo.
Validación de reglas de negocio Etapa 4
El motor de reglas verifica cada campo contra un conjunto de restricciones: formatos, rangos, coherencia entre campos. Los casos de baja confianza van a revisión humana.
-
Nombre del titular — formato válido
-
N° de cuenta — dígito verificador correcto
-
Formato de fecha — corregido automáticamente
OCR:"31/03/24"→ normalizado:"2024-03-31" -
Saldo final — cuadra con suma de movimientos
-
DNI — longitud y formato válidos
JSON estructurado + Integración Etapa 5
El documento procesado se almacena como JSON estructurado. Se emite un evento hacia los sistemas downstream (core bancario, CRM) con audit trail completo.
"document_id": "doc_8f3a2b",
"type": "estado_de_cuenta",
"status": "validated",
"extracted": {
"titular": "Juan Pérez García",
"cuenta": "0012-3456-78",
"periodo": {
"desde": "2024-03-01",
"hasta": "2024-03-31"
},
"dni": "12345678",
"saldo_final": 3885.00,
"moneda": "PEN"
},
"confidence": 0.97,
"validated_at": "2024-04-01T09:15:03Z",
"corrections": [
{ "field": "periodo.hasta", "original": "31/03/24", "normalized": "2024-03-31" }
]
Capacidades por tipo de documento bancario
Cada tipo de documento presenta desafíos únicos de extracción. El pipeline adapta la estrategia de prompting y las reglas de validación según la categoría.
Documento Nacional de Identidad (DNI)
Campos extraídos
| Campo | Ejemplo | Confianza típica |
|---|---|---|
| Apellidos y nombres | PÉREZ GARCÍA, JUAN | ~98% |
| Número de DNI | 12345678 | ~99% |
| Fecha de nacimiento | 1985-07-22 | ~97% |
| Fecha de vencimiento | 2029-07-22 | ~96% |
| Sexo | M | ~99% |
| Código MRZ | P| ~91% | |
Desafíos específicos
- Fondos de seguridad (guilloche) interfieren con el OCR en zonas de baja resolución
- Variaciones de diseño entre generaciones de DNI (2005, 2013, 2019+)
- Fotos con reflejo o daño físico dificultan la lectura del MRZ
- Caracteres especiales (ñ, tildes) en nombres propios con OCR base
Precisión global aproximada
~96%
Recibo de Servicios
Campos extraídos
| Campo | Ejemplo | Confianza típica |
|---|---|---|
| Razón social / proveedor | Empresa Eléctrica SAC | ~96% |
| Número de recibo | REC-2024-00891 | ~97% |
| Período de consumo | Marzo 2024 | ~93% |
| Monto a pagar | S/ 145.80 | ~98% |
| Fecha de vencimiento | 2024-04-15 | ~95% |
| N° medidor / suministro | 10293847 | ~92% |
Desafíos específicos
- Alta variabilidad de layouts entre empresas proveedoras (luz, agua, gas, telecomunicaciones)
- Tablas de desglose con subtotales y conceptos variables
- Fechas en múltiples formatos dentro del mismo documento
- Recibos deteriorados o con manchas en zonas críticas de monto
Precisión global aproximada
~94%
Estado de Cuenta Bancario
Campos extraídos
| Campo | Ejemplo | Confianza típica |
|---|---|---|
| Titular de la cuenta | Juan Pérez García | ~98% |
| Número de cuenta | 0012-3456-78 | ~97% |
| Período del estado | 2024-03-01 / 2024-03-31 | ~93% |
| Saldo inicial / final | S/ 2.000 / S/ 3.885 | ~96% |
| Listado de movimientos | [array de transacciones] | ~91% |
| Tipo de cuenta | Cuenta Corriente | ~97% |
Desafíos específicos
- Tablas multi-página con cientos de movimientos: requiere estrategia de chunking para el LLM
- Encabezados repetidos en cada página dificultan la deduplicación
- Formatos de moneda mixtos (S/, USD, EUR) en cuentas multimoneda
- Notas y referencias en texto libre mezcladas con datos estructurados
Precisión global aproximada
~93%
Contrato Bancario
Campos extraídos
| Campo | Ejemplo | Confianza típica |
|---|---|---|
| Partes contratantes | Banco Ejemplo / Juan Pérez | ~97% |
| Tipo de producto | Préstamo personal | ~95% |
| Monto del crédito | S/ 20.000,00 | ~96% |
| Tasa de interés (TEA) | 18.5% | ~93% |
| Fecha de inicio / vencimiento | 2024-04-01 / 2027-04-01 | ~94% |
| Firma y sello | Detectado (no extraído) | ~88% |
Desafíos específicos
- Documentos de 10–50 páginas: procesamiento en chunks con contexto compartido
- Cláusulas legales en lenguaje técnico dificultan la extracción semántica
- Tasas de interés expresadas de múltiples formas (TEM, TEA, TCEA)
- Partes con múltiples firmantes y representantes legales
Precisión global aproximada
~95%
Métricas de desempeño del pipeline
Cifras referenciales del caso de estudio (~). Resultados obtenidos sobre un conjunto de documentos de prueba en condiciones controladas.
Precisión por tipo de documento
% de campos extraídos correctamente (aproximado)
Ver datos en tabla
| Tipo de documento | Precisión (~) |
|---|---|
| DNI | 96% |
| Recibo de servicios | 94% |
| Estado de cuenta | 93% |
| Contrato | 95% |
Tiempo de procesamiento
Segundos por documento — manual vs. automatizado (~)
Ver datos en tabla
| Tipo | Manual (~s) | Automatizado (~s) |
|---|---|---|
| DNI | 20 | 1.5 |
| Recibo | 28 | 2.0 |
| Estado de cuenta | 40 | 3.2 |
| Contrato | 90 | 6.0 |
Distribución de errores residuales
Por etapa del pipeline donde se origina el error (~)
Ver datos en tabla
| Origen del error | Proporción (~) |
|---|---|
| OCR (baja calidad de imagen) | 45% |
| LLM (ambigüedad semántica) | 30% |
| Validación (regla no cubierta) | 15% |
| Otros (formato no soportado) | 10% |
Decisiones clave de diseño del sistema
Cada decisión de arquitectura implica un tradeoff explícito. Aquí se documentan las más relevantes del pipeline.
Motor OCR: Textract + Tesseract fallback
AWS Textract ofrece hasta 99% de precisión en documentos impresos pero tiene costo variable. Tesseract es gratuito pero requiere preprocesamiento de imagen (deskew, binarización).
AWS Textract para producción (soporte nativo de tablas y formularios). Tesseract como fallback local para desarrollo y entornos sin conectividad AWS.
Alta precisión
Layout awareness
Costo variable
LLM con JSON Schema estricto
El output estructurado (constrained generation) garantiza que el JSON del LLM sea válido y parseable sin regex ni post-procesamiento frágil. Evita alucinaciones de formato.
Se usan modelos con soporte de structured outputs (constrained decoding via JSON Schema). El schema define tipos, formatos y campos opcionales. Elimina el post-procesamiento frágil con regex.
Determinístico
Sin regex
Validación en origen
Human-in-the-loop para baja confianza
Documentos con confidence_score < 0.80 se encolan para revisión humana. Esto mantiene alta la precisión general sin bloquear el flujo de alto volumen.
Documentos con confidence_score < 0.80 se enrutan a una cola de revisión manual. La intervención humana retroalimenta el sistema de reglas.
Threshold configurable
Feedback loop
Manejo de PII — masking y no retención
Los documentos originales se eliminan post-procesamiento. Solo se retienen datos enmascarados o los campos estrictamente necesarios según el modelo de datos del negocio.
Los datos personales (DNI, nombre, cuenta) se enmascaran en logs y trazas. Los documentos originales no se retienen en el pipeline más del tiempo de procesamiento. Cumplimiento GDPR/SBS.
Compliance SBS
GDPR-ready
Audit trail sin PII
Arquitectura propuesta de producción en AWS
Selecciona un componente para ver su descripción, responsabilidades y decisiones de diseño.
Arquitectura propuesta — referencial