A Galinha dos Ovos de Ouro Digital

Ou como um Estado pode comprar tecnologia durante décadas até descobrir que deixou de ser dono das suas escolhas.

Há negócios extraordinários.

E depois há negócios em que o cliente compra o produto, paga a manutenção, paga as actualizações, paga a integração, paga o armazenamento, paga a formação, paga a migração e, alguns anos mais tarde, descobre que também terá de pagar uma pequena fortuna se quiser deixar de ser cliente.

É uma espécie particularmente sofisticada de fidelização.

Na linguagem romântica do marketing chama-se ecossistema.

Na linguagem menos perfumada da engenharia chama-se vendor lock-in.

E Portugal parece ter desenvolvido, ao longo de décadas, uma notável facilidade para entrar alegremente nestes ecossistemas, fechar a porta atrás de si e, muito mais tarde, perguntar onde deixaram a chave.

A Microsoft não inventou esta fragilidade portuguesa.

Fez algo muito mais banal e profissional: percebeu-a, integrou-se profundamente no cliente e continuou a vender.

O problema não é a Microsoft

Convém começar por aqui, antes que alguém imagine uma cruzada religiosa contra uma empresa americana ou comece a procurar agentes revolucionários escondidos dentro do kernel Linux.

A Microsoft é uma das maiores empresas tecnológicas do mundo. Desenvolve produtos sólidos, emprega engenheiros de enorme competência, possui uma plataforma cloud gigantesca, dispõe de ferramentas de produtividade e segurança muito sofisticadas e tem uma máquina comercial capaz de compreender profundamente os seus clientes.

Não há nada de surpreendente nisso.

Uma empresa privada existe para vender, crescer, conservar clientes e maximizar o valor do seu negócio.

Não é assim que funciona uma economia de mercado.

O problema começa quando, do outro lado da mesa, está um Estado que não compra tecnologia com a mesma sofisticação com que ela lhe é vendida.

De um lado chegam arquitectos de soluções, especialistas em licenciamento, juristas, economistas, engenheiros cloud, especialistas em segurança e equipas comerciais que conhecem o produto, o contrato, o cliente e a estratégia de expansão.

Do outro pode encontrar-se uma Administração Pública fragmentada, sujeita a ciclos políticos, mudanças de dirigentes, concursos demorados e dificuldades históricas em recrutar e conservar especialistas técnicos ao nível de remuneração do mercado.

É uma assimetria de competência.

E numa negociação tecnológica, a assimetria de competência acaba quase sempre por transformar-se em assimetria económica.

A armadilha que ninguém precisou de montar

O mais interessante é que o lock-in nem sequer precisa de resultar de qualquer conspiração.

Pode nascer simplesmente da acumulação de decisões aparentemente razoáveis.

Primeiro compra-se um sistema operativo. Depois uma plataforma de identidade. Depois correio electrónico. Depois ferramentas de produtividade. Depois colaboração. Depois análise de dados. Depois segurança. Depois gestão de dispositivos. Depois cloud.

Cada decisão, isoladamente, pode ser tecnicamente defensável.

O problema é o efeito acumulado.

O produto seguinte passa a ser escolhido porque integra melhor com o anterior. O terceiro encaixa perfeitamente nos dois primeiros. O quarto reduz custos de integração. O quinto aproveita identidades já existentes.

Dez ou quinze anos depois, aparece uma alternativa interessante.

E então alguém faz a pergunta que devia ter sido feita no primeiro dia:

Quanto custa mudar?

A resposta pode incluir conversão de dados, novas identidades, formação de milhares de funcionários, reescrita de aplicações, migração de correio, reconstrução de integrações, alterações de segurança, revisão de procedimentos e risco operacional.

Nesse momento, o fornecedor já não precisa de prender o cliente.

O cliente construiu sozinho a própria prisão.

Portugal não está a discutir uma hipótese abstracta

A presença do ecossistema Microsoft na Administração Pública portuguesa não é uma fantasia. Os próprios procedimentos públicos mostram aquisições e subscrições recentes associadas a Microsoft 365, Microsoft Project, Power BI, Azure e outras formas de licenciamento Microsoft, frequentemente com a fórmula juridicamente prudente «ou equivalente».

Isto não demonstra qualquer irregularidade.

Também não demonstra, por si só, que as soluções adquiridas fossem tecnicamente erradas ou economicamente desvantajosas.

Demonstra apenas algo que merece ser analisado: o peso estrutural de um determinado ecossistema tecnológico dentro da máquina pública portuguesa.

E quanto mais estrutural se torna uma tecnologia, menos sensato é avaliar futuras aquisições apenas pelo preço da licença seguinte.

Portugal possui, aliás, legislação, orientações e estruturas dedicadas à interoperabilidade e às normas abertas. Portanto, o problema não pode ser reduzido à ausência de princípios.

O desafio é transformar esses princípios em arquitectura, contratação, conhecimento interno e capacidade real de dizer não.

Bruxelas já deu um nome ao problema

Esta discussão deixou há muito de pertencer ao pequeno universo dos defensores militantes do software livre.

A própria União Europeia reconhece explicitamente o vendor lock-in como um problema de contratação, concorrência, interoperabilidade, portabilidade e autonomia tecnológica.

As orientações do Interoperable Europe Portal são particularmente claras: o lock-in pode tornar técnica, jurídica ou economicamente difícil mudar de fornecedor; pode aumentar custos de longo prazo, limitar a concorrência, prejudicar a portabilidade de dados e reduzir a autonomia operacional das autoridades públicas.

E a recomendação europeia é exactamente aquilo que qualquer bom arquitecto de sistemas defenderia: formatos documentados, APIs conhecidas, direitos claros sobre informação e configurações, transferência de conhecimento, cláusulas de saída e capacidade prática de um fornecedor alternativo assumir a solução.

Mais significativo ainda: em 25 de Junho de 2026, a Comissão Europeia comunicou a sua posição preliminar de que Microsoft Azure e Amazon Web Services deveriam ser designadas gatekeepers ao abrigo do Digital Markets Act.

Entre os factores referidos encontram-se precisamente bases de utilizadores fortemente estabelecidas, grandes ecossistemas, efeitos de lock-in e elevados custos de mudança.

Portanto, quando alguém fala de dependência tecnológica, não está necessariamente a inventar um monstro debaixo da cama.

Bruxelas já acendeu a luz.

A primeira regra: antes de entrar, saber sair

Todos os grandes contratos tecnológicos públicos deveriam conter, desde o primeiro dia, uma componente que raramente entusiasma vendedores: um plano de saída.

Antes de contratar uma plataforma, o Estado deveria saber como serão exportados os dados, em que formatos, através de que interfaces, com que documentação, em quanto tempo, com que assistência e a que custo.

Deveria saber quem possui as configurações, os scripts, os modelos de dados, os conectores, a documentação técnica e o conhecimento necessário para transferir a operação.

A Comissão Europeia está precisamente a avançar nesta direcção através do Data Act. As regras europeias procuram tornar mais simples a mudança entre serviços de processamento de dados e exigem, nomeadamente, mecanismos de portabilidade, interfaces abertas em determinados serviços e exportação de dados em formatos correntes e legíveis por máquina.

A partir de 12 de Janeiro de 2027, o Data Act prevê também a eliminação dos encargos de switching abrangidos pelas suas regras, incluindo determinados custos de saída de dados.

Segunda regra: calcular o preço da dependência

O preço de entrada é uma medida demasiado pobre para uma decisão tecnológica de longo prazo.

O que interessa é o custo total de propriedade: licenciamento, subscrições, infra-estrutura, cloud, formação, integração, administração, migrações, actualizações, armazenamento, transferência de dados e, finalmente, custo de saída.

A própria Comissão Europeia lembra que a falta de interoperabilidade pode ser encarada como um custo ao longo do ciclo de vida de uma contratação.

É exactamente aí que a contabilidade tecnológica se torna adulta.

Duas soluções que custam hoje dez milhões de euros não têm o mesmo preço se uma puder ser substituída daqui a cinco anos sem drama e a outra exigir a reconstrução de metade da Administração Pública.

Terceira regra: padrões abertos por defeito

Documentos públicos deveriam utilizar formatos abertos sempre que tecnicamente adequado.

Interfaces entre sistemas públicos deveriam possuir especificações documentadas. Dados deveriam poder ser exportados em formatos conhecidos. APIs utilizadas em serviços críticos deveriam evitar dependências proprietárias desnecessárias.

Não porque «open» seja uma palavra magicamente virtuosa.

Mas porque interoperabilidade é uma apólice de seguro contra o futuro.

O Reino Unido adoptou há anos princípios formais de padrões abertos para a tecnologia governamental precisamente para promover interoperabilidade, concorrência, flexibilidade e redução do lock-in. As orientações britânicas chegam ao ponto de defender que a dependência tecnológica e a estratégia de saída sejam consideradas desde o início de um projecto.

Não é ideologia.

É engenharia acompanhada de memória institucional.

Quarta regra: open source tem de entrar realmente na competição

Isto não significa decretar: «A partir de amanhã tudo será Linux.»

Seria apenas substituir uma religião por outra, e a humanidade já possui religiões suficientes.

Linux, PostgreSQL, LibreOffice, Nextcloud, Kubernetes, OpenStack e milhares de outras tecnologias abertas devem poder competir sempre que façam sentido.

Microsoft, Oracle, IBM, Google, Amazon e qualquer outro fornecedor também.

Mas competir verdadeiramente.

A Comissão Europeia adoptou em Junho de 2026 uma nova estratégia para ecossistemas digitais abertos, relacionando software open source, interoperabilidade, resiliência e soberania tecnológica.

A abordagem correcta não é «open source contra software proprietário».

É impedir que a arquitectura do concurso seja escrita de tal maneira que apenas a solução já instalada consiga realisticamente ganhar.

Quando uma especificação diz «ou equivalente», mas todas as dependências, integrações, formatos e competências internas foram construídos durante vinte anos em redor de um único produto, a palavra «equivalente» pode tornar-se uma pequena peça de literatura administrativa.

Quinta regra: o Estado precisa de cérebros próprios

Esta talvez seja a regra decisiva.

Portugal nunca terá verdadeira soberania tecnológica se o Estado não conseguir recrutar, conservar e valorizar engenheiros altamente competentes.

Não basta contratar consultoras. Consultoras são úteis. Fornecedores são úteis. Integradores são úteis.

Mas alguém do lado do Estado tem de compreender suficientemente bem a arquitectura para fazer a pergunta que todo o fornecedor prefere não ouvir:

«Prove.»

Prove que precisamos desta licença. Prove que esta integração exige este produto. Prove que não existe alternativa. Prove o custo total em dez anos. Prove que conseguimos sair.

O Estado precisa de arquitectos de sistemas, especialistas em segurança, administradores de bases de dados, engenheiros de redes, especialistas cloud, programadores, especialistas em inteligência artificial e profissionais de procurement tecnológico suficientemente bons para negociar de igual para igual.

E precisa de lhes oferecer carreiras técnicas onde seja possível progredir sem que o prémio por ser um excelente engenheiro seja deixar de fazer engenharia e passar a preencher mapas de férias.

Sexta regra: dividir para continuar livre

Outro erro clássico consiste em concentrar demasiadas funções no mesmo fornecedor: identidade, correio, documentos, colaboração, cloud, segurança, Business Intelligence e gestão de dispositivos.

Quanto mais verticalmente integrada fica a solução, mais cara se torna a substituição de qualquer uma das peças.

A arquitectura pública deveria ser modular sempre que razoável.

Componentes substituíveis. Interfaces claras. Dados portáveis. Baixo acoplamento.

É uma velha ideia da engenharia de software que também funciona admiravelmente bem em contratação pública:

aquilo que pode ser substituído continua negociável.

Sétima regra: medir a dependência

Portugal deveria publicar regularmente um verdadeiro mapa da dependência tecnológica da Administração Pública.

Não mais um portal com três círculos coloridos e uma fotografia de um governante diante de um tablet.

Um mapa técnico.

Quanto gastamos por fornecedor? Quantos sistemas críticos dependem de tecnologias proprietárias específicas? Quantos possuem alternativas operacionais? Quantos permitem exportação integral dos dados? Quantos usam padrões abertos? Quantos contratos possuem cláusulas de reversibilidade? Quanto custaria abandonar cada plataforma dominante? Quanto conhecimento está dentro do Estado e quanto existe exclusivamente dentro do fornecedor?

Aquilo que não se mede transforma-se facilmente em «sempre fizemos assim».

Não se trata de expulsar a Microsoft

Imaginemos que, depois de todas estas regras, a Microsoft continua a ganhar determinado concurso.

Perfeitamente.

Nesse caso, ganhou porque apresentou a melhor solução dentro de uma competição real.

Não porque vinte anos de dependências tornaram praticamente impossível escolher outra.

Essa diferença é gigantesca.

Num mercado saudável, o fornecedor deve saber que o cliente pode partir.

Essa possibilidade mantém preços sob pressão, obriga à inovação e produz um fenómeno extraordinário: comerciais extremamente atentos às necessidades do cliente.

Quando o fornecedor percebe que o cliente praticamente não pode sair, a relação muda.

O casamento transforma-se numa hipoteca tecnológica.

A verdadeira soberania digital

Soberania tecnológica não significa fabricar computadores portugueses numa fábrica em Trás-os-Montes e baptizar o sistema operativo de LusitanoOS.

Significa algo muito menos folclórico e muito mais importante.

Ter escolha.

Escolher onde ficam os dados. Escolher quem os processa. Escolher quem fornece os serviços. Escolher tecnologias europeias quando fizer sentido. Escolher open source quando for melhor. Escolher Microsoft quando Microsoft for melhor.

E conseguir mudar amanhã.

Esta última frase contém quase toda a política tecnológica de que precisamos.

Um Estado tecnologicamente adulto não pergunta apenas: «Que produto vamos comprar?»

Portugal passou demasiado tempo a comprar tecnologia como quem compra mobiliário: escolhe-se, instala-se, paga-se e presume-se que o assunto terminou.

Mas sistemas digitais não são cadeiras.

Criam dependências. Acumulam dados. Moldam processos. Condicionam decisões futuras.

Está na altura de o Estado começar a comprar não apenas produtos, mas também independência futura.

A Microsoft poderá continuar a vender-nos excelentes soluções. Amazon, Google, Oracle, IBM e todas as outras também.

A culpa não está em a galinha pôr ovos de ouro.

O problema é o dono do galinheiro ter oferecido a chave, esquecido onde fica a porta e passado anos a felicitar-se pela modernização.

Um dia perceberemos talvez o princípio mais simples de todos:

o galinheiro pertence ao cliente.

E a porta deve abrir por dentro.

Nota Editorial

Referências credíveis

• European Commission — Interoperable Europe: Public Procurement, interoperability and preventing vendor lock-in
• European Commission — Interoperability and vendor lock-in
• European Commission — Data Act explained: switching between data processing services
• European Commission — Preliminary position on AWS and Microsoft Azure under the Digital Markets Act, 25 June 2026
• European Commission — Open and interoperable digital ecosystems for public administrations, 3 June 2026
• UK Government — Open Standards Principles
• UK Cabinet Office — Architecture Principles: manage technology dependencies and plan exit strategy
• eSPap — Procedimento 2025_P086: licenciamento Microsoft 365, Project, Power BI e Azure, do tipo ou equivalente
• AMA — Regulamentos e orientações: normas abertas, racionalização TIC e interoperabilidade na Administração Pública portuguesa