Si alguien me hubiera dicho en 2009 que una tesis sobre software libre terminaría en la responsabilidad de liderar la protección del dato en una organización pública gigante, no le habría creído. Mirando hacia atrás, el recorrido no solo fue coherente: fue directo.
La tesis de 2009 y el camino a la CDPO
Investigué software libre porque era el punto exacto donde el derecho ya no alcanzaba con la doctrina y necesitaba asomarse al código. Esa dislocación —leyes que clasifican fenómenos que todavía no saben nombrar— me formó en el puente que, años después, ocupa el centro de lo que hago todos los días.
Nadie estudiaba "privacidad por diseño" en aquella época, pero ya estaba claro que el jurista útil era el que sabía leer un contrato, un archivo de configuración y una política de licencias al mismo tiempo. Esa capacidad de alternar entre el texto legal y el texto técnico es, literalmente, el oficio de una CDPO.
El software como activo de información
En la tesis, el objeto de regulación era el programa: la licencia que condiciona su uso, su copia, su modificación. Hoy, el objeto de regulación se desplazó un piso más abajo: los datos que el programa procesa. Y el aprendizaje central de la gestión de licencias se mantuvo intacto: un activo que no está inventariado no se puede gobernar.
Sostengo que controlar el software y controlar el dato son la misma disciplina con dos capas. Saber qué se instala, con qué contrato y quién lo aprobó es exactamente la misma pregunta que saber qué datos se tratan, con qué base legal y para quién se ponen a disposición. La lista de ingredientes del primer artículo de este blog —qué se usa, para qué y bajo qué condiciones— es también la definición de un registro de tratamientos.
Privacidad por diseño como evolución del copyleft
El copyleft fue un acto de imaginación jurídica: el autor de software condicionaba las obras futuras —las copias, las modificaciones, los usos— escribiendo las condiciones antes de que el conflicto existiera. La privacidad por diseño es exactamente la misma jugada, aplicada al dato: anticipar los usos, los plazos y los límites en la arquitectura del producto, en lugar de discutirlos después de que ocurrieron.
Esa continuidad me parece la mejor manera de explicar por qué una abogada criada entre licencias libres terminó dirigiendo protección de datos. La pregunta "¿qué condiciones le pongo a lo que otro va a usar?" es una sola, ya sea sobre una biblioteca de código o sobre un padrón de legitimados.
Lo que cambió y lo que no
- Cambió el activo crítico: el dato reemplazó al programa como el objeto que concentra el poder, el riesgo y la regulación.
- Cambió la escala: una licencia se audita con un inventario; la protección del dato se juega en millones de registros y en terceros con los que compartimos infraestructura.
- No cambió la necesidad de reglas claras: ni el código ni el dato se gobiernan solos; ambos exigen documentación, controles y responsables.
- No cambió la vocación de anticiparse: el que gobierna lo que todavía no está regulado —software libre en 2009, inteligencia artificial hoy— corre unos años de ventaja.
La lista podría resumirse en una fórmula: cambió la materia, no el método.
Conclusión del recorrido
Mi trayectoria profesional no es una sucesión de especialidades distintas: es la misma pregunta hecha cada vez con más responsabilidad. ¿Quién decide, con qué reglas y ante quién rinde cuentas el artefacto tecnológico que une a la organización con las personas que la usan?
En 2009 respondí con una tesis sobre licencias. Hoy respondo con un programa de gobernanza de la información. Si el derecho tecnológico tiene una frase de futuro, es esta: cada activo —código, dato, modelo— necesita un dueño, un contrato y una rendición de cuentas.
Cambió el activo, no el método: se gobierna con inventario, reglas claras y sobre todo antes de que exista el conflicto.