En casi todas las organizaciones hay un momento, justo cuando el proyecto ya está listo para salir, en que alguien dice: “Después vemos el tema de privacidad.” Ese “después” suele parecer razonable. El problema es que casi siempre llega tarde. Y cuando llega tarde, trae retrabajo, ajustes contractuales urgentes, discusiones incómodas entre áreas y, en el peor escenario, exposición innecesaria.
La Ley 21.719 cambia esa lógica. Introduce el principio de protección de datos desde el diseño y por defecto. Puede sonar conceptual, pero en realidad es una instrucción operativa muy concreta: los sistemas, productos, campañas y automatizaciones deben nacer tratando solo los datos estrictamente necesarios, con accesos limitados y con una lógica de conservación definida desde el inicio. No es un complemento. Es parte de la arquitectura.
“Por defecto” significa decidir antes, no corregir después
Cuando la ley exige que, por defecto, solo se traten los datos estrictamente necesarios, considerando número de datos, extensión del tratamiento, plazo de conservación y accesibilidad, está hablando directamente al diseño técnico y organizacional.
Esto implica tres decisiones estructurales.
Primero, minimización real. No capturar información “por si acaso”. Cada dato debe tener una finalidad clara y una base jurídica identificable.
Segundo, control de accesos bajo criterio de privilegio mínimo. El acceso no se otorga por comodidad ni por jerarquía, sino por necesidad funcional.
Tercero, retención definida desde el inicio. No existe el “guardemos y después vemos”. Debe existir una regla clara de conservación y un mecanismo que ejecute el borrado o anonimización.
Eso es privacidad por defecto: sistemas configurados para exponer lo mínimo necesario, no lo máximo posible.
Lo que mostró la experiencia europea
Con la entrada en vigor del Reglamento General de Protección de Datos, muchas empresas europeas descubrieron algo que no estaba en los titulares: el dato sin gobernanza se vuelve caro.
Al tener que justificar tratamientos, documentar bases jurídicas y demostrar cumplimiento, conservar información innecesaria dejó de ser una práctica neutra. Más datos implicaban más riesgo en caso de brecha, más obligaciones de seguridad, más complejidad contractual y mayor exposición ante la autoridad.
El resultado fue práctico: reducción de almacenamiento, optimización de procesamiento y depuración de bases históricas. No fue un cambio moral. Fue un ajuste de gestión. Chile puede aprender de esa experiencia sin pasar por el mismo nivel de fricción.
Privacidad por diseño no es del abogado
Uno de los errores más frecuentes es delegar este principio exclusivamente al área legal. Pero privacidad por diseño no se implementa en un contrato; se implementa en decisiones técnicas y de negocio.
Cuando se diseña un formulario, la pregunta relevante no es si el campo “podría servir”, sino si es estrictamente necesario para la finalidad definida.
Cuando se configura un sistema, la pregunta no es quién podría necesitar acceso en algún escenario hipotético, sino quién lo necesita hoy para cumplir su función.
Cuando se desarrolla una automatización o se entrena un modelo, la pregunta no es cuánto tiempo conviene conservar los datos, sino cuánto tiempo es legítimo y defendible mantenerlos.
Si esas preguntas se hacen al final, el costo es alto. Si se hacen al inicio, el impacto es mínimo.
El privacy gate: institucionalizar la pausa inteligente
La forma madura de aplicar este principio no es confiar en la memoria o en la buena voluntad del equipo. Es establecer un mecanismo previo a la salida a producción: un privacy gate.
Antes de lanzar un proyecto, debería existir una revisión estructurada que valide cinco aspectos esenciales: los datos que se capturan y su justificación; la configuración por defecto de accesos y permisos; la trazabilidad interna mediante roles y logs; la política de retención y su ejecución efectiva; y la participación de terceros o transferencias que deban documentarse.
No es un freno a la innovación. Es un filtro de calidad. Un privacy gate bien aplicado genera evidencia auditable: justificación por campo, matrices que vinculan datos con finalidad y base jurídica, configuraciones documentadas, registros de acceso activos y mecanismos automáticos de borrado. Eso es gobernanza preventiva.
El beneficio real: menos correcciones, menos crisis
Aplicar privacidad desde el diseño no es solo cumplir con la ley. Es reducir costos ocultos. Es evitar rediseñar campañas porque la base jurídica era débil. Es prevenir renegociaciones contractuales cuando el flujo de datos no estaba claro. Es limitar el impacto de una brecha porque los accesos y las retenciones estaban bien definidos.
En Europa, muchas organizaciones comprendieron que el verdadero costo no era implementar el estándar, sino corregir tarde.
Diciembre de 2026 puede parecer una referencia lejana. Pero la cultura de diseño no se instala en el último trimestre. Si los proyectos actuales no incorporan estos criterios, la organización llegará a esa fecha con capas acumuladas de riesgo y complejidad.
Diseñar hoy para minimizar mañana
Privacidad por diseño no es una restricción a la innovación. Es una forma más sofisticada de innovar. Obliga a preguntarse qué datos realmente generan valor y cuáles solo aumentan exposición.
En un entorno regulatorio que eleva el estándar y que contará con herramientas reales de fiscalización, diseñar sistemas que acumulen información sin límite no es ambición; es vulnerabilidad.
La cuestión ya no es si este principio debe aplicarse. La cuestión es si estamos dispuestos a seguir lanzando productos y procesos sin integrar, desde el inicio, la lógica de minimización, control y retención.
Porque minimizar no significa perder información. Significa operar con criterio. Y operar con criterio es, finalmente, lo que diferencia a una organización que reacciona de una que gobierna.
