# Privacidade real vs aparente: as perguntas que convém fazer a si mesmo > Cuadernos Lacre > https://solo2.net/pt/cadernos/articulos/privacidade-arquitetural-vs-privacidade-declarativa.html Síntese operacional do ciclo 2: as perguntas que distinguem um serviço com privacidade arquitetónica de um com privacidade declarativa. Um questionário para o profissional europeu antes de adotar qualquer ferramenta digital para dados sensíveis. --- > Para nos entendermos: Dois serviços com o mesmo aviso legal podem comportar-se de maneira muito distinta. Um protege por desenho técnico. O outro protege por promessa contratual. A diferença não se lê no aviso — descobre-se formulando as perguntas concretas. A qualidade das respostas diz tanto do produto como o seu próprio conteúdo. ## A diferença entre privacidade arquitetónica e privacidade declarativa Ao longo dos sete artigos anteriores deste ciclo percorremos camadas distintas do mesmo assunto. O direito das transferências internacionais com Schrems II. A ideia matemática do hash criptográfico que sela cada Cuaderno. A escolha arquitetónica do kill switch e a captura institucional que quase sempre o acompanha. O mecanismo da cifragem de ponta a ponta e a pergunta operacional sobre onde residem as chaves. O alinhamento de incentivos segundo o modelo de negócio. A identidade criptográfica autossoberana. O auto-hospedagem como estratégia proporcional. Cada artigo ocupou-se de um ângulo. Este, o último do ciclo, reúne-os num questionário. A distinção que convém reter é simples: há serviços cuja privacidade é *arquitetónica* e há serviços cuja privacidade é *declarativa*. A primeira está incrustada no desenho técnico: certas violações do compromisso de privacidade são tecnicamente difíceis ou impossíveis porque a arquitetura não as permite. A segunda está depositada no texto do aviso legal: certas violações seriam contratualmente sancionáveis se ocorrerem, mas tecnicamente nada as impede. Os dois modelos podem cumprir o RGPD; mas um protege por construção e o outro protege por promessa, e a diferença é operacionalmente enorme. As perguntas que se seguem estão concebidas para distinguir um caso do outro. Não são perguntas técnicas avançadas. São as perguntas que qualquer fornecedor honesto pode responder na sua documentação pública. A qualidade e precisão da resposta diz tanto do produto como a própria resposta. As perguntas agrupam-se em seis camadas; convém fazê-las todas antes de adotar o serviço para dados sensíveis, não apenas as que o primeiro instinto identifica. ## Camada 1: arquitetura Convém fixar um termo antes de prosseguir. Por *operador* entendemos a empresa que presta o serviço: a entidade que controla os servidores e o software, não uma pessoa concreta. Feita essa ressalva, a pergunta arquitetónica de raiz é: o que faz o operador com o conteúdo entre o remetente e o destinatário? Há três respostas possíveis e convém saber distingui-las, porque as três são por vezes publicitadas com vocabulário semelhante. A pergunta complementar —já formulada no Cuaderno sobre cifragem— é: quem tem as chaves criptográficas que permitem ler o conteúdo? Se as tem o utilizador e só o utilizador, a cifragem é real. Se as tem também o operador sob qualquer forma —mesmo sob o nome de «recuperação de conta» ou «sincronização entre dispositivos»—, a cifragem é nominal. A pergunta não admite resposta intermédia honesta. ## Camada 2: modelo de negócio A pergunta sobre o modelo de negócio importa tanto como a pergunta arquitetónica, e pela mesma razão substantiva: os incentivos produzem, ao longo do tempo, produtos sistematicamente distintos ainda que com propósitos declarados idênticos. Como ganha dinheiro hoje o operador? Uma só fonte, duas, mistura? Se o financiamento inclui publicidade ou monetização de dados, que dados se monetizam e sobre que base jurídica do RGPD se faz? A finalidade declarada no aviso legal cobre os dados de terceiros que o profissional pretende confiar ao serviço? E a pergunta de segunda ordem, nem sempre formulada: qual é a situação financeira do operador a três ou cinco anos vista? Uma empresa em fase de capital de risco opera sob pressões distintas de uma empresa em rentabilidade estável. A mudança de modelo de financiamento é, repetidamente, o momento em que o contrato implícito com os utilizadores se reescreve sem negociação. ## Camada 3: jurisdição Para o profissional europeu, a pergunta da jurisdição não é retórica. Em que jurisdição está incorporado o operador? Em que país estão fisicamente os servidores que processam os dados? A resposta às duas perguntas anteriores é a mesma ou diferente, e se difere, que legislação se aplica? Uma região europeia operada por uma empresa norte-americana não é, para efeitos de Schrems II, uma resposta europeia: a empresa está sujeita ao FISA 702 independentemente de onde estejam os servidores. A pergunta complementar operacional é: se chegasse amanhã uma ordem de informações válida na jurisdição do operador pedindo a entrega dos meus dados ou dos dos meus clientes, o que aconteceria? Se a resposta honesta começa por «a empresa estaria obrigada a entregá-los», o serviço não protege contra essa ordem por muito que a publicidade sugira o contrário. Se a resposta honesta começa por «a empresa não poderia entregá-los porque não os tem em claro», o serviço protege sim; e a diferença depende quase inteiramente das duas primeiras camadas, não da qualidade da política de privacidade. ## Camada 4: operador e kill switch Que capacidade técnica retém o operador para suspender, bloquear, eliminar ou degradar o serviço à distância? A pergunta não é paranoica: é operacional. As plataformas digitais exerceram essa capacidade repetidamente nos últimos anos, por vezes por iniciativa própria, outras sob ordem de Governos, outras após mudanças de propriedade ou de política. Se a capacidade existe, convém saber sob que pressupostos contratualmente declarados se exerce, e reservar uma margem para os pressupostos não declarados que a prática dos últimos anos mostrou serem igualmente relevantes: ordem judicial inesperada, sanção internacional, mudança de governo corporativo, aquisição por uma entidade com outra política. A pergunta irmã é a do plano de continuidade: se o operador exercesse a capacidade contra o profissional —pela razão que for, justa ou não—, que tempo de atividade continuaria disponível, que procedimento de exportação de dados existe, e para que fornecedor alternativo se poderia migrar? Se a resposta começa por «não deveria acontecer», não é uma resposta operacional; é uma promessa. ## Camada 5: identidade e acesso Quem controla as credenciais de acesso ao serviço? Se o operador pode repor o acesso do utilizador sem a participação do utilizador —procedimento normalmente chamado «recuperação de conta»—, o operador é, tecnicamente, o guardião da conta e pode também cedê-la a quem o solicite mediante o procedimento adequado. Se o operador não pode repor o acesso porque a identidade reside criptograficamente no dispositivo do utilizador, o operador também não pode cedê-la, nem sequer sob ordem. As duas modalidades são legítimas consoante o contexto; mas, mais uma vez, são distintas, e convém saber qual se está a adotar. O que acontece com os dados do profissional se o profissional perder o acesso? Existem mecanismos de recuperação —de conta, de arquivo, de sessão— que dependem do operador? Esses mecanismos são compatíveis com a deontologia profissional do setor se o operador for coagido a usá-los? ## Camada 6: futuro Esta última camada costuma ser descurada porque exige projeção. O que aconteceria se o serviço fosse adquirido por outra empresa? Quase todas as aquisições trazem consigo uma revisão dos termos do serviço nos meses seguintes. O que aconteceria se as exigências regulatórias mudassem? O direito europeu aumentou as obrigações de retirada e bloqueio desde 2022, não as reduziu. O que aconteceria se o operador desaparecesse? Uma parte significativa dos serviços na cloud não tem plano de saída documentado para o cenário de encerramento do operador; o profissional descobre o problema quando já não há tempo de o preparar. Há uma formulação que convém reter para esta camada: as arquiteturas que dependem menos do operador são mais resilientes perante mudanças do operador. O auto-hospedagem em qualquer das suas modalidades, a identidade criptográfica autossoberana, as comunicações sem servidor pelo meio, todas estas reduzem a superfície de risco futura através do procedimento de reduzir a superfície de dependência presente. Não a eliminam; reduzem-na. ## A diferença entre estrutura e promessa Se tivéssemos de destilar o ciclo numa só frase, seria esta: as respostas estruturais mantêm-se ainda que o operador, a administração ou a legislação mudem; as respostas por promessa mantêm-se enquanto quem promete puder e quiser mantê-las. As duas podem estar corretas no momento de serem adotadas. Só uma das duas se sustenta independentemente da passagem do tempo e da mudança das circunstâncias. Isto não significa que cada profissional deva exigir respostas estruturais a todos os serviços que adota. A proporcionalidade continua a ser legítima: uma folha de cálculo para contabilidade interna não precisa da mesma resposta que o processo clínico de um paciente. Significa, sim, que a profissionalidade consiste em saber que tipo de resposta se aceitou em cada caso, e em ter decidido conscientemente que esse tipo de resposta é proporcional ao dado concreto. ## O questionário, ordenado Doze perguntas concretas que sintetizam o ciclo, ordenadas para que a resposta a cada uma informe a seguinte: 1. O conteúdo passa por um servidor do operador? Se passa: em claro, cifrado com chaves do operador, ou cifrado com chaves exclusivas do utilizador? 2. Se for invocada cifragem de ponta a ponta, onde residem as chaves criptográficas? O operador conhece ou conserva alguma parte delas sob qualquer forma, incluindo a «recuperação»? 3. Que metadados gera e conserva o serviço? Durante quanto tempo? A quem são visíveis? 4. Como se financia o operador? Se o financiamento inclui publicidade ou monetização de dados, a finalidade declarada cobre dados de terceiros confiados pelo profissional? 5. Qual é a situação financeira do operador a três ou cinco anos vista? Há fatores que sugiram uma mudança iminente de modelo (entrada em bolsa pendente, ronda de financiamento a esgotar-se, aquisição provável)? 6. Em que jurisdição está incorporado o operador? Em que país estão fisicamente os servidores? Se diferem, que legislação nacional se aplica ao tratamento? 7. O que aconteceria se uma ordem de informações válida na jurisdição do operador pedisse a entrega dos meus dados? A empresa poderia cumpri-la tecnicamente? 8. Que capacidade técnica retém o operador para suspender, bloquear ou eliminar o serviço? Sob que pressupostos contratuais? Sob que pressupostos não contratuais historicamente documentados? 9. Que plano de saída existe se o operador exercer essa capacidade contra mim, justa ou injustamente? Há um procedimento documentado de exportação de dados para um fornecedor alternativo? 10. Quem controla as credenciais de acesso? O operador pode repô-las sem a minha participação? Isso protege-me ou expõe-me? 11. Existe uma alternativa europeia, auto-hospedada ou sem servidor pelo meio para esta função concreta? Qual é o seu custo real, comparado com o risco avaliado? 12. Se a decisão de hoje fosse examinada daqui a cinco anos por um inspetor, um auditor ou um cliente afetado por uma violação, a escolha atual seria defensável com os argumentos disponíveis hoje, ou exigiria pedir desculpa por não ter feito perguntas razoáveis? As perguntas não esperam respostas perfeitas. Esperam respostas honestas, que o operador honesto sabe dar e o operador menos honesto evita formular com precisão. A diferença operacional entre as duas classes de operador, dizemo-lo sem dramatismo, costuma percecionar-se lendo devagar as respostas que oferecem voluntariamente, antes mesmo de ter de pedir mais. --- *Com este artigo encerramos o segundo ciclo dos Cuadernos Lacre. Começámos com a dívida editorial herdada de Schrems II e terminamos com um questionário operacional. Pelo caminho percorremos conceitos —hash, cifragem, identidade— e análises aplicadas —kill switch, modelo de negócio, self-hosting—. A intenção editorial declarada da publicação não era sobrecarregar o leitor com a lista exaustiva de problemas, mas entregar-lhe ferramentas para que distinga, perante qualquer serviço novo, que tipo de resposta está a aceitar. Essa distinção —entre arquitetura e promessa— é a ferramenta. O resto cada profissional o colocará ao serviço dos dados que considere, na sua prática, dignos da pergunta.* ## Fontes e leitura adicional - Esta publicação, ciclo 2 (maio de 2026) — *Schrems II, cinco anos depois*, *O que é realmente o SHA-256*, *Kill switch e a captura institucional*, *Cifragem de ponta a ponta explicada a sério*, *O modelo de negócio como sinal de confiança*, *As 24 palavras: o que é uma identidade criptográfica*, *Self-hosting como prática profissional*. Os sete artigos sobre os quais assenta este questionário. - Regulamento (UE) 2016/679 — Regulamento Geral sobre a Proteção de Dados. Quadro jurídico de referência para todas as perguntas que o questionário coloca, em particular os artigos 5.º, 6.º, 25.º, 28.º, 32.º, 33.º e o capítulo V. - Comité Europeu para a Proteção de Dados — diretrizes e pareceres operacionais sobre Schrems II, transferências internacionais, avaliações de impacto e responsabilidade proativa (publicações 2020-2024). - Agência Espanhola de Proteção de Dados — sanções publicadas 2022-2024 a responsáveis pelo tratamento por instrumentos inadequados de transferência ou por avaliações de impacto formais sem conteúdo substantivo. - noyb.eu — Centro Europeu para os Direitos Digitais, dirigido por Maximilian Schrems. Repositório público de denúncias, recursos e análises sobre o cumprimento real, não aparente, das normas europeias de proteção de dados. --- *Cuadernos Lacre · Uma publicação da Menzuri Gestión S.L. · escrita por R.Eugenio · editada pela equipa do Solo2.* *https://solo2.net/pt/cadernos/*