Gobierno de Datos en la Nube para Empresas Peruanas: Políticas, Catálogo y Cumplimiento con la Ley 29733

Una empresa mediana en Lima ya tiene expedientes, contratos y datos de empleados en S3 o Azure Blob. Pero con frecuencia no sabe exactamente qué datos contiene cada bucket, en qué región están almacenados, ni si los contratos con el proveedor cloud cumplen el DS 016-2024-JUS vigente desde marzo de 2025. Adoptar la nube sin gobernar los datos que contiene no es una estrategia incompleta — es una infracción en curso. Este artículo entrega el marco práctico para cerrar esa brecha.

El Punto de Inflexión: DS 016-2024-JUS y lo que Cambió para el Cloud

De la norma del 2013 al reglamento de 2025

El Reglamento de la Ley 29733 que rigió durante más de una década —el DS 003-2013-JUS— fue diseñado cuando la computación en nube era una tecnología incipiente en el mercado peruano. No contemplaba explícitamente los modelos IaaS, PaaS o SaaS, ni el rol del proveedor cloud como entidad que procesa datos por encargo de una empresa peruana.

El DS 016-2024-JUS, publicado el 30 de noviembre de 2024 y vigente desde el 30 de marzo de 2025, cierra esa laguna con aplicación extraterritorial explícita: alcanza a AWS, Azure y Google Cloud cuando ofrecen servicios a titulares de datos ubicados en Perú, independientemente de dónde estén sus servidores.

Los cinco cambios críticos para empresas que usan cloud

1. Aplicación extraterritorial — el reglamento alcanza a los proveedores cloud aunque sus centros de datos estén en Virginia, Irlanda o São Paulo; el factor determinante es que los titulares de los datos se encuentren en Perú.
2. El proveedor cloud como encargado del tratamiento — la empresa peruana es el responsable; AWS, Azure o GCP son los encargados. El contrato entre ambos debe incluir cláusulas específicas de seguridad, confidencialidad, notificación de brechas y eliminación de datos al término del servicio.
3. Transferencias internacionales formalizadas — la carga de la prueba recae en la empresa peruana: debe demostrar que el país de destino ofrece protección equivalente o que existen garantías contractuales adecuadas.
4. Notificación de brechas en 48 horas a la ANPD — sin excepción ni margen de discrecionalidad; retardar la notificación constituye una infracción adicional, independiente de la brecha misma.
5. Oficial de Protección de Datos (ODP) — obligatorio para entidades que tratan datos a escala o manejan datos sensibles; la designación debía completarse antes del 30 de noviembre de 2025 y comunicarse a la ANPD.

Sanciones: de 0.5 a 100 UIT

El punto que muchas empresas no dimensionan: no tener ODP designado, no notificar una brecha en 48 horas y no contar con un contrato de encargado con el proveedor cloud son tres infracciones independientes. Pueden acumularse sobre un mismo incidente.

Residencia de Datos: La Pregunta que Nadie se Hace

Perú no tiene región cloud propia

A 2026, ninguno de los tres hiperescaladores tiene una región de disponibilidad en territorio peruano. La consecuencia directa es que toda empresa peruana que usa AWS, Azure o GCP enfrenta una transferencia internacional de datos personales bajo el DS 016-2024-JUS:

Elegir región no es un detalle técnico

La decisión entre us-east-1 (Virginia) y sa-east-1 (São Paulo) tiene implicancias jurídicas directas. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD), considerada por la doctrina equivalente al estándar de la Ley 29733. Chile aprobó su nueva Ley 21.719 de protección de datos en 2024 con un nivel de exigencia comparable. Usar una región en Brasil o Chile facilita demostrar protección equivalente ante la ANPD peruana.

Usar us-east-1 no viola automáticamente la ley, pero incrementa la carga probatoria: la empresa debe justificar por qué eligió una jurisdicción más distante en términos jurídicos y qué garantías contractuales adicionales implementó para compensar esa distancia.

Tres arquitecturas para reducir el riesgo de residencia

1. Región LATAM + Data Processing Agreement — opción base para la mayoría de empresas; almacenar en sa-east-1 o Brazil South y firmar el DPA del proveedor. Cobertura suficiente para el 80% de casos.
2. Arquitectura híbrida — datos en reposo en data center local peruano; procesamiento en cloud LATAM para operaciones que no exponen identificadores personales. Adecuada para entidades sujetas a SBS o MINSA que enfrentan controles más estrictos sobre la ubicación de los datos.
3. Cifrado con llaves del cliente (BYOK/CMK) — AWS KMS, Azure Key Vault o Google Cloud KMS permiten que la empresa controle las llaves de cifrado aunque los datos estén almacenados en otra jurisdicción. Agrega una capa de control técnico sobre el encargado: sin las llaves, el proveedor cloud no puede acceder al contenido.

Catálogo de Datos: El Inventario que Reemplaza el Excel

Qué es y por qué es el punto de partida

Un catálogo de datos es el inventario centralizado y automatizado de qué datos existen en la organización, dónde están almacenados, quién los posee, cómo están clasificados y cuánto tiempo deben retenerse. La diferencia con un Excel no es filosófica sino funcional: el Excel registra lo que debería existir; el catálogo registra lo que existe realmente, escaneando fuentes activas con crawlers automáticos que detectan nuevos activos sin intervención manual.

La consecuencia práctica más inmediata está en los derechos ARCO. Ante una solicitud de acceso, rectificación, cancelación u oposición, la Ley 29733 establece un plazo de 20 días hábiles para responder. Sin un catálogo actualizado, identificar todos los registros de una persona dispersos en S3, una base de datos RDS, un SharePoint y un ERP es operativamente inviable dentro de ese plazo.

Herramientas por proveedor cloud

Las cuatro fases para construir el catálogo

flowchart LR
    A[Descubrimiento\nautomatizado] --> B[Clasificación\nde sensibilidad]
    B --> C[Curatoria humana\nData Stewards]
    C --> D[Gobierno continuo\nalertas y revisión trimestral]

• Descubrimiento: los crawlers escanean todos los repositorios cloud —buckets, bases de datos, data lakes— y registran cada activo en el catálogo. Responsable: Data Custodian.
• Clasificación: herramientas como Macie o Cloud DLP asignan automáticamente niveles de sensibilidad según el contenido detectado. La clasificación automática es el punto de partida, no el resultado final.
• Curatoria humana: los Data Stewards revisan las clasificaciones automáticas, corrigen falsos positivos y agregan contexto de negocio que ningún algoritmo puede inferir —por ejemplo, que un campo “código interno” corresponde a un DNI transformado.
• Gobierno continuo: alertas automáticas ante nuevos activos no catalogados, cambios de clasificación, y revisiones trimestrales formales del catálogo completo.

Clasificación de Sensibilidad: De la Ley al Dato

El artículo 13 de la Ley 29733 como punto de partida

La Ley 29733 identifica una categoría de datos sensibles que requieren protección reforzada: datos de salud, biometría, opinión política, credo religioso y vida sexual, entre otros. Para una empresa de gestión documental, estos datos aparecen con mayor frecuencia de lo que se anticipa: historias clínicas digitalizadas, expedientes de accidentes laborales con diagnósticos médicos, registros biométricos de control de asistencia, contratos con cláusulas sobre afiliación política de directivos.

Esquema de clasificación L1–L5 adaptado al Perú

Documentos digitalizados: el perímetro que se ignora

La mayoría de organizaciones gobiernan los datos estructurados —bases de datos SQL, CRMs— pero descuidan los repositorios documentales: PDFs, imágenes de expedientes, contratos escaneados. Un documento digitalizado contiene datos personales exactamente igual que una fila en una base de datos, y está sujeto a las mismas obligaciones de clasificación, retención y control de acceso. El proceso de catalogación debe incluir estos repositorios desde el primer crawl, no como fase posterior.

Políticas de Retención: La Tabla que Toda Empresa Necesita

Plazos por regulador

La regla del plazo mayor

Cuando un mismo documento está sujeto a múltiples reguladores, se aplica el plazo más largo sin excepción. Ejemplo concreto: un expediente de un empleado con accidente laboral en una entidad financiera está sujeto a SUNAFIL (20 años para registros SST) y potencialmente a SBS (10 años). Prevalecen los 20 años. La lifecycle policy en el repositorio cloud debe reflejar ese plazo, no el más corto ni el más conveniente.

Cómo traducir la tabla a lifecycle policies en cloud

El equivalente en AWS S3 de una política de retención de 10 años para expedientes SBS se configura así en Terraform:

resource "aws_s3_bucket_lifecycle_configuration" "sbs_retention" {
  bucket = aws_s3_bucket.expedientes_financieros.id

  rule {
    id     = "sbs-10-years-retention"
    status = "Enabled"

    # Mover a Glacier después de 2 años (acceso poco frecuente)
    transition {
      days          = 730
      storage_class = "GLACIER"
    }

    # NUNCA configurar expiration antes de cumplir el plazo legal
    # expiration { days = 3650 }  # Solo habilitar al cumplir 10 años
  }
}

Advertencia crítica: configurar una política de borrado automático a los 2 o 3 años es la infracción silenciosa más frecuente en empresas peruanas que adoptan cloud. El equipo técnico optimiza costos de almacenamiento; el equipo legal no fue consultado. El resultado viola simultáneamente SUNAT, SBS y SUNAFIL.

Eliminación segura: no basta con “delete”

Eliminar un objeto en S3 con una operación DELETE estándar no garantiza eliminación efectiva: el objeto puede persistir en versiones anteriores del bucket, en snapshots o en Glacier. Para cumplir los plazos y luego eliminar de forma certificada, las plataformas ofrecen mecanismos de retención forzada:

• AWS S3 Object Lock modo Compliance — ningún usuario, incluido el administrador root, puede eliminar el objeto antes del período definido.
• Azure Immutable Blob Storage — políticas WORM (Write Once, Read Many) inmutables durante el período de retención configurado.
• GCS Retention Policy con Delete Protection — el bucket no puede eliminarse hasta que todos los objetos superen el período de retención.

Estos mecanismos son también la base técnica de la evidencia legal: un objeto protegido por Object Lock en modo Compliance no puede ser alterado ni eliminado por ninguna acción administrativa, lo que le otorga valor probatorio ante cualquier auditoría.

Linaje de Datos: Saber de Dónde Vino y a Dónde Fue

Definición y por qué es la columna vertebral de la auditoría

El linaje de datos documenta el ciclo de vida completo de un activo: su origen, las transformaciones que sufrió, los destinos a los que llegó y los accesos que recibió. Para una empresa de gestión documental, el linaje de un expediente digitalizado responde en segundos cualquier pregunta de auditoría: ¿fue modificado después de digitalizarse? ¿Quién lo vio y cuándo? ¿Pasó por un proceso de OCR? ¿Cuándo llegó al repositorio y desde qué origen?

Diagrama de linaje para un documento digitalizado

flowchart LR
    A[Documento\nfísico] --> B[Escáner\ncertificado]
    B --> C[OCR / ICR\nreconocimiento]
    C --> D[Repositorio cloud\nS3 / Azure Blob]
    D --> E[Clasificación automática\nMacie / Purview / DLP]
    E --> F[Indexación en\ncatálogo de datos]
    F --> G[Acceso por\nusuario autorizado]
    G --> H[Registro en\nCloudTrail / Azure Monitor]

Cada nodo debe estar registrado con timestamp, identidad del sistema o usuario que ejecutó la acción, y resultado. La ausencia de cualquier nodo convierte el linaje en parcial, y una evidencia parcial ante un regulador tiene menos valor que ninguna.

Linaje automático en Purview, Glue y Dataplex

Microsoft Purview ofrece el linaje más granular de los tres: visualiza la relación entre entidades a nivel de tabla y de columna, capturando automáticamente las transformaciones de Azure Data Factory y Synapse Analytics sin configuración adicional.

AWS Glue registra el linaje de trabajos ETL: qué datasets entraron, qué transformaciones se aplicaron y qué dataset de salida se generó. Para repositorios S3 sin ETL, el linaje de acceso a objetos individuales proviene de CloudTrail con S3 Data Events habilitados.

Google Dataplex gestiona el linaje a nivel de dominio de datos, con integración nativa con Dataflow y BigQuery. Para documentos en GCS, Cloud Audit Logs de tipo Data Access proveen el registro de acceso objeto a objeto.

Auditoría sin Hojas de Cálculo: Logs, SIEM y Evidencia Regulatoria

Por qué el Excel de permisos no es auditoría

Un Excel de permisos registra quién debería tener acceso. No registra quién accedió realmente, cuándo, desde qué dirección IP, a qué objeto específico ni qué acción ejecutó. No detecta accesos fuera de horario laboral, desde ubicaciones no habituales, ni patrones de descarga masiva. Y lo más relevante: no genera evidencia válida ante un regulador, porque puede ser modificado por quien lo administra.

Logs nativos por plataforma

AWS: CloudTrail registra todas las llamadas API de gestión y está activo por defecto. Sin embargo, S3 Data Events —el log de acceso a objetos individuales— está deshabilitado por defecto y debe activarse explícitamente por bucket. Sin él, CloudTrail no registra quién leyó o descargó un documento específico. Complementan el ecosistema: S3 Server Access Logging, AWS Config para cambios de configuración, Amazon GuardDuty para detección de anomalías, y Security Hub como dashboard unificado de cumplimiento.

Azure: Azure Monitor con Log Analytics permite consultas KQL para reportes de auditoría exportables. Microsoft Defender for Cloud mapea el entorno contra estándares como ISO 27001 y NIST. Azure Policy fuerza configuraciones obligatorias —cifrado, logs activos— en todos los recursos. Privileged Identity Management (PIM) registra todos los accesos privilegiados temporales con aprobación previa.

Google Cloud: Cloud Audit Logs opera en tres tipos: Admin Activity (siempre activo), Data Access (deshabilitado por defecto en GCS para acceso a objetos — debe activarse), y System Event. Cloud Security Command Center centraliza hallazgos de seguridad. VPC Service Controls crea perímetros que impiden la exfiltración de datos incluso para administradores con permisos IAM válidos.

Arquitectura de auditoría recomendada

flowchart TD
    A[Repositorio cloud\nS3 / Blob / GCS] --> B[Logs nativos\nCloudTrail / Azure Monitor / Cloud Audit]
    B --> C[SIEM o Log Analytics\ncentralizado]
    C --> D[Alertas automáticas\nalertas de anomalías]
    C --> E[Dashboard de cumplimiento\nSBS / SUNAFIL / ANPD]
    E --> F[Evidencia exportable\npara auditoría regulatoria]
    D --> G[Respuesta a incidentes]

Logs inmutables como evidencia legal

Un log que el administrador puede modificar o eliminar no tiene valor probatorio ante SBS, SUNAFIL o la ANPD. La inmutabilidad técnica —S3 Object Lock en modo Compliance, Azure Immutable Blob Storage, GCS Retention Policy— es el requisito que convierte un log en evidencia admisible: garantiza que el registro de auditoría es idéntico al momento del evento, sin posibilidad de alteración posterior, independientemente de los permisos del administrador.

Roles y Responsabilidades: El Lado Humano del Gobierno de Datos

Los cinco roles que toda organización necesita definir

El error más común: empezar por la tecnología

Contratar Microsoft Purview o activar Amazon Macie antes de haber definido quién es el Data Owner de cada dominio de datos es el camino más corto hacia un catálogo que nadie mantiene después del lanzamiento. La tecnología de gobierno de datos es el habilitador; la política y los roles son el punto de partida. Sin un Data Steward responsable de revisar las clasificaciones automáticas de Macie, la herramienta genera un inventario que nadie valida y que pierde vigencia en semanas.

Cinco Errores Frecuentes en Empresas Peruanas

1. Asumir que el cloud provider es el responsable ante la Ley 29733. AWS, Azure y GCP son encargados del tratamiento bajo el modelo de responsabilidad compartida; el responsable legal ante la ANPD es siempre la empresa peruana cliente. La corrección es simple: leer, aceptar activamente el DPA del proveedor y archivar esa documentación como evidencia de cumplimiento.

2. No firmar el Data Processing Agreement con el proveedor cloud. Los tres grandes ofrecen DPAs, pero el cliente debe aceptarlos activamente — no se activan por defecto al contratar el servicio. El DPA debe tramitarse antes de transferir cualquier dato personal al repositorio cloud, no al recibir una auditoría.

3. Seleccionar la región cloud por costo o latencia sin analizar implicancias jurídicas. Usar us-east-1 en lugar de sa-east-1 aumenta la distancia jurídica y la dificultad de demostrar protección equivalente ante la ANPD. La prioridad debe ser regiones en países con marco de protección reconocido como equivalente —Brasil con LGPD, Chile con Ley 21.719.

4. No habilitar los logs de acceso a objetos. CloudTrail en AWS y Cloud Audit Logs de Data Access en GCP están deshabilitados por defecto para acceso a objetos individuales. Sin activarlos, es imposible saber quién leyó un documento específico. La habilitación debe ocurrir desde el primer día de operación, no al recibir una notificación de fiscalización.

5. Configurar lifecycle policies de borrado sin respetar plazos regulatorios. Una regla que elimina objetos a los 2 o 3 años puede violar simultáneamente SUNAT (5 años), SBS (10 años) y SUNAFIL (hasta 20 años). El mapa de cada bucket al regulador aplicable debe definirse antes de configurar cualquier regla de ciclo de vida.

Casos de Uso por Sector

Sector Financiero (SBS)

Las entidades supervisadas por la SBS almacenan expedientes de crédito, registros LAFT y documentación de clientes que deben conservarse por 10 años desde la extinción de la operación. En Azure, esto se traduce en Azure Blob Storage con Immutable Storage habilitado en modo WORM, impidiendo cualquier modificación o eliminación antes del plazo regulatorio.

Microsoft Purview es la herramienta natural para este sector: su integración con Azure SQL y Data Lake genera linaje automático, y Privileged Identity Management controla que los accesos a expedientes L5 pasen por un flujo de aprobación registrado. Los reportes de Log Analytics en formato KQL pueden exportarse directamente para auditorías SBS sin trabajo manual adicional.

Sector Salud (MINSA, EsSalud, Clínicas Privadas)

Las historias clínicas son simultáneamente datos L5 (retención de 20 años) y datos sensibles bajo el artículo 13 de la Ley 29733. En Google Cloud, Cloud DLP clasifica automáticamente cualquier documento que contenga diagnósticos, códigos CIE-10 o referencias a tratamientos como dato sensible de salud, aplicando las restricciones de acceso correspondientes.

VPC Service Controls crea un perímetro técnico alrededor del repositorio: incluso un administrador con permisos IAM válidos no puede exfiltrar datos fuera del perímetro definido. Ante una solicitud ARCO de acceso o cancelación, el catálogo de Cloud Data Catalog permite localizar todos los registros de un paciente en minutos, no en días.

Sector Minero y Manufactura (SUNAFIL)

Los registros de seguridad y salud en el trabajo tienen el plazo de retención más largo fuera del sector salud: 20 años para enfermedades ocupacionales, 10 para otros registros SST. En AWS, Amazon Macie monitorea continuamente los buckets S3 que contienen estos registros y alerta si detecta datos sensibles sin clasificación adecuada.

AWS Config Rules pueden forzar que todo bucket con datos L4 o L5 tenga cifrado habilitado, versioning activo y S3 Data Events encendidos. Si alguna configuración se desvía de esa línea base, Config genera un hallazgo automático antes de que SUNAFIL llegue a una fiscalización sin previo aviso —que es el modelo de inspección habitual de esa entidad.

Archivos Físicos Digitalizados (Clientes de AyP Digital)

La digitalización certificada bajo NTP 392.030-2:2015 y DL 681 produce microformas con valor legal equivalente al documento físico. Al ingresar al repositorio cloud, cada microforma recibe un hash SHA-256 registrado en el catálogo en el momento de la carga. S3 Object Lock en modo Compliance protege el objeto durante el período legal; el hash registrado permite demostrar integridad en cualquier momento posterior.

Ante un requerimiento de SUNAT o una auditoría legal, la organización puede presentar tres evidencias técnicas complementarias: existencia (el hash en el catálogo), integridad (el hash actual del objeto coincide con el hash original), y trazabilidad de accesos (CloudTrail con S3 Data Events muestra cada acceso con fecha, hora, usuario e IP). Esa combinación es funcionalmente equivalente a presentar el documento físico original.

Hoja de Ruta: Los Primeros 90 Días

Días 1–30: Visibilidad

• Inventariar todos los repositorios cloud activos: S3 buckets, Azure Storage Accounts, GCS buckets.
• Activar logs de acceso a objetos en todos los repositorios (S3 Data Events en AWS; Cloud Audit Logs Data Access en GCP).
• Identificar qué datos personales se tratan, en qué región cloud están almacenados y qué regulador aplica a cada conjunto.
• Designar al Oficial de Protección de Datos si no existe, y comunicar la designación a la ANPD.

Días 31–60: Formalización

• Firmar o revisar el DPA con cada proveedor cloud activo; incorporar las cláusulas tipo del Ministerio de Justicia para transferencias internacionales.
• Mapear cada bucket o contenedor al regulador aplicable y configurar las lifecycle policies de retención correctas.
• Lanzar el primer crawl del catálogo de datos con AWS Glue Data Catalog, Microsoft Purview o Google Cloud Data Catalog.
• Habilitar S3 Object Lock, Azure Immutable Blob Storage o GCS Retention Policy en los repositorios con datos L4 y L5.

Días 61–90: Gobierno continuo

• Aprobar las cinco políticas mínimas: clasificación de sensibilidad, retención, control de acceso, transferencia internacional y respuesta a incidentes.
• Configurar alertas automáticas ante accesos anómalos (GuardDuty en AWS, Defender for Cloud en Azure, Security Command Center en GCP).
• Realizar la primera revisión formal de accesos con criterio de mínimo privilegio.
• Definir el ciclo de revisión trimestral del catálogo y los permisos, con Data Steward responsable por dominio.

Cómo AyP Digital Apoya el Gobierno de Datos Documental

La digitalización certificada bajo NTP 392.030-2:2015 y DL 681 es el paso cero del gobierno de datos documental: transforma papel en microformas con valor legal que pueden entrar en un catálogo gobernado desde el primer día, con hash de integridad, metadatos de origen y clasificación de sensibilidad asignada en el momento de la carga. Un documento digitalizado sin esos atributos es un objeto opaco en el repositorio cloud; con certificación y metadatos, es un activo trazable y auditable.

ePaper, como plataforma de gestión documental, incorpora trazabilidad nativa en cada expediente: el linaje desde el origen físico está registrado, el control de acceso opera por rol, y los registros de auditoría son exportables para fiscalizaciones de SUNAT, SBS o SUNAFIL sin necesidad de construir reportes manuales.

El acompañamiento de AyP Digital cubre la transición completa: desde el inventario del archivo físico y el proceso de digitalización certificada hasta la configuración del repositorio cloud y las políticas de retención alineadas con cada regulador aplicable al cliente.

Conclusión

El gobierno de datos en la nube no es un proyecto con fecha de fin: es una capacidad organizacional permanente que requiere roles definidos, herramientas activas y revisiones periódicas. Las empresas peruanas que actúen hoy tienen una ventaja concreta: el DS 016-2024-JUS ya está vigente, pero la ANPD se encuentra aún en una fase de maduración de su capacidad supervisora. Implementar el catálogo, los contratos de encargado con los proveedores cloud, los logs inmutables y las lifecycle policies correctas ahora significa llegar a una auditoría con evidencia organizada, no construyéndola bajo presión en 72 horas.

El costo de gobernar los datos —herramientas, tiempo de configuración, roles formalizados— es medible y acotado. El costo de una infracción de 100 UIT más el daño reputacional ante clientes regulados como bancos, aseguradoras o entidades públicas es significativamente mayor, y con frecuencia detonado por un error técnico que ningún área de la empresa sabía que estaba cometiendo: un bucket sin logs, una lifecycle policy demasiado agresiva, un DPA que nadie firmó.