O que o GDPR exige do seu provedor de infraestrutura de e-mail?
Quando você contrata um provedor terceirizado de infraestrutura de email, o GDPR estabelece uma relação controlador-operador: você é o controlador (decide finalidades e meios do tratamento dos dados pessoais dos destinatários), nós somos o operador (tratamos seguindo suas instruções documentadas). O artigo 28 lista as obrigações específicas que um operador deve aceitar contratualmente: tratar somente conforme instruções documentadas, garantir a confidencialidade do pessoal, aplicar as medidas de segurança do artigo 32, respeitar as regras sobre suboperadores, assistir nos direitos do titular, assistir na notificação de incidentes e demais obrigações dos artigos 32-36, devolver ou apagar os dados ao término do contrato, e disponibilizar a informação necessária para demonstrar conformidade. Nosso DPA em /dpa cobre cada obrigação de forma expressa.
Como estamos posicionados como operador de tratamento.
OS Domains GmbH é a entidade jurídica que assina o DPA. Somos constituídos na UE (Áustria), com roteamento padrão na UE, equipe de engenharia e operações na UE, com DPO designado acessível em [email protected] que responde em 1 dia útil. Nossa lista pública de suboperadores está em /dpa#sub-processors com aviso prévio de 30 dias sobre qualquer mudança. O compromisso de notificação de incidente é de 48 horas desde o conhecimento até a notificação ao cliente — mais rigoroso que o piso regulatório de 72 horas — especificamente para dar margem suficiente para sua própria notificação do artigo 33 à autoridade competente. O registro de atividades de tratamento do artigo 30 é mantido internamente e extraído sob demanda.
Por que o GDPR importa para uma empresa brasileira?
Mesmo sendo uma empresa brasileira regulada pela LGPD, o GDPR pode aplicar diretamente quando: você oferece bens ou serviços a residentes na UE (Art. 3.2.a), você monitora o comportamento de residentes na UE (Art. 3.2.b), você tem subsidiária estabelecida na UE. Para fintechs, e-commerces e SaaS brasileiros com base europeia de usuários, isso significa cumprir simultaneamente LGPD e GDPR. Operar com infraestrutura UE simplifica significativamente: os dados de usuários europeus ficam na UE por padrão, evitando complicações de transferência internacional bidirecional, e a documentação contratual aceita ambos os regimes de uma só vez. Para empresas brasileiras sem usuários europeus, o GDPR não aplica diretamente, mas é referência habitual em DPAs internacionais.
Como os princípios do artigo 5 se aplicam à infraestrutura de e-mail?
Licitude, lealdade e transparência: tratamos conforme instruções documentadas e nosso DPA descreve o tratamento no Anexo 1. Limitação de finalidade: usamos os dados do cliente exclusivamente para prestar os serviços, nunca para treinar modelos de ML ou agregar em datasets comercializáveis. Minimização: aceitamos apenas os dados que você envia; não enriquecemos com fontes terceiras. Exatidão: ferramentas para corrigir ou apagar dados via painel e API. Limitação de retenção: períodos documentados em /dpa#annex-4, de 7 dias para conteúdo de mensagem a 12 meses para relatórios DMARC, com opção de encurtar. Integridade e confidencialidade: medidas de segurança do artigo 32 detalhadas em /dpa#annex-2. Responsabilidade proativa: controles do artigo 32 operados e documentados, com evidência de controle pré-certificação disponível mediante solicitação; direito de auditoria em planos Enterprise.
Qual é a direção regulatória de 2026 com o Digital Omnibus?
O texto do GDPR não mudou na sua substância, mas o contexto regulatório de 2026 sim se moveu, e vale a pena saber em que direção. Em 19 de novembro de 2025 a Comissão Europeia apresentou o pacote Digital Omnibus, uma proposta de simplificação que toca o GDPR, o AI Act e as regras de dados, com o objetivo declarado de reduzir a carga administrativa sobre as empresas sem rebaixar os direitos de fundo. Entre os pontos que importam para um provedor de e-mail estão os ajustes propostos ao registro de atividades de tratamento para entidades menores, alguma flexibilização nos prazos e formatos de certas obrigações documentais, e o realinhamento de prazos do AI Act. É uma proposta, não lei: tem que passar pelo Parlamento Europeu e pelo Conselho, e o seu conteúdo final pode mudar ao longo de 2026. A nossa postura é não reescrever a documentação de conformidade em torno de uma proposta que ainda se move, e sim manter o cumprimento contra o texto vigente do GDPR enquanto seguimos a tramitação. Quando o Digital Omnibus se consolidar, ajustaremos os artefatos afetados, mas a base —tratamento na UE, DPA com as cláusulas do artigo 28, medidas do artigo 32— não depende dessa reforma para ser sólida hoje.
As medidas de segurança do artigo 32, ditas em concreto.
O artigo 32 do GDPR exige medidas técnicas e organizativas apropriadas ao risco, e o útil é dizer o que isso significa em concreto em vez de repetir a fórmula legal. Em trânsito, todo o correio sai com TLS 1.3 onde o receptor o suporta, com fallback negociado, e o acesso ao painel e à API corre só sobre HTTPS com HSTS. Em repouso, o conteúdo das mensagens, os dados do destinatário e os logs ficam cifrados com AES-256, e as chaves se gerenciam separadas dos dados. O controle de acesso aplica o princípio do menor privilégio sobre as contas de operador, com MFA obrigatório no painel e papéis segmentados por scope para que uma chave de envio não toque a configuração nem as listas. A pseudonimização se aplica aos identificadores de destinatário onde o tratamento o permite. A resiliência se apoia em pontos de presença redundantes na UE com failover, e a capacidade de restaurar a disponibilidade e o acesso aos dados depois de um incidente se testa em vez de só se afirmar. Os registros de auditoria das ações administrativas ficam disponíveis para o cliente. Cada uma dessas medidas se nomeia no addendum DPA com o seu detalhe, porque um controlador que tem que demonstrar a conformidade do artigo 32 do seu operador precisa de uma lista concreta e não de uma garantia genérica.
Como funciona a cadeia de autorização de suboperadores do artigo 28?
O artigo 28 do GDPR governa a relação entre controlador e operador, e uma das suas exigências é que o operador não recorra a um suboperador sem autorização prévia do controlador, geral ou específica, e que informe das mudanças com tempo para opor-se. A nossa abordagem é uma autorização geral por escrito com notificação prévia das mudanças: a lista de suboperadores está no addendum DPA com o papel de cada um, e qualquer adição ou substituição se comunica com antecedência para que o controlador possa avaliar e, se for o caso, opor-se antes de surtir efeito. A cadeia para uma conta padrão é curta e nomeada: a conectividade de rede a montante, o CDN diante do painel, o processador de pagamentos do faturamento e os feeds de dados semente ou de reputação. Cada suboperador está ligado por um contrato que impõe as mesmas obrigações de proteção de dados que assumimos com você, como o artigo 28(4) exige. Para contas com requisitos de residência estritos, estreitamos o conjunto de suboperadores aos que operam só na UE e documentamos essa configuração no contrato. A diferença frente a uma página web de suboperadores que muda sem aviso é que aqui a mudança é um evento contratual com direito de oposição, que é o que o artigo 28 pede e o que um auditor espera ver.
O registro de atividades de tratamento e a carga de prova do controlador.
O artigo 30 do GDPR exige que controladores e operadores mantenham um registro das atividades de tratamento, e a carga de demonstrar a conformidade recai sobre o controlador, que é você quando nos usa como operador. Um registro útil para a parte do e-mail descreve as categorias de titulares e de dados tratados, as finalidades, os destinatários incluindo os suboperadores, as transferências internacionais se as houver, os prazos de conservação e uma descrição geral das medidas de segurança. O ponto onde muitos controladores tropeçam é que metade desses campos descreve o que o operador faz, e se o operador não os fornece de forma clara, o controlador acaba reconstruindo-os a partir de tickets de suporte e de capturas de tela. Por isso entregamos um pacote de suporte ao registro com a nossa entidade legal, as localizações de tratamento na UE, a lista de suboperadores, os prazos de conservação configurados para a conta e o resumo das medidas do artigo 32, redigido na forma que encaixa diretamente no seu registro. Quando a sua equipe de privacidade prepara ou atualiza o registro, a linha do e-mail se preenche a partir do nosso material em vez de ser deduzida. Um registro completo é a primeira coisa que uma autoridade pede numa inspeção, e a parte do provedor de e-mail não deveria ser o buraco que atrasa a resposta.
A interseção entre o GDPR e o AI Act toca os dados dos seus destinatários?
O AI Act da UE entrou em vigor de forma escalonada, e a pergunta razoável de um controlador é se o uso de qualquer componente de aprendizado de máquina na infraestrutura de e-mail arrasta os dados dos seus destinatários para o âmbito do AI Act sobre o do GDPR. A resposta no nosso caso é delimitada. Onde aplicamos modelos —por exemplo, na filtragem antiabuso, na detecção de padrões de spam ou na pontuação de risco de reputação— o tratamento opera sobre metadados de envio e sinais agregados, e não sobre o conteúdo das mensagens dos seus destinatários para fins de perfilamento, e não tomamos decisões automatizadas com efeito jurídico sobre os titulares no sentido do artigo 22 do GDPR. Isso mantém o uso fora das categorias de alto risco do AI Act que exigiriam obrigações adicionais do lado do fornecedor. Onde um cliente integra a sua própria camada de IA por cima do nosso envio —geração de conteúdo, segmentação preditiva— essa é uma atividade de tratamento do controlador, e a responsabilidade de avaliá-la sob o GDPR e o AI Act é dele, ainda que possamos fornecer a informação técnica que a avaliação precisa. Documentamos com clareza onde há e onde não há tratamento por modelos sobre dados pessoais, porque uma resposta vaga aqui é o que transforma uma pergunta de due diligence simples num atraso.
O pano de fundo sancionatório e o que de fato reduz a exposição.
As multas do GDPR chegam a 20 milhões de euros ou 4% do faturamento global anual, o que for maior, e o histórico de aplicação mostra que as sanções grandes recaem com mais frequência sobre transferências internacionais mal fundamentadas e sobre falhas de base jurídica e de segurança do que sobre detalhes de papelório. Para a parte do e-mail, isso aponta para onde a exposição real se reduz. Manter o tratamento dentro do EEE com um operador que não está sujeito ao direito de um terceiro país elimina a categoria de risco que produziu as multas de transferência mais sonadas. Ter uma base jurídica clara para cada envio —consentimento ou interesse legítimo bem documentado— fecha a segunda categoria. Cumprir as medidas do artigo 32 de forma demonstrável fecha a terceira. A nossa contribuição para reduzir a sua exposição é concreta e não retórica: tratamento na UE por padrão sob uma entidade austríaca, um DPA com as cláusulas do artigo 28 e do artigo 32 detalhadas, um pacote de suporte ao registro e à avaliação, e a documentação de transferência onde algum fluxo a exija. Nenhum provedor pode garantir que você nunca enfrentará uma sanção, porque a maior parte da sua exposição depende das suas próprias decisões de tratamento, mas a parte que corresponde à infraestrutura de e-mail é a que deixamos coberta com evidência em vez de promessas.