A dependência tecnológica não é apenas uma discussão entre governos: ela aparece quando uma API muda de preço, um serviço de nuvem fica indisponível ou uma empresa não consegue migrar seus dados sem reescrever metade do sistema. Na Web Summit, Henna Virkkunen, comissária europeia responsável pela soberania tecnológica, segurança e democracia, afirmou que 80% da tecnologia usada na Europa vem de fora do continente. Segundo o Observador.pt, a proposta não é fechar o mercado, mas reduzir dependências arriscadas — uma distinção que também deveria orientar decisões de arquitetura.
O que soberania tecnológica significa para quem desenvolve software
Virkkunen associou tecnologia a competitividade, segurança e poder geopolítico. O ponto prático é que uma dependência pode virar risco operacional mesmo sem um ataque ou uma crise diplomática: basta o fornecedor alterar condições comerciais, encerrar um produto ou restringir o acesso a uma região.
Para uma equipe de desenvolvimento, soberania não significa hospedar tudo em servidores próprios nem evitar empresas estrangeiras. Significa saber de quem se depende, quais dados e serviços estão envolvidos e quanto esforço seria necessário para trocar de fornecedor. Se a resposta para “como saímos daqui?” for “reescrevemos o produto”, existe um risco de arquitetura.
Também é importante tratar a estimativa dos 80% com precisão: trata-se de uma declaração atribuída à comissária na cobertura do Observador.pt, não de uma auditoria técnica detalhada apresentada na notícia. Ainda assim, o debate que ela levanta é concreto: grande parte da infraestrutura digital europeia depende de empresas e tecnologias globais.
Dependências arriscadas existem em várias camadas da stack
É comum pensar em dependência tecnológica como sinônimo de provedor de nuvem. Na prática, o mapa é bem maior. Uma aplicação pode depender do provedor de nuvem, do banco gerenciado, do serviço de identidade, do registro de pacotes, do modelo de IA, do sistema de observabilidade e até de uma única biblioteca mantida por uma pessoa.
- Infraestrutura: regiões disponíveis, serviços proprietários, custos de saída de dados e disponibilidade em situações de crise.
- Software: licenças, atualizações, vulnerabilidades e saúde dos projetos open source usados em produção.
- Dados: localização, controle de acesso, retenção, backups e possibilidade real de exportação.
- IA: termos de uso, política de retenção de prompts, disponibilidade do modelo, custos por token e capacidade de executar uma alternativa.
- Conhecimento: dependência de ferramentas que poucas pessoas na equipe sabem operar ou substituir.
Uma análise séria olha para essas camadas juntas. Um provedor europeu pode reduzir certos riscos jurisdicionais, mas ainda depender de chips, software ou serviços de terceiros de fora da Europa. Da mesma forma, executar um modelo localmente não elimina riscos de licença, segurança, manutenção ou cadeia de suprimentos. “Europeu” não é uma propriedade mágica que torna uma arquitetura automaticamente resiliente.
Nuvem europeia, hyperscalers e portabilidade real
Há alternativas europeias de hospedagem, como OVHcloud, Scaleway e Hetzner, além de opções de implantação própria. Elas podem fazer sentido quando residência de dados, previsibilidade de custos ou controle operacional são requisitos importantes. AWS, Azure e Google Cloud, por outro lado, oferecem uma variedade grande de serviços gerenciados, regiões e integrações. Não existe uma escolha universalmente correta: a decisão depende do risco que se quer reduzir e do custo operacional que a equipe consegue assumir.
Um erro frequente é declarar a aplicação “portável” só porque ela roda em Kubernetes. Kubernetes padroniza o agendamento de contêineres, mas não substitui automaticamente um banco gerenciado, uma fila proprietária, uma função serverless ou um serviço de identidade. Se a lógica de negócio depende dessas APIs, a migração continua exigindo mudanças substanciais.
Portabilidade também tem custo. Manter uma camada de abstração para cada serviço pode aumentar a complexidade e limitar funcionalidades úteis. Eu prefiro identificar primeiro os componentes críticos e definir uma estratégia de saída para eles, em vez de tentar esconder toda diferença entre provedores atrás de uma abstração genérica.
IA: desenvolver modelos próprios ou escolher vários fornecedores?
Virkkunen defendeu acelerar o desenvolvimento de modelos europeus de fronteira e reconheceu que, no momento citado na notícia, os modelos mais capazes vêm dos Estados Unidos e da China. Também ressaltou a importância de envolver a China em conversas sobre segurança da IA. Isso não equivale a recomendar que empresas usem qualquer modelo de qualquer origem sem avaliação: cooperação em segurança e decisão de compra são questões diferentes.
Para uma equipe de produto, as opções mais comuns são usar uma API comercial, executar um modelo de pesos abertos em infraestrutura própria ou combinar as duas abordagens. APIs externas reduzem o trabalho operacional e facilitam experimentar modelos avançados. Em contrapartida, criam dependência de disponibilidade, preço, políticas de uso e condições de tratamento de dados do fornecedor.
Modelos com pesos disponíveis podem oferecer mais controle sobre implantação e dados, mas “pesos abertos” não significa necessariamente software livre sem restrições. É preciso conferir a licença, os requisitos de hardware, o desempenho para o idioma e a tarefa, e quem vai cuidar de atualizações, monitoramento e segurança. A conta de uma GPU subutilizada também pode ficar mais cara do que uma API.
Uma estratégia híbrida costuma ser mais realista: classificar os dados e os casos de uso, direcionar tarefas sensíveis para um ambiente controlado e manter uma alternativa para tarefas de menor risco. A classificação deve ser feita pelo sistema e pelas regras da organização, não deixada para o modelo decidir depois de receber o conteúdo.
Na Prática: encaminhe prompts por classificação de dados
O exemplo abaixo usa a API compatível com o formato de chat da OpenAI. Configure os endereços e as chaves conforme os fornecedores escolhidos. A política é deliberadamente conservadora: dados restritos vão apenas para o endpoint local; dados internos, para o endpoint europeu; e conteúdo público, para um serviço externo. Se faltar configuração, o programa falha em vez de enviar o prompt para outro lugar automaticamente.
- Defina a classificação do dado na aplicação antes de montar a chamada ao modelo.
- Configure um endpoint e uma chave apropriados para cada nível.
- Revise contrato, localização efetiva, retenção de logs e subprocessadores do fornecedor.
- Monitore erros sem registrar prompts sensíveis nos logs da aplicação.
import json
import os
from urllib.request import Request, urlopen
ROUTES = {
"publico": ("PUBLIC_API_BASE", "PUBLIC_API_KEY", "PUBLIC_MODEL"),
"interno": ("EU_API_BASE", "EU_API_KEY", "EU_MODEL"),
"restrito": ("LOCAL_API_BASE", "LOCAL_API_KEY", "LOCAL_MODEL"),
}
def chat(prompt: str, classification: str) -> str:
if classification not in ROUTES:
raise ValueError("Classificação desconhecida; chamada bloqueada.")
base_var, key_var, model_var = ROUTES[classification]
base = os.environ.get(base_var)
model = os.environ.get(model_var)
if not base or not model:
raise RuntimeError(
f"Endpoint ou modelo ausente para: {classification}"
)
# Chaves podem ser dispensáveis em servidores locais.
api_key = os.environ.get(key_var)
payload = json.dumps({
"model": model,
"messages": [{"role": "user", "content": prompt}],
"temperature": 0.2,
}).encode("utf-8")
headers = {"Content-Type": "application/json"}
if api_key:
headers["Authorization"] = f"Bearer {api_key}"
request = Request(
base.rstrip("/") + "/chat/completions",
data=payload,
headers=headers,
method="POST",
)
# Sem fallback automático: uma falha não deve mudar o destino dos dados.
with urlopen(request, timeout=30) as response:
result = json.loads(response.read().decode("utf-8"))
return result["choices"][0]["message"]["content"]Esse código é um ponto de partida, não uma garantia de soberania. O rótulo “EU” no nome de uma variável não prova que os dados ficam na União Europeia. É preciso verificar a configuração do serviço, os termos contratuais e a cadeia de subprocessadores. Também não basta colocar a chave em uma variável de ambiente em produção: use um gerenciador de segredos e controle quem pode acessá-la.
Erros comuns ao tentar reduzir dependências tecnológicas
- Confundir localização com controle: hospedar dados numa região europeia não responde, por si só, quem pode acessá-los nem quais leis se aplicam ao fornecedor.
- Fazer fallback sem revisar a política: se o modelo local falha e o código envia o mesmo prompt para uma API externa, a rota alternativa pode violar justamente a regra que se queria aplicar.
- Abstrair tudo antes de entender o problema: uma interface genérica para dezenas de provedores pode esconder diferenças de segurança, custo e comportamento, além de adicionar manutenção.
- Ignorar custos de saída: armazenamento barato pode deixar de ser barato quando exportar grandes volumes para outro provedor custa caro ou demora semanas.
- Tratar open source como sinônimo de risco zero: dependências abertas também precisam de inventário, atualização, verificação de licença e resposta a vulnerabilidades.
- Escolher pelo passaporte do fornecedor: origem importa para certos riscos, mas disponibilidade, suporte, segurança, jurisdição e capacidade de migração também precisam entrar na análise.
Uma forma pragmática de começar
Eu começaria com um inventário dos serviços que, se ficassem indisponíveis amanhã, parariam a receita ou exporiam dados sensíveis. Para cada um, registraria o fornecedor, os dados processados, os pontos de integração, as condições de saída e o tempo estimado para migrar. Esse trabalho costuma revelar riscos mais úteis do que uma discussão abstrata sobre “fazer tudo na Europa”.
Depois, faria um teste de saída pequeno e periódico: exportar dados, restaurar um backup em outro ambiente e executar os fluxos essenciais sem o serviço principal. No caso de IA, compararia pelo menos um modelo alternativo com casos reais da aplicação, avaliando qualidade, latência, custo e comportamento em falhas. Sem teste, “temos plano de contingência” é só uma frase em documento.
A posição de Virkkunen, conforme relatada pelo Observador.pt, não pede isolamento tecnológico. Para quem programa, a tradução mais útil é reduzir pontos únicos de falha e tomar decisões conscientes sobre controle, interoperabilidade e custo de troca. Dependência não é sempre um problema; dependência invisível, sem plano de saída e envolvendo dados críticos costuma ser.
Perguntas frequentes sobre soberania tecnológica e desenvolvimento
Usar uma nuvem europeia garante soberania dos dados?
Não automaticamente. É necessário verificar a entidade contratante, a jurisdição aplicável, a localização dos dados e dos backups, as regras de acesso e os subprocessadores. A localização do servidor é apenas uma parte da análise.
Kubernetes torna uma aplicação independente do provedor?
Não por si só. Kubernetes ajuda a padronizar a execução de contêineres, mas não remove dependências de bancos, filas, identidade, armazenamento e APIs proprietárias. A portabilidade precisa ser testada nos componentes que realmente sustentam o produto.
Um modelo de IA local é sempre mais seguro?
Não. Ele pode reduzir o envio de prompts a terceiros, mas exige proteção da infraestrutura, controle de acesso, atualização, observabilidade e avaliação de licença. Um modelo local mal configurado também pode expor dados.
Como reduzir dependência de um único fornecedor de IA?
Separe a lógica do produto da chamada ao modelo, mantenha uma interface pequena e teste alternativas com as mesmas tarefas. Defina também regras explícitas para fallback e classificação de dados; não redirecione prompts sensíveis automaticamente para outro serviço.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.