Infraestructura como código para una fintech regulada: 12 módulos, un solo apply, mínimo privilegio

Cliente. Una plataforma fintech regulada que opera identidad y verificación (KYC), wallets y transacciones de usuarios: un dominio donde cada permiso de más, cada cambio de infraestructura sin rastro y cada acceso indebido a datos es un pasivo regulatorio, no un detalle de ingeniería.

Enfoque

Este caso recorre dos eslabones del método —ingeniería de software e ingeniería de datos— sin handoffs entre ellos: quien escribe la infraestructura es el mismo que diseña el camino del dato hacia el análisis, de modo que la disciplina de auditabilidad no se pierde en el empalme. El primer eslabón —la lectura de la organización— ya estaba dado por el encuadre regulatorio del negocio; el cuarto —la IA sobre el dato— queda fuera del alcance entregado: acá la inteligencia se aplica como instrumento de trabajo del ingeniero, no como producto. La distinción es deliberada y es parte de la honestidad de la marca.

La tesis que gobierna el trabajo es que, en un entorno regulado, la auditabilidad no es un anexo: es la arquitectura. Un sistema fintech no se sostiene por lo que hace cuando todo funciona, sino por lo que puede demostrar cuando alguien pregunta quién hizo qué, con qué permiso y sobre qué dato. Infraestructura como código, mínimo privilegio y trazabilidad del dato no son tres buenas prácticas sueltas: son la misma propiedad —la de poder rendir cuentas— vista desde tres capas.

El problema detectado

Una plataforma fintech regulada se construye sobre un codebase multi-repo —backend Django, clientes móviles, tooling— para un equipo chico, donde la velocidad de producto convive con una exigencia de control que no admite atajos. El problema declarado era operativo: aprovisionar y reproducir entornos —dev, staging, prod— era un trabajo manual de varios días, propenso a la deriva entre uno y otro, y sin un registro confiable de qué recursos existían ni por qué.

El problema real era anterior: sin infraestructura como código no hay auditabilidad de la infraestructura. Cada permiso otorgado a mano, cada bucket creado desde la consola, cada excepción de política sin documentar es una superficie de riesgo que nadie puede explicar después. En una fintech regulada eso no es deuda técnica: es deuda de cumplimiento. Y a eso se sumaba una necesidad analítica creciente —entender el negocio sobre los datos transaccionales— que no podía resolverse tocando la base de producción.

Relevamiento funcional

El relevamiento no fue de procesos de usuario sino del estado real de la plataforma y sus garantías: qué recursos existían, bajo qué identidades, con qué permisos, y qué tenía que poder demostrarse ante una auditoría. De ahí salieron las capas que la infraestructura tenía que gobernar de forma explícita:

El relevamiento incluyó un mapeo explícito de rutas de escalada de privilegios: dónde una identidad podía, encadenando permisos, terminar con más poder del que su rol justificaba. Documentar esas rutas —para después cerrarlas— fue parte del relevamiento tanto como inventariar los recursos.

Construcción de la solución técnica

La pieza central es un baseline de infraestructura como código en OpenTofu/Terraform, del que fui autor y único dueño: 12 módulos reutilizables —Cloud SQL, networking, IAM, Secret Manager, logging, BigQuery, Datastream, Redis, schedulers, storage, Cloud Build y Org Policy— y ~39 recursos declarados, reproducibles en dev, staging y prod. El aprovisionamiento de un entorno pasó de un setup manual de varios días a un solo tofu apply.

Sobre ese baseline, el diseño de identidad fue secure-by-design, no endurecido a posteriori:

• IAM de mínimo privilegio con roles custom de un solo permiso, en lugar de roles amplios predefinidos.
• Bindings de service-account token-creator acotados, para que la impersonación sea posible solo donde el diseño lo justifica.
• Cierre de las rutas de self-escalation detectadas en el relevamiento.
• Excepciones quirúrgicas de Org Policy (Domain Restricted Sharing) resueltas vía impersonation, en lugar de relajar la política para toda la organización.
• Retención diferenciada de Cloud Logging, ajustada a lo que cada tipo de registro exige conservar.

En el backend Django, los workflows de KYC y screening de organizaciones se modelaron como máquinas de estado finito con defensa en profundidad: triggers de base de datos que impiden transiciones inválidas aun si el código de aplicación falla, signed URLs para la media de usuario y un modelo AuditLog signal-driven que deja rastro de cada cambio relevante. Sumé tests end-to-end y corregí el ordenamiento del middleware de autenticación.

Capa de información y datos

El acceso al dato para análisis fue diseño, no anexo. El frente central es un pipeline analítico CDC: PostgreSQL → Datastream → BigQuery, usando replicación lógica para exponer vistas analíticas con impacto cero sobre la base transaccional. El negocio puede leerse sobre los datos sin que una consulta de análisis toque jamás la base que sostiene las transacciones de los usuarios.

Dos propiedades de gobierno acompañan el pipeline:

• Separación de cargas. La replicación lógica desacopla el plano analítico del transaccional; la presión de las consultas de negocio no se traslada a la operación crítica.
• Acceso acotado y trazable. El camino del dato hacia BigQuery está declarado en la misma infraestructura como código, bajo las mismas garantías de identidad: quién puede leer qué, y por qué, es auditable.

Sobre esa capa se provisionó además un stack analítico Apache Superset sobre Cloud Run, también declarado en infraestructura como código, para que el consumo del dato tenga una superficie gobernada y reproducible.

Cómo se condujo el trabajo

El trabajo se ejecutó con un harness de agentes de código gobernado por instrumentos propios, no por prompting improvisado. Lo concreto y verificable:

• Infraestructura como código con módulos reutilizables. El baseline no es un conjunto de scripts: son 12 módulos compuestos, de modo que un cambio se razona y se aplica una sola vez y se propaga a los tres entornos sin deriva manual.
• CI de Terraform read-only en cada PR. Un pipeline en Cloud Build, vía GitHub App, corre tofu plan en cada pull request bajo un service account de mínimo privilegio, con acceso a secretos acotado a la etapa de plan. El cambio de infraestructura se revisa con su plan a la vista, antes de tocar nada productivo —el agente y el revisor trabajan contra el contrato del cambio, no contra el entorno vivo.
• Estándares de ingeniería en 7 repositorios: pre-commit, CI gates, ruff/black/mypy y secret scanning, de modo que la disciplina sea del repositorio y no de la voluntad de cada commit.
• Una suite de tooling interna que enlaza ClickUp↔GitHub a nivel de commits, dando trazabilidad entre la tarea de negocio y el cambio de código.
• Las tareas repetitivas —contrastar un cambio de IAM contra el mínimo privilegio, registrar una excepción de política, verificar la forma de un módulo— se vuelven workflows reproducibles sobre estas herramientas, en lugar de pasos manuales que se degradan con el cansancio.

El punto: la IA no está en el producto entregado al cliente; está en cómo construyo, como cualquier ingeniero serio usa hoy su instrumental. Mostrarlo así —factual, sin adjetivos— es lo que distingue el dominio real de la herramienta del discurso de moda.

Qué prueba este caso

• Platform engineering de verdad: un baseline de infraestructura como código de 12 módulos y ~39 recursos, reproducible en tres entornos con un solo apply, no una colección de cambios hechos a mano en la consola.
• Disciplina de entorno regulado: mínimo privilegio demostrable, rutas de escalada cerradas y excepciones de política quirúrgicas —seguridad como arquitectura, no como parche posterior.
• Data engineering con respeto por lo crítico: un pipeline CDC que abre el dato al análisis sin que una sola consulta toque la base transaccional que sostiene el dinero de los usuarios.