Entre 28 de julho e 1º de agosto de 2025, participei do Programa Internacional Comunitas - uma imersão em Cambridge e Londres que reuniu prefeitos, secretários estaduais e dirigentes federais brasileiros para trocar experiências com líderes e instituições britânicas sobre a transformação digital do Estado.

Ao longo de cinco dias, vimos que por trás dos gráficos e das promessas de “modernização” havia sempre a mesma questão: como fazer a tecnologia servir à política pública, e não o contrário.

O momento que cristalizou essa percepção aconteceu no primeiro intervalo no Møller Institute, em Cambridge.

Em volta de uma mesa de café, gestores de diferentes níveis e origens começaram a contar histórias: aplicativos lançados com alarde e abandonados meses depois; sistemas caríssimos que não melhoraram um único serviço; e raros casos de sucesso sustentados ao longo de anos.

Um prefeito resumiu em tom confessional: “Comprei software, não comprei solução". Ali, longe das apresentações oficiais, veio o consenso: transformação digital é política pública, não catálogo de software.

Essa frase é mais do que um slogan. Ela reorganiza prioridades. Se tecnologia é meio - poderoso e indispensável, mas meio - a pergunta que abre qualquer projeto deveria ser outra: que valor público isso cria? Tempo devolvido ao cidadão? Redução de custos de transação para pequenas empresas? Melhora na qualidade da decisão administrativa? Sem uma resposta clara, o melhor código vira ruído caro.

Foi com essa lente que revisitamos três experiências que, à primeira vista, parecem puramente técnicas e, no entanto, são essencialmente políticas.

A primeira é o NUAR (National Underground Asset Register), o registro britânico de ativos subterrâneos. Durante anos, cada concessionária e órgão público mantinha mapas próprios de cabos e tubulações.

Obras pararam por causa de fios “invisíveis”, rombos de orçamento aconteciam por falta de informação compartilhada. O NUAR levou sete anos para sair do papel. Não por capricho, mas porque exigiu uma lei que obrigasse a cooperação e um arranjo de governança capaz de lidar com resistências legítimas: quem paga pelo mapeamento? Quem responde por erro? Quem pode acessar e em que condições?

O triunfo do NUAR não é um software elegante; é a construção paciente de uma mesa em que todos permaneceram - e permanecem porque a regra é clara e o benefício coletivo supera o incômodo individual.

Padrões técnicos comuns

A segunda experiência é o LOTI (London Office of Technology and Innovation), que conhecemos em Londres. O LOTI não é um laboratório com vitrines; é um acordo duradouro entre os 32 boroughs (espécie de subprefeituras) da capital para trabalhar como sistema.

Isso significa padrões técnicos comuns, projetos compartilhados, compras coordenadas e, sobretudo, um fórum onde a prática de um distrito passa a ser ponto de partida para o vizinho.

Sem o LOTI, cada borough seguiria acumulando pequenos sistemas incompatíveis com os demais; com o LOTI, a cidade ganha interoperabilidade e economias de escala. É uma política de articulação, confiança e objetivos compartilhados traduzida em linhas de código que conversam.

A terceira peça é o ecossistema de inovação de Cambridge. A tentação é falar de universidades e startups, mas o que vimos foi outra coisa: rotina. Pessoas, processos e instituições que fazem da colaboração um hábito e não um evento.

O IdeaSpace e estruturas como Cambridge Enterprise operam como “safe place to fail”: ambientes onde errar bem — com hipótese explícita, objetivo mensurável e aprendizado documentado — é parte do método, não um desvio. O que se celebra ali não é o pitch mais vistoso, mas a capacidade de iterar com responsabilidade até que uma solução prove seu valor.

Esses casos expõem dilemas universais que gestores públicos reconhecem de longe. O primeiro é velocidade versus qualidade. A pressão por mostrar serviço é legítima - e necessária. Mas a tecnologia mal planejada tem um efeito colateral perverso: cristaliza maus processos. Automatiza burocracia ruim. O ganho de curto prazo vira custo estrutural.

O segundo dilema é inovação versus accountability. Como experimentar sem abrir mão de controle e responsabilidade? A resposta não está em blindagens retóricas, e sim em desenho institucional: fases de teste com critérios de saída, métricas públicas de desempenho, comitês que acompanham riscos e portas claramente marcadas entre piloto e escala.

O Brasil não começa do zero. Gov.br e Pix mostram que, quando liderança e governança se combinam, impacto e continuidade andam juntos. O Gov.br organizou mais de quatro mil serviços sob uma identidade única, reduzindo o labirinto de senhas e formulários.

O Pix, ao atacar a fricção de transferir recursos, transformou comportamento cotidiano e criou uma infraestrutura compartilhada que novos serviços podem aproveitar. Nenhum dos dois é “apenas tecnologia”: são decisões políticas que criaram bases comuns sobre as quais soluções florescem, e que foram aperfeiçoadas com o tempo.

Há uma tentação recorrente, porém, que precisamos resistir: importar “apps campeões” como se fossem plug-and-play. O aprendizado que trouxemos na mala aponta para outra direção. Em vez de colecionar ferramentas, construir estruturas. Em vez de anúncios, estabelecer ritos de governança. Em vez de reinventar roda, publicar padrões (técnicos e de dados) que reduzam ambiguidade e apliquem disciplina ao entusiasmo.

Ecossistemas colaborativos

É nesse ponto que a viagem também iluminou o papel de lideranças que seguram o leme. Projetos longos, como o NUAR, sobrevivem porque alguém com mandato e legitimidade decide que vale insistir, sustenta o diálogo entre atores que não se falam espontaneamente e protege o aprendizado quando as coisas saem do previsto.

No LOTI, a liderança aparece menos em discursos e mais no trabalho de arrumar a mesa: definir prioridades comuns, dar transparência às métricas, criar incentivos para compartilhar o que funciona e abandonar o que não funciona - rápido, sem drama.

O que fazer daqui em diante? Antes de pensar em compras, definir o problema público com clareza. Antes de “codar”, publicar padrões e acordar governança. Antes de lançar, pilotar com critérios e comunicar expectativas. Depois de lançar, medir e ajustar com base no uso real, não na apresentação. E em todas as etapas, lembrar que tecnologia multiplica aquilo que encontra: sem liderança e governança, amplifica a desordem; com elas, multiplica produtividade, reduz custos e devolve tempo para resolver problemas que importam.

Este é o ponto de partida para uma série de três artigos que vou publicar nas próximas semanas. Na próxima oportunidade, abordarei a importância dos dados e da confiança: como a experiência do cidadão legitima (ou corrige) as escolhas digitais.

No terceiro texto, irei concluir abordando a importância dos ecossistemas colaborativos: por que inovação pública só escala quando há redes que conectam governo, academia, empresas e sociedade civil, com ambientes seguros para experimentar e aprender.

Porque no fundo, e foi isso que Londres e Cambridge nos ensinaram, ninguém transforma o Estado sozinho (nós o fazemos juntos!) — e tecnologia, por melhor que seja, não substitui o trabalho de construir instituições que durem.