Controlador e operador na LGPD: entenda as responsabilidades

O mercado de inteligência artificial e computação em nuvem está em expansão acelerada. Toda semana surge uma nova ferramenta, um novo modelo, um novo produto “vibe coded” em poucas horas. Mas por trás dessa agilidade técnica existe um arcabouço jurídico igualmente complexo, e que, na prática, decide se uma empresa sobrevive a um incidente de segurança ou se torna o próximo caso sancionado pela Autoridade Nacional de Proteção de Dados (ANPD).

Foi exatamente esse o eixo da conversa no podcast Builders, que reuniu Dra. Renata Barros, diretora jurídica, compliance e governança da Skyone, e Henrique Fabretti, sócio do escritório Opice Blum Advogados. O gancho da discussão foi um guia recém-publicado pela CNIL (a autoridade francesa de proteção de dados) sobre a alocação de papéis entre as partes envolvidas na gestão de serviços de nuvem. A partir daí, a conversa percorreu um território que toda empresa que lida com dados pessoais, IA ou cloud precisa dominar: quem é responsável pelo quê, e por quê.

O ponto de partida: controlador e operador não são a mesma coisa

Tanto a LGPD brasileira quanto o GDPR europeu, que serviu de inspiração para a lei brasileira, dividem as responsabilidades sobre o tratamento de dados pessoais em duas figuras centrais. Como explicou Henrique Fabretti, essa divisão não é burocrática, é uma questão de justiça regulatória:

A legislação resolveu dividir papéis porque há partes com mais ingerência e poder decisório sobre os dados, e partes com menos poder, e não seria justo aplicar a mesma régua para as duas.

O controlador é quem toma as decisões relevantes: define a finalidade do tratamento, decide o que fazer com os dados, por quanto tempo retê-los, quando excluí-los. O operador (o processor do GDPR) apenas executa instruções. Ele trata dados por conta e ordem de outra parte, sem autonomia decisória sobre a finalidade daquele tratamento.

A armadilha, segundo Fabretti, é que essa distinção “parece simples num primeiro momento”, mas raramente é binária. Ele cita o próprio exemplo da Skyone: “muitas vezes, na grande maioria das vezes, uma empresa não é só operadora ou só controladora numa mesma relação”. Uma companhia pode ser controladora em uma parte da operação e operadora em outra, dentro do mesmo contrato, do mesmo produto. Por isso, o primeiro exercício de qualquer negócio que trata dados pessoais é: mapear, pedaço por pedaço da operação, qual papel você exerce ali.

Você também pode se interessar: IA generativa usa dados da empresa? Riscos, LGPD e como proteger informações corporativas

O erro mais comum: confundir quem guarda o dado com quem manda no dado

Um dos momentos mais didáticos da conversa foi quando os apresentadores propuseram um exemplo prático: um desenvolvedor cria um CRM usando IA — o chamado “vibe coding” — e esse CRM armazena um banco de dados de clientes. Quem é o controlador nessa relação: quem desenvolveu o CRM ou quem o utiliza?

A resposta da Dra. Renata desfaz uma confusão extremamente comum no mercado de tecnologia:

Ou seja: a maior carga regulatória recai sobre quem usa a ferramenta e decide a finalidade do dado, não sobre quem construiu a infraestrutura tecnológica. Como observou André Senna durante o programa, isso é contra intuitivo: “à primeira luz, você pode pensar o oposto”. A tendência natural é achar que quem detém a complexidade técnica (o provedor de nuvem, o desenvolvedor da plataforma) é automaticamente o responsável. Não é. Segundo Renata, o provedor “define o ‘como’ tecnicamente, é o trilho onde roda a operação. Mas quem define negócio é controlador, e é isso que traz a maior responsabilidade.”

É precisamente essa zona cinzenta que o guidance da CNIL busca eliminar: o fato de um provedor ter infraestrutura tecnológica mais sofisticada não o transforma automaticamente em controlador nem o torna “dono do dado”.

Quando a teoria vira sanção real: o caso do aplicativo “vibe codado”

A discussão deixou de ser abstrata quando Fabretti trouxe à mesa um caso concreto e recente: um processo sancionador da ANPD, tornado público na semana anterior à gravação, envolvendo uma plataforma de relacionamento voltada ao público LGBTQ+ desenvolvida por meio de vibe coding. A plataforma teve um crescimento explosivo, mais de 30 mil usuários em pouco tempo, e, por falha de configuração de segurança, expôs os dados de todos os usuários recém-chegados.

O ponto levantado por Fabretti sobre a gravidade do caso vai muito além do valor da multa:

Esse exemplo ilustra um princípio central da LGPD que a Dra. Renata reforçou ao longo do episódio: trata-se de uma legislação baseada em risco, não de regras binárias. Não existe uma resposta simples de “pode ou não pode”, existe um espectro de exposição, e o nível de cuidado exigido é proporcional à gravidade do dano potencial. Dados de saúde, orientação sexual ou outras informações sensíveis exigem um patamar de diligência muito mais alto do que, por exemplo, uma base de nome e CPF.

Leia também: Vibe Coding: IA, produtividade e o papel das pessoas nos negócios

Segurança DA nuvem vs. segurança NA nuvem: a distinção que evita (ou gera) incidentes

Um dos conceitos mais operacionais discutidos no episódio é a diferença entre a segurança da nuvem (responsabilidade do provedor: infraestrutura física, patches do sistema operacional, controle de acesso físico ao data center) e a segurança na nuvem (responsabilidade de quem usa o serviço: gestão de acessos, configuração correta das ferramentas, revogação de credenciais).

Segundo Fabretti, que atua diretamente em resposta a incidentes no escritório Opice Blum, a esmagadora maioria dos problemas não vem de falhas do provedor:

A Dra. Renata resumiu essa distinção com uma analogia que vale a pena guardar:

Essa metáfora traduz, de forma direta, por que boa parte das empresas erra o alvo ao investir pesado em infraestrutura sem investir da mesma forma em governança de acesso, rotação de credenciais e treinamento das equipes.

Como a ANPD avalia a responsabilidade em casos de causalidade difícil

Um dos trechos mais ricos do episódio explorou um cenário deliberadamente extremo: um ataque via periférico físico (um teclado comprometido que instala malware ao ser conectado), de rastreabilidade praticamente impossível. Quem responde por isso?

A resposta de Fabretti trouxe uma virada de perspectiva importante sobre como o regulador brasileiro efetivamente analisa esses casos:

Isso significa, na prática, que a existência de um incidente não é, por si só, prova de negligência. O que a autoridade avalia é a diferença entre duas histórias possíveis: uma empresa que treinou pessoas, monitorou a rede, mantinha logs e fez perícia forense após o ocorrido. Versus uma empresa que não tinha absolutamente nenhuma dessas camadas e só descobriu o problema porque um terceiro avisou. No caso do aplicativo vibe codado, segundo Fabretti, a visão da ANPD foi direta: “eles não tomaram nenhuma das medidas adequadas de segurança, e por isso o incidente aconteceu, por isso eles estão sendo sancionados.”

A conclusão prática, resumida por Renata, é que governança não é burocracia, é a matéria-prima da defesa jurídica futura: “às vezes o jurídico é meio chato, quer que documente isso, faça aquilo. Mas para contar essa história lá na frente, ela tem que convencer. Não adianta só contar a história, você tem que mostrar a prova.”

Privacy by Design e a nova fronteira: Compliance by Design

Um conceito que atravessa toda a conversa é o Privacy by Design. A ideia de que soluções tecnológicas devem nascer já incorporando as cautelas de proteção de dados, e não recebê-las como um remendo posterior. Segundo a Dra. Renata:

No episódio, os apresentadores também provocaram um cenário realista: e se o desenvolvedor seguir à risca as boas práticas de Privacy by Design e Security by Design e, ainda assim, sofrer um incidente? A resposta de Fabretti equilibra honestidade jurídica com pragmatismo:

Há ainda um segundo elemento, além do risco: a boa-fé. Fabretti destaca que demonstrar boa-fé não é apenas um princípio da LGPD, é um item concreto no cálculo de dosimetria de multas aplicado pela ANPD, capaz de reduzir a penalidade. Documentação e evidenciação, portanto, não são apenas defesa: são atenuante.

Aprenda as melhores práticas de desenvolvimento seguro para sua empresa

A dica de ouro: “se não pode ser feito, dito ou comprovado, não faça”

Ao fechar o episódio, a Dra. Renata resumiu sua orientação para pessoas físicas e empresas em uma frase que sintetiza toda a filosofia de gestão de risco discutida no programa:

Henrique Fabretti complementou com uma recomendação de estresse de cenário, aplicável a qualquer produto digital que trate dados pessoais:

O recado para quem está construindo com IA hoje

A conversa deixa um mapa claro para qualquer fundador, desenvolvedor ou empresa que esteja “vibe coding” um novo produto de IA ou nuvem:

1. Mapeie seus papéis — controlador ou operador — em cada relação de tratamento de dados, antes que um incidente force essa análise sob pressão.
2. Documente a divisão de responsabilidades em contrato, distinguindo claramente segurança da nuvem e segurança na nuvem.
3. Implemente governança de acesso com o mesmo rigor que se investe em infraestrutura — tokens, credenciais e permissões de terceiros são o ponto de falha mais comum.
4. Adote Privacy by Design e Compliance by Design desde a concepção do produto, não como remendo posterior.
5. Documente e evidencie tudo. Diante de um regulador, boa-fé e diligência comprovada fazem diferença real na dosimetria da responsabilidade.

Como resumiu Robson Del Fiol durante o programa, a exposição a esse tipo de risco não começa quando o produto é lançado, “começa na hora da ideação”. E é exatamente esse o ponto cego de muitos negócios digitais hoje: a tecnologia avança em semanas, mas as consequências jurídicas de uma decisão mal informada podem acompanhar a empresa por anos.

Quer ouvir a conversa completa, com todos os exemplos, analogias e os “hacks” de produtividade dos convidados? Escute o episódio na íntegra do podcast Builders, com Dra. Renata (Skyone) e Henrique Fabretti (Opice Blum Advogados), disponível agora no Spotify.

Escrito por Skyone