La privacidad es poder: ¿tu sistema tiene el envoltorio abierto?

Dos paletas de caramelo, aparentemente iguales. Una está envuelta. La otra está descubierta, con moscas sobre la superficie. La diferencia salta a la vista: existe una barrera entre lo que tiene valor y el entorno.

La frase que acompaña esa idea es directa: la privacidad es poder.

Cuando llevo esa imagen al desarrollo de sistemas, pienso en formularios, currículums, fotos, registros de usuarios, credenciales e información de clientes. Todo lo que alguien entrega a una aplicación porque necesita resolver algo.

El problema es que, en el software, el envoltorio no aparece en la captura de pantalla.

Un panel bonito puede esconder permisos mal definidos. Una pantalla de inicio de sesión puede existir sin proteger adecuadamente los datos. Un botón que dice “eliminar” puede borrar una fila y dejar copias dispersas. Por eso, la privacidad debe formar parte del proyecto desde el principio.

El poder de poner límites

Piensa en tu dirección. Puedes facilitarla para recibir un paquete sin querer que esté disponible para cualquier visitante de un sitio web. Puedes entregar un currículum a una empresa sin desear que tu trayectoria profesional se convierta en una base de datos para fines que desconoces.

El contexto cambia el significado de compartir información.

Para mí, hablar de privacidad es discutir esos límites: qué información es necesaria, para qué finalidad, quién puede utilizarla y durante cuánto tiempo. La persona necesita entender qué ocurre con sus datos; quien construye el servicio debe poder explicar y sostener esas decisiones.

La LGPD, en su artículo 6, aborda principios como finalidad, necesidad, transparencia y seguridad. El artículo 46 también exige medidas de protección desde la concepción del producto o servicio.

Esto tiene una consecuencia práctica: se puede proteger muy bien una base de datos y, aun así, recopilar demasiada información. La seguridad y la privacidad deben avanzar juntas.

La pantalla era bonita. La contraseña era “admin123”

Al prestar apoyo a proyectos, me encontré con una situación cuya lógica podía resumirse así:

si contraseña == "admin123", entonces es administrador

Eso era lo que determinaba el acceso administrativo.

Este tipo de hallazgo explica por qué insisto tanto en mirar más allá de la interfaz. La aplicación puede parecer lista mientras una decisión esencial depende de una credencial fija en el código.

El MITRE CWE-798 describe precisamente el uso de credenciales integradas en el software. Tener un nombre técnico para la debilidad ayuda a reconocerla y a discutir su corrección con precisión.

Y sustituir aquella contraseña por una frase larguísima no resuelve, por sí solo, el diseño del control de acceso. Es necesario identificar a los usuarios, proteger la autenticación y establecer qué operaciones puede ejecutar cada identidad.

Ya he comparado este escenario con cambiar el escudo del Capitán América por una cometa de papel de seda: bonita, hecha con esmero, pero inadecuada para su función.

Esto se aplica al software producido con o sin inteligencia artificial. La responsabilidad de verificar el resultado sigue existiendo.

Quien está aprendiendo necesita orientación para reconocer esas capas. Cuando el proyecto empieza a recibir datos de otras personas, revisar estas decisiones pasa a formar parte de la entrega.

El currículum que no necesita convertirse en una base de datos

Una decisión que discutí recientemente para Pinheiral Digital fue la propuesta de un generador público de currículums: la persona rellena los campos, crea el documento y lo descarga en su propio dispositivo, sin necesidad de iniciar sesión y sin la intención de almacenar su currículum en el servicio.

El objetivo del proyecto es ayudar a alguien a producir un archivo útil.

A partir de ahí, cabe preguntarse si mantener una colección de currículums en el servidor aportaría algo necesario a esa entrega. Cada información guardada trae nuevas tareas: controlar el acceso, definir la retención, atender solicitudes y administrar copias.

La OWASP, en su guía de almacenamiento criptográfico, recomienda evitar el almacenamiento de información sensible cuando sea posible. Es una orientación que encaja muy bien con este diseño.

En algunos proyectos, una buena medida de protección consiste en no crear un archivo de información innecesario.

Sin embargo, hay una diferencia entre la intención de “no almacenar” y la implementación de esa promesa. Si los campos pasan por el servidor, entran en registros de errores o son capturados por una herramienta de análisis de uso, la información ya ha recorrido otros caminos.

Por eso, una arquitectura que genere el archivo en el navegador también debe revisar los scripts de terceros, la telemetría y las solicitudes de red. Rellenar los campos de forma local solo cumple la propuesta si el resto de la aplicación respeta esa decisión.

Este ejemplo sigue siendo una decisión de diseño que estoy discutiendo. Muestra cómo la privacidad puede orientar la arquitectura incluso antes de crear la primera tabla.

Guardar para siempre también es una decisión

En otra discusión de proyecto, relacionada con fotografías en un proceso de recepción, trabajábamos inicialmente con una propuesta de retención de 90 días. La orientación recibida durante la consultoría con Sebrae fue reducir ese plazo a 60 días.

El aprendizaje consistió en revisar la necesidad de conservar esa información y establecer un límite concreto.

Aquel plazo correspondía a aquel contexto. Sesenta días no son una regla general de la LGPD: la definición depende de la finalidad, de las obligaciones aplicables y de la justificación para conservar la información.

También es necesario transformar la decisión en un comportamiento del sistema. Una política puede prometer la eliminación, pero el proceso debe abarcar las copias pertinentes y establecer cómo tratar los backups, las exportaciones y las posibles obligaciones de conservación.

La orientación de la OWASP sobre logs incluye precauciones sobre retención y eliminación, además de advertir contra el registro directo de contraseñas, tokens e información personal sensible.

Es fácil cuidar el registro principal y olvidarse del archivo de depuración. La privacidad también vive en esos lugares poco fotogénicos.

El “envoltorio” debe funcionar en las solicitudes

En el trabajo con Oombe y las integraciones con marketplaces, el contexto de cada cuenta forma parte del problema que debemos resolver. Una acción implica a un vendedor, una cuenta conectada, determinados datos y permisos.

Imagina, por ejemplo, dos empresas que utilizan el mismo servicio. El usuario de una de ellas no debería poder consultar el pedido de la otra simplemente porque está autenticado.

Aquí es donde la distinción cobra importancia: la autenticación identifica quién ha entrado; la autorización determina qué puede hacer esa persona.

La OWASP recomienda conceder el mínimo privilegio necesario, denegar el acceso por defecto y verificar los permisos en cada solicitud. Las decisiones deben tomarse en una capa confiable del sistema.

Ocultar un botón en el navegador ayuda a organizar la experiencia. La protección real exige impedir también la operación correspondiente cuando la solicitud llega a la aplicación.

El mismo razonamiento se aplica a documentos, imágenes e informes. Si el archivo es privado, la ruta utilizada para descargarlo debe respetar esa condición.

En servicios con varias cuentas, comprobar esa separación debe formar parte de la entrega. Una prueba autorizada con dos cuentas de demostración ayuda a verificar si los límites definidos realmente existen.

Contraseñas, secretos y el archivo que quedó expuesto

Otro ejemplo que ya he comentado involucra credenciales escritas directamente en el código y archivos .env disponibles a través de la web.

Un .env puede formar parte de la configuración de una aplicación. La protección depende de cómo se almacena, de quién puede leerlo y de lo que publica el servidor.

La OWASP orienta la gestión de secretos con acceso restringido y precauciones durante todo el ciclo de vida de las credenciales. Si una clave quedó expuesta, retirar el archivo de la web debe ir acompañado de la revocación o sustitución del secreto comprometido. Las copias que alguien ya obtuvo no desaparecen por cortesía.

Las contraseñas de los usuarios requieren otro cuidado. Para verificarlas durante la autenticación, la OWASP recomienda funciones específicas de hashing, como Argon2id, con salt. Guardar la contraseña en texto plano o limitarse a aplicar un cifrado reversible no ofrece la protección recomendada para este uso.

Son problemas relacionados, pero diferentes: una credencial de integración debe gestionarse como un secreto; una contraseña de inicio de sesión necesita un almacenamiento adecuado para su verificación.

Una interfaz bonita no puede compensar ninguna de estas decisiones.

OWASP y MITRE ayudan a hacer mejores preguntas

Me gustan estas referencias porque permiten dejar atrás el “creo que es seguro” y discutir criterios verificables.

El OWASP Top 10:2025 presenta riesgos relevantes de las aplicaciones web. Para profundizar en la verificación, el OWASP ASVS reúne requisitos de seguridad que pueden orientar el desarrollo, la revisión y la contratación.

En el universo MITRE, conviene distinguir dos referencias:

Referencia	Para qué ayuda
CWE	Describir tipos de debilidad de software y hardware.
ATT&CK	Entender tácticas y técnicas de adversarios a partir de comportamientos observados.

Además de las credenciales hardcoded, el CWE-862 trata la ausencia de autorización. El CWE-359 describe la exposición de información personal privada a quienes no deberían recibirla.

Por su parte, ATT&CK ayuda a pensar en el comportamiento de un atacante y en la relación entre las distintas etapas de un ataque.

Estas referencias respaldan el trabajo técnico. La evidencia de que un producto está protegido debe aparecer en su diseño, su implementación, sus pruebas y su operación.

Para quien contrata, esto también cambia la conversación: conviene pedir demostraciones de los controles de acceso, de la protección de los datos y de la eliminación prevista. La respuesta debe ir más allá de “tiene inicio de sesión”.

¿Y cuando la inteligencia artificial entra en escena?

La IA puede ayudar a revisar un formulario, explicar una regla de autorización o sugerir escenarios de prueba. En mi opinión, utilizarla también exige prestar atención al material que le entregamos.

Antes de pegar una hoja de cálculo, un currículum o un registro de atención en una herramienta, conviene verificar qué datos son necesarios para la tarea y qué condiciones se aplican a ese servicio.

Muchas veces, un ejemplo ficticio conserva la estructura del problema. Para revisar una función que da formato al CPF, por ejemplo, necesitamos entender el formato y las reglas; una lista de documentos reales de ciudadanos añade una exposición evitable.

Durante el desarrollo, podemos pedir a la IA que explique dónde se valida un permiso, qué campos llegan a los logs y cómo se realiza la eliminación a través de la aplicación. Esas respuestas ayudan a orientar la revisión, pero deben comprobarse.

Me gusta la velocidad que ofrecen estas herramientas. Quiero que venga acompañada de la capacidad de entender lo que estamos poniendo en funcionamiento.

La persona que utiliza el servicio confiará sus datos al resultado de esa combinación.

Seis preguntas antes de poner el sistema en funcionamiento

Para convertir esta conversación en trabajo concreto, empezaría por estas preguntas:

1. ¿Necesitamos cada dato solicitado? Cada campo debe tener una finalidad comprensible y una necesidad justificable.
2. ¿Quién puede acceder a cada información? Conviene verificar los permisos por usuario, función, cuenta y recurso.
3. ¿Por dónde pasan los datos? Incluye APIs, herramientas de análisis, servicios de IA, logs y exportaciones.
4. ¿Hasta cuándo necesitamos conservarlos? Define la retención, la eliminación y las excepciones justificadas por la operación o por las obligaciones aplicables.
5. ¿Qué demuestra que los controles funcionan? Revisa la configuración, el código y las pruebas autorizadas, incluidos los intentos de acceso entre cuentas de demostración.
6. ¿Quién responde cuando algo se sale de lo previsto? Define responsables y un proceso para investigar problemas, contener la exposición y atender a las personas afectadas.

Estas preguntas sirven para un pequeño formulario y pueden profundizarse según la complejidad del servicio. El cuidado debe acompañar a los datos y a los riesgos involucrados.

Vuelvo, entonces, a las paletas de caramelo.

El envoltorio hace visible una diferencia. En los sistemas, debemos construir esa diferencia con decisiones que no siempre aparecen en la presentación comercial: recopilar menos, limitar el acceso, proteger las credenciales y cumplir los plazos de conservación.

La privacidad es poder porque establece límites sobre el uso de la información acerca de nosotros.

Para quienes desarrollamos, esto significa reconocer la responsabilidad que llega con cada registro. La persona vino a resolver un problema. Nos corresponde entregar una solución que merezca su confianza.