Por que o setor público brasileiro tem exigências próprias?
As administrações públicas brasileiras (União, Estados, Municípios, autarquias, fundações, empresas públicas) e os fornecedores que contratam com elas operam sob marco regulatório que adiciona camadas sobre a LGPD: a Lei 14.133/2021 (Nova Lei de Licitações e Contratos) que regula a contratação de serviços de TI, a Lei 12.527/2011 (Lei de Acesso à Informação) que estabelece prazos e formatos para comunicações de transparência, o Decreto 10.046/2019 sobre Governança no Compartilhamento de Dados, as obrigações específicas de acessibilidade sob o Decreto 9.296/2018 conforme NBR 17225 e WCAG 2.1 AA. Uma infraestrutura de email que sirva a administrações tem que documentar conformidade com cada uma destas frentes; a LGPD genérica por si só não cobre esse requisito.
Como encaixamos com o marco brasileiro de TI no setor público.
Para contratações públicas brasileiras sob a Lei 14.133/2021, a documentação habitual exigida é: certificação ISO 27001 (que mantemos), ISO 27017 sobre cloud security (mapeável da nossa ISO 27001), ISO 27018 sobre privacy in cloud (também mapeável), atestados técnicos de capacidade equivalente. Para órgãos federais, soma-se o atendimento aos princípios da IN SGD/ME 1/2019 sobre processo de contratação de soluções de TIC. Para órgãos estaduais e municipais, as exigências variam mas a base é similar. Entregamos no plano Enterprise um pacote de documentação para subsidiar a habilitação técnica em processos licitatórios, com tradução juramentada para português quando exigida.
Clientes do setor público que servimos.
Servimos a entidades do setor público europeu sob contratos Enterprise: administrações locais e regionais para comunicações a residentes (notificações de impostos, avisos administrativos, alertas de emergência), serviços de saúde regionais para comunicação com pacientes, uma universidade pública para comunicação acadêmica, e organismos europeus (instituições UE) sob o regime específico do Regulamento (UE) 2018/1725. Para o Brasil, o processo de contratação segue a Lei 14.133/2021 com modalidades de licitação adequadas ao valor e tipo de serviço, e nossa experiência em sector público europeu serve de referência para os requerimentos técnicos típicos.
Que particularidades tem a contratação pública brasileira?
A Lei 14.133/2021 (Nova Lei de Licitações) revogou progressivamente a Lei 8.666/1993 e introduz mudanças relevantes para contratação de serviços de TI: modalidade pregão eletrônico como regra para bens e serviços comuns, possibilidade de diálogo competitivo para contratações complexas, exigência de matriz de risco em contratos de longo prazo, classificação de bens e serviços em catálogo eletrônico CATMAT/CATSER, garantia contratual de 1% a 5% do valor do contrato. A facturação no setor público brasileiro é via NF-e de serviço com retenções aplicáveis (INSS, ISS, IRRF). Para serviços de TI contratados de fornecedor estrangeiro, há IRRF de 15% sobre serviços técnicos, ISS conforme município, IOF câmbio.
O que não fingimos ser.
Não somos um processador de informação classificada plenamente habilitado. Não temos credenciamento para informação sigilosa do governo federal brasileiro na escala atual, nem o equivalente europeu para EU RESTRICTED ou EU CONFIDENTIAL nas nossas instalações e no nosso pessoal. Os órgãos que tratam informação classificada sob a Lei de Acesso à Informação e o Decreto 7.845/2012 não podem nos usar para essa carga. Somos apropriados para comunicações não classificadas voltadas ao cidadão, difusão de informação pública, notificações de licitações, avisos regulatórios e notificações operacionais de serviço público. Para cargas classificadas, orientamos o cliente a provedores especializados do setor público com o credenciamento correspondente em cada jurisdição. Dizer isso numa proposta importa, porque um avaliador já viu fornecedores exagerarem o seu alcance, e nomear o limite com clareza lê como mais crível do que borrá-lo.
Como a Lei Europeia de Acessibilidade se aplica ao e-mail do setor público?
A Lei Europeia de Acessibilidade passou a ser exigível em 28 de junho de 2025, e ao longo de 2026 a pergunta deixou de ser se é preciso cumprir para virar quem está conferindo. No Brasil, o paralelo é a Lei Brasileira de Inclusão (Lei 13.146/2015) e o Decreto 9.296/2018, que já obrigam os sítios e serviços digitais do poder público à acessibilidade segundo o eMAG. Os dois marcos apontam para o mesmo padrão técnico de fundo, as WCAG, e a versão europeia harmonizada, a EN 301 549, está caminhando para incorporar as WCAG 2.2 ao longo de 2026. A consequência específica para o e-mail é concreta: uma notificação ao cidadão que se renderiza como um bloco HTML inacessível reprova a mesma barra que um sítio web. Os nossos templates de mensagem e o portal de cliente cumprem a EN 301 549 contra as WCAG 2.2 AA, e os padrões de template que entregamos carregam essa conformidade, então o trabalho de acessibilidade é feito uma vez na camada de template em vez de ser redescoberto depois de uma reclamação. Para um órgão brasileiro que presta serviço a cidadãos na UE, cumprir o padrão europeu além do eMAG fecha os dois requisitos de uma vez.
eIDAS 2.0 e a carteira de identidade chegam em 2026, junto às notificações ao cidadão.
O eIDAS 2.0, o Regulamento (UE) 2024/1183, entrou em vigor em maio de 2024 e obriga cada Estado-membro a oferecer uma Carteira Europeia de Identidade Digital a cidadãos, residentes e empresas, com a implantação caindo ao longo de 2026. A carteira guarda credenciais verificadas pela administração e suporta Assinaturas Eletrônicas Qualificadas reconhecidas em toda a União. O paralelo brasileiro é a identidade digital gov.br com os seus níveis bronze, prata e ouro e a assinatura eletrônica avançada e qualificada do ICP-Brasil, que cumprem um papel equivalente para o cidadão brasileiro. Para uma autoridade pública, a carteira muda a superfície de cadastro e de autenticação ao redor do mesmo cidadão que recebe o seu e-mail, o que eleva a barra na parte da notificação: uma notificação legal entregue por e-mail precisa cada vez mais encaixar num fluxo de entrega qualificada em vez de aterrissar como correio comum. O eIDAS mantém a entrega eletrônica registrada qualificada como serviço de confiança no seu artigo 44, e é aí que encaixamos. Fornecemos uma configuração que cumpre os requisitos técnicos de um serviço de entrega eletrônica registrada qualificada —a entrega, a evidência, os carimbos de tempo— enquanto a qualificação em si permanece no órgão supervisor nacional do lado do cliente. Operamos a entrega técnica e a evidência de prova de entrega, e o status legal de qualificação é concedido ao seu serviço pelo seu supervisor, não afirmado por nós.
A nota fiscal eletrônica e a fatura por e-mail no setor público: o que muda e o que não.
Os fornecedores do setor público convivem com a fatura eletrônica obrigatória ao governo há mais tempo que o setor privado. No Brasil, a NF-e e a NFS-e são autorizadas pela SEFAZ e pela prefeitura, e o XML é o documento com valor fiscal; o e-mail que entrega o DANFE e o aviso ao fornecedor ou ao cidadão é a camada de cortesia, não o documento em si. Na União Europeia, a fatura B2G já circula pela rede Peppol em formatos estruturados como XRechnung na Alemanha e Factur-X na França, e o pacote de IVA na Era Digital estende o B2B ao mesmo caminho até 2030. Para uma autoridade pública que envia comunicações de pagamento e de contratação, isso traça a mesma fronteira que traçamos em outras frentes. A fatura estruturada que carrega o peso legal e fiscal viaja pelo seu canal próprio a partir de um sistema de finanças, e nós não somos esse sistema; não geramos nem transmitimos o XML da NF-e nem o documento Peppol, e não vamos fingir que sim. O que o e-mail faz é transportar a confirmação legível, a atualização de estado, a cópia de cortesia e a notificação procedimental ao fornecedor ou ao cidadão, e o nosso trabalho é que cheguem de forma confiável e acessível sobre infraestrutura residente na UE. Manter essa distinção explícita numa resposta a licitação importa, porque os avaliadores já viram fornecedores inflarem o seu alcance.
Por que a soberania é estrutural para o e-mail do setor público?
Para uma autoridade pública o requisito de residência de dados raramente é satisfeito por um ajuste de região numa plataforma com sede estadunidense, porque a preocupação é a jurisdição e não a geografia: um provedor com matriz estadunidense segue exposto a pedidos de acesso extraterritoriais independentemente de onde os bytes residam. A nossa posição é estrutural. A sociedade está constituída na Áustria sem matriz estadunidense na cadeia corporativa, as contas do setor público fixam por padrão a seleção de pontos de presença só-UE com os gateways de Dallas e Panamá desabilitados, e a lista de suboperadores para essas contas exclui entidades que roteariam o processamento por operações só-estadunidenses. Onde uma norma nacional vai além e proíbe que os dados fluam mesmo para outro país da UE, a residência de país único fixa todos os dados e o processamento dentro do Estado escolhido. Essa escolha troca resiliência por soberania, porque uma âncora a um só país limita o failover aos pontos de presença dentro desse país, e as autoridades aceitam a troca porque a restrição de soberania não é negociável. Um provedor cuja soberania é uma questão de estrutura corporativa e não um interruptor de configuração é o que sobrevive à revisão jurídica sem um asterisco.
Por que notificações ao cidadão não são marketing?
Uma notificação ao cidadão —uma convocação, um aviso de vencimento, uma atualização de status de um benefício ou de um processo— tem um perfil de entrega oposto ao do marketing, e tratá-la com a mesma infraestrutura é um erro. O destinatário não optou por recebê-la no sentido comercial; ele tem direito a recebê-la, e a falha de entrega tem consequência jurídica em vez de comercial. Por isso roteamos as notificações ao cidadão por um pool separado do promocional, com a reputação mais alta e mais estável, e com prioridade de fila, de modo que um envio informativo do governo não fique atrás de uma campanha. A autenticação é estrita —SPF, DKIM e DMARC em p=reject— porque um aviso oficial falsificado é um vetor de fraude contra o cidadão, e o BIMI com o logo verificado do órgão, onde suportado, ajuda o destinatário a distinguir o aviso real do golpe. Medimos a colocação no inbox por provedor para essas mensagens em vez de nos contentarmos com a taxa de entrega, porque uma convocação na pasta de spam é, para efeitos práticos, uma convocação não entregue. O roteamento reflete que a mensagem é um serviço público e não uma peça de marketing.