Se constrói um portal de clientes, uma 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 equipa jurídica ou advogado interno. Este guia foca no RGPD europeu (o regulamento que se aplica sempre que tem clientes ou utilizadores na União Europeia), mas em Portugal aplica-se diretamente, com a CNPD como autoridade de controlo e a Lei n.º 58/2019 a assegurar a sua execução. Se o seu negócio atende clientes em vários países da União Europeia, os mesmos princípios e a mesma checklist prática servem para todos. 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 RGPD) se apoia numa 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, e-mails ou reservas dos seus clientes dentro da sua app. Um operador trata estes dados em nome do controlador e segundo as suas instruções, é o caso de cada ferramenta que conecta: a sua plataforma no-code/IA, o seu provedor de alojamento, o a sua base de dados, a sua ferramenta de e-mail, o seu processador de pagamentos. Esta distinção importa por um motivo bem prático: ela mostra quem responde por quê, e é por isso que deve exigir um contrato de tratamento de dados (DPA, ou equivalente ao "contrato de operação" da RGPD) de cada operador que toca nos dados dos seus utilizadores. 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 da sua app.
- Operador: a sua plataforma, o seu provedor de alojamento, a sua ferramenta de e-mail, o 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 base 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 RGPD pede.
- Uma política de privacidade em linguagem clara: o que 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 e-mails 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), controlo de acesso razoável, palavras-passe com hash, backups regulares.
- Direitos dos utilizadores: uma forma de solicitar acesso, correção ou eliminação dos dados, e recebê-los em formato portável.
- Consciência sobre incidentes: se algo der errado, pode precisar notificar a sua autoridade de controlo e, em alguns casos, os utilizadores 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 das 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 destes 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 vai armazenar?
- Pode exportar o seu esquema e os seus dados, e eliminar tudo sob demanda, sem depender do suporte do fornecedor?
- A IA é usada só para ajudar a escrever o código da sua app, ou ela também vê e retém os dados de produção dos seus utilizadores finais?
- A plataforma atua como intermediária opaca para os dados pessoais dos seus clientes, ou detém as chaves da base 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 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 pode aceitar diretamente, e permite escolher a região de alojamento do seu próprio projeto de base 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, base de dados, ferramenta de e-mail, processador de pagamentos, ferramenta de analytics, não só o seu criador de apps.
Cookies e rastreadores na app ou site que gera
As regras de cookies são mais simples do que parecem, uma vez que separa as duas categorias. Cookies estritamente necessários, os que mantêm um utilizador 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 uma app pequena: começar apenas com cookies estritamente necessários, e só adicionar um banner de consentimento quando de facto incluir uma ferramenta de analytics ou publicidade que precise dele.
Uma checklist sem advogado para tipos comuns de app
Site institucional ou portfólio: uma página de política de privacidade linkada no rodapé, um formulário de contacto que indique o que acontece com os dados enviados e por quanto tempo, e um banner de cookies apenas se 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, contacto, data), e listando os 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 registos de clientes, acesso baseado em papéis para que cada membro da equipa veja só o que precisa, uma forma documentada de exportar ou eliminar permanentemente o registo de um cliente, e um prazo de retenção que realmente aplica em vez de guardar tudo para sempre.
Onde a Cadrant se encaixa: fica com as chaves?
A Cadrant é construído em torno de uma arquitetura "traga o seu próprio Supabase": ao construir uma app, conecta a sua própria organização Supabase, em vez de uma base de dados que a Cadrant hospedaria e controlaria por si. Isso tem consequências diretas para o GDPR (e, por extensão, para a RGPD). Escolhe o seu próprio projeto Supabase e a sua região de alojamento. O Supabase, como operador do a sua base de dados, publica o seu próprio DPA, que aceita diretamente com eles. Continua a ser o controlador dos dados dos seus utilizadores finais, as pessoas que reservam, se registam ou enviam formulários pela sua app, e mantém, a qualquer momento, a capacidade total de consultar, exportar ou eliminar estes dados diretamente no seu próprio painel Supabase, de forma independente da Cadrant. Isso é delibertadamente diferente de plataformas em que os dados dos seus clientes ficam dentro de uma base de dados opaco, partilhado e de propriedade do fornecedor, que não consegue consultar nem exportar.
Para ser transparente sobre a nossa própria estrutura: a Cadrant é publicado pela Convergence Lab, uma empresa francesa, e a plataforma em si, não as bases de dados que conecta, é alojada em infraestrutura AWS que não é exclusivamente da UE; contamos com salvaguardas apropriadas para qualquer transferência fora da UE, e o 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 deve receber com saudável ceticismo qualquer afirmação assim de qualquer fornecedor até realmente ver o certificado.
Como a Cadrant ajuda a se manter em conformidade, na prática?
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 contacto que explique o que é feito com os envios, ou uma página de definições de conta onde os seus próprios utilizadores finais possam solicitar os seus dados ou pedir a eliminação. Como o a sua base de dados vive no seu próprio projeto Supabase, atender a um pedido de eliminaçã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 detém os dados torna cada passo seguinte muito mais simples.