Tokenización y Control de Acceso Granular en Repositorios Documentales: Guía para Entidades Reguladas

Un repositorio documental en una entidad financiera o aseguradora peruana es un activo crítico de seguridad, no un archivo pasivo. Contiene DNIs, RUCs, números de cuenta, historial crediticio, datos médicos y expedientes sensibles. Cuando ese repositorio no segmenta ni protege el dato a nivel granular, una sola brecha compromete miles o millones de registros de forma inmediata. El perímetro de red —firewalls, antivirus, VPN— protege el borde. Pero si un atacante compromete credenciales válidas, o un empleado autorizado decide extraer datos, el perímetro no ofrece ninguna protección adicional.

En 2024, la ANPDP impuso multas que superaron los S/ 13 millones, con el sector financiero y telecomunicaciones como blancos principales. El nuevo reglamento de la Ley 29733 (DS 016-2024-JUS, vigente desde el 31 de marzo de 2025) endurece las sanciones e introduce la obligación de notificar brechas en 48 horas. La Resolución SBS 2286-2024 exige Sistema de Gestión de Seguridad de Información y Ciberseguridad (SGSI-C) certificado como requisito para operar en el Open Finance peruano. Las reglas cambiaron de forma fundamental.

Tokenización y control de acceso granular actúan como segunda y tercera línea de defensa cuando el perímetro cede. Esta guía explica cómo implementarlos en instituciones reguladas: qué exigen las normas peruanas, qué diferencia tokenización de cifrado, cómo combinar RBAC con ABAC, y los errores más costosos que cometen las entidades en Perú.

Por qué la urgencia regulatoria es real en 2025-2026

La aceleración de sanciones y nuevas obligaciones

Las infracciones graves a la Ley 29733 resultan en sanciones entre 5 UIT (S/ 26,750) y 100 UIT (S/ 535,000). Las infracciones muy graves superan ese rango. El ritmo de fiscalización se aceleró en 2024, con procedimientos más rápidos y criterios más estrictos en cada revisión.

El DS 016-2024-JUS introdujo tres cambios estructurales directos:

• Notificación de brechas en 48 horas obligatoria: antes no existía plazo definido. Incumplir este plazo genera una infracción adicional e independiente.
• Oficial de Datos Personales como responsable independiente: equivalente al DPO europeo. Obligatorio para entidades que tratan datos sensibles de forma habitual. No es optativo ni puede ser presionado; reporta directamente a la alta dirección.
• Alcance extraterritorial: aplica a cualquier organización que procese datos de personas ubicadas en Perú, incluso si el procesamiento ocurre en el extranjero.

SBS: ciberseguridad como barrera de entrada regulatoria

La Resolución SBS 504-2021, modificada por Res. 2286-2024 (vigente julio 2025), exige SGSI-C a bancos, cajas municipales, cajas rurales, cooperativas, AFP, aseguradoras y bolsas. Los requisitos incluyen directamente:

• Política de clasificación de activos de información: el repositorio documental no es un sistema periférico, sino un activo crítico. Debe estar clasificado, inventariado y protegido desde el ingreso del dato.
• Control de acceso con autenticación multifactor (MFA): obligatoria para operaciones de alto riesgo. La entidad es responsable legal por operaciones realizadas sin segundo factor.
• Monitoreo y auditoría continua: logs de acceso inmutables, SIEM, respuesta a incidentes documentada. Logs almacenados localmente sin protección no cumplen los requisitos normativos.

El problema central que persiste en la mayoría de entidades: inversión concentrada en perímetro, pero datos en claro dentro del repositorio. Un insider con credenciales válidas, o un atacante que las comprometa, accede a todo sin fricción adicional. La tokenización y el control granular modifican ese modelo desde la raíz.

Marco regulatorio aplicable: qué exigen en concreto

Ley 29733 y DS 016-2024-JUS: principios operativos

La ley establece el principio de seguridad: medidas técnicas y organizativas proporcionales al riesgo del dato. La tokenización cumple directamente: si el repositorio almacena tokens en lugar de datos originales, la exposición ante brecha disminuye de forma significativa.

El principio de minimización de datos tiene implicación directa en el diseño: tokenizar datos que no se usan en el flujo normal —como el DNI completo en búsquedas— reduce el alcance regulatorio. Si el índice contiene el token FPE del DNI en lugar del DNI real, el repositorio queda parcialmente fuera del alcance normativo de datos personales.

Las categorías de datos sensibles —biométricos, médicos, financieros— requieren controles reforzados. Un expediente de siniestros de salud contiene simultáneamente datos médicos y financieros. Ambas categorías exigen el mismo nivel de protección, pero con accesos diferenciados por rol y función.

SBS 504-2021: controles técnicos específicos

La norma referencia NIST SP 800-53 e ISO/IEC 27001. Los controles directamente aplicables al repositorio documental son:

Ley 30096 — Delitos Informáticos: ABAC como prueba regulatoria

El artículo 3 tipifica el acceso no autorizado a sistemas. Si un empleado con permisos amplios accede a datos fuera de su función, puede calificar como acceso no autorizado si existe política interna que lo prohíba. ABAC bien implementado genera evidencia auditada de que el acceso fue no autorizado, lo que protege a la entidad ante reguladores y, en casos extremos, fundamenta una denuncia penal interna.

Tokenización: qué es y por qué no es cifrado

La confusión conceptual más costosa

Muchas entidades confunden tres conceptos con consecuencias regulatorias distintas:

• Cifrado: transforma el dato; la clave lo revierte. Todos los sistemas que acceden al dato cifrado son responsables regulatorios de gestión de clave y seguridad.
• Enmascaramiento de pantalla (“DNI: 123****78”): oculta el dato en la interfaz, pero el DNI permanece en claro en base de datos, logs y APIs internas. No protege en profundidad.
• Tokenización: reemplaza el dato por sustituto sin valor intrínseco. El token no se puede revertir sin acceso a la bóveda o a la clave. El repositorio almacena tokens, nunca datos originales.

Tipo 1: Tokenización con Vault centralizado

El dato original se almacena en bóveda segura; el repositorio recibe un token de referencia aleatorio.

Mecanismo: DNI 12345678 entra al vault → vault genera token TK-AF7Q3X → repositorio almacena TK-AF7Q3X → la consulta requiere autorización del vault para resolver el DNI real.

Ventaja: token completamente aleatorio, sin relación matemática con el dato original.

Desventaja: el vault es punto único de fallo. Alta latencia en escala (millones de documentos implican millones de consultas al vault). Requiere infraestructura de alta disponibilidad costosa.

Tipo 2: FPE Vaultless (Format-Preserving Encryption)

No existe bóveda centralizada. El token se genera criptográficamente desde el dato original con una clave secreta.

Mecanismo: DNI 12345678 + Clave secreta → algoritmo FF1/FF3-1 (NIST SP 800-38G) → token 12549637 (mismo formato, 8 dígitos). El repositorio almacena el token. Sin la clave FPE, el token es inutilizable.

Ventaja crítica: es determinista —mismo input más misma clave igual a mismo token siempre—. Permite búsquedas sin exponer datos reales: buscar “DNI = 12549637” en el índice sin revelar el DNI original. Escala a millones de documentos sin latencia adicional.

Desventaja: la clave FPE es el secreto crítico. Exponerla compromete todos los tokens históricos.

Cuándo usar cada técnica según tipo de dato

Punto crítico: la tokenización debe ocurrir en el ingreso al repositorio (post-OCR, pre-almacenamiento), nunca en la salida. Tokenizar en el momento de la consulta crea ventanas de exposición en memoria y logs.

RBAC: el piso mínimo de control de acceso

El Control de Acceso Basado en Roles (RBAC) asigna permisos a roles —Analista de Crédito, Auditor, Admin— y los usuarios heredan los permisos del rol asignado. La decisión de acceso se toma en el aprovisionamiento, no en cada solicitud.

Ventaja: simple de entender, implementar y auditar. Alineado con organigramas. Es la base obligatoria que toda entidad debe tener antes de escalar.

Limitación crítica: demasiado tosco para repositorios complejos. Un rol “Analista de Crédito” ve toda la cartera sin distinción entre lectura en pantalla y descarga masiva; no considera horario, dispositivo ni si el cliente está asignado a ese analista específico.

Cómo estructurar RBAC sin generar “permission creep”

1. Roles alineados con funciones, no con departamentos: “Analista de Crédito” no es lo mismo que “Empleado del Área de Crédito”. El primero tiene permisos específicos y bien delimitados.
2. Principle of Least Privilege (PoLP): el acceso predeterminado es denegado; se concede solo lo necesario. No “todos los analistas ven todo salvo excepciones”.
3. Separación de funciones (SoD): quien aprueba un crédito no puede modificar el expediente después. Quien audita no puede descargar datos masivos.
4. Revisión semestral obligatoria: bajas de personal revocando accesos en menos de 24 horas. Las promociones requieren asignación explícita de nuevo rol, nunca acumulación de permisos anteriores.

RBAC no previene que un analista autorizado acceda a expedientes de competidores, descargue masivamente o acceda fuera de horario. Para esas limitaciones, se necesita ABAC.

ABAC: el siguiente nivel de madurez

El Control de Acceso Basado en Atributos (ABAC) evalúa múltiples atributos en tiempo real en cada solicitud de acceso. La decisión no se toma una sola vez; se re-evalúa en cada acceso, considerando el contexto completo del momento.

Las cuatro dimensiones de evaluación

1. Atributos del Sujeto (Usuario): rol, departamento, nivel de habilitación, antigüedad en la entidad, estado del contrato (activo/suspendido/en término), tipo de dispositivo, ubicación geográfica, MFA verificado en sesión.

2. Atributos del Recurso (Documento): clasificación de sensibilidad, tipo de dato contenido (PII, médico, financiero), propietario del documento, etapa del proceso (solicitud/evaluación/aprobación/cierre), antigüedad del documento.

3. Atributos de la Acción: lectura, descarga, impresión, compartir, modificación, eliminación, reporte de agregación, volumen (¿una lectura individual? ¿descarga masiva de 500 documentos?).

4. Atributos del Entorno (Contexto): horario laboral o fuera de jornada, ubicación IP (red corporativa / VPN verificada / IP desconocida), estado de cifrado del dispositivo, desviación de comportamiento histórico (¿el usuario descargó 10 documentos ayer y hoy intenta 500?).

Ejemplo práctico: política ABAC para expediente crediticio

PERMITIR si:
  rol = "Analista de Crédito"
  AND departamento = "Crédito"
  AND cliente_asignado_al_analista = TRUE
  AND acción = "lectura"
  AND horario = "laboral"
  AND dispositivo = "corporativo_cifrado"
  AND MFA_verificado = TRUE

DENEGAR + EXIGIR re-autenticación si:
  acción = "descarga" AND volumen > 50 documentos/día

DENEGAR + LOG INTENSIVO + ALERTA CISO si:
  ubicación_IP = "desconocida"
  AND dispositivo NOT "corporativo"
  AND rol NOT "auditor"

Cada línea es una política auditable, versionable y transparente para el Oficial de Datos. El motor de políticas (Open Policy Agent / OPA, XACML) la ejecuta sin intervención humana en tiempo real.

ABAC previene insider threats que RBAC no detecta

• Analista accediendo a cliente de competidor: RBAC no lo bloquea si es del mismo tipo de producto. ABAC bloquea si cliente_asignado_al_analista = FALSE.
• Descarga masiva fuera de horario: RBAC lo permite. ABAC lo bloquea y genera alerta inmediata.
• Usuario en proceso de desvinculación: RBAC puede olvidar la revocación. ABAC detecta estado_contrato = "término" y niega automáticamente.
• Acceso desde IP desconocida: RBAC es ciego al contexto. ABAC exige re-autenticación forzada.

Arquitectura de referencia: capas de protección

El flujo seguro de un documento desde su ingesta hasta su consulta atraviesa seis capas diferenciadas:

[1. INGESTA Y CLASIFICACIÓN]
  Documento físico / PDF / Email / Sistema externo
  → OCR/ICR: extrae campos sensibles (DNI, RUC, datos financieros)
  → Clasificación automática: Público / Interno / Confidencial / Reservado

[2. TOKENIZACIÓN]
  → FPE vaultless para DNI/RUC (token preserva formato)
  → Vault tokenization para nombres y números de cuenta
  → Resultado: documento con campos sensibles reemplazados

[3. ALMACENAMIENTO CIFRADO EN REPOSO]
  → AES-256 en documentos y metadatos
  → Token Data Environment (clave FPE) en infraestructura FIPS 140-2
  → Segregado de la red del repositorio principal

[4. CONSULTA CON CONTROL DE ACCESO]
  → RBAC: ¿tiene rol autorizado? SÍ → continúa
  → ABAC: ¿atributos cumplen política? SÍ → continúa
  → MFA: ¿segundo factor verificado? SÍ → descifrado y entrega

[5. VISUALIZACIÓN ENMASCARADA]
  → "DNI: 123****78" en pantalla (no en base de datos)
  → Datos no autorizados se muestran como "[RESTRINGIDO]"
  → Descargas: PDF con datos enmascarados según política

[6. AUDITORÍA E INMUTABILIDAD]
  → Quién + IP + dispositivo + qué + cuándo + ubicación
  → SIEM centralizado remoto (no en servidor local)
  → Retención mínima: 1 año legal; 3-7 años para auditorías recurrentes

El Token Data Environment (TDE) es el núcleo de la protección. Contiene la clave FPE o el mapeo vault, con acceso limitado a sistemas muy restringidos. Debe estar en infraestructura FIPS 140-2, separado lógicamente de la red del repositorio, con redundancia geográfica y monitoreo 24/7. Si el TDE se compromete, todo el modelo colapsa. Se gestiona como infraestructura crítica.

Errores costosos en instituciones peruanas

Error 1: Enmascaramiento de pantalla confundido con protección real

La aplicación muestra “DNI: 123****78”. El equipo de IT cree que el dato está protegido. El DNI en claro permanece en la base de datos, en los logs y en los backups. Un atacante que compromete la BD accede al DNI completo sin importar lo que muestre la pantalla.

Consecuencia regulatoria: ANPDP considera que el dato no está protegido. Multa por no implementar medidas técnicas proporcionales al riesgo.

Solución: tokenizar en la capa de almacenamiento, antes de entrar a la base de datos. El enmascaramiento es complementario, nunca sustituto.

Error 2: Vault centralizado sin redundancia

Una sola instancia del vault. Si cae, el repositorio queda inutilizable: nadie puede leer ni cifrar documentos. El downtime no planificado en una entidad financiera genera multa SBS por incumplimiento de disponibilidad del SGSI-C.

Solución: redundancia geográfica mínima en dos sitios, sincronización cifrada entre vaults y failover automático en menos de 5 minutos documentado en el plan de continuidad.

Error 3: Roles inflados por excepciones acumuladas

“El Analista A necesita acceso temporal a documentos de Gerencia.” Se concede. El proyecto termina; nadie revoca. Meses después, el Analista cambió de área y conserva permisos del cargo anterior. ANPDP y SBS detectan “acceso excesivo” como hallazgo crítico de cumplimiento.

Solución: excepciones temporales con fecha de expiración automática. Revisión semestral forzada por Oficial de Datos y CISO en conjunto. Cambio de rol implica revocación explícita del anterior.

Error 4: Logs desprotegidos y no centralizados

Los logs se almacenan en el mismo servidor del repositorio. Un insider modifica los logs para borrar evidencia del robo. En auditoría, la entidad no puede demostrar monitoreo continuo. Sanción SBS por incumplimiento del requisito de logs inmutables.

Solución: logs inmutables centralizados en SIEM remoto (Wazuh, ELK, Azure Sentinel). El servidor del repositorio no puede modificar logs remotos. Retención mínima: 1 año legal; 3-7 años para auditorías regulatorias recurrentes.

Error 5: Documentos físicos digitalizados fuera del alcance de protección

La entidad tokeniza documentos nativos digitales. Los documentos físicos se escanean, se guardan como PDF y no se aplica OCR ni tokenización. El archivo escaneado contiene datos en claro en la imagen. La brecha llega por un PDF de 50 páginas de expedientes de clientes.

Solución: flujo integrado sin excepción — físico → scanner → OCR → identificación de campos sensibles → tokenización en metadatos → documento cifrado en reposo. No es “scan y guardar”; es “scan, procesar, proteger”.

Error 6: No planificar rotación de claves FPE

Se implementa FPE con una clave. Años después, por cambio de proveedor o auditoría, se necesita rotar. Cambiar la clave implica retokenizar todos los datos. Sin planificación, los índices, referencias cruzadas y aplicaciones quedan inconsistentes. Downtime no planificado e incapacidad de demostrar manejo seguro de tokens.

Solución: en la arquitectura de FPE, implementar key versioning desde el diseño inicial. La clave tiene versión; al rotar se genera clave v2. Ambas versiones coexisten; los datos migran gradualmente. Las aplicaciones soportan múltiples versiones de token.

Casos de uso por sector regulado en Perú

Banca y microfinanzas: expedientes crediticios

El expediente contiene DNI, RUC, estados de cuenta (PDF), boletas de pago, declaraciones tributarias y formularios de capacidad de pago. El analista de crédito asignado debe poder leer; el área de riesgo genera reportes de cartera sin exponer datos individuales; el auditor revisa historial completo sin descargar masivamente.

Implementación típica:

• FPE en campos DNI/RUC en metadatos de búsqueda (auditoría sin ver el DNI real).
• AES-256 en documentos escaneados (PDFs de boletas y declaraciones).
• ABAC: rol = "Analista" AND cliente_asignado = TRUE AND acción = "lectura" → PERMITIR. Descarga → exigir justificación y autorización de gerente.
• Audit trail inmutable de quién leyó qué expediente y cuándo.

Normativa activada: Ley 29733, SBS 504-2021, PCI DSS si hay datos de tarjeta en el expediente.

Seguros: expedientes de siniestros

El expediente combina información médica (dato sensible bajo Ley 29733), documentos de identidad del asegurado, fotos del daño y dictámenes técnicos. El ajustador de siniestros accede a sus casos asignados; el médico revisor ve solo informes médicos, sin acceso a datos financieros del asegurado.

Implementación típica:

• Subcarpeta por tipo de documento dentro del expediente.
• ABAC por tipo de rol y subdocumento: rol = "Médico_Revisor" AND tipo_documento = "informe_médico" → PERMITIR. tipo_documento = "datos_financieros" → DENEGAR si no es gestor de siniestros.
• Tokenización del número de póliza y DNI en campos de búsqueda.

Normativa activada: Ley 29733 (datos de salud con protecciones reforzadas), SBS 504-2021, normativa MINSA sobre confidencialidad médica.

AFP y fondos de pensiones: aportes de afiliados

El portal de autoservicio permite a cada afiliado ver solo sus saldos. El asesor de cuenta accede al perfil completo de sus afiliados asignados. El área actuarial genera estadísticas de cartera sin exponer datos individuales.

Implementación típica:

• RBAC base: Afiliado, Asesor, Auditor, Admin.
• ABAC: usuario_tipo = "Afiliado" AND afiliado_id = usuario_id → PERMITIR lectura propia. usuario_tipo = "Asesor" AND afiliado_en_cartera_asesor = TRUE → PERMITIR lectura y modificaciones autorizadas.
• Reportes actuariales: datos pseudonimizados (ID_afiliado = hash del DNI, no DNI real).

Normativa activada: Ley 29733, SBS 504-2021, normativa específica de AFP.

Cooperativas y cajas municipales: implementación pragmática

Entidades con recursos limitados enfrentan el mismo marco normativo que instituciones grandes. La SBS 504-2021 aplica igual.

Implementación Tier 1 (inicio):

• RBAC bien estructurado: Caja, Gerente, Auditor, Admin, alineado con funciones reales.
• Tokenización de DNI/RUC en campos de búsqueda del repositorio.
• Política ABAC básica: horario laboral + dispositivo corporativo + MFA para acceso a expedientes.
• Audit trail en SIEM open source (Wazuh).

Escalamiento Tier 2 (cuando hay capacidad):

• Atributo cliente_asignado en políticas ABAC.
• Segregación de funciones formal.
• Integración con directorio corporativo para automatizar revocación de accesos en bajas de personal.

Checklist de cumplimiento para CISO: 10 elementos de autoevaluación

Usa este checklist para identificar brechas antes de una auditoría SBS o ANPDP.

• Clasificación de documentos: ¿existe política de clasificación por nivel de sensibilidad aplicada automáticamente en ingesta?
• Identificación automática de datos sensibles: ¿el sistema identifica campos PII (DNI, RUC, datos médicos) en la ingesta con OCR o clasificación asistida por IA?
• Tokenización implementada: ¿los datos sensibles están reemplazados por tokens en almacenamiento? ¿el Token Data Environment está segregado en infraestructura FIPS 140-2?
• Cifrado en reposo: ¿documentos almacenados con AES-256? ¿gestión de claves en HSM externo o equivalente certificado?
• RBAC bien estructurado: ¿roles alineados con funciones de negocio, con revisión semestral de derechos de usuarios?
• Políticas ABAC activas: ¿se evalúan atributos en tiempo real (horario, dispositivo, ubicación, cliente asignado)? ¿políticas documentadas y auditables en lenguaje formal?
• Separación de funciones: ¿restricciones que previenen que el mismo usuario apruebe y modifique documentos críticos?
• MFA obligatoria: ¿segundo factor para acceso a datos sensibles y descargas masivas? ¿factor de naturaleza diferente a la contraseña (app de autenticación, token de hardware)?
• Audit trail centralizado: ¿logs inmutables en SIEM remoto con retención mínima de 1 año y acceso restringido a Oficial de Datos y CISO?
• Plan de respuesta a brechas: ¿procedimiento documentado de notificación a ANPDP en 48 horas? ¿simulacros anuales realizados y documentados?

Resultado: 8-10 ítems marcados = madurez nivel 3 (cumplimiento demostrable ante auditoría). 5-7 = nivel 2 (en tránsito, brechas identificadas). Menos de 5 = nivel 1 (exposición regulatoria inmediata; prioridad urgente).

El rol de AyP Digital en la ingesta inteligente

AyP Digital no vende tokenización ni motores criptográficos. Su rol es anterior y crítico: la ingesta determina si el dato entra al repositorio protegido o en claro, y ese momento no tiene marcha atrás eficiente.

Cuando AyP Digital digitaliza un documento —factura, boleta de pago, expediente judicial, contrato— el OCR no solo reconoce el texto: identifica dónde están los campos sensibles. La salida es JSON estructurado con campos etiquetados ("dni": "12345678", "ruc": "20612853798", "monto": "5000"). Sin esta estructura, la tokenización posterior es manual y propensa a errores. El dato sensible queda en claro en la imagen del PDF sin ser identificado para protección.

ePaper, la plataforma de gestión documental de AyP Digital, es el punto central donde convergen control de acceso y clasificación. Soporta políticas de acceso a nivel de documento y carpeta, e integra servicios de tokenización vía API en el momento de la ingesta.

La propuesta concreta: no es “scan y guardar PDF”. Es digitalización con protección por defecto —scan → OCR → identificar sensibles → tokenizar → clasificar → almacenar con control de acceso desde el primer día—. Las entidades que digitalizan documentos históricos con este flujo no necesitan remediaciones de emergencia posteriores. Las que ya tienen años de documentos en claro pueden retokenizar de forma ordenada, con trazabilidad completa, no en modo de crisis.

Microforma digital con valor legal (DL 681, NTP 392.030-2:2015): los documentos digitalizados por AyP Digital tienen validez legal en Perú. Esto resuelve un dilema práctico de auditoría: ¿cómo mantener documentos protegidos si después necesito presentar el original en litigio? La microforma generada en ingesta es la evidencia admisible de que el documento original existió y fue capturado fielmente, aunque después se haya tokenizado para almacenamiento seguro.

Próximos pasos

El DS 016-2024-JUS está vigente. Las auditorías SBS con énfasis en SGSI-C comenzaron en 2025. Las sanciones ANPDP van en aumento sistemático. No es tema de planes futuros; es realidad operacional presente.

Las entidades financieras y aseguradoras que mantienen datos sensibles en claro en repositorios documentales están expuestas en tres frentes: multas ANPDP de hasta S/ 535,000 por infracción grave, hallazgos SBS que pueden condicionar habilitaciones operativas, y riesgo reputacional de brecha pública con nombre de empresa en medios.

RBAC + tokenización básica es punto de partida realista para entidades pequeñas con recursos limitados. RBAC + ABAC + FPE + vault para datos críticos es el modelo robusto para bancos, aseguradoras y AFP.

El primer paso no es comprar tecnología. Es evaluar el estado actual: qué datos existen, cuáles están en claro, qué roles tienen acceso a qué, dónde están los logs. Esa auditoría de madurez documental es el diagnóstico desde el cual se diseña arquitectura específica para cada entidad.

Contacta a AyP Digital para una consultoría de diagnóstico inicial — evaluaremos tu repositorio actual y mostraremos dónde estás versus dónde necesitas estar según DS 016-2024-JUS y SBS 504-2021.

• Teléfono: +51 942 867 653
• Email: ventas@aypdigital.com
• Ubicación: Lima, Perú