A cena é quase um déjà vu para quem trabalha com sistemas de informação crítica: uma figura pública retorna de um período de ausência, posa para fotos estrategicamente montadas — documentos sobre a mesa, postura estudada, iluminação favorável — e o ciclo de notícias ganha um novo fôlego. O Observador, na semana passada, capturou esse fenômeno ao descrever a volta de uma liderança ministerial que, após férias, surgiu com polo pastel e uma encenação de trabalho intenso que nas redes virou piada instantânea. Mas por que isso interessa a quem desenvolve software, arquiteta sistemas ou lida com dados em escala?
Porque o que está em jogo não é a performance individual, mas a arquitetura de informação que sustenta — ou deixa de sustentar — a confiança pública. Quando a única forma que uma instituição encontra para demonstrar que está trabalhando é uma pose de escritório com papéis espalhados, temos um sintoma claro: o sistema de informação que deveria gerar transparência contínua falhou. E essa falha não é política, é técnica. Ela se manifesta em dashboards desatualizados, APIs quebradas, portais de dados abertos que só recebem atualização quando a imprensa pressiona, e workflows de aprovação que transformam qualquer métrica operacional em peça de ficção.
A síndrome da pose IKEA nos sistemas de gestão pública
Chamo de "pose IKEA" aquela situação em que tudo parece montado e funcional no momento da fotografia, mas basta um toque para perceber que não há parafusos segurando a estrutura. Nos sistemas que desenvolvemos para o setor público — e já liderei equipes que entregaram soluções para secretarias de fazenda e órgãos de controle —, o maior erro de projeto é otimizar para o momento da prestação de contas, não para a operação contínua. Cria-se um banco de dados que responde bem a consultas trimestrais, mas trava nos processos diários de alimentação.
A fonte do Observador relata que "os atrasos das finanças só se lembram de trabalhar quando sai nas notícias". Traduzindo para linguagem de sistemas: não há sensores, nem logs, nem esteiras de processamento que gerem visibilidade em tempo real. A instituição opera com planilhas que são consolidadas manualmente uma vez por mês, e o indicador de desempenho só é atualizado quando um cidadão ou jornalista faz uma solicitação formal. Isso não é má vontade — é um problema de arquitetura de informação. E arquitetura de informação mal resolvida, mais cedo ou mais tarde, produz crises de imagem que nem a melhor foto de escritório consegue disfarçar.
O paralelo com engenharia de software é direto: se você depende de um deploy manual em ambiente de produção porque seu pipeline de CI/CD não foi configurado, mais cedo ou mais tarde alguém vai tirar print da tela vermelha e viralizar. A diferença é que, no setor privado, o custo é financeiro e a correção pode ser feita em silêncio. No setor público, o custo é reputacional e a correção vira espetáculo.
Documentos espalhados como metáfora de dados desconectados
A imagem dos documentos sobre a mesa não é apenas uma encenação política — é a representação física do maior problema de integração de dados que existe. Cada pasta representa uma fonte de dados que não conversa com as outras. A pasta azul é o sistema de folha de pagamento, a verde é o orçamento empenhado, a amarela são os contratos emergenciais. Não há um data lake, não há um barramento de eventos, não há uma camada de integração que normalize esses registros e permita consultas horizontais.
Numa conversa com um gestor público ano passado, ele me confessou: "a gente sabe que tem um rombo na previdência, mas são três sistemas diferentes que calculam a alíquota de formas distintas. Nenhum diretor técnico consegue bater o número". Esse é o custo real da falta de governança de dados: você gasta energia discutindo qual número está certo, em vez de discutir o que fazer com o número. A pose IKEA com documentos na mesa tenta criar a ilusão de que há controle, mas quem entende de integração enxerga ali o caos operacional disfarçado.
Do ponto de vista de arquitetura de sistemas, a solução não passa por desenvolver mais um portal de transparência monolítico. Passa por criar camadas de abstração que permitam que sistemas legados — mainframes dos anos 80, ERPs dos anos 90, planilhas dos anos 2000 — exponham seus dados por APIs padronizadas, mesmo que em lotes diários. O padrão que mais funcionou em projetos que liderei foi o Event Sourcing com CQRS: audita-se cada alteração como um evento imutável e constroem-se visões materializadas para consulta. A transparência deixa de ser um "print mensal" e vira um fluxo contínuo de eventos que podem ser verificados por qualquer cidadão que tenha acesso a um cliente REST.
IA aplicada à detecção precoce de crises reputacionais
Se a fonte do Observador aponta que a crise gera a lembrança de trabalhar, meu argumento é que isso deveria ser automatizado. Modelos de linguagem natural treinados em atas de reunião, releases oficiais e notícias locais conseguem, com precisão razoável, identificar quando uma instituição está entrando em ciclo de baixa transparência. O padrão é quase sempre o mesmo: queda no volume de publicações de dados abertos, aumento no tempo de resposta a pedidos de informação, pico de comunicações internas próximas a datas de fechamento fiscal.
Não estou falando de uma IA que substitua decisão humana. Estou falando de um sistema de alerta precoce que acenda uma luz amarela no dashboard do controlador interno, sinalizando que aquele órgão está se aproximando de um ponto crítico onde a "pose IKEA" será a única saída. Projetamos algo similar para um tribunal de contas: um modelo treinado em séries históricas de transparência que, ao detectar anomalias nos padrões de publicação, gera automaticamente recomendações de auditoria. Reduziu em 40% o tempo entre o desvio e a intervenção corretiva.
Mas há um trade-off importante: a curadoria dos dados de treinamento. Se o modelo for treinado exclusivamente sobre notícias de crise, ele vai confundir ruído comunicacional com falha operacional. É preciso equilibrar com dados brutos de sistemas transacionais — execução orçamentária, folha, licitações — para que o modelo aprenda a diferença entre "estão fazendo marketing de crise" e "estão realmente com problemas de fluxo de caixa". Sem isso, a IA vira mais um instrumento de performance teatral, alimentando o ciclo que se propõe a quebrar.
O papel da engenharia de software na quebra do ciclo de encenação
Não basta apontar o problema. Como engenheiro de sistemas que já esteve dos dois lados do balcão — desenvolvendo soluções para governo e testando os mesmos sistemas como cidadão —, vejo três alavancas concretas que poderiam desmontar a lógica da pose IKEA:
- Padronização de interfaces de dados: enquanto cada órgão público usar um formato proprietário de exportação, o cidadão e o jornalista vão depender de "furos de reportagem" ou "dossiês montados na mesa". Uma lei de dados abertos que obrigue APIs REST com contratos OData ou GraphQL, por exemplo, força a integração a ser resolvida na camada de infraestrutura, não na mesa do gestor.
- Dashboards com proveniência rastreável: um indicador de desempenho só deveria ser considerado válido se sua origem for rastreável até o evento que o gerou. Hoje, a maior parte dos painéis de transparência pública exibe números que vieram de planilhas exportadas manualmente, sem hash de verificação nem carimbo de tempo blockchain. Implementar imutabilidade no registro de métricas operacionais elimina a possibilidade de "arrumar o número antes da foto".
- Auditoria contínua por IA geracional: modelos de linguagem podem ser configurados para comparar automaticamente o discurso público com os dados reais dos sistemas transacionais. Se o ministro diz que "as finanças estão em dia" mas o sistema de ordens bancárias mostra 70% de pagamentos em atraso, o modelo gera um alerta que vai direto para o controlador, sem depender de um jornalista fazer a ponte. É o fim da assimetria informacional.
Nenhuma dessas soluções é trivial. A primeira exige investimento em modernização de legados que ninguém quer mexer. A segunda demanda cultura de engenharia de dados que ainda é escassa no serviço público. A terceira enfrenta resistência política porque, convenhamos, transparência real incomoda quem construiu carreira em cima da opacidade. Mas o custo de não fazer nada é continuar vendo polos pastéis e poses IKEA como única estratégia de comunicação de crise.
Privacidade em produto e o dilema dos dados públicos
Uma objeção comum que ouço quando defendo rastreabilidade extrema é: "e a privacidade dos agentes públicos?" De fato, expor dados operacionais granulares pode revelar padrões de comportamento individual — quem aprovou o quê, quando, em que horário. E aí entramos num terreno delicado. Minha posição técnica é que dados de agentes públicos em exercício de função pública não gozam do mesmo regime de privacidade que dados de cidadãos comuns, mas isso não significa que qualquer exposição seja aceitável.
O desenho de produto precisa balancear granularidade e anonimização. É possível, por exemplo, expor o fluxo de aprovação de uma despesa sem revelar o nome do servidor que autorizou cada etapa — usa-se identificadores funcionais e agrega-se por setor. O que não pode acontecer é o apagão completo, onde o dado simplesmente não existe até que alguém faça a pose com os papéis na mesa. O trade-off aqui é entre accountability e segurança do servidor. Não é um falso dilema, e cada implementação precisa de uma avaliação de impacto à privacidade (RIPD) nos moldes da LGPD, mesmo quando o objeto são dados governamentais.
Lições de implementação e o futuro dos sistemas de comunicação pública
Os projetos de transparência que vi darem certo compartilham uma característica: eles foram desenhados pensando no pior cenário de uso. Não no usuário ideal que sabe SQL, mas no cidadão com um smartphone e conexão 3G instável. Isso significa APIs leves, respostas em menos de 200ms, dados disponíveis em formato JSON e CSV simultaneamente, e documentação que um estudante de ensino médio consegue seguir. Quando o sistema é robusto para o pior caso, ele naturalmente serve bem ao jornalista, ao auditor, ao ministro.
A crise descrita pelo Observador — a volta de férias com polo pastel e pose IKEA — não se resolve com nova estratégia de comunicação. Ela se resolve com sistemas que tornem a comunicação supérflua, porque os dados já falam por si, em tempo real, sem necessidade de encenação. O desafio é que construir esses sistemas exige investimento em capital humano e tecnológico que, no ciclo político curto, parece "custo sem retorno eleitoral". Mas, como engenheiro, aprendi que as melhores decisões de arquitetura são aquelas que não aparecem na foto — até que a crise chega, e o sistema aguenta.
Recomendo a todo gestor público que leia o relato da encenação burocrática não como piada política, mas como diagnóstico de um sistema de informação falido. E a todo profissional de tecnologia, que veja ali uma oportunidade gigantesca de projetar a próxima geração de sistemas de transparência pública. Porque, no fim, a verdadeira "crise" não é o gestor de polo pastel: é a arquitetura que permite que essa seja a única imagem de trabalho disponível.