"Construir ou comprar" no setor público: a IA está a mudar as regras do jogo

Há um dilema que aparece quase sempre que se fala de tecnologia na administração pública: desenvolver internamente ou contratar fora. Durante anos, essa pergunta era apresentada como uma escolha estratégica mas muitas vezes a realidade era mais simples - não havia equipas internas para construir com velocidade, consistência e segurança, e por isso “comprar” (ou contratar) era o caminho natural, mesmo quando isso significava aceitar soluções pouco ajustadas, dependências prolongadas e um certo fatalismo do “é o que é”.

A Inteligência Artificial está a mexer no equilíbrio de poder

O que está a acontecer agora, com a inteligência artificial, é mais disruptivo do que parece à primeira vista, precisamente porque mexe na premissa que sustentava o modelo: a ideia de que construir é "sempre caro, lento e reservado a equipas grandes e altamente especializadas". A IA não resolve tudo, não substitui engenharia, e não apaga a necessidade de governação mas está a reduzir o custo de transformar uma ideia num protótipo, e um protótipo num MVP funcional.

Não é só porque se escreve código mais depressa. É porque, pela primeira vez em muito tempo, o build pode deixar de ser uma opção teórica e passar a ser uma opção praticável, com equipas menores, desde que tenham as pessoas certas.

A democratização do “construir”

Quando se diz que a IA democratiza o desenvolvimento, há quem imagine um cenário quase caricato onde qualquer pessoa escreve meia dúzia de frases e sai dali um sistema pronto a ir para produção. Não é isso que está em causa, e até acho que essa caricatura atrapalha a discussão, porque permite que se descarte o tema com um sorriso e um “isso não é realista”.

O que é realista é que ferramentas como Claude Code, OpenAI Codex e outras estão a encurtar brutalmente a distância entre quem entende o problema e quem consegue materializar uma solução minimamente funcional - nem que seja para validar hipóteses. Isto tem impacto em todos os setores mas no setor público é especialmente relevante porque existe muito conhecimento de negócio concentrado em pessoas que não têm disponibilidade para projetos que consomem imensas horas, sessões infindáveis de “passagem de conhecimento” a equipas externas, nem tempo para estar meses a explicar, refinar, reexplicar, voltar atrás e recomeçar, até alguém conseguir traduzir isso para requisitos, para user stories, para especificações ou para desenvolvimento.

A IA não elimina a necessidade de programadores, até porque o código precisa de revisão, validação, testes, integração e responsabilidade mas muda o que é mais caro num projeto: a fricção. A fricção de traduzir o conhecimento para quem vai executar, a fricção de esperar por janelas de desenvolvimento, a fricção de depender de um backlog interminável onde “o que é importante” compete sempre com “o que é urgente”. E, sobretudo, a fricção de só se descobrir se o fluxo faz sentido quando o sistema já está pesado, caro e politicamente difícil de mexer.

Com a IA, um protótipo passa a ser uma ferramenta de decisão e isso tem um valor enorme num contexto onde tantas decisões são tomadas por intuição, por memória, por medo do risco ou simplesmente porque não há tempo para medir e experimentar.

O que muda no setor público: menos equipas, mais desenho e mais autonomia

Se tivéssemos de resumir a mudança a um ponto, eu diria que a IA favorece organizações que consigam trabalhar com equipas menores, mas mais maduras, e com foco no que interessa: desenho de solução, arquitetura, integração e impacto no serviço.

No meu entendimento, a nuance mais importante é que a IA não elimina a necessidade de perfis técnicos, pelo contrário, pode até aumentar a importância de certos perfis porque acelera a produção e, quando se acelera a produção, os erros e a entropia também aceleram. O “bloqueio” real, para muitas entidades públicas, passa a ser menos “quantas pessoas consigo ter a escrever código” e mais “consigo ter as pessoas certas a orientar, desenhar, integrar e governar”.

Arquitetos, solution designers e outros perfis seniores são mais escassos e caros, a administração pública, nos moldes atuais, tem dificuldade em competir por estes recursos. Ou seja, a IA democratiza o "construir" mas desloca o problema para um sítio mais exigente - a qualidade do desenho e a responsabilidade técnica, uma organização pode produzir mais depressa mas se não tiver uma espinha dorsal de arquitetura e governação, produz mais depressa soluções que não se aguentam.

Ao mesmo tempo, a oportunidade é real porque para departamentos de IT pequenos, enfraquecidos e dependentes, começa a ser plausível imaginar equipas internas mais ágeis, com menos pessoas, mas proativas e dinâmicas, capazes de construir e evoluir componentes com autonomia e sem precisar de “pedir apoio” ao mercado para cada iteração. O impacto disso na dependência do fornecedor é óbvio: menos vendor lock-in por inércia ou falta de capacidade técnica, menos condicionamento, mais capacidade de decisão informada.

E isto é onde o setor público pode ganhar muito, não porque vai passar a “fazer tudo sozinho” mas porque pode deixar de ser refém de um modelo em que o conhecimento sai pela porta sempre que o contrato acaba e em que cada melhoria vira uma negociação, um aditamento, um novo ciclo de contratação, um novo risco de continuidade.

A parte desconfortável: muitos fornecedores vão ter de deixar de vender presença

Durante muito tempo, o modelo dominante de prestação de serviços ao Estado foi simples: colocar uma equipa disponível, abrir o "taxímetro" e ir “fazendo” em função do que o cliente vai pedindo. Isto não é necessariamente má-fé, muitas vezes é consequência do próprio modelo de contratação, que paga esforço e capacidade, não necessariamente resultado e impacto. Só que esse modelo depende da "condição" de que o cliente não tenha alternativa, que não consiga executar internamente e que não consiga testar ou prototipar sem depender do fornecedor.

Quando uma entidade pública consegue, com uma equipa pequena e focada, produzir protótipos rapidamente, clarificar requisitos com menos ruído, acelerar ciclos de feedback e até desenvolver partes do sistema com mais autonomia, torna-se muito mais difícil justificar um fornecedor que vende apenas “mão-de-obra” e “presença”. Não só porque tudo fica mais rápido mas também fica mais evidente quando se está a perder tempo nas minudências, nas discussões infinitas de detalhe, no refinamento que não desbloqueia decisões, e no “andar às voltas” com a sensação de avanço. E aqui o imediatismo da IA é implacável: se o mercado consegue entregar mais depressa, o cliente vai exigir valor mais depressa. Não quer dizer que os projetos complexos deixem de ser complexos, quer dizer que a paciência para pagar complexidade mal gerida vai diminuir.

O que me parece inevitável é uma migração para modelos onde a proposta de valor do fornecedor passa a estar muito mais ligada a responsabilidade. Garantir coerência, garantir integração, garantir segurança, garantir resultados, reduzir risco real e entregar impacto mensurável, em vez de apenas absorver trabalho - deixo apenas uma nota curta aqui porque quero dedicar a próxima reflexão a isto com mais detalhe, tenho visto aparecer a ideia de Results as a Service (RaaS) como reação a esta mudança. Fica para a próxima.

O risco maior: toda a gente a automatizar e ninguém a construir um sistema

Há, no entanto, um risco que me preocupa mesmo e que não se resolve com entusiasmo tecnológico. A facilidade de construir pode levar a uma explosão de soluções “desgarradas” se cada equipa, cada pessoa, cada departamento começa a criar pequenas aplicações para automatizar tarefas mecânicas que hoje se fazem à mão, isso pode gerar ganhos locais rápidos, mas também pode aumentar a entropia global, porque essas aplicações não comunicam entre si, não partilham dados de forma consistente, não seguem uma arquitetura comum e não constroem um verdadeiro sistema.

O resultado pode ser paradoxal, uma vez que automatizamos a execução de tarefas mas a integração continua manual. Criamos mais ferramentas, mas não criamos mais coerência. E, sem uma visão agregadora de arquitetura técnica, aplicacional e de negócio, a Administração Pública arrisca-se a trocar burocracia por fragmentação.

A isto junta-se o risco da confiança cega no código gerado, que pode introduzir fragilidades de segurança, problemas de escalabilidade e decisões técnicas difíceis de manter. Um programador humano também erra mas a diferença é que a IA consegue errar em escala, com grande velocidade, e com uma aparência de “certo” que engana facilmente quem não tem prática de revisão.

É por isso que, para mim, a discussão build vs buy tem de evoluir: já não chega discutir preço, capacidade e prazo. É preciso discutir governança, arquitetura, capacidade de manutenção e responsabilidade técnica, porque construir mais depressa sem uma estrutura mínima para sustentar a evolução vai só criar uma dívida maior, mais cedo.

No fundo, a IA está a deslocar o centro de gravidade. A administração pública pode ganhar autonomia, reduzir dependência e reter conhecimento, mas só se tiver coragem de investir em perfis certos e em arquitetura, e só se não cair na tentação de transformar “facilidade de construir” em fragmentação.

E os fornecedores, se forem inteligentes, não vão lutar contra isto, vão adaptar-se. Porque a pergunta que vai começar a aparecer com mais frequência, de forma muito crua, é esta: se hoje é possível fazer mais com menos, por que razão continuamos a pagar como se fosse impossível?