Controlador y operador según la LGPD: comprenda las responsabilidades

El mercado de la inteligencia artificial y la computación en la nube se expande rápidamente. Cada semana surge una nueva herramienta, un nuevo modelo, un nuevo producto innovador en cuestión de horas. Pero tras esta agilidad técnica se esconde un marco legal igualmente complejo que, en la práctica, determina si una empresa sobrevive a un incidente de seguridad o se convierte en el próximo caso sancionado por la Autoridad Nacional de Protección de Datos (ANPD).

Ese fue precisamente el tema central de la conversación en el Builders, que reunió a la Dra. Renata Barros, directora legal de cumplimiento y gobernanza en Skyone, y a Henrique Fabretti, socio del bufete Opice Blum Advogados. La conversación comenzó con una guía publicada recientemente por la CNIL (la autoridad francesa de protección de datos) sobre la asignación de funciones entre las partes involucradas en la gestión de servicios en la nube. A partir de ahí, la conversación exploró aspectos fundamentales que toda empresa que maneja datos personales, IA o computación en la nube debe dominar: quién es responsable de qué y por qué.

El punto de partida: controlador y operador no son lo mismo

Tanto la LGPD brasileña como el RGPD europeo, que sirvió de inspiración para la ley brasileña, dividen las responsabilidades del tratamiento de datos personales entre dos figuras centrales. Como explicó Henrique Fabretti, esta división no es burocrática, sino una cuestión de equidad regulatoria:

La legislación decidió diferenciar las funciones porque hay partes con mayor influencia y poder de decisión sobre los datos, y partes con menos poder, y no sería justo aplicar el mismo criterio a ambas.

El responsable del tratamiento es quien toma las decisiones pertinentes: define la finalidad del tratamiento, decide qué hacer con los datos, cuánto tiempo conservarlos y cuándo eliminarlos. El operador (el encargado del tratamiento según el RGPD) solo ejecuta instrucciones. Trata los datos por cuenta de un tercero, sin autonomía para decidir sobre la finalidad de dicho tratamiento.

Según Fabretti, la trampa reside en que esta distinción «parece sencilla a primera vista», pero rara vez es binaria. Cita el ejemplo de Skyone: «a menudo, en la gran mayoría de los casos, una empresa no es solo operadora ni solo controladora en la misma relación». Una empresa puede ser controladora en una parte de la operación y operadora en otra, dentro del mismo contrato y del mismo producto. Por lo tanto, el primer paso para cualquier empresa que gestione datos personales es: definir, paso a paso, el rol que desempeña en cada etapa de la operación.

También te puede interesar: ¿La IA generativa utiliza datos de la empresa? Riesgos, LGPD (Ley General de Protección de Datos de Brasil) y cómo proteger la información corporativa.

El error más común: confundir a la persona que posee los datos con la persona que los controla

Uno de los momentos más instructivos de la conversación fue cuando los ponentes propusieron un ejemplo práctico: un desarrollador crea un CRM utilizando IA —la llamada «programación intuitiva» — y este CRM almacena una base de datos de clientes. ¿Quién tiene el control en esta relación: quien desarrolló el CRM o quien lo utiliza?

La respuesta de la Dra. Renata aclara una idea errónea extremadamente común en el mercado tecnológico:

En otras palabras, la mayor carga regulatoria recae sobre quienes utilizan la herramienta y deciden el propósito de los datos, no sobre quienes construyeron la infraestructura tecnológica. Como señaló André Senna durante el programa, esto resulta contraintuitivo: «a primera vista, se podría pensar lo contrario». La tendencia natural es asumir que quien posee la complejidad técnica (el proveedor de la nube, el desarrollador de la plataforma) es automáticamente responsable. Pero no es así. Según Renata, el proveedor «define el "cómo" técnicamente; es la base sobre la que se ejecuta la operación. Pero quien define el negocio es el responsable, y eso conlleva la mayor responsabilidad».

Es precisamente esta zona gris la que la guía de la CNIL pretende eliminar: el hecho de que un proveedor tenga una infraestructura tecnológica más sofisticada no lo transforma automáticamente en un responsable del tratamiento ni lo convierte en el "propietario de los datos".

Cuando la teoría se convierte en realidad: el caso de la aplicación "vibe codado"

La discusión dejó de ser abstracta cuando Fabretti mencionó un caso concreto y reciente: un proceso sancionador de la ANPD (Autoridad Nacional de Protección de Datos), hecho público la semana anterior a la grabación, que involucraba una plataforma de citas dirigida a la comunidad LGBTQ+ desarrollada mediante codificación Vibe. La plataforma experimentó un crecimiento explosivo, alcanzando más de 30.000 usuarios en poco tiempo, y, debido a una falla en la configuración de seguridad, expuso los datos de todos los usuarios recién llegados.

La cuestión que planteó Fabretti sobre la gravedad del caso va mucho más allá del importe de la multa:

Este ejemplo ilustra un principio fundamental de la LGPD (Ley General de Protección de Datos de Brasil) que la Dra. Renata recalcó a lo largo del episodio: se trata de una legislación basada en el riesgo, no en reglas binarias. No existe una respuesta simple de "puede o no puede"; hay un espectro de exposición, y el nivel de cuidado requerido es proporcional a la gravedad del daño potencial. Los datos de salud, la orientación sexual u otra información sensible requieren un nivel de diligencia debida mucho mayor que, por ejemplo, una base de datos de nombres y CPF (número de identificación fiscal brasileño).

Lea también: Vibe Coding: IA, productividad y el papel de las personas en los negocios

Seguridad en la nube frente a seguridad en la nube: la distinción que previene (o crea) incidentes

Uno de los conceptos más operativos que se abordan en el episodio es la diferencia entre la seguridad en la nube (responsabilidad del proveedor: infraestructura física, actualizaciones del sistema operativo, control de acceso físico al centro de datos) y la seguridad en la nube (responsabilidad del usuario: gestión de acceso, configuración correcta de las herramientas, revocación de credenciales).

Según Fabretti, que trabaja directamente en la respuesta a incidentes en la oficina de Opice Blum, la gran mayoría de los problemas no se deben a fallos de los proveedores:

La Dra. Renata resumió esta distinción con una analogía que vale la pena recordar:

Esta metáfora ilustra directamente por qué muchas empresas no dan en el clavo al invertir mucho en infraestructura sin invertir de igual manera en la gobernanza del acceso, la rotación de credenciales y la capacitación del equipo.

¿Cómo evalúa la ANPD (Autoridad Nacional de Protección de Datos de Brasil) la responsabilidad en casos de causalidad difícil?

Uno de los segmentos más interesantes del episodio exploró un escenario deliberadamente extremo: un ataque mediante un periférico físico (un teclado comprometido que instala malware al conectarse), prácticamente sin dejar rastro. ¿Quién es el responsable?

La respuesta de Fabretti provocó un cambio importante de perspectiva sobre cómo el regulador brasileño analiza realmente estos casos:

En la práctica, esto significa que la existencia de un incidente no es, por sí sola, prueba de negligencia. Lo que la autoridad evalúa es la diferencia entre dos posibles escenarios: una empresa que capacitó a su personal, monitoreó la red, mantuvo registros y realizó análisis forenses después del incidente; frente a una empresa que carecía por completo de estas medidas y solo descubrió el problema porque un tercero se lo notificó. En el caso de la aplicación Vibe Codado, según Fabretti, la postura de la ANPD fue clara: «No tomaron ninguna de las de seguridad, y por eso ocurrió el incidente, y por eso están siendo sancionados».

La conclusión práctica, resumida por Renata, es que la gobernanza no es burocracia; es la materia prima para la defensa legal futura: “A veces el departamento legal es un poco molesto, pidiéndote que documentes esto, que hagas aquello. Pero para contar esa historia más adelante, tiene que ser convincente. No sirve de nada solo contarla; hay que mostrar las pruebas”

Privacidad desde el diseño y la nueva frontera: Cumplimiento desde el diseño

Un concepto recurrente en la conversación es la privacidad desde el diseño. La idea es que las soluciones tecnológicas se diseñen desde el principio para incorporar medidas de protección de datos, en lugar de añadirlas posteriormente. Según la Dra. Renata:

En el episodio, los presentadores también plantearon un escenario realista: ¿qué sucede si el desarrollador sigue estrictamente las mejores prácticas de Privacidad desde el Diseño y Seguridad desde el Diseño y aun así sufre un incidente? La respuesta de Fabretti equilibra la honestidad legal con el pragmatismo:

Además del riesgo, existe un segundo elemento: la buena fe. Fabretti subraya que demostrar la buena fe no es solo un principio de la LGPD (Ley General de Protección de Datos de Brasil), sino un factor concreto en el cálculo de las multas impuestas por la ANPD (Autoridad Nacional de Protección de Datos), capaz de reducir la sanción. Por lo tanto, la documentación y las pruebas no son solo una defensa: son factores atenuantes.

Conozca las mejores prácticas de desarrollo seguro para su empresa

La regla de oro: "Si no se puede hacer, decir o demostrar, no lo hagas"

Al final del episodio, la Dra. Renata resumió sus recomendaciones para particulares y empresas en una frase que encapsula toda la filosofía de gestión de riesgos tratada en el programa:

Henrique Fabretti añadió una recomendación de prueba de estrés aplicable a cualquier producto digital que maneje datos personales:

Un mensaje para quienes desarrollan proyectos con inteligencia artificial hoy en día

La conversación proporciona una hoja de ruta clara para cualquier fundador, desarrollador o empresa que esté "programando con la técnica vibe" un nuevo producto de IA o en la nube:

1. Define claramente tus funciones —controlador u operador— en cada relación de procesamiento de datos, antes de que un incidente obligue a realizar este análisis.
2. Documente la división de responsabilidades en el contrato, distinguiendo claramente entre seguridad en la nube y seguridad en la nube.
3. Implemente la gobernanza de acceso con el mismo rigor con el que invierte en la infraestructura: los tokens, las credenciales y los permisos de terceros son el punto de fallo más común.
4. Adopte la privacidad desde el diseño y el cumplimiento normativo desde el diseño desde la concepción del producto, no como una idea posterior.
5. Documente y aporte pruebas de todo. Ante un organismo regulador, la buena fe y la diligencia demostrada marcan una verdadera diferencia a la hora de determinar la responsabilidad.

Como resumió Robson Del Fiol durante el programa, la exposición a este tipo de riesgo no comienza con el lanzamiento del producto, sino en la fase de ideación. Y ese es precisamente el punto ciego de muchas empresas digitales actuales: la tecnología avanza en semanas, pero las consecuencias legales de una decisión mal informada pueden perseguir a la empresa durante años.

¿Quieres escuchar la conversación completa, con todos los ejemplos, analogías y trucos de productividad de los invitados? Escucha el episodio completo del Builders, con la Dra. Renata (Skyone) y Henrique Fabretti (Opice Blum Advogados), ya disponible en Spotify.

Escrito por Skyone