Ley de protección de datos personales: guía para desarrolladores

Si tu sistema recibe un DNI, lo consulta y guarda el nombre que vuelve, ya estás tratando datos personales. No importa que sea un checkout, un formulario de registro o un ERP interno: la Ley 29733, Ley de Protección de Datos Personales, aplica a ese flujo.

Muchos desarrolladores creen que esto es tema de abogados. En la práctica, la ley define cómo diseñas el formulario, qué columnas tiene tu tabla de clientes, qué escribes en los logs y cuánto tiempo conservas cada registro. Decisiones técnicas, no solo legales.

En este artículo vas a ver qué regula la ley, cuáles son sus principios, qué significan para un sistema que consulta el DNI y qué prácticas concretas puedes aplicar desde hoy. No vamos a citar artículos ni montos de multas: para eso está el texto oficial y tu asesor legal.

---

Qué regula la Ley 29733

La Ley 29733 protege los datos personales de las personas naturales en el Perú. Su autoridad de control es la Autoridad Nacional de Protección de Datos Personales, que depende del Ministerio de Justicia y Derechos Humanos. La ley se complementa con un reglamento que detalla obligaciones y procedimientos.

Un dato personal es cualquier información sobre una persona natural identificada o identificable. El número de DNI es un dato personal. El nombre completo asociado a ese DNI también. La combinación de ambos, con más razón.

Hay una categoría más delicada: los datos sensibles, como la información de salud, los datos biométricos, el origen étnico o la afiliación política o sindical. Su tratamiento tiene reglas más estrictas. Una consulta de DNI normal no devuelve datos sensibles, pero si tu sistema los cruza con otros (por ejemplo, con un historial médico), entras en ese terreno.

Un banco de datos personales es cualquier conjunto organizado de datos personales. Tu tabla clientes con DNI y nombres es un banco de datos. Tu empresa es el titular de ese banco, y quien lo procesa por encargo tuyo (un proveedor de hosting, por ejemplo) es un encargado de tratamiento.

Los principios que afectan a tu código

La ley se organiza alrededor de principios. Cuatro de ellos tocan directamente tus decisiones de diseño.

Consentimiento

Para tratar datos personales necesitas, como regla general, el consentimiento del titular. La ley exige que sea libre, previo, expreso, inequívoco e informado. Traducido a interfaz: una casilla que la persona marca por su cuenta, no una casilla marcada por defecto ni un consentimiento escondido en los términos.

Existen situaciones en las que no se requiere consentimiento, como cuando los datos son necesarios para cumplir una obligación legal o para ejecutar una relación contractual con el titular. Emitir una boleta de venta con el DNI del comprador cuando el monto llega a S/ 700 es un ejemplo de obligación legal. Qué base aplica en cada flujo de tu sistema es algo que conviene definir con tu asesor.

Finalidad

Los datos se recogen para una finalidad determinada, explícita y lícita, y no pueden usarse para otra incompatible. Si pediste el DNI para emitir el comprobante, no puedes usarlo después para una campaña de marketing sin una base distinta. En tu sistema esto se traduce en etiquetar para qué se recogió cada dato y respetar esa etiqueta.

Proporcionalidad

Solo debes tratar los datos adecuados, relevantes y no excesivos para la finalidad. Si tu proceso necesita el nombre para la boleta, no guardes además la fecha de nacimiento, el estado civil o la dirección "por si acaso". Cada columna de más es un riesgo de más.

Seguridad

El titular del banco debe adoptar medidas técnicas, organizativas y legales para evitar la alteración, pérdida, acceso o tratamiento no autorizado. Es el principio más cercano a la ingeniería: cifrado, control de acceso, registro de accesos, respaldos y gestión de incidentes.

Hay más principios (legalidad, calidad, disposición de recurso, nivel de protección adecuado). Este último importa si tu base de datos vive en un servidor fuera del Perú: la transferencia internacional de datos tiene reglas propias. Revisa la fuente oficial antes de elegir región en tu proveedor de nube.

Qué significa para un sistema que consulta DNI

Veamos tres escenarios típicos y cómo encaja cada uno.

Checkout o punto de venta. El cliente ingresa su DNI, el sistema consulta la API de DNI de endpoint.pe y rellena nombres y apellidos para la boleta. La finalidad es emitir el comprobante y cumplir con SUNAT. Lo que guardas es lo que el comprobante requiere, y lo conservas el tiempo que la normativa tributaria exige para esos documentos. Igual tienes que informar a la persona qué haces con sus datos.

Registro o verificación de identidad. Un usuario se registra en tu plataforma y validas que el DNI corresponde al nombre que escribió. Aquí la base suele ser el consentimiento o la ejecución del contrato de servicio. Si solo necesitas verificar, no tienes por qué almacenar la respuesta completa: compara y descarta.

Enriquecimiento masivo. Alguien propone "pasar una lista de DNI por la API para saber quiénes son". Si esas personas no tienen relación contigo y no hay finalidad legítima declarada, no lo hagas. Que técnicamente sea posible no lo vuelve lícito.

En todos los casos, el titular de los datos tiene derechos que tu sistema debe poder atender: acceso (qué datos tienes sobre él), rectificación (corregirlos), cancelación (borrarlos) y oposición (dejar de tratarlos). Se los conoce como derechos ARCO. Si no puedes exportar, corregir o eliminar los datos de una persona concreta, tienes una deuda técnica legal.

La ley también exige inscribir los bancos de datos personales ante la Autoridad. El procedimiento y sus condiciones están en la fuente oficial; aquí basta con que sepas que tu tabla de clientes probablemente debe estar registrada.

Buenas prácticas de diseño y código

Lo que sigue es una lista de hábitos que reducen riesgo sin frenar el producto.

1. Minimiza desde el esquema. Antes de crear una columna, pregúntate qué finalidad la justifica. Si no hay respuesta, no la crees.
2. Define retención. Cada tabla con datos personales debería tener una política: cuánto tiempo se guarda y qué pasa después (borrado o anonimización). Los comprobantes tienen sus propios plazos de conservación tributaria; respétalos, pero no los uses como excusa para guardar todo para siempre.
3. Cifra en tránsito y en reposo. HTTPS en toda comunicación, discos y respaldos cifrados, y cifrado adicional de columnas especialmente sensibles.
4. Controla el acceso por rol. No todos los usuarios de tu sistema necesitan ver DNI completos. Enmascara en pantalla cuando no haga falta el dato entero.
5. Mantén los logs limpios. Un DNI o un nombre en un log de aplicación es una copia sin control. Registra identificadores internos y enmascara el resto.
6. Trata la caché como un banco de datos más. Si guardas respuestas de consultas de DNI para ahorrar llamadas, aplícale las mismas reglas: finalidad, cifrado, tiempo de vida. En caché de consultas RUC y DNI vemos tiempos de vida razonables por tipo de dato.
7. Nunca consultes desde el navegador. El token de la API vive en el backend. Además de seguridad, esto te permite controlar y auditar cada consulta. Más detalle en seguridad de tokens API.
8. Formaliza a tus proveedores. Hosting, correo transaccional, API de datos: cada uno que procese datos por tu cuenta debería tener un contrato que fije sus obligaciones.
9. Ten un plan de incidentes. Define quién hace qué si se filtra la base. La normativa contempla obligaciones ante incidentes de seguridad; revisa la fuente oficial para conocerlas.

Un ejemplo de backend que aplica varios de estos puntos: valida el formato, consulta la API, devuelve solo lo que el formulario necesita y no persiste la respuesta.

// Backend (Node + Express). El token nunca llega al navegador.
app.post("/api/identidad", async (req, res) => {
  const dni = String(req.body.dni ?? "").trim();
  if (!/^\d{8}$/.test(dni)) {
    return res.status(400).json({ error: "dni_invalido" });
  }

  const r = await fetch(`https://api.endpoint.pe/v1/dni/${dni}`, {
    headers: { Authorization: `Bearer ${process.env.ENDPOINT_TOKEN}` },
  });

  if (r.status === 404) {
    return res.status(404).json({ error: "not_found" });
  }
  if (!r.ok) {
    return res.status(502).json({ error: "consulta_fallida" });
  }

  const { data } = await r.json();

  // Log sin datos personales: solo el DNI enmascarado
  logger.info(`consulta de identidad ****${dni.slice(4)}`);

  // Solo lo necesario para el formulario, sin guardar nada aquí
  res.json({
    nombres: data.nombres,
    apellidos: `${data.apellido_paterno} ${data.apellido_materno}`,
  });
});

Con el DNI de ejemplo 12345678 (es un número ficticio para ilustrar), el formulario recibiría JUAN CARLOS y PÉREZ QUISPE. Si decides guardar esos datos, hazlo en el paso siguiente, cuando la persona confirme y exista una finalidad concreta, no en el endpoint de consulta.

La política de privacidad y el formulario

La política de privacidad no es un trámite: es el documento donde cumples el deber de informar. Como mínimo debería decir quién es el titular del banco de datos, qué datos recoge, para qué, con quién los comparte, cuánto tiempo los conserva, si los transfiere fuera del país y cómo ejercer los derechos ARCO.

En el formulario, acompaña el campo de DNI con una frase corta ("Usamos tu DNI para emitir tu comprobante de pago") y un enlace a la política completa. Si además quieres enviar promociones, pide un consentimiento separado, con su propia casilla, desmarcada por defecto.

Guarda evidencia del consentimiento: fecha y hora, versión de la política aceptada y, si es viable, el origen de la petición. Cuando alguien pregunte "¿cuándo acepté esto?", vas a tener la respuesta.

Si todavía no tienes claro qué devuelve una consulta de DNI y qué no, lee primero qué es el DNI y qué datos contiene. Y si lo que buscas es la parte técnica de la validación, está en cómo validar un DNI en tu sistema.

En resumen

• Un DNI y un nombre son datos personales; tu tabla de clientes es un banco de datos y tu empresa es su titular.
• Consentimiento, finalidad, proporcionalidad y seguridad son los principios que más afectan a tu diseño.
• Recoge solo lo necesario, define cuánto tiempo lo guardas y cifra lo que almacenas.
• Consulta siempre desde el backend, enmascara en logs y pantallas, y trata la caché como otra base de datos personales.
• Tu sistema debe poder exportar, corregir y borrar los datos de una persona concreta.
• Informa con una política de privacidad clara y guarda evidencia del consentimiento.

Preguntas frecuentes

¿Es legal consultar un DNI por API?

Sí, siempre que exista una finalidad lícita y determinada, como emitir un comprobante o verificar la identidad de tu propio cliente. Lo que vuelve (nombres y apellidos) sigue siendo dato personal y debe tratarse como tal. endpoint.pe entrega esos datos desde fuentes oficiales; lo que hagas con ellos es tu responsabilidad.

¿Necesito consentimiento para pedir el DNI en una boleta?

Cuando el monto llega a S/ 700, consignar el DNI del comprador es una obligación tributaria, y la ley contempla el cumplimiento de obligaciones legales como base para tratar datos sin consentimiento. Aun así, tienes que informar a la persona qué haces con su dato. Para montos menores o para otros usos, revisa con tu asesor qué base aplica.

¿Puedo guardar en caché las respuestas de la API?

Sí, pero esa caché es un banco de datos personales más. Dale una finalidad (evitar consultas repetidas), un tiempo de vida razonable, cifrado y control de acceso. Y borra lo que ya no necesitas.

¿Qué pasa si mi base de datos está en un servidor fuera del Perú?

Eso se considera una transferencia internacional de datos y tiene reglas propias, como garantizar un nivel de protección adecuado e informar al titular. Antes de elegir región en tu proveedor de nube, revisa la fuente oficial o consulta con tu asesor legal.