Un banco del Grupo Credicorp no puede compartir espacio lógico con su subsidiaria de seguros. Un holding de retail no puede almacenar datos de trabajadores temporales de una cadena en el mismo bucket que facturas de otra. Pero ¿dónde termina la seguridad y dónde comienza el desperdicio de costos? Esta pregunta define la decisión arquitectónica más importante que enfrenta hoy cualquier grupo empresarial peruano que busca migrar su gestión documental a la nube.
El contexto peruano introduce capas de complejidad que los modelos SaaS globales no contemplan. Una sola empresa del grupo puede estar sujeta simultáneamente a SUNAT (5 años de retención), SBS (10 años), SUNAFIL (variable), MINSA e INDECOPI — cada regulador con exigencias distintas sobre quién accede, qué documentos, cuándo y con qué garantías de trazabilidad. Trasladar arquitecturas diseñadas para startups de Silicon Valley sin adaptar al marco normativo peruano genera dos tipos de fallo críticos: el fallo de cumplimiento, que resulta en multas y hallazgos en auditoría, y el fallo de costo, donde se sobre-invierte en aislamiento innecesario o se sub-invierte en donde el regulador lo exige.
Este artículo presenta los tres patrones principales de arquitectura multi-tenant para gestión documental — silo, pool y bridge — con implementación práctica en AWS y Azure, un análisis de cumplimiento actualizado a normativa peruana 2025-2026, y una guía de decisión accionable para grupos empresariales con subsidiarias de perfiles regulatorios heterogéneos.
El marco regulatorio peruano: cambios recientes y sus implicancias arquitectónicas
Antes de elegir cualquier patrón técnico, el equipo de arquitectura debe entender el piso normativo actual. Tres cambios recientes redefinieron las restricciones del diseño.
D.S. 303-2025-EF — Acceso remoto de SUNAT a sistemas cloud
Publicado en diciembre de 2025 sin período de transición, este decreto permite a SUNAT acceder visualmente a información en los sistemas del contribuyente, generar reportes y realizar auditorías remotas en tiempo real. El impacto arquitectónico es inmediato: el sistema multi-tenant debe proveer perfiles de auditor de solo lectura segregados por RUC y subsidiaria, con logs auditables de quién accedió, qué documento consultó y en qué momento. Un sistema que no demuestre esta segregación de acceso no cumple, independientemente de la robustez del aislamiento de almacenamiento subyacente.
Ley 29733 + D.S. 016-2024-JUS — Protección de datos: sanciones significativamente elevadas
La actualización reglamentaria de 2025 eleva las sanciones por infracciones graves hasta S/ 550,000 (aproximadamente USD 150,000), frente a los S/ 5,000 anteriores. La norma aplica extraterritorialmente: proveedores cloud que procesan datos de peruanos quedan sujetos incluso si los servidores residen en Brasil o EE.UU. Para grupos empresariales, el riesgo es compuesto: en un bucket compartido sin aislamiento criptográfico, una brecha en subsidiaria A puede exponer datos de subsidiaria B, amplificando el alcance regulatorio y potencialmente multiplicando las sanciones por incidente.
SBS Resolución 975-2025 — Conglomerados financieros y aislamiento operativo
Publicada en junio de 2025, esta resolución refuerza los límites de concentración de riesgo operativo entre subsidiarias financieras y exige demostraciones de aislamiento más rigurosas. En combinación con la Resolución 504-2021 — que requiere notificación previa a SBS antes de contratar servicios cloud — el marco supervisorio peruano impulsa a subsidiarias bancarias, aseguradoras y AFP hacia patrones de aislamiento más estrictos.
Los tres patrones de arquitectura multi-tenant
Silo: aislamiento dedicado por subsidiaria
En el modelo silo, cada subsidiaria opera con infraestructura completamente separada. En AWS, esto implica cuentas distintas dentro de AWS Organizations, con bucket S3 propio, base de datos RDS dedicada y Customer Managed Key (CMK) independiente en KMS. En Azure, equivale a suscripciones separadas en Management Groups, Storage Accounts propios y Key Vault con CMK por subsidiaria.
Ventajas comprobadas: Una falla de seguridad en subsidiaria A no puede propagarse a B por construcción arquitectónica, no por política. La facturación nativa es por cuenta, simplificando el chargeback interno. Los auditores de SBS pueden verificar el aislamiento sin revisar políticas IAM complejas — es visible en la estructura misma.
Limitaciones operacionales: El overhead de gestionar múltiples cuentas escala linealmente con el número de subsidiarias. Grupos con más de 50 unidades pequeñas enfrentan costos administrativos que superan los beneficios. Los reportes consolidados requieren arquitecturas adicionales (AWS Lake Formation o Azure Synapse) para agregar datos entre cuentas sin comprometer el aislamiento.
Cuándo elegir silo: Subsidiarias supervisadas por SBS, unidades con requerimientos regulatorios radicalmente distintos (sector salud + finanzas + retail en el mismo holding), o cuando mandatos de auditoría interna o reguladores exigen explícitamente separación física de datos.
Pool: recursos compartidos con aislamiento lógico
En el modelo pool, todas las subsidiarias comparten infraestructura. El aislamiento se logra mediante prefijos de objeto en S3, Row-Level Security (RLS) en base de datos y políticas IAM segregadas por tenant_id.
En AWS, la estructura típica usa un bucket compartido (s3://grupo-docs/) con prefijos por subsidiaria. Los S3 Access Points proveen políticas independientes por tenant sin necesidad de cuentas separadas, escalando a decenas de miles de tenants por cuenta. Para satisfacer el D.S. 303-2025-EF, S3 Access Grants es particularmente relevante: emite credenciales temporales de mínimo privilegio y genera logs de auditoría granulares — no solo “la aplicación de subsidiaria A accedió”, sino “Juan Pérez, empleado de subsidiaria A, consultó documento X el 2026-02-15 a las 14:30”, precisión que satisface los requisitos de trazabilidad SUNAT.
En base de datos, PostgreSQL RLS automáticamente filtra por tenant_id incluso si hay vulnerabilidades en la capa de aplicación:
CREATE POLICY tenant_isolation ON documentos
USING (tenant_id = current_setting('app.current_tenant')::int);
Limitaciones técnicas significativas: El modelo pool tiene topes ingenieriles que los equipos suelen descubrir tarde. AWS S3 permite máximo 20 KB de política de bucket y 1,000 reglas de lifecycle por bucket — con cientos de subsidiarias y tipos de documento, estos límites se alcanzan rápidamente. PostgreSQL con 500 o más schemas presenta degradación observable de rendimiento. El riesgo principal: un error en configuración IAM puede exponer datos entre subsidiarias, con consecuencias bajo la Ley 29733 actualizada que son exponencialmente más severas que antes.
Cuándo elegir pool: Grupos con 50 o más subsidiarias pequeñas en sectores no supervisados por SBS, requisitos regulatorios similares entre unidades, o como arquitectura inicial antes de migrar subsidiarias críticas a silo.
Bridge: arquitectura híbrida por capas regulatorias
El modelo bridge reconoce una realidad de la mayoría de grupos empresariales peruanos: tienen pocos activos críticos (subsidiarias SBS) y múltiples unidades operacionales con menor riesgo regulatorio. El patrón asigna niveles de aislamiento diferenciados por capa:
| Capa | Patrón | Justificación |
|---|---|---|
| Aplicación y API Gateway | Pool compartido | Entrada única para usuarios de todo el grupo |
| Metadatos y búsqueda (PostgreSQL) | Schema-per-tenant + RLS | Aislamiento moderado suficiente para índices |
| Almacenamiento de objetos (S3/Azure Blob) | Silo para SBS, prefijo-pool para operacionales | Aislamiento máximo donde lo exige el regulador |
| Auditoría y logs (CloudTrail/Azure Monitor) | Pool centralizado particionado | Análisis consolidado, acceso auditado por subsidiaria |
La ventaja práctica: Una empresa de retail con 100 tiendas y dos filiales bancarias no necesita 102 cuentas AWS. Necesita 2 cuentas para filiales SBS y una cuenta compartida para tiendas. Esto reduce el overhead administrativo en más del 90% manteniendo aislamiento donde lo exige el regulador.
Complejidad de diseño: Bridge requiere documentación rigurosa de qué subsidiarias están en qué patrón. Sin esa claridad, operaciones comete errores que rompen el aislamiento. Migrar una subsidiaria de pool a silo cuando crece o ingresa a supervisión SBS requiere re-arquitectura y migración de datos — costoso si no se previó desde el diseño inicial.
Tabla comparativa de los tres patrones
| Aspecto | Silo | Pool | Bridge |
|---|---|---|---|
| Aislamiento | Máximo (físico) | Lógico | Medio (híbrido) |
| Costo de infraestructura | Alto | Bajo | Medio |
| Escalabilidad (100+ subsidiarias) | No viable | Sí | Sí |
| Cumplimiento SBS | Más fácil de defender | Difícil de defender | Viable con diseño documentado |
| Complejidad de implementación | Simple conceptualmente | Compleja lógicamente | Moderada |
Cifrado por subsidiaria: la defensa más robusta en auditoría
En patrones pool o bridge, una Customer Managed Key (CMK) independiente por subsidiaria garantiza que incluso con errores de configuración en IAM, los datos permanecen ininteligibles sin la clave correcta. Este es el control más efectivo para defender ante auditores de SBS y SUNAT.
En AWS KMS, la práctica recomendada es una CMK por subsidiaria gestionada en cuenta central de seguridad, con roles IAM de cada subsidiaria que solo pueden usar su CMK. El costo potencialmente alto de KMS se mitiga con S3 Bucket Keys: sin ellas, cada operación en S3 llama a KMS individualmente; con ellas, S3 llama a KMS una vez por día por bucket. En repositorios con millones de documentos, el ahorro puede alcanzar el 95% en costos criptográficos.
En Azure Key Vault, el patrón equivalente es un vault central con CMK por contenedor o Storage Account, usando managed identities para que las aplicaciones de cada subsidiaria solo operen con su CMK en operaciones de cifrado y descifrado.
Retenciones regulatorias: mapeo a lifecycle policies granulares
El error más frecuente en grupos empresariales es aplicar políticas de ciclo de vida globales a buckets con documentos de retenciones distintas. La siguiente tabla resume las obligaciones por regulador:
| Regulador | Tipo de Documento | Plazo de Retención | Patrón Recomendado |
|---|---|---|---|
| SUNAT | Comprobantes, libros contables | 5 años | Pool viable; Glacier Deep Archive |
| SBS | Operaciones bancarias, seguros, AFP | 10 años | Silo preferible; WORM Lock en S3 |
| SUNAFIL | Planillas, contratos laborales | 5 años | Pool viable; Standard-IA → Glacier |
| MINSA | Historias clínicas | Variable por tipo | Silo preferible |
| INDECOPI | Propiedad industrial | 5-10 años según tipo | Depende del documento |
Las lifecycle policies deben ser granulares por prefijo y tipo de documento, nunca globales. Un comprobante SUNAT de subsidiaria A se elimina a los 5 años; un contrato de seguro de filial aseguradora necesita WORM Lock por 10 años sin opción a eliminación anticipada.
Un punto práctico crítico: AWS Glacier Deep Archive requiere entre 12 y 15 horas para rehidratar un archivo. Si SUNAT solicita un documento durante una auditoría bajo D.S. 303-2025-EF, el sistema debe mantener en tiers accesibles los documentos de los últimos 2 a 3 años, no solo los del mes en curso.
Para ciclo de vida estándar con retención larga (Standard → Standard-IA → Glacier Instant → Glacier Deep Archive), el ahorro puede alcanzar el 65-75% frente a mantener todo en Standard, especialmente en documentos históricos que rara vez se consultan pero deben conservarse por mandato regulatorio.
Implementación técnica: AWS versus Azure
Aislamiento de objetos en AWS S3
Silo (bucket por subsidiaria en cuenta separada): aislamiento máximo, fácil de auditar, facturación nativa por cuenta. Cross-account access via STS AssumeRole para la aplicación central.
Pool (prefijo + Access Points): un bucket compartido con S3 Access Points provee políticas segregadas por tenant sin complejidad de cuentas separadas, escalando a decenas de miles de tenants. El riesgo es que un ARN mal configurado permite acceso cruzado entre prefijos — debe validarse en la capa de aplicación y mediante CMK independientes.
Avanzado (S3 Access Grants + Session Broker): ideal cuando el D.S. 303-2025-EF exige trazabilidad de identidad individual. El Session Broker emite credenciales temporales que registran la identidad real del usuario — no solo el rol de aplicación — en cada operación sobre cada objeto. Este nivel de granularidad en CloudTrail es el estándar más defendible ante inspecciones.
Aislamiento de objetos en Azure Blob Storage
Silo (Storage Account por subsidiaria): máxima claridad, facturación separada por suscripción, CMK por Key Vault dedicado.
Bridge (contenedor por subsidiaria en Storage Account compartido): RBAC asigna roles específicos de lectura/escritura por contenedor, sin necesidad de suscripciones separadas. CMK por contenedor desde Key Vault central. Escala bien para grupos con decenas de subsidiarias operacionales.
Azure Smart Tier (disponible desde noviembre de 2025): evalúa patrones de acceso en tiempo real y mueve objetos automáticamente entre Hot, Cool, Cold y Archive sin configuración manual de políticas. En pilotos, más del 50% de la capacidad se desplazó a tiers más fríos, reduciendo costos de almacenamiento significativamente. Es especialmente útil en repositorios documentales donde el patrón de acceso es impredecible.
Aislamiento en base de datos: tres enfoques
Database-per-tenant (Silo): una base de datos PostgreSQL independiente por subsidiaria. Aislamiento máximo, backup y restore independientes. Recomendado para subsidiarias SBS con volumen documental alto. Complejidad operacional alta con muchas subsidiarias.
Schema-per-tenant (Bridge): una base de datos con un schema por subsidiaria. Los permisos de rol aseguran que la aplicación de subsidiaria A no puede consultar el schema de subsidiaria B. Viable para grupos de 10 a 200 subsidiarias con volumen moderado. Con 500 o más schemas, el rendimiento se degrada.
Row-Level Security — Pool (RLS): una tabla compartida con columna tenant_id y política RLS que filtra automáticamente por tenant en cada consulta. Escalable a cientos de subsidiarias. Requiere pruebas de rendimiento exhaustivas con volumen representativo antes de producción. Recomendado para grupos con 100 o más subsidiarias pequeñas de sectores no financieros.
Guía de decisión: el árbol regulatorio primero
La elección entre silo, pool y bridge no empieza en la arquitectura — empieza en el compliance. El árbol de decisión:
¿El grupo tiene subsidiarias supervisadas por SBS (bancos, AFP, aseguradoras)?
- Sí, con volumen documental alto (más de 1 TB/año) → Silo obligatorio para esas subsidiarias
- Sí, con volumen bajo → Bridge viable, silo solo para entidades SBS, pool para operacionales
¿El grupo no tiene subsidiarias SBS?
- Más de 50 subsidiarias → Pool con RLS (economía de escala)
- Menos de 50 subsidiarias con requisitos mixtos → Bridge (balance óptimo)
Diez errores que destruyen arquitecturas multi-tenant
- Asumir que un prefijo S3 equivale a aislamiento suficiente sin cifrado diferenciado ni políticas IAM correctas.
- Ignorar los límites técnicos de AWS S3 en patrones pool: 20 KB de política de bucket y 1,000 reglas de lifecycle. Con cientos de subsidiarias y tipos de documento, estos límites se alcanzan rápidamente.
- No considerar costos de egress: transferir datos fuera de la nube puede superar el costo de almacenamiento.
- Implementar PostgreSQL RLS sin probar con carga real: puede degradar queries complejas. Las pruebas con volumen representativo son obligatorias antes de producción.
- No separar datos entre subsidiarias desde el inicio: migrar de pool a silo con millones de documentos ya almacenados es exponencialmente costoso.
- Confundir aislamiento lógico con cumplimiento SBS: el regulador puede interpretar que un bucket compartido no equivale a la separación exigida. El aislamiento físico (silo) es más defendible.
- No mapear retenciones regulatorias a lifecycle policies granulares: documentos laborales (5 años) y bancarios (10 años) en el mismo bucket sin reglas diferenciadas generan eliminación prematura o gasto innecesario.
- Ignorar los tiempos de rehidratación de archivos (12-15 horas en Glacier Deep Archive) cuando SUNAT puede solicitar acceso inmediato bajo D.S. 303-2025-EF.
- No preparar perfiles de auditor de solo lectura segregados por RUC antes de que comiencen las inspecciones: el decreto está vigente sin transición.
- Coordinar con SGS Perú para microformas cloud al final del proyecto en lugar de desde el diseño inicial.
Microformas digitales: la frontera normativa abierta
El D.L. 681 y la NTP 392.030-2:2015 otorgan a documentos digitalizados bajo certificación SGS el mismo valor probatorio que el original físico cuando interviene Fe Pública. La certificación requiere tres pilares: proceso de digitalización certificado, bóveda con controles ambientales documentados y certificados de seguridad validados por INDECI.
Existe un vacío regulatorio relevante: ningún regulador peruano ha definido explícitamente si un bucket S3 o un contenedor Azure puede servir como “bóveda certificada” bajo NTP 392.030-2:2015. Los tres pilares asumen infraestructura física. Las preguntas sin respuesta oficial incluyen: ¿cómo valida SGS controles ambientales en un data center de AWS en Virginia? ¿Quién responde por los certificados INDECI, AWS o el cliente? ¿La replicación cross-region invalida la certificación peruana?
La posición pragmática para grupos empresariales es una arquitectura dual: documentos de máxima criticidad legal bajo certificación SGS en infraestructura física certificada, documentos operacionales en cloud con el patrón multi-tenant correspondiente al perfil regulatorio del grupo. Esta coexistencia reduce la exposición regulatoria mientras el marco normativo para microformas cloud se define. Grupos que necesitan microformas deben coordinar con SGS desde el diseño inicial.
Cuatro pasos accionables para comenzar ahora
Mapear reguladores antes de contratar infraestructura. Qué subsidiaria está sujeta a SBS, cuáles solo a SUNAT, cuáles a SUNAFIL. Este mapa — no la elección entre AWS y Azure — es el insumo principal para elegir silo, pool o bridge. La diferencia de precio entre proveedores (alrededor del 5-10%) es marginal comparada con el costo de re-arquitectura por una decisión de patrón equivocada.
Implementar CMK por subsidiaria desde el día uno. En cualquier patrón que no sea silo puro, implementar Customer Managed Keys independientes por subsidiaria desde el inicio. El costo es marginal (aproximadamente USD 1 por CMK mensual en AWS o Azure). El costo de cifrar retroactivamente millones de objetos ya almacenados es exponencialmente mayor.
Diseñar y probar perfiles de auditor SUNAT ahora. Crear roles IAM o Azure RBAC de solo lectura segregados por RUC, verificar que CloudTrail registra identidad granular de cada acceso, y probar que un perfil de auditor SUNAT no puede consultar datos de subsidiaria distinta a la auditada. El D.S. 303-2025-EF está vigente sin período de transición.
Aplicar lifecycle policies granulares desde el inicio. Política por prefijo, tipo de documento y regulador aplicable. Diferencia entre Standard permanente y transiciones progresivas a Archive: ahorro del 65-75% en horizontes de 5-10 años, exactamente los horizontes de retención que SUNAT y SBS exigen.
Un grupo empresarial que posterga esta decisión enfrenta tres riesgos que crecen simultáneamente: riesgo regulatorio de auditorías SUNAT sin preparación técnica, riesgo operacional de migrar millones de documentos sin aislamiento correcto, y riesgo financiero de costos de infraestructura que escalan con el patrón equivocado. La arquitectura multi-tenant correcta no es la más cara ni la más barata — es la que corresponde al perfil regulatorio real del grupo y se documenta de forma que un auditor pueda entenderla en una tarde.
¿Tu grupo empresarial navega la complejidad del multi-tenant en cloud? Contacta con nuestro equipo de especialistas en compliance cloud peruano: ventas@aypdigital.com o +51 942 867 653. AyP Digital: digitalización con certeza regulatoria.
