Como a memória da ditadura molda o design de sistemas de informação no Brasil

O exercício de revisitar o passado de um país não é apenas literário ou historiográfico — é também um ato de engenharia social que reverbera em cada camada de abstração dos sistemas que construímos. Quando Milton Hatoum afirma, em entrevista recente, que “as desgraças começaram na Ditadura Militar”, ele não está apenas resenhando a história brasileira. Está, sem querer, oferecendo uma chave de leitura para compreender por que a arquitetura de sistemas de informação, as políticas de privacidade e até mesmo a cultura de desenvolvimento de software no Brasil carregam marcas profundas daquele período.

Não se trata de um exercício de nostalgia política ou de partidarismo barato. Trata-se de reconhecer que infraestruturas tecnológicas são artefatos culturais e políticos. Quem projeta sistemas de registro civil, bases de dados governamentais, plataformas de vigilância ou mesmo sistemas de autenticação para serviços financeiros está operando dentro de um legado institucional formado décadas atrás. A pergunta que me faço como engenheiro é: será que estamos conscientes disso ao desenhar nossos componentes?

O legado institucional nos sistemas de dados

Hatoum descreve Brasília como o centro da repressão durante a ditadura, um local onde a vigilância e o controle eram mais intensos. Essa concentração de poder informacional não desapareceu — ela se transformou. O Serviço Nacional de Informações (SNI), criado em 1964 e extinto formalmente em 1990, foi substituído por uma miríade de agências, sistemas e bases de dados que, embora mais fragmentadas, mantêm o mesmo princípio centralizador. Quando projetamos sistemas de integração de dados governamentais — como o Conecta SUS, o Cadastro Único ou as plataformas estaduais de matrícula escolar —, estamos trabalhando sobre uma herança que valoriza a centralização em detrimento da autonomia do cidadão.

Na prática, isso significa que muitos engenheiros de software brasileiros, especialmente os que atuam em projetos governamentais ou em fintechs reguladas, enfrentam trade-offs que não existem em países com tradição federativa mais forte ou com histórico de proteção de dados mais antigo. A decisão de centralizar dados biométricos em uma única base nacional, por exemplo, não é puramente técnica: ela carrega um juízo de valor sobre confiança institucional que remonta à década de 1970.

O paradoxo da eficiência versus controle

Há um argumento legítimo de que sistemas centralizados são mais eficientes para a prestação de serviços públicos. Eu mesmo já defendi, em projetos de infraestrutura em nuvem, que a consolidação de dados reduz custos operacionais e simplifica a governança. Mas o que a experiência com clientes governamentais me mostrou é que a centralização raramente vem acompanhada de mecanismos robustos de controle social e transparência. O projeto de um sistema de informação nunca é apenas técnico: ele reflete uma visão de mundo sobre quem merece controlar a informação e quem deve ser controlado por ela.

No Brasil, a Lei Geral de Proteção de Dados (LGPD), sancionada em 2018 e em vigor desde 2020, tenta equilibrar essa balança. Mas é notável que um país com histórico de centralização autoritária tenha demorado tanto para aprovar uma legislação que, em muitos aspectos, ainda é mais permissiva que a europeia. A cultura de “coletar primeiro, perguntar depois” ainda domina muitos projetos de produto digital, especialmente em setores como crédito, seguros e saúde suplementar.

Vigilância como legado técnico

Hatoum relembra que a repressão não era apenas física, mas também informacional. A vigilância durante a ditadura dependia de delatores, dossiês e fichamentos. Hoje, temos algoritmos de recomendação, sistemas de scoring e plataformas de monitoramento de redes sociais. A diferença não é de natureza, mas de escala e precisão. O que antes exigia uma rede de informantes humanos agora pode ser feito por um modelo de machine learning treinado em milhões de posts públicos.

Para quem trabalha com engenharia de dados e inteligência artificial, essa continuidade histórica deveria ser um alerta. Não estou dizendo que todo sistema de recomendação é uma ferramenta de repressão — longe disso. Mas a ausência de reflexão sobre o contexto histórico em que operamos leva a decisões de design que podem replicar padrões de vigilância sem que isso seja intencional. Um exemplo concreto: sistemas de detecção de fraude que utilizam dados de localização, histórico de compras e conexões sociais podem, sem querer, recriar mecanismos de controle populacional que lembram práticas autoritárias.

O papel do engenheiro na concepção de sistemas

Muitos desenvolvedores com quem converso tratam questões de privacidade e vigilância como problemas de compliance ou de relações públicas. “A gente segue a LGPD, está tudo certo”, é a frase que mais escuto. Mas a LGPD é um piso, não um teto. Ela estabelece o mínimo aceitável, não o desejável. Projetar sistemas que respeitem a autonomia do usuário exige ir além da lei: exige uma compreensão do que significa viver em uma sociedade que já foi traumatizada pelo controle estatal.

Em projetos de infraestrutura em nuvem, por exemplo, a escolha entre arquiteturas multi-tenant ou single-tenant, a decisão sobre onde armazenar logs de acesso, a política de retenção de dados — todas essas escolhas técnicas têm implicações políticas. Um sistema que armazena logs de todas as consultas dos usuários por cinco anos pode ser “eficiente” para depuração, mas também cria um acervo de vigilância potencial. O engenheiro que não considera esse contexto está projetando para o pior cenário, mesmo que inconscientemente.

A memória como ferramenta de design

O que a literatura de Hatoum nos ensina é que a memória não é apenas um registro do passado, mas uma ferramenta para interpretar o presente. Aplicado à engenharia de software, isso significa que deveríamos usar a história política brasileira como um dos inputs para nossas decisões de arquitetura. Não se trata de politizar o código, mas de reconhecer que o código já é político — a questão é saber de que forma.

Quando projeto um sistema de autenticação para um serviço público, por exemplo, pergunto: quantos fatores de autenticação são realmente necessários? Onde esses dados serão armazenados? Quem terá acesso? Qual é a política de exclusão? Essas perguntas não são apenas técnicas; elas refletem uma visão sobre a relação entre Estado e cidadão. Um país com histórico de abuso de poder deveria, talvez, ser mais cauteloso ao exigir dados biométricos para o acesso a serviços básicos.

Implicações para produtos digitais

Para gestores de produto e CTOs, o legado autoritário brasileiro impõe uma camada extra de complexidade. Produtos que funcionam bem em mercados como Estados Unidos ou Europa podem encontrar resistência no Brasil não por questões técnicas, mas por desconfiança histórica. Um sistema de crédito baseado em análise de redes sociais, por exemplo, pode ser percebido como invasivo em um país onde a delação foi institucionalizada por décadas.

Isso não significa que devemos evitar inovação, mas sim que precisamos incorporar a sensibilidade histórica ao design de produto. A transparência algorítmica, a explicabilidade de modelos de machine learning e a granularidade no consentimento do usuário não são apenas boas práticas de UX — são respostas diretas a um contexto histórico de abuso informacional. Empresas que ignoram isso correm o risco de enfrentar não apenas rejeição de mercado, mas também regulação mais severa no futuro.

Riscos, limitações e pontos de atenção

Há quem argumente que associar decisões técnicas contemporâneas a eventos históricos é um exagero. “A ditadura acabou faz tempo, a tecnologia é neutra”, diriam. Discordo frontalmente. Tecnologia não é neutra — ela é moldada por quem a projeta, para quem é projetada e sob quais condições. A neutralidade é um mito conveniente para quem não quer assumir responsabilidade pelas consequências de suas escolhas.

Por outro lado, é preciso cuidado para não cair em determinismo histórico. Nem toda base de dados centralizada é um instrumento de repressão. Nem todo sistema de vigilância é herança da ditadura. O que defendo é que a consciência histórica seja mais um critério de decisão técnica, não o único. O equilíbrio entre eficiência, segurança e privacidade exige ponderação, e a história nos dá insumos para fazer essa ponderação de forma mais informada.

Uma perspectiva pessoal sobre o tema

Há alguns anos, participei de um projeto de integração de dados de saúde pública para um estado brasileiro. A equipe estava empolgada com a possibilidade de cruzar informações de prontuários, exames e dispensação de medicamentos para gerar insights epidemiológicos. Do ponto de vista técnico, era um projeto fascinante. Mas, em uma reunião, um colega mais velho — que viveu a ditadura — perguntou: “E se esses dados caírem em mãos erradas?”. A pergunta mudou o rumo do projeto. Implementamos criptografia forte, anonimização por padrão e políticas de acesso baseadas em necessidade real, não em conveniência. O projeto ficou mais caro e mais lento, mas também mais seguro. A memória daquele colega funcionou como um mecanismo de defesa que a engenharia sozinha não teria fornecido.

Esse episódio me convenceu de que a diversidade de perspectivas em equipes de tecnologia não é apenas uma questão de inclusão social — é uma questão de qualidade técnica. Pessoas com vivências diferentes enxergam riscos que engenheiros formados em bolhas técnicas podem ignorar. A memória histórica, nesse sentido, é um ativo de engenharia.

Conclusão: o código como testemunho

Milton Hatoum escreve para que não esqueçamos. Como engenheiros, projetamos sistemas que são, eles também, testemunhos de uma época. Cada linha de código, cada schema de banco de dados, cada política de privacidade reflete as escolhas que fazemos sobre quem controla a informação e com que propósito. Ignorar o contexto histórico em que essas escolhas são feitas é projetar no escuro.

O Brasil carrega as marcas de um período em que a informação era usada como ferramenta de controle. Cabe a nós, profissionais de tecnologia, decidir se vamos replicar esse padrão ou construir algo diferente. A resposta não está nos algoritmos, mas na consciência com que os projetamos.