Procesar un PDF con inteligencia artificial parece un flujo sencillo: recibir el documento, extraer el contenido, enriquecerlo y guardar los datos. La complejidad aparece cuando cada paso introduce otro servicio, otro despliegue y otro punto de fallo.
Esta arquitectura de referencia muestra cómo simplificar ese sistema en Azure antes de definirlo con Terraform.
Antes de convertir bloques y flechas en infraestructura, conviene revisar el diagrama con ojos críticos: qué componente resuelve una necesidad real, cuál solo transmite trabajo y qué fallo será difícil de explicar durante una incidencia.
Este es un escenario técnico hipotético creado con fines didácticos. No describe un cliente, un proyecto real ni resultados obtenidos. Cada entorno debe validar seguridad, rendimiento, costes y requisitos regulatorios con sus propios datos.
El escenario
El sistema debe:
- recibir documentos PDF;
- reaccionar cuando llega un fichero;
- analizarlo con Azure AI Document Intelligence;
- enriquecer el contenido con un modelo de lenguaje;
- almacenar el resultado de forma estructurada;
- ofrecer logs y trazabilidad del proceso.
Una primera variante del diseño resuelve el flujo funcional, pero añade varias capas operativas:
- Azure Logic Apps como orquestador;
- tres Azure Functions encadenadas;
- un disparador programado;
- infraestructura Terraform monolítica.
Ninguna decisión era incorrecta de forma aislada. El problema era el coste conjunto de operar todas ellas.
Dónde estaba la complejidad
Logic Apps solo como intermediario
Logic Apps es útil cuando existe una orquestación con múltiples conectores y estados. En este caso, su trabajo principal era detectar un cambio y llamar a una Function.
Azure Event Grid ya puede reaccionar al evento Microsoft.Storage.BlobCreated. Eliminar el intermediario reduce configuración, coste y puntos de diagnóstico.
Tres Functions en cascada
Separar componentes puede mejorar una arquitectura cuando existen responsabilidades y ciclos de vida distintos. Aquí, la fragmentación obligaba a desplegar, observar y mantener tres piezas para completar una única operación.
Un fallo intermedio detenía el pipeline y hacía más difícil reconstruir el contexto del documento.
Polling para un proceso basado en eventos
El trigger programado preguntaba periódicamente si había documentos pendientes. Eso introduce espera y ejecuciones sin trabajo.
La llegada del blob ya es el evento de negocio. Utilizarlo como disparador hace que el sistema reaccione cuando existe trabajo real.
Terraform sin límites claros
Un único bloque de infraestructura mezclaba cómputo, entrada, datos y observabilidad. Los cambios tenían un radio de impacto mayor y las piezas no podían reutilizarse en otros proyectos.
Arquitectura propuesta
El flujo simplificado queda así:
PDF → Azure Blob Storage
→ Event Grid
→ Azure Function
→ Document Intelligence
→ Azure OpenAI
→ Cosmos DBLa Function recibe el evento, obtiene el documento, coordina el análisis y guarda el resultado. Application Insights centraliza logs, errores y tiempos.
Este diseño no afirma que una única Function sea siempre mejor. Es adecuado mientras el procesamiento comparte el mismo ciclo de vida y cabe dentro de los límites de ejecución. Si aparecen trabajos largos, reintentos independientes o gran volumen, conviene valorar colas, Durable Functions u otro patrón de orquestación.
Aislar almacenamiento por responsabilidad
Aunque el flujo sea pequeño, el almacenamiento debería distinguir:
incoming: documentos que activan el pipeline;processed: documentos tratados o movidos tras completarse;- almacenamiento interno de la Function;
- resultados estructurados en Cosmos DB.
La separación facilita permisos, retención, recuperación y diagnóstico.
Módulos Terraform
La infraestructura puede organizarse en módulos con límites operativos:
modules/
ingestion/ Storage y Event Grid
processing/ Function App e identidad
intelligence/ Document Intelligence y OpenAI
data/ Cosmos DB
observability/ Application Insights y alertasEl objetivo no es modularizar por estética. Cada módulo debe representar una responsabilidad con cambios y permisos comprensibles.
Seguridad y operación
Antes de producción hay que decidir:
- identidades gestionadas frente a secretos;
- acceso privado a Storage, OpenAI y Cosmos DB;
- cifrado y retención de documentos;
- tratamiento de PDFs fallidos;
- idempotencia ante eventos duplicados;
- límites de tamaño y tipo de archivo;
- alertas por errores, latencia y cola acumulada;
- atribución de costes por entorno o cliente.
Event Grid puede entregar un evento más de una vez. El procesamiento debe identificar documentos ya tratados y evitar resultados duplicados.
Qué medir
Una arquitectura operable necesita un baseline:
- tiempo desde la carga hasta el resultado;
- documentos procesados y fallidos;
- reintentos por componente;
- coste por documento;
- consumo de tokens;
- tiempo de análisis y enriquecimiento;
- incidencias que requieren intervención.
Estas medidas permiten decidir cuándo la solución necesita colas, paralelismo o límites adicionales.
La decisión importante ocurre antes de Terraform
Infrastructure as Code hace reproducible una arquitectura, pero también puede hacer reproducible una complejidad innecesaria.
Primero se simplifica el flujo. Después se definen ownership, fallos y observabilidad. Solo entonces merece la pena convertir el diseño en módulos Terraform.
Si vuestra agencia repite este tipo de solución para varios clientes, el siguiente paso no es copiar el repositorio completo: es crear una base de entrega multi-cliente que reutilice el proceso manteniendo datos y accesos aislados.
