La digitalización masiva de documentos en el Perú no es un problema de software sino de escala impredecible. Una entidad bancaria puede necesitar procesar 50,000 documentos en un día pico durante una campaña de cumplimiento SBS, y descender a 1,000 documentos diarios al mes siguiente. Una infraestructura fija dimensionada para el pico estará ociosa el 90% del tiempo; una subdimensionada colapsará precisamente cuando el regulador audita. La arquitectura serverless resuelve este dilema fundamental: pagas por el procesamiento real, no por la capacidad reservada.
Esta guía explora cómo diseñar pipelines de procesamiento documental a escala mediante AWS Lambda + Textract + SQS y Azure Durable Functions + Document Intelligence + Service Bus. No es una introducción teórica: incluye configuraciones concretas, fórmulas validadas en producción y las restricciones normativas peruanas —SBS 504-2021, NTP 392.030-2:2015, Ley 29733, D.L. 1412— que determinan decisiones arquitectónicas reales.
El público objetivo son arquitectos de digitalización en entidades financieras, CTOs de organismos públicos y directores IT en redes de salud que necesitan implementar o auditar un pipeline documental. Si ya entiendes qué es Lambda y qué es OCR, esta guía te proporciona el nivel de detalle necesario para construir o evaluar una solución en producción.
Por qué el modelo serverless es inevitable para digitalización en el Perú
La digitalización peruana opera por campañas y plazos regulatorios, no por consumo sostenido. El D.L. 1412 exige que todas las entidades públicas migren a expedientes electrónicos antes de 2028, generando proyectos masivos y acotados en el tiempo. La SBS impone plazos de digitalización de legajos de crédito. SUNAT requiere la migración de acervos físicos de comprobantes. Ninguno de estos proyectos genera carga uniforme: todos presentan un pico intenso seguido de operación normal significativamente menor.
El costo de estar mal preparado para esos picos es concreto:
- Retraso regulatorio: si el pipeline colapsa y no entrega el acervo digitalizado antes de la auditoría SBS, la entidad enfrenta observaciones formales que afectan su calificación.
- Cadena de custodia comprometida: un pipeline que duplica documentos o pierde timestamps genera registros inconsistentes que invalidan la microforma ante SGS Perú.
- Costo de oportunidad: infraestructura fija dimensionada para el pico cuesta entre 5 y 8 veces más que serverless en proyectos de 4 a 6 meses con patrón pico-valle.
Contexto normativo que condiciona tu arquitectura
Antes de elegir entre AWS y Azure, o entre síncrono y asíncrono, debes comprender qué exige la normativa peruana de tu arquitectura. Estas no son formalidades administrativas: moldean decisiones técnicas concretas que afectan el diseño del sistema.
SBS 504-2021: cloud en banca
Toda entidad financiera supervisada debe notificar o solicitar autorización SBS antes de usar servicios cloud para procesar información crítica de clientes. Un pipeline que procesa legajos de crédito o datos de DNI de clientes es un “servicio TI crítico” conforme a esta resolución. Las implicaciones arquitectónicas son directas:
- El pipeline debe proveer recuperación ante fallos regionales: si cae us-east-1 en AWS, la SBS exige continuidad en horas, no días.
- CloudTrail y los logs de acceso deben conservarse con trazabilidad completa y ser auditables por el regulador sin restricciones.
- La entidad debe mantener un inventario actualizado de servicios cloud contratados, incluyendo el pipeline de OCR, con revisiones trimestrales.
NTP 392.030-2:2015 y S3 Object Lock
Esta norma técnica peruana exige que la microforma —el archivo digitalizado certificado con sus metadatos y certificado de autenticidad— resida en medios WORM (Write Once Read Many). El equivalente en cloud es S3 Object Lock en modo COMPLIANCE, que impide modificación o borrado incluso por el administrador de la cuenta, durante el período de retención definido.
SGS Perú, el organismo certificador, está en proceso de reconocimiento formal de S3 Object Lock como equivalente WORM. La interpretación práctica vigente es que el pipeline puede procesar en cloud, pero la microforma debe migrar a S3 Object Lock documentando la equivalencia técnica ante el auditor. Este es un espacio donde el consultor que domina la normativa agrega valor diferenciador.
Ley 29733: protección de datos en el pipeline
Si el pipeline procesa datos de salud, información financiera o biométrica —DNI, firma digitalizada, expedientes clínicos—, la Ley 29733 exige cifrado en tránsito y en reposo, logs de acceso con trazabilidad completa, y consentimiento documentado del titular. Esto hace que el uso de AWS KMS o Azure Key Vault sea no negociable, no una buena práctica opcional.
Anatomía universal del pipeline serverless
Independientemente del proveedor cloud, todo pipeline de procesamiento documental transita por cinco etapas funcionales. El desacoplamiento entre ellas mediante colas de mensajes es lo que permite escalar cada etapa de forma independiente sin crear cuellos de botella.
INGESTA → VALIDACIÓN → OCR/EXTRACCIÓN → CLASIFICACIÓN IA → ALMACENAMIENTO
↕ ↕ ↕ ↕ ↕
SQS/ SQS/ SQS/ SQS/ DynamoDB
ServiceBus ServiceBus ServiceBus ServiceBus /CosmosDB
La decisión más crítica no es qué proveedor usar, sino si el procesamiento será síncrono o asíncrono. La matriz de decisión validada:
| Tipo de documento | Tamaño típico | Ruta recomendada | Latencia total |
|---|---|---|---|
| Factura simple (1 página) | < 1 MB | Textract síncrono / DI síncrono | 3–8 seg |
| Expediente estándar (20 páginas) | 20–50 MB | Textract async / DI batch | 30–120 seg |
| Microforma histórica (500+ páginas) | > 200 MB | Batch async con SNS/Event Grid | 5–20 min |
El desacoplamiento por colas absorbe inestabilidad: si Textract está bajo demanda alta y tarda 10 minutos, la etapa de ingesta no se bloquea ni pierde mensajes. La cola actúa como amortiguador de presión, permitiendo que el sistema continúe ingiriendo documentos. Este es el mecanismo de backpressure natural que hace resilientes a los pipelines serverless.
AWS: arquitectura de referencia (Lambda + SQS + Textract + S3)
Flujo completo
S3 Landing Zone (ObjectCreated event)
↓
Lambda Fan-Out → descompone lotes, publica 1 mensaje por documento
↓
SQS Standard Queue (MaximumConcurrency=20, VisibilityTimeout=360s)
↓
Lambda OCR Processor
├→ Textract DetectDocumentText (síncrono, < 10 MB)
└→ Textract StartDocumentAnalysis (asíncrono, SNS notifica al completar)
↓
DynamoDB Metadata Table (estado del documento, GSI por status)
↓
Lambda Classifier (SageMaker BERT o Bedrock Claude Haiku)
↓
S3 Processed Bucket (KMS + Lifecycle → Glacier)
↓
Webhook POST → sistema cliente (ERP, core bancario)
Configuración crítica de SQS
La configuración más importante —y más frecuentemente mal ejecutada— es el Visibility Timeout. La fórmula validada en producción:
Visibility Timeout = max(6 × Lambda timeout, Lambda timeout + 5 minutos)
Si Lambda tiene timeout de 60 segundos y el Visibility Timeout está en 90 segundos, SQS reencolará el mensaje mientras Lambda aún procesa. El resultado son duplicados silenciosos que rompen la cadena de custodia y multiplican el costo. Con timeout de Lambda de 60 segundos, el Visibility Timeout debe ser 360 segundos (6 minutos).
Configuración completa de Event Source Mapping:
{
"EventSourceArn": "arn:aws:sqs:...",
"FunctionName": "ocr-processor",
"MaximumConcurrency": 20,
"BatchSize": 5,
"FunctionResponseTypes": ["ReportBatchItemFailures"]
}
ReportBatchItemFailures es crítico: sin él, si Lambda procesa un batch de 10 mensajes y uno falla, SQS reintenta los 10 completos. Con esta configuración, Lambda retorna solo los IDs de mensajes fallidos y SQS reintenta únicamente esos, reduciendo desperdicio exponencial.
DynamoDB: tabla de estado + GSI
El diseño de tabla que escala sin hot partitions:
{
"documentId": "doc-uuid",
"processTimestamp": "2025-06-19T15:30:45Z",
"status": "ocr-in-progress",
"batchId": "batch-2025-06-19",
"classification": "FACTURA",
"entities": { "RUC": "20123456789", "monto": 5000.00 },
"ttl": 1797820800
}
El GSI (Global Secondary Index) con clave status#<valor> permite queries como “todos los documentos con estado ocr-in-progress” sin escanear la tabla completa. Sin este GSI, el monitoreo del pipeline requiere full table scans que generan costos prohibitivos y latencia innecesaria.
Fan-out para lotes de cientos de documentos
def lambda_handler(event, context):
zip_file = download_from_s3(bucket, key)
files = extract_zip(zip_file)
for file in files:
msg = {
"file_key": f"validated/{uuid.uuid4()}.pdf",
"batch_id": batch_id,
"timestamp": iso_timestamp()
}
sqs.send_message(QueueUrl=QUEUE, MessageBody=json.dumps(msg))
return {"statusCode": 202, "enqueued": len(files)}
Este patrón descompone el lote antes de encolar. Cada documento es un mensaje independiente, permitiendo que múltiples Lambdas lo procesen en paralelo sin coordinación explícita. La atomicidad de SQS garantiza que cada mensaje es procesado al menos una vez; la idempotencia garantiza exactamente una vez.
S3 Lifecycle + KMS
El ciclo de vida que equilibra disponibilidad operativa y retención normativa:
- Días 0–30: S3 Standard (acceso durante procesamiento activo y revisión temprana)
- Días 30–90: S3 Standard-IA (acceso ocasional para revisiones posteriores)
- Días 90–365: Glacier Instant Retrieval (archivo con recuperación en minutos)
- Año 1 en adelante: Glacier Deep Archive o S3 Object Lock en COMPLIANCE (microforma certificada con retención legal indefinida)
El cifrado KMS con rotación automática cada 90 días cumple los requisitos de la Ley 29733 para datos financieros y de salud, además de alinearse con estándares internacionales de protección de datos.
Azure: arquitectura de referencia (Durable Functions + Service Bus + Document Intelligence)
El patrón checkpoint-and-replay
La ventaja diferencial de Azure Durable Functions sobre Lambda es la orquestación con estado persistente. Si el pipeline procesa un expediente judicial de 200 páginas y falla en la etapa de clasificación (etapa 4 de 5), Durable Functions retoma desde el último checkpoint, no desde el inicio. Lambda requiere implementar esta lógica manualmente usando DynamoDB, agregando complejidad y puntos de fallo.
[FunctionName("ProcessDocumentOrchestrator")]
public static async Task RunOrchestrator(
[OrchestrationTrigger] IDurableOrchestrationContext context)
{
var input = context.GetInput<DocumentInput>();
var validation = await context.CallActivityAsync<ValidationResult>(
"ValidateDocument", input);
if (!validation.IsValid)
throw new InvalidOperationException(validation.Error);
var ocrResult = await context.CallActivityAsync<OcrResult>(
"ExtractWithDocumentIntelligence", input);
var classification = await context.CallActivityAsync<ClassificationResult>(
"ClassifyDocument", new { input, ocrResult });
await context.CallActivityAsync(
"StoreMetadata", new { input, ocrResult, classification });
return new { status = "SUCCESS", classification };
}
Mientras la orquestación espera el resultado del OCR —que puede tardar minutos—, no consume CPU ni memoria. Solo se factura el tiempo de ejecución real de cada actividad. Este modelo es especialmente ventajoso para expedientes multipágina donde OCR es la etapa dominante.
Document Intelligence v4.0 vs. Textract: comparativa técnica
| Característica | AWS Textract | Azure Document Intelligence |
|---|---|---|
| Precisión OCR en documentos peruanos | 94–96% | 95–97% |
| Tablas complejas con agrupación | Sí | Sí (mejor con subdocumentos) |
| Subdocumentos embebidos | No | Sí (detecta cambios de tipo automáticamente) |
| Modelos custom entrenables | Sí | Sí (vía Azure Foundry, más accesible) |
| Batch async nativo | Vía SNS externo | Nativo desde v4.0 |
| Residencia de datos garantizada | Por región (estándar) | Data Zone Standard disponible |
| Cobertura DNI/RUC Perú | Parcial | Mejor cobertura en Latinoamérica |
Para entidades SBS o MINSA que requieren que los datos no salgan de una región específica, el modelo Data Zone Standard de Azure es la opción más robusta disponible actualmente. AWS no ofrece un equivalente directo con la misma garantía documental y aislamiento de red.
Residencia de datos para entidades reguladas en Perú
Azure ofrece tres modelos de deployment para servicios de IA, cada uno con implicaciones de cumplimiento diferentes:
- Global Standard: inferencia puede ejecutarse en cualquier región. No recomendado para datos sensibles regulados.
- Standard: inferencia y datos en reposo en la región seleccionada. Mínimo recomendado para compliance SBS.
- Data Zone Standard: aislamiento de red total, costo entre 20 y 30% superior. Recomendado para MINSA y datos de salud.
La región más cercana con compliance equivalente a Ley 29733 es Azure Brazil South (cumple también con LGPD). Para entidades SBS que auditan latencia, la diferencia respecto a us-east-1 es material: aproximadamente 50 ms versus 150 ms desde Lima. Para aplicaciones de tiempo real, ese delta es significativo.
Resiliencia en producción: las configuraciones que salvan pipelines
Dead Letter Queue y el patrón poison pill
Un poison pill es un documento que siempre causa fallo en Lambda: un PDF cifrado con contraseña, un TIFF corrupto, un archivo que supera el límite de tamaño de Textract. Sin DLQ, este documento bloquea la cola indefinidamente, acumulando mensajes posteriores. Con DLQ correctamente configurada:
{
"RedrivePolicy": {
"deadLetterTargetArn": "arn:aws:sqs:...:ocr-queue-dlq",
"maxReceiveCount": 4
}
}
Después de 4 reintentos fallidos, el mensaje se traslada a la DLQ. Un proceso operativo —automatizado o manual según el volumen— revisa la DLQ, documenta el fallo para auditoría y decide si reingesta o descarta el documento. El pipeline principal continúa sin interrupciones, eliminando un punto único de fallo crítico.
Idempotencia desde el día 1
La idempotencia garantiza que cada documento se procese exactamente una vez, incluso si Lambda se invoca dos veces por el mismo evento —lo cual SQS puede hacer en condiciones de red inestable o durante reinicios de nodos. La forma más directa en AWS es Lambda Powertools Idempotency:
from aws_lambda_powertools.utilities.idempotency import idempotent
@idempotent(key_attr="documentId")
def lambda_handler(event, context):
# sin re-ejecutar el OCR ni recargar desde S3
process_document(event["documentId"])
Implementar idempotencia como retrofit en un pipeline que ya tiene datos en producción es extremadamente riesgoso: requiere validación retrospectiva de todos los registros y resolución manual de duplicados. Debe diseñarse desde el inicio del proyecto.
Event sourcing para auditoría regulatoria
Cada transición de estado del documento debe registrarse de forma inmutable, formando un log de eventos que reconstruye completamente el histórico:
2025-06-19 15:30:45 | doc-123 | INGESTED | batchId=batch-001 | sha256=a1b2c3...
2025-06-19 15:30:50 | doc-123 | VALIDATED | checksum=sha256:abc... | userId=lambda-role
2025-06-19 15:31:15 | doc-123 | OCR_COMPLETE| jobId=textract-xyz | pages=3 | duration=25s
2025-06-19 15:31:16 | doc-123 | CLASSIFIED | type=FACTURA | confidence=0.97 | model_version=v2.1
2025-06-19 15:31:17 | doc-123 | STORED | s3Key=processed/... | dbId=ddb-xyz | ttl_days=365
Este log inmutable es lo que SGS Perú necesita para verificar la cadena de custodia sin ambigüedad. Si la arquitectura no genera este registro desde el inicio, construirlo retroactivamente requiere pausar el pipeline o aceptar gaps de auditoría que pueden derivar en observaciones regulatorias.
Cumplimiento normativo en la arquitectura
Separar queues por tipo documental
La estructura de queues más robusta para entidades con múltiples sectores regulados:
sqs-sbs-documents— Lambda con IAM role exclusivo para SBS, KMS key exclusiva, logs en namespace CloudWatch separado.sqs-minsa-documents— Lambda con acceso a KMS key para datos de salud, sin acceso cruzado a datos SBS ni SUNAT.sqs-sunat-documents— Lambda con acceso solo a comprobantes electrónicos, logs separados.
Esta separación facilita la auditoría sectorial: el auditor SBS puede ver exactamente qué Lambda accedió a qué documentos, sin que los logs estén mezclados con procesamiento de otros sectores. Un incidente de seguridad en la queue SUNAT no expone datos de la queue SBS ni MINSA, conteniendo el impacto mediante principios de mínimo privilegio.
KMS y Secrets Manager: cifrado en todas las etapas
La regla más simple y más frecuentemente ignorada: nunca hardcodear credenciales en código Lambda ni en variables de entorno. El patrón correcto es que Lambda use su IAM role para invocar servicios AWS directamente —sin credenciales explícitas—, y que los secretos de terceros se gestionen en AWS Secrets Manager o Azure Key Vault con rotación automática.
# Correcto: Lambda role tiene permisos; AWS gestiona credenciales internas
textract = boto3.client("textract")
# El cliente usa las credenciales del role automáticamente, sin exponerlas
# Secretos externos: recuperar desde Secrets Manager
secrets_client = boto3.client("secretsmanager")
webhook_token = secrets_client.get_secret_value(SecretId="webhook-api-token")["SecretString"]
La rotación automática de claves KMS cada 90 días es requisito no negociable para cumplir la Ley 29733 en pipelines que procesan datos de salud o financieros, además de alinearse con estándares SOC 2 Type II.
Modelo de costos: pay-per-use en contexto peruano
Para un proyecto de digitalización a gran escala en 4 meses —patrón típico en migración bancaria—, el desglose aproximado en AWS (us-east-1) ilustra dónde está el gasto real:
| Servicio | Costo aprox. | % del total |
|---|---|---|
| AWS Textract (promedio 2 pág/doc) | Dominante | 60–65% |
| Lambda (compute + invocaciones) | Moderado | 3–5% |
| S3 (almacenamiento + requests) | Moderado | 2–3% |
| DynamoDB (writes + reads) | Bajo | menos del 1% |
| KMS + Secrets Manager | Bajo | menos del 1% |
| SQS + CloudWatch Logs | Bajo | menos del 1% |
El componente dominante es Textract: cualquier optimización debe enfocarse ahí primero. Batch async en lugar de llamadas individuales puede reducir el costo de Lambda entre 90 y 99%, pero el costo de Textract por página es fijo independientemente del patrón de invocación. La verdadera palanca es minimizar páginas procesadas mediante validación temprana y descarte de duplicados antes de llegar al OCR.
Punto de inflexión: on-demand vs. provisioned
- Menos de 500K documentos/mes: on-demand gana sin excepciones. Configurar Reserved Concurrency o DynamoDB provisioned añade complejidad sin retorno económico.
- Entre 500K y 5M documentos/mes: modo híbrido. Reserved Concurrency para etapas críticas (fan-out, OCR dispatcher), on-demand para etapas variables (clasificación, almacenamiento).
- Más de 5M documentos/mes: provisioned en todos los componentes principales puede reducir costos entre 50 y 60% respecto a on-demand, pero requiere forecasting preciso de carga.
La comparativa con infraestructura fija es consistente en todos los segmentos: en proyectos de 4 a 6 meses con patrón pico-valle típico de digitalización en el Perú, serverless resulta entre 5 y 8 veces más económico cuando se incluye el costo de infraestructura ociosa en el período post-campaña.
Hoja de ruta para implementar tu primer pipeline
Fase 1 — MVP con corpus de prueba (2 a 3 semanas) Implementar fan-out + SQS + Lambda OCR con Textract síncrono para documentos simples: facturas de 1 a 2 páginas, recibos, boletas. Validar configuración de DLQ, Visibility Timeout, idempotencia e integración DynamoDB. Resultado: pipeline funcional end-to-end para el tipo documental más frecuente en el caso de uso.
Fase 2 — Integración con sistemas legacy (3 a 4 semanas) Agregar webhook de salida hacia el ERP, core bancario o sistema de gestión documental del cliente. Implementar Textract async para expedientes multipágina. Configurar S3 Lifecycle, KMS con rotación y CloudTrail para auditoría. Resultado: pipeline completamente integrado en el ecosistema operativo del cliente con cifrado y trazabilidad completa.
Fase 3 — Certificación de cumplimiento normativo (6 a 8 semanas) Habilitar event sourcing completo con tabla DynamoDB de auditoría, S3 Object Lock para microformas certificadas, separación de queues por sector regulador y generación automática de reportes de auditoría. Coordinar con auditor SGS para revisión de cadena de custodia. Resultado: pipeline certificable ante SBS, SUNAT o MINSA según el sector.
Fase 4 — Optimización continua (ongoing) Ajustar MaximumConcurrency y batch sizes según datos reales de producción, analizar métricas de tasa de error por tipo documental, evaluar migración de clasificación a SageMaker fine-tuned cuando el volumen supere el millón de documentos por mes, y activar CloudWatch Cost Anomaly Detection para detectar derivas de costo.
Errores comunes y cómo evitarlos
| Error | Consecuencia operativa | Corrección |
|---|---|---|
| Visibility Timeout menor a 6x el Lambda timeout | Duplicados silenciosos multiplican costo y rompen auditoría | Aplicar fórmula: VT = 6 × max Lambda timeout |
| Sin DLQ configurada | Documentos corruptos bloquean la cola, deteniendo el pipeline | Configurar DLQ con maxReceiveCount=4 en todas las queues |
| Sin idempotencia desde el diseño | Re-procesamiento genera duplicados en DynamoDB y S3 | Implementar Powertools Idempotency o conditional writes desde el inicio |
| Credenciales hardcodeadas en Lambda | Exposición en CloudWatch Logs; auditoría rechaza el acceso | Usar IAM roles + Secrets Manager con rotación; nunca strings de credencial |
| Sin ReportBatchItemFailures activado | El batch completo se reintenta por un solo fallo; costo exponencial | Activar FunctionResponseTypes en Event Source Mapping |
| Sin event sourcing desde el día 1 | Cadena de custodia irreconstruible ante auditoría regulatoria | Registrar cada transición de estado en tabla DynamoDB de auditoría inmutable |
| S3 sin Object Lock para microformas | Incumplimiento NTP 392.030-2:2015; SGS rechaza la certificación | Activar Object Lock en modo COMPLIANCE con período de retención definido |
| MaximumConcurrency sin límite definido | Throttling en Textract destruye el pipeline sin aviso previo | Limitar a 20–50 concurrencias según el límite de cuenta de Textract |
| CloudTrail no habilitado en S3 | Auditoría no puede verificar quién accedió a los datos | Habilitar CloudTrail con Object Lock en el bucket de logs; retención mínima 7 años |
Conclusión
La arquitectura serverless no es una moda tecnológica para la digitalización peruana: es la respuesta racional a un contexto operacional donde la carga es episódica, la normativa es estricta y los márgenes de los proyectos no permiten infraestructura ociosa. AWS Lambda + Textract y Azure Durable Functions + Document Intelligence son tecnologías maduras con casos de uso documentados en entidades financieras y de gobierno equivalentes a las peruanas.
Los tres factores que hacen inevitable esta transición son precisos y económicamente medibles: el D.L. 1412 genera demanda masiva y acotada en el tiempo que no puede absorberse con infraestructura fija sin incurrir en costos prohibitivos; el costo por documento en serverless es entre 5 y 8 veces menor que en infraestructura dedicada para proyectos con patrón pico-valle típico; y la cadena de auditoría que exigen SBS, MINSA y SGS se implementa de forma más robusta con los servicios nativos de logging e inmutabilidad de AWS y Azure que con soluciones on-premise.
El diferencial competitivo no está en elegir AWS o Azure —ambas son opciones técnicamente válidas dependiendo del ecosistema del cliente—. Está en dominar las configuraciones que transforman un pipeline que funciona en demos en uno que resiste una auditoría SBS sin hallazgos: Visibility Timeout correcto desde el diseño, idempotencia implementada desde el primer día, separación de queues por sector regulador, event sourcing completo con logs inmutables, y DLQ configurada para contener poison pills. Estos cinco elementos son la diferencia entre un proyecto de digitalización que genera valor durable y uno que genera deuda técnica y riesgo regulatorio.
