Se você constrói um portal de clientes, um app de reservas ou um pequeno CRM para os seus clientes, a conformidade com proteção de dados vira rapidamente uma questão real — mesmo sem equipe jurídica ou advogado interno. Este guia foca no GDPR europeu (o regulamento que se aplica sempre que você tem clientes ou usuários na União Europeia), mas os conceitos são quase idênticos aos da LGPD brasileira: controlador vira "controlador", operador vira "operador", e a autoridade de controle europeia tem sua equivalente na ANPD. Se seu negócio atende clientes no Brasil e na Europa, os mesmos princípios e a mesma checklist prática servem para os dois. Este é um panorama educativo, não uma opinião jurídica: para setores regulados (saúde, finanças, dados de menores) ou tratamento em maior escala, converse com um advogado ou encarregado de dados antes de publicar.
Controlador vs operador: a distinção que esclarece tudo
O GDPR (e, da mesma forma, a LGPD) se apoia em uma divisão simples, mas que costuma confundir. O controlador decide por que e como os dados pessoais são tratados — geralmente é você, como responsável pelo negócio, ao coletar nomes, emails ou reservas dos seus clientes dentro do seu app. Um operador trata esses dados em nome do controlador e segundo as suas instruções — é o caso de cada ferramenta que você conecta: sua plataforma no-code/IA, seu provedor de hospedagem, seu banco de dados, sua ferramenta de email, seu processador de pagamentos. Essa distinção importa por um motivo bem prático: ela mostra quem responde por quê, e é por isso que você deve exigir um contrato de tratamento de dados (DPA, ou equivalente ao "contrato de operação" da LGPD) de cada operador que toca nos dados dos seus usuários. Se um fornecedor não conseguir apresentar um DPA quando solicitado, trate isso como um sinal de alerta.
- Controlador: você, em relação aos dados dos seus clientes finais coletados através do seu app.
- Operador: sua plataforma, seu provedor de hospedagem, sua ferramenta de email, seu processador de pagamentos — qualquer um que trate dados apenas segundo as suas instruções.
- Suboperador: os próprios fornecedores de um operador, como a nuvem por trás do seu provedor de banco de dados.
O que o GDPR normalmente exige de uma pequena aplicação
Sem o jargão jurídico, a maior parte das obrigações do GDPR para uma pequena app se resume a uma lista curta e prática — e que também cobre boa parte do que a LGPD pede.
- Uma política de privacidade em linguagem clara: o que você coleta, por quê, por quanto tempo, quem tem acesso, e como exercer os direitos.
- Uma base legal para cada tipo de tratamento: execução de contrato para cumprir uma reserva, consentimento para emails de marketing ou cookies não essenciais, legítimo interesse para segurança básica e prevenção de fraude.
- Consentimento onde realmente é exigido: uma adesão explícita para comunicações de marketing e para qualquer cookie ou rastreador não essencial.
- Minimização de dados: coletar apenas os campos realmente necessários para entregar o serviço — resistir ao reflexo de adicionar campos "só por precaução".
- Segurança básica: conexões criptografadas (HTTPS), controle de acesso razoável, senhas com hash, backups regulares.
- Direitos dos usuários: uma forma de solicitar acesso, correção ou exclusão dos dados, e recebê-los em formato portável.
- Consciência sobre incidentes: se algo der errado, você pode precisar notificar sua autoridade de controle e, em alguns casos, os usuários afetados.
As perguntas extras que uma plataforma no-code ou de IA acrescenta
Construir sobre uma plataforma no-code ou de IA não te desobriga de suas responsabilidades como controlador — acrescenta uma camada de perguntas sobre o seu fornecedor. Antes de confiar dados reais de clientes a qualquer plataforma, pergunte o seguinte.
- Onde os dados vivem fisicamente — na infraestrutura de quem, em qual região?
- Quem é o operador desses dados, e ele publica uma lista dos próprios suboperadores?
- Existe um contrato de tratamento de dados (DPA) disponível, e ele realmente cobre os dados que você vai armazenar?
- Você pode exportar seu esquema e seus dados, e excluir tudo sob demanda, sem depender do suporte do fornecedor?
- A IA é usada só para ajudar a escrever o código do seu app, ou ela também vê e retém os dados de produção dos seus usuários finais?
- A plataforma atua como intermediária opaca para os dados pessoais dos seus clientes, ou você detém as chaves do banco de dados real?
Escolhendo uma região e obtendo um DPA
Duas perguntas determinam boa parte da sua exposição a risco: onde os dados são armazenados, e se você consegue um DPA assinado para isso. A maioria dos provedores sérios de backend-as-a-service — o Supabase entre eles — publica um DPA padrão que você pode aceitar diretamente, e permite escolher a região de hospedagem do seu próprio projeto de banco de dados, incluindo regiões na UE. Isso importa porque coloca a escolha da jurisdição nas suas mãos, em vez de depender do padrão de uma plataforma. Vale checar isso para cada operador do seu stack — banco de dados, ferramenta de email, processador de pagamentos, ferramenta de analytics — não só o seu criador de apps.
Cookies e rastreadores no app ou site que você gera
As regras de cookies são mais simples do que parecem, uma vez que você separa as duas categorias. Cookies estritamente necessários — os que mantêm um usuário logado ou lembram um carrinho de compras — não exigem consentimento. Tudo o mais, como analytics, anúncios ou pixels de redes sociais, geralmente exige, por meio de uma adesão clara antes de o cookie ser instalado. A abordagem mais simples para um app pequeno: começar apenas com cookies estritamente necessários, e só adicionar um banner de consentimento quando você de fato incluir uma ferramenta de analytics ou publicidade que precise dele.
Uma checklist sem advogado para tipos comuns de app
Site vitrine ou portfólio: uma página de política de privacidade linkada no rodapé, um formulário de contato que informe o que acontece com os dados enviados e por quanto tempo, e um banner de cookies apenas se você adicionar analytics ou anúncios.
App de reservas ou agendamento: uma base legal que combine execução de contrato para a reserva em si e consentimento para lembretes de marketing, coletando apenas o necessário para cumprir a reserva (nome, contato, data), e listando seus operadores — sincronização de calendário, pagamento, provedor de SMS ou email — na sua política de privacidade.
Portal de clientes ou pequeno CRM: um DPA em vigor com cada operador que toca em registros de clientes, acesso baseado em papéis para que cada membro da equipe veja só o que precisa, uma forma documentada de exportar ou excluir permanentemente o registro de um cliente, e um prazo de retenção que você realmente aplica em vez de guardar tudo para sempre.
Onde o Cadrant se encaixa: você fica com as chaves
O Cadrant é construído em torno de uma arquitetura "traga seu próprio Supabase": ao construir um app, você conecta sua própria organização Supabase, em vez de um banco de dados que o Cadrant hospedaria e controlaria por você. Isso tem consequências diretas para o GDPR (e, por extensão, para a LGPD). Você escolhe seu próprio projeto Supabase e sua região de hospedagem. O Supabase, como operador do seu banco de dados, publica seu próprio DPA, que você aceita diretamente com eles. Você continua sendo o controlador dos dados dos seus usuários finais — as pessoas que reservam, se cadastram ou enviam formulários pelo seu app — e mantém, a qualquer momento, a capacidade total de consultar, exportar ou excluir esses dados diretamente no seu próprio painel Supabase, de forma independente do Cadrant. Isso é deliberadamente diferente de plataformas em que os dados dos seus clientes ficam dentro de um banco de dados opaco, compartilhado e de propriedade do fornecedor, que você não consegue consultar nem exportar.
Para ser transparente sobre a nossa própria estrutura: o Cadrant é publicado pela Convergence Lab, uma empresa francesa, e a plataforma em si — não os bancos de dados que você conecta — é hospedada em infraestrutura AWS que não é exclusivamente da UE; contamos com salvaguardas apropriadas para qualquer transferência fora da UE, e nosso encarregado de proteção de dados pode ser contatado em dpo@cadrant.ai para questões sobre a plataforma em si. Hoje não reivindicamos certificação SOC 2 ou ISO 27001, e você deve receber com saudável ceticismo qualquer afirmação assim de qualquer fornecedor até realmente ver o certificado.
Como o Cadrant ajuda você a se manter em conformidade, na prática
Você pode pedir em linguagem natural as peças que dão suporte à conformidade: uma página de política de privacidade, um banner de consentimento de cookies, um formulário de contato que explique o que é feito com os envios, ou uma página de configurações de conta onde os seus próprios usuários finais possam solicitar seus dados ou pedir a exclusão. Como o seu banco de dados vive no seu próprio projeto Supabase, atender a um pedido de exclusão ou exportação é uma ação real e auditável — não um chamado de suporte enviado a terceiros. A conformidade nunca é totalmente automática, mas partir de uma arquitetura em que você detém os dados torna cada passo seguinte muito mais simples.