Por Jvnn Hermoza · Publicado: 14 sep. 2026 · Lectura: 6 min
Si tu sistema guarda el nombre, el DNI o el correo de una persona, ya está dentro del alcance de la Ley 29733. Esta guía no es asesoría legal — es la traducción práctica de lo que esa ley le exige a la arquitectura de un sistema, para que sepas qué preguntar a tu proveedor de desarrollo o a tu equipo técnico.
Respuesta directa
La Ley 29733 de Protección de Datos Personales exige que cualquier sistema que maneje datos de personas — clientes, usuarios, pacientes, empleados — tenga consentimiento informado registrado, medidas de seguridad proporcionales al tipo de dato, y capacidad de responder a los derechos ARCO (acceso, rectificación, cancelación, oposición) del titular. Para datos sensibles (salud, biométricos, opiniones políticas o religiosas, entre otros) las exigencias son más estrictas. En términos de arquitectura, esto se traduce en: cifrado de datos en tránsito y en reposo, control de accesos por rol, y un registro de auditoría de quién accedió a qué. Esta es información general — para tu caso específico, consulta con un abogado especializado en protección de datos.
Qué cuenta como dato sensible.
No todo dato personal pesa igual. Un correo de contacto es un dato personal común; un diagnóstico médico, un dato sensible con reglas más estrictas. La ley da tratamiento reforzado a categorías como salud, origen racial o étnico, opiniones políticas, convicciones religiosas o filosóficas, afiliación sindical, información sobre la vida sexual, e ingresos económicos.
Si tu sistema maneja alguna de estas categorías — no solo en el sector salud: una plataforma de RR.HH. con datos de salud ocupacional, un sistema financiero con datos de ingresos, una app con datos de afiliación — la arquitectura debe reflejar ese nivel de exigencia desde el diseño, no agregarlo después como parche.
Lo que esto significa para la arquitectura del sistema.
Consentimiento registrado, no asumido. El sistema debe poder demostrar que el titular consintió el tratamiento de sus datos — un checkbox sin registro ni versión del texto legal aceptado no sirve como evidencia.
Control de accesos por rol. No todos los usuarios internos del sistema deben ver todos los datos. Un operador administrativo no necesita ver el historial clínico completo si su función no lo requiere.
Registro de auditoría. Quién accedió a qué dato sensible, cuándo y desde dónde. Es la evidencia que necesitas si alguna vez hay que demostrar que el acceso fue legítimo.
Cifrado en tránsito y en reposo. Los datos sensibles no deben viajar ni almacenarse en texto plano en ningún punto del sistema, incluidos respaldos.
Mecanismo para los derechos ARCO. El titular de los datos tiene derecho a pedir acceso, rectificación, cancelación u oposición al tratamiento de sus datos — el sistema necesita un flujo (aunque sea manual al inicio) para atender esas solicitudes.
¿Tu sistema maneja datos sensibles?
Cuéntanos qué datos maneja y te decimos qué nivel de arquitectura necesita.
En OXICARE DadeMedical (oxicareplatform.com), cada movimiento de insumos médicos entre proveedores, distribuidores y hospitales queda registrado con actor, fecha y estado — la misma lógica de auditoría que exige manejar datos sensibles de salud. No fue un módulo agregado al final: se diseñó como fundamento de la arquitectura desde el Discovery. El resto de requisitos que aplican al sector salud específicamente — más allá de la protección de datos — están en software para clínicas y empresas de salud en Perú.
Preguntas frecuentes.
01
¿Qué es la Ley 29733?
Es la Ley de Protección de Datos Personales de Perú, que regula cómo las empresas deben recolectar, almacenar, usar y proteger los datos personales de las personas — clientes, usuarios, empleados. Aplica a cualquier sistema que registre datos identificables: nombre, DNI, contacto, historial de compras, y con mayor exigencia a datos sensibles como salud o afiliación.
02
¿Qué se considera un dato sensible bajo la ley peruana?
La ley da un tratamiento reforzado a datos como salud, origen racial o étnico, ingresos económicos, opiniones políticas, convicciones religiosas, y datos biométricos, entre otros. Si tu sistema maneja alguno de estos, los requisitos de seguridad y consentimiento son más estrictos que para un dato personal común como un email.
03
¿Un sistema pequeño también tiene que cumplir la Ley 29733?
El tamaño del sistema no exime del cumplimiento — lo que importa es qué datos maneja. Un sistema chico que guarda datos de salud tiene las mismas obligaciones de fondo que uno grande: consentimiento informado, medidas de seguridad razonables y capacidad de responder a los derechos ARCO (acceso, rectificación, cancelación, oposición) del titular de los datos.
04
¿Qué medidas técnicas concretas ayudan a cumplir la ley?
Cifrado de datos sensibles en tránsito y en reposo, control de accesos por rol (que cada usuario vea solo lo que le corresponde), registro de auditoría (quién accedió a qué dato y cuándo), consentimiento explícito registrado en el sistema, y un mecanismo para que el titular pueda pedir acceso o eliminación de sus datos. Ninguna es exótica — son parte de una arquitectura de seguridad bien diseñada desde el inicio.
05
¿Construyen sistemas pensando en la Ley 29733 desde el diseño?
Sí, es parte del Discovery cuando el sistema maneja datos personales o sensibles — se diseña la arquitectura de accesos y auditoría desde el inicio, no como parche después. En OXICARE DadeMedical (oxicareplatform.com), cada movimiento entre proveedores, distribuidores y hospitales queda registrado con trazabilidad completa, exactamente el tipo de control que exige manejar información sensible del sector salud.
