O sistema de IA mais importante pode ser aquele que ninguém vê.

O modelo é a camada visível. A verdadeira capacidade de IA da Europa depende dos chips, da computação, das redes, dos registos, dos contratos e das pessoas...

O sistema de IA mais importante pode ser aquele que ninguém vê.

A máquina por trás da resposta

O primeiro supercomputador exascale da Europa não é uma metáfora. O JUPITER é um sistema real no Forschungszentrum Jülich, operado pelo Jülich Supercomputing Centre. A EuroHPC Joint Undertaking descreve a sua arquitetura BullSequana com refrigeração líquida direta, uma partição flash ultrarrápida de 20 petabytes e um design pensado para simulações exigentes e inteligência artificial com uso intensivo de computação. A descrição está cheia dos detalhes que tornam um sistema possível: uma arquitetura de processador, um nível de armazenamento, um método de refrigeração, uma instituição operadora e um caminho de acesso. O modelo que poderá eventualmente funcionar sobre esse sistema é apenas uma parte da frase.

Essa distinção é fácil de perder porque a parte visível da IA é uma resposta. Uma pessoa faz uma pergunta, um modelo devolve texto e o ecrã dá a impressão de que a inteligência chegou num único pacote. O trabalho oculto é menos cinematográfico. A eletricidade tem de chegar ao edifício. Os componentes têm de chegar nas condições certas. Uma imagem de firmware tem de ser fiável. As redes têm de transportar dados entre processadores e armazenamento. A identidade tem de estabelecer que pessoa ou serviço pode utilizar que recurso. Um agendador tem de encontrar capacidade. Um registo tem de dizer ao operador que modelo, contentor e versão de dados estão em uso. A monitorização tem de detetar que o sistema mudou. Alguém tem de continuar a saber como repará-lo numa terça-feira chuvosa, quando a documentação do fornecedor ganhou um novo número de versão e a única pessoa que percebia da anterior está de férias.

O sistema de IA importante pode, portanto, ser aquele que ninguém vê. É a cadeia de abastecimento, o contrato de energia, a malha de rede, o plano de manutenção, a árvore de dependências de software, a decisão de aquisição e a memória institucional que permitem que um modelo seja utilizado sem fingir que o modelo é todo o serviço. Quando esse sistema oculto é fraco, um modelo mais capaz não torna o serviço mais forte. Dá ao sistema fraco uma forma mais impressionante de falhar.

Isto não é um argumento contra modelos ou grandes programas públicos de computação. É um argumento a favor de os descrever com honestidade. A Europa está a construir capacidade através do Chips Act, do EuroHPC e do programa AI Factories. As páginas políticas da Comissão falam de dependências estratégicas, resiliência da cadeia de abastecimento, acesso para empresas mais pequenas e da infraestrutura necessária para uma IA fiável. Essas são questões de infraestrutura, não questões de imagem de marca. Se o continente quer capacidade útil em vez de uma coleção de demonstrações impressionantes, tem de tratar as camadas silenciosas como parte da capacidade.

A resposta é a camada superior. O serviço depende de todas as camadas que estão por baixo.

Um modelo é um componente, não um país

A discussão pública usa muitas vezes um modelo como abreviatura de uma capacidade inteira. Um país tem um modelo, uma empresa tem um modelo, um departamento tem um modelo, e o modelo é tratado como se carregasse a sua própria cadeia de abastecimento. Não carrega. Um modelo tem um ficheiro, parâmetros, um runtime e um conjunto de pressupostos sobre o trabalho que se espera que faça. O serviço à sua volta assume o resto das obrigações.

Considere um sistema modesto que classifica documentos recebidos antes de uma equipa humana os rever. Precisa de um canal de entrada, uma fila, um analisador sintático, armazenamento, controlo de acessos, um runtime de modelo, um repositório de resultados, um caminho de notificação, uma forma de reverter uma versão e um registo do que aconteceu. O classificador pode ser preciso no seu conjunto de testes e ainda assim ser inutilizável se o analisador sintático perder um campo, se o sistema de identidade atribuir a função errada, se o contentor do modelo não puder ser recuperado, ou se o operador não conseguir dizer qual versão fez uma recomendação. Nenhuma destas falhas são alucinações do modelo. São falhas no serviço que tornou o modelo consequente.

O erro oposto é igualmente comum. As equipas descrevem um serviço inteiro como resiliente porque o modelo foi avaliado, deixando as dependências fora do limite da avaliação. Um teste de modelo pode verificar resultados para uma carga de trabalho selecionada. Raramente verifica se um certificado expira ao mesmo tempo que um repositório de software muda a sua chave de assinatura, se um nível de armazenamento tem capacidade suficiente para um documento mais longo do que o habitual, ou se uma pessoa consegue recuperar o registo de origem depois de um fornecedor mudar uma interface de programação de aplicações. Essas preocupações pertencem ao sistema operacional. Continuam a fazer parte do que um utilizador experiencia como IA.

A questão útil não é se um modelo é bom isoladamente. É quais outras coisas têm de ser verdade antes de se poder confiar na saída do modelo, e quem tem autoridade para reparar essas coisas. Essa questão move a conversa de um catálogo de modelos para um limite de sistema. Também cria um inventário menos lisonjeiro, mas mais útil.

  • Que recursos físicos têm de permanecer disponíveis?
  • Que componentes de software e firmware têm de chegar intactos e permanecer suportados?
  • Que serviços de identidade, rede, armazenamento e registo têm de responder?
  • Que organização é responsável quando a dependência muda?
  • Que evidência permite a outra pessoa verificar a resposta mais tarde?
  • Proposal for the Chips Act 2.0, Comissão Europeia, 3 de junho de 2026.

Estas questões não são teóricas. São a diferença entre uma capacidade que pode ser operada e uma capacidade que pode ser demonstrada uma vez. Demonstrações são agradáveis. Serviços essenciais têm de sobreviver à próxima janela de manutenção.

As cadeias de abastecimento estão dentro do limite do sistema

O trabalho da ENISA sobre a integridade da cadeia de abastecimento começa com uma observação pouco lisonjeira: governos, organizações, empresas e consumidores dependem cada vez mais de produtos e serviços TIC e, portanto, das cadeias de abastecimento que os entregam. O seu relatório nomeia ameaças que vão desde adulteração durante o desenvolvimento, distribuição ou operação até à substituição por componentes contrafeitos ou clonados. O ponto é mais amplo do que uma lista de verificação de segurança. A coisa fornecida não é apenas uma caixa. É uma sequência de pessoas, código, componentes, contratos e decisões através da qual a caixa se torna suficientemente confiável para ser usada.

Um serviço de IA herda essa sequência. Uma execução de treino depende de uma imagem base, um compilador, um controlador, um kernel, um escalonador e um conjunto de dados de origem. Um serviço de inferência depende das mesmas camadas mais um runtime de serviço, um índice, um portão de políticas e uma interface que possa continuar a funcionar quando o tráfego não tem a forma do conjunto de testes. Uma instituição pública pode comprar um serviço em vez de qualquer uma dessas partes, mas a cadeia oculta não desaparece porque o contrato lhe chama plataforma.

O relatório de prospetiva da ENISA para 2024 coloca o comprometimento da cadeia de fornecimento de software no topo da sua lista de ameaças à cibersegurança para 2030. Coloca também a escassez de competências, o erro humano em ecossistemas ciberfísicos, os fornecedores transfronteiriços de TIC como ponto único de falha e o impacto físico das perturbações ambientais na infraestrutura digital crítica entre as principais preocupações. Não se trata de afirmações de que todos os projetos de IA encontrarão todas estas ameaças. São um lembrete de que a superfície de ameaça é feita de relações. Uma correção, um fornecedor, uma pessoa e uma inundação podem afetar o mesmo serviço, mesmo que apareçam em registos de risco diferentes.

A linguagem do mesmo relatório é útil porque resiste à fantasia de que o risco cibernético pertence apenas à equipa de segurança. Uma dependência pode ser comprometida no software, mas as suas consequências podem chegar através de um processo físico, de uma escolha de aprovisionamento ou de uma competência em falta. Um serviço pode tornar-se um ponto único de falha porque o seu fornecedor é tecnicamente excelente e amplamente utilizado. A concentração não é o mesmo que incompetência. É uma propriedade da rede em torno de um serviço.

Isto cria um problema prático de delimitação. Se uma organização avaliar apenas o modelo e o seu ambiente de execução imediato, o resultado pode ser preciso para a delimitação que escolheu e enganador para o serviço que opera. Se avaliar todos os fornecedores com a mesma intensidade, produzirá uma folha de cálculo que ninguém conseguirá manter. A resposta é um mapa de dependências que segue a consequência. Identifique o que pode alterar um resultado, interromper um serviço, apagar provas, alargar autoridade ou impedir a recuperação. Depois, pergunte se a dependência é suficientemente visível para ser monitorizada e se existe outra via.

Esse mapa deve incluir materiais comuns. Um servidor requer memória, dispositivos de armazenamento, conversão de energia, equipamento de refrigeração e peças sobresselentes. Uma rede requer componentes óticos, comutadores, software de encaminhamento e pessoas que conheçam a topologia. Uma cadeia de fornecimento de software requer mantenedores, infraestrutura de compilação, registos de pacotes, chaves de assinatura e procedimentos de lançamento. Nenhum destes elementos se torna menos importante porque o folheto do produto diz inteligência artificial.

É tentador responder com um questionário de fornecedores mais extenso. Um questionário pode ser útil, mas não é um mapa de dependências. Regista o que um fornecedor diz num determinado momento. A questão operacional é se o comprador consegue detetar uma alteração, interpretá-la e tomar uma ação proporcionada. Uma lista de certificados não substitui o conhecimento de qual componente interromperia o serviço se desaparecesse amanhã de manhã. As organizações europeias são admiravelmente boas a recolher documentos. A arte mais difícil é fazer com que os documentos apontem para uma decisão.

Os chips tornam o invisível físico

A Lei Europeia dos Chips afirma um facto que deveria ser óbvio e ainda precisa de ser afirmado: os semicondutores são blocos de construção para produtos eletrónicos e centrais para setores que vão das comunicações e do processamento de dados à saúde, energia, transportes e automação industrial. A Lei entrou em vigor em setembro de 2023 e define objetivos que incluem o reforço da investigação e da liderança tecnológica, o reforço da capacidade de conceção, fabrico e empacotamento, a resposta à escassez de competências e o desenvolvimento de uma compreensão mais profunda da cadeia de fornecimento global de semicondutores.

Essa lista é importante para a IA porque a capacidade de computação não é feita por um logótipo de nuvem. É feita por uma cadeia de conceções, bolachas, equipamento, empacotamento, testes, fornecimento de energia, refrigeração, redes e manutenção. Uma escassez ou atraso numa parte pode alterar o que um centro de dados consegue entregar, mesmo quando os ficheiros do modelo estão prontos. Se um componente tiver um prazo de entrega longo, o operador não pode resolver o problema com um prompt inteligente. Se uma dependência de firmware não puder ser atualizada com segurança, a escolha pode ser entre uma redução controlada do serviço e uma tentativa insegura de manter tudo a funcionar.

A panorâmica da Comissão regista os três pilares do Regulamento Circuitos Integrados. O primeiro apoia o reforço de capacidades e a inovação, incluindo linhas-piloto e centros de competências. O segundo aborda a segurança do aprovisionamento e a resiliência através do fabrico, da embalagem avançada, dos ensaios e da montagem. O terceiro cria mecanismos de monitorização e de resposta a crises, incluindo um Conselho Europeu de Semicondutores que mapeia e monitoriza a cadeia de valor e coordena as respostas a crises no setor dos semicondutores. A conceção institucional é uma correção útil à ideia de que a soberania significa produzir internamente todos os componentes. A resiliência depende em parte da capacidade, em parte da visibilidade e em parte da capacidade de responder quando uma dependência se desloca.

A página apresenta também exemplos concretos de instalações pioneiras aprovadas em Catânia, Crolles, Dresden, Novara, Premstätten, Milão e noutras localizações europeias. Essas entradas não provam que a Europa resolveu o problema dos semicondutores. Provam que a cadeia de valor tem lugares físicos, tecnologias e decisões de investimento que podem ser nomeados. Nomeá-los muda a conversa. Permite que alguém pergunte que capacidade acrescenta cada instalação, de que insumos ainda depende, que competências necessita e como seria apoiada durante uma perturbação.

A proposta da Comissão para um Regulamento Circuitos Integrados 2.0, publicada em junho de 2026, afirma que a União continua dependente de países terceiros em áreas fundamentais como o fabrico avançado de circuitos integrados e a conceção de semicondutores. Para um artigo de 31 de julho, esta é uma declaração política atual, não uma previsão sobre um futuro diploma. A sua implicação prática é direta: um serviço europeu pode estar alojado na Europa e continuar a depender de uma cadeia global cujas decisões mais importantes acontecem noutro lugar. A localização física é valiosa. Não é o mesmo que controlo.

A política de IA pode tornar-se mais séria quando adota este vocabulário físico. Em vez de perguntar se um modelo é europeu, pergunte que partes do serviço podem ser reparadas, substituídas, inspecionadas e suspensas no âmbito das instituições europeias. Em vez de perguntar se um fornecedor tem uma região europeia, pergunte como o hardware, o firmware, as dependências de software e a autoridade operacional circulam pelo serviço. A resposta será desarrumada. Ainda bem. Os mapas desarrumados são muitas vezes os primeiros honestos.

A computação é uma capacidade pública

A EuroHPC oferece um caso útil porque torna visível a infraestrutura de computação sem a transformar num produto de consumo. A sua lista pública indica que a Empresa Comum adquiriu doze supercomputadores de última geração na Europa. A lista nomeia sistemas e anfitriões: JUPITER em Jülich, na Alemanha, LUMI em Kajaani, Leonardo em Bolonha, MareNostrum 5 em Barcelona, Karolina em Ostrava e Arrhenius na Universidade de Linköping, entre outros. As localizações importam menos como tabela classificativa do que como recordação de que a computação está incorporada em instituições, edifícios, pessoal, sistemas de energia, armazenamento e programas de investigação.

O JUPITER é descrito como o primeiro supercomputador exascale da Europa, com uma arquitetura de refrigeração líquida direta, uma partição flash de 20 petabytes e um módulo de cluster que utiliza o processador SiPearl Rhea1 juntamente com um booster acelerado por GPU. A página do LUMI descreve partições separadas de CPU, GPU, análise de dados e cloud de contentores, com um sistema de armazenamento que combina flash, um sistema de ficheiros paralelo e um serviço de gestão de dados. Estes pormenores não são triviais apenas para engenheiros. Dizem a um leitor de políticas que um supercomputador é um conjunto de recursos com formas diferentes. Uma carga de trabalho que cabe numa partição pode não caber noutra. O acesso, o agendamento e a movimentação de dados fazem parte da capacidade.

O MareNostrum 5, alojado no Barcelona Supercomputing Center, e o Arrhenius, em instalação na Universidade de Linköping e operado pela National Academic Infrastructure for Supercomputing, na Suécia, ilustram o mesmo ponto de formas diferentes. Uma capacidade europeia distribuída não é uma única máquina gigante. É um conjunto de sistemas com processadores, soluções de armazenamento, operadores, regras de acesso e comunidades científicas distintos. A rede entre eles é importante, mas as fronteiras também o são.

A política de AI Factories da Comissão descreve um programa construído sobre essa realidade. As AI Factories utilizam a capacidade de supercomputação do EuroHPC para desenvolver IA generativa avançada e ligar centros de computação, universidades, pequenas e médias empresas, indústria e atores financeiros. A página refere que, na altura da sua atualização de abril de 2026, dezanove AI Factories e treze antenas estavam operacionais, estando planeados pelo menos nove novos supercomputadores otimizados para IA. Descreve também um investimento de longo prazo de dez mil milhões de euros através do EuroHPC entre 2021 e 2027. São acordos institucionais, não uma garantia de que todos os projetos receberão a capacidade que desejam ou de que todos os modelos serão fiáveis.

O valor destes acordos não reside apenas na velocidade. A computação pública pode criar um espaço onde investigadores e empresas europeias possam executar cargas de trabalho sob regras e condições de acesso visíveis para as instituições públicas. Pode apoiar experiências que, de outro modo, ficariam excluídas por custos, e pode tornar algum conhecimento reproduzível entre locais. Pode também introduzir novas dependências se um programa depender de um número reduzido de fornecedores, de uma única pilha de software ou de uma força de trabalho insubstituível. A posse pública de uma infraestrutura não elimina o trabalho operacional. Torna a responsabilidade mais difícil de ocultar, o que é mais saudável.

Quando a computação se torna capacidade pública, o seu sucesso deve ser medido para além do desempenho máximo. Um grupo de investigação mais pequeno consegue obter acesso? Uma carga de trabalho sensível pode ser separada de uma genérica? Um operador consegue mostrar que software e hardware foram utilizados? Uma equipa consegue mover uma carga de trabalho quando uma partição está cheia ou uma dependência é descontinuada? Uma autoridade pública consegue explicar as condições em que um modelo foi treinado? Uma máquina rápida que não responde a estas perguntas continua a ser útil para alguma ciência, mas ainda não é uma base completa para a IA pública.

Redes, armazenamento e identidade fazem o trabalho silencioso

As camadas mais importantes são muitas vezes as que não aparecem num diagrama de IA. Um diagrama desenha um modelo entre uma entrada e uma saída. Um operador vê uma cadeia de caminhos de rede, classes de armazenamento, declarações de identidade, filas, certificados, registos, segredos, pipelines de observabilidade e controlos de alterações. O diagrama não está errado. Está incompleto exatamente da forma que produz surpresas dispendiosas.

Comece pela rede. Um serviço de modelos de grande dimensão pode mover dados entre aceleradores, memória, armazenamento e outros serviços. Uma carga de trabalho de investigação pública pode mover conjuntos de dados para um supercomputador e devolver resultados a uma universidade. Um fluxo de trabalho de produção pode cruzar uma fronteira política antes de chegar a um modelo e outra fronteira antes de devolver uma decisão. Latência, perda de pacotes, alterações de encaminhamento e manutenção podem alterar o comportamento de todo o serviço sem mudar um único parâmetro no modelo. Um tempo limite pode tornar-se uma nova tentativa, uma nova tentativa pode tornar-se trabalho duplicado, e trabalho duplicado pode tornar-se um registo incorreto. O modelo não decidiu tentar novamente. O sistema envolvente decidiu.

O armazenamento tem a sua própria gramática oculta. Existe o registo de origem, o registo transformado, o índice, a cache, o log, a cópia de segurança, o marcador de eliminação e a evidência que indica qual versão foi utilizada. Um serviço pode ser capaz de responder a uma pergunta sem conseguir provar quais dados tornaram a resposta possível. A retenção e a recuperação não são imagens espelhadas. Guardar tudo para sempre pode violar uma limitação de finalidade; eliminar a origem e deixar um derivado ou uma cache pode criar um problema diferente. Uma fronteira de dados séria define o que é armazenado, durante quanto tempo, por quem, e como um revisor posterior pode verificar que a fronteira foi respeitada.

A identidade não é um ecrã de início de sessão. É o mecanismo que dá a uma pessoa, serviço ou agente autoridade para executar uma ação. Se um endpoint de inferência puder chamar uma ferramenta, o sistema tem de saber qual principal fez o pedido, que política permitiu a chamada e o que a ferramenta podia tocar. Se um registo permitir a promoção de um contentor, tem de saber quem pode aprovar a promoção e que evidência é exigida. Se um certificado for renovado automaticamente, o serviço tem de ter uma forma de detetar que a relação de identidade mudou. Um segredo que permanece válido depois de a pessoa que o solicitou sair é um problema de manutenção com consequências de segurança.

Os registos são a memória de um sistema em movimento. Um registo de modelos pode conter versões e metadados. Um registo de artefactos pode conter contentores, pacotes ou versões assinadas. Um registo de dados pode descrever esquemas e propriedade. Um inventário de hardware pode identificar uma placa, a versão de firmware e o estado de substituição. O objetivo não é criar um registo para tudo. O objetivo é tornar explícita a fonte autoritativa de cada afirmação. Se nenhum sistema conseguir responder a que modelo, controlador, versão de dados e versão de política estavam ativos, uma revisão posterior é forçada a inferir a história a partir dos logs que sobreviveram.

A observabilidade fecha o ciclo. As métricas dizem a um operador que uma fila cresceu ou que um dispositivo está quente. Os traces mostram o caminho percorrido por um pedido. Os logs transportam contexto, embora continuem fáceis de interpretar mal. Eventos e atestações podem preservar decisões e alterações. Estes objetos têm funções diferentes. Tratá-los como intercambiáveis produz ruído ou uma falsa sensação de prova. A questão de design é o que uma pessoa precisa de saber quando o serviço está atrasado, errado, indisponível ou contestado, e qual registo pode responder a essa pergunta sem um exercício de reconstrução.

Pode-se descrever isto como engenharia monótona. Isso não é um insulto. A engenharia monótona é a parte que continua a funcionar depois de o anúncio de lançamento ter saído da página inicial. É também a parte que determina se um novo modelo pode ser adotado sem reescrever a instituição à sua volta.

A manutenção é uma capacidade, não uma linha de despesa

As histórias de infraestrutura gostam de terminar na implementação. É aí que o trabalho se torna um serviço. Um modelo é lançado, um cluster é comissionado, uma fábrica abre, um contrato é assinado e a narrativa avança para o próximo anúncio. O sistema em si continua através de correções, substituição de hardware, formação, revisões de acesso, atualizações, descontinuações, resposta a incidentes e o desaparecimento gradual das pessoas que se lembram de por que motivo uma definição foi escolhida.

O relatório de ameaças da ENISA coloca a escassez de competências no topo das suas preocupações de longo prazo. Isto não é apenas uma questão de mercado de trabalho. É uma questão de resiliência. Um serviço cujas dependências não podem ser compreendidas por mais do que uma pessoa tem um ponto único de falha oculto. Uma organização pode ter máquinas sobressalentes e ainda assim não ter capacidade para as utilizar em segurança porque o runbook, o processo de compilação ou o contrato de dados vive na memória de um único engenheiro. Comprar suporte pode reduzir o risco, mas o comprador ainda precisa de compreensão suficiente para desafiar o fornecedor e decidir quando parar.

Manutenção também altera o que significa uma alegação de desempenho. Uma execução de benchmark numa versão diz algo sobre essa versão nas condições indicadas. Não diz que o sistema terá o mesmo comportamento após uma atualização de driver, uma alteração de compilador, um novo agendador, um caminho de armazenamento diferente ou uma nova carga de trabalho. Um serviço útil mantém as condições das suas alegações. Regista versões, entradas, hardware, políticas e alterações para que alguém possa repetir um teste ou explicar por que razão a repetição deixou de ser possível.

Há um custo humano em fingir que a manutenção é uma preocupação de menor importância. Os operadores adiam atualizações porque o grafo de dependências não é claro. As equipas de segurança têm dificuldade em saber qual pacote está realmente em produção. As compras renovam um contrato porque ninguém ensaiou uma saída. Os investigadores não conseguem reproduzir um resultado porque o ambiente se desviou. Os utilizadores encontram erros intermitentes que são atribuídos ao modelo porque o serviço não tem uma linguagem comum para as camadas subjacentes. O resultado não é uma única falha dramática. É uma redução lenta da confiança.

Um calendário de manutenção deve, portanto, incluir mais do que datas de patches. Deve incluir revisões de propriedade, expiração de acessos, rotação de certificados e chaves, testes de restauro de backups, revisão de dependências, ciclo de vida de hardware, avisos de alteração de fornecedores, reforma de modelos e as evidências necessárias para cada um. Algumas destas tarefas podem ser automatizadas. A responsabilidade não pode ser automatizada. Alguém tem de decidir o que conta como uma alteração material, quem recebe o sinal e que autoridade pode pausar o serviço.

O instinto europeu de criar um comité para um problema difícil é por vezes ridicularizado, muitas vezes injustamente. Um comité que possui um mapa de dependências, uma regra de alteração e um caminho de escalonamento é mais útil do que um painel que não pertence a ninguém. O problema não é a governação. O problema é a governação que não consegue chegar à máquina.

As compras são onde as dependências se tornam compromissos

Os contratos transformam uma dependência num compromisso. Um comprador escolhe um fornecedor, um componente, um acordo de suporte, uma localização de dados, um período de renovação e uma condição de saída. A decisão pode ser descrita como a compra de um serviço de IA, mas o comprador também está a comprar o processo de atualização do fornecedor, a resposta a incidentes, o modelo de identidade, a estabilidade da interface, a documentação e a capacidade de permanecer em atividade. Essas não são funcionalidades secundárias. Determinam quanta autoridade o comprador mantém.

O documento do grupo consultivo da ENISA de 2025 sobre a implementação da NIS2 é invulgarmente direto sobre isto. Nota que as empresas mais pequenas podem cair no trabalho de conformidade com a NIS2 porque fornecem entidades que estão no âmbito. Defende um quadro europeu de segurança da cadeia de abastecimento e de compras com uma base de medidas e um método comum de diligência devida. Também apela a uma base de compras com requisitos mínimos de contrato, cláusulas padrão, abordagens de teste de segurança e uma forma simples de o cliente avaliar fornecedores. O documento é uma opinião consultiva, não um regulamento. O seu valor aqui é que nomeia o atrito operacional produzido quando cada comprador inventa uma versão diferente de diligência.

As equipas de compras não precisam de exigir que cada fornecedor divulgue todos os detalhes internos. Precisam de fazer perguntas que se liguem a consequências. Que componentes são essenciais para o serviço? Como são comunicadas as alterações? Como pode o comprador verificar o software e o firmware em uso? O que acontece se um fornecedor ou subfornecedor não puder fornecer um componente? Que dados e evidências podem ser exportados? Durante quanto tempo o suporte continua após uma versão ser reformada? Quem pode pausar uma operação, e o que acontece ao trabalho já em curso?

Estas perguntas são menos glamorosas do que uma demonstração. Também são mais difíceis de fingir. Um fornecedor consegue apresentar uma resposta fluente em dez minutos. É mais difícil apresentar um inventário completo de dependências, um restauro testado, um caminho de migração e uma pessoa autorizada a dizer não no momento certo. O comprador não deve tratar esta dificuldade como motivo para evitar as perguntas. É o motivo para as fazer antes de o serviço se tornar difícil de substituir.

O risco de concentração merece uma linguagem cuidada. Um fornecedor muito utilizado não é automaticamente inseguro, e um fornecedor pequeno não é automaticamente resiliente. A concentração torna-se um risco quando um fornecedor, repositório de software, rota geográfica, autoridade de identidade ou equipa de manutenção carrega mais consequência do que a organização consegue absorver. O relatório prospetivo da ENISA descreve os fornecedores transfronteiriços de serviços TIC como um potencial ponto único de falha. A resposta adequada não é fingir que a concentração pode ser eliminada. É identificar onde existe, definir uma dependência aceitável e ensaiar o que acontece se a rota ficar indisponível.

As cláusulas de saída são muitas vezes escritas como mobiliário jurídico. Uma cláusula de saída real tem uma forma técnica. Nomeia formatos, interfaces, direitos de recuperação, chaves, registos, provas, apoio durante a transição, confirmação de eliminação e a informação mínima necessária para reconstruir um serviço noutro local. É mais forte quando foi testada numa carga de trabalho pequena. O teste não precisa de ser teatral. Uma exportação controlada, um restauro num ambiente independente e uma comparação do comportamento resultante podem revelar mais do que várias páginas de garantias.

As infraestruturas críticas são uma rede de dependências

A Diretiva Resiliência das Entidades Críticas faz um movimento semelhante ao nível dos serviços essenciais. Define resiliência como a capacidade de uma entidade de prevenir, proteger contra, responder, resistir, mitigar, absorver, acomodar e recuperar de um incidente. Descreve as infraestruturas críticas como um ativo, instalação, equipamento, rede ou sistema necessário para um serviço essencial. A redação é deliberadamente mais ampla do que um edifício. Trata um serviço como uma relação entre ativos, pessoas e funções.

A diretiva afirma que os Estados-Membros devem considerar os riscos intersetoriais e transfronteiriços, e aponta para as interdependências crescentes entre infraestruturas e setores. Afirma também que os efeitos na cadeia de abastecimento devem ser considerados ao avaliar a importância de um incidente disruptivo. Isto é relevante para as infraestruturas de IA porque o serviço em causa pode nem sequer estar rotulado como inteligência artificial. Uma ligação de dados, sistema de energia, serviço de identidade, sistema de registos hospitalares ou rede de investigação pode ser a camada que torna possível um serviço baseado em IA.

A diretiva não é um manual de operações de IA. Não classifica todos os serviços de modelos como críticos e não substitui as regras específicas de cada setor. Fornece uma forma de pensar sobre a consequência. Se um sistema suporta um serviço essencial, a questão não é apenas se o modelo passou numa avaliação. É se a entidade consegue continuar a prestar o serviço essencial quando um componente, instalação, fornecedor, rede ou condição externa muda.

A NIS2 acompanha esta visão física e organizacional com obrigações de gestão de risco de cibersegurança e de notificação de incidentes para entidades relevantes. A interação jurídica é específica e depende da entidade e do setor. A lição geral não é que uma única diretiva resolve a resiliência. É que as dependências cibernéticas e físicas têm de ser coordenadas. Uma rede pode estar segura contra um tipo de ataque e ainda assim falhar quando o arrefecimento está indisponível. Uma instalação pode ter energia redundante e ainda assim não conseguir autenticar operadores. Um fornecedor pode notificar um incidente de software enquanto o comprador não tem os registos necessários para compreender o seu efeito.

Para lidar com a resiliência é preciso um vocabulário para o serviço degradado, e não apenas para a interrupção total. Consegue o sistema aceitar menos pedidos? Consegue desativar uma função de alto risco enquanto preserva uma de baixo risco? Consegue mudar para um modelo mais pequeno ou para um caminho manual? Consegue continuar enquanto uma fila é esvaziada e uma fonte é verificada? Consegue provar que trabalho foi atrasado ou reprocessado? São decisões operacionais. Também determinam se cidadãos, investigadores e empresas passam por uma limitação controlada ou por uma resposta misteriosa que chega depois de a instituição ter perdido o contexto para a rever.

A imagem útil é a de uma rede cujos nós têm donos e cujas arestas têm condições. Uma aresta pode ser uma ligação elétrica, uma dependência de software, um contrato, uma transferência de dados ou uma relação de autoridade. Um design resiliente não parte do princípio de que todas as arestas estarão disponíveis. Regista a aresta, monitoriza a condição que interessa e define uma resposta antes de a pressão chegar.

Um composto ilustrativo, não um relato de incidente

É útil tornar concreto o problema das dependências sem inventar uma interrupção real. O que se segue é um composto ilustrativo. Não descreve nenhuma organização, fornecedor, instalação, pessoa, data ou evento nomeados. É uma experiência de pensamento montada a partir de relações de infraestrutura comuns.

Imagine um serviço público de investigação que permite a equipas autorizadas submeter um documento, executar um fluxo de trabalho de classificação e receber um resultado para revisão humana. O serviço está alojado em infraestrutura europeia. O seu modelo está guardado num registo de artefactos. Os documentos de origem vivem num nível de armazenamento e o índice noutro. Um gateway verifica a identidade e encaminha o trabalho para uma fila. Os trabalhadores usam uma imagem de contentor e um controlador de hardware. Os resultados são escritos num repositório de registos e num fluxo de evidências. Um painel diz à equipa operacional se o sistema está saudável.

Nada disto é invulgar. É esse o ponto. Agora mude uma condição de cada vez. O registo muda a sua política de assinatura. A atualização do controlador exige um novo runtime de contentor. Um certificado expira para o serviço que escreve evidências, enquanto o repositório de resultados continua a aceitar escritas. É atingida uma quota de armazenamento para um índice derivado, mas não para os documentos de origem. Um fornecedor muda uma interface e o consumidor da fila tenta novamente uma operação que não foi desenhada para ser repetida. Um operador experiente sai e o runbook ainda descreve a implementação anterior. Nenhuma destas mudanças exige que um modelo produza uma frase falsa. Cada uma pode mudar a fiabilidade do serviço ou a sua capacidade de se explicar.

Uma organização que observa apenas a precisão do modelo pode não ver nenhum aviso. O conjunto de teste continua a passar. Uma organização que observa todo o serviço verá sinais diferentes: uma falha de verificação, uma contagem crescente de tentativas, uma lacuna no fluxo de evidências, um limite de armazenamento, uma mudança não revista ou um alarme de propriedade. Os sinais não são equivalentes e não exigem todos uma interrupção. Exigem uma regra sobre quem decide o que acontece a seguir.

Suponha que a equipa escolhe reduzir a capacidade enquanto verifica a dependência. Isso não é um sinal de que o serviço falhou o seu propósito. Pode ser um sinal de que o serviço tem um propósito maior do que o débito. Se o sistema conseguir preservar o registo de origem, marcar o trabalho atrasado, impedir tentativas não autorizadas e dar a um humano um caminho claro para inspecionar os casos afetados, degradou-se de forma controlada. Se continuar a produzir respostas polidas enquanto o seu caminho de evidências está partido, preservou a aparência de serviço à custa da confiança.

The composite is deliberately ordinary because spectacular incidents make the lesson too easy. Everyone understands that a flood can interrupt a facility. The harder work is recognising that an expired certificate, an unowned registry, a changed supplier contract or a missing recovery test can also move a service outside its safe operating boundary. Boring dependencies are not less causal because they lack a dramatic photograph.

Failure propagates through relationships

A failure-propagation map should follow relationships rather than technology labels. Start with the service promise. What does the user expect to happen, and what must remain true for that expectation to be met? Then trace backwards through the model, runtime, policy gate, identity, network, storage, hardware, energy, supplier and institution. At each step, ask what failure looks like, how it is detected, who owns the response and what evidence remains.

This sounds linear, but real systems branch. A model can be available while a policy service is unavailable. A policy can permit a call while an identity record is stale. A request can be accepted while a queue is unable to drain. A result can be returned while the record needed to contest it is missing. An infrastructure team can restore the service while a data owner still has to decide whether the affected work can be trusted. The propagation map should show these branches because a single green status light cannot.

One useful way to draw the map is to separate four kinds of consequence. Availability asks whether the work can happen. Integrity asks whether the work and its records are unchanged and complete. Authority asks whether the actor was allowed to perform the work. Recoverability asks whether the service can return to a known state and explain what occurred. A dependency may be acceptable for one dimension and unacceptable for another. A cache can improve availability while being unsuitable as the authoritative record. A third-party identity service can be convenient while making authority hard to inspect during a disruption.

The map should also show time. Some dependencies fail immediately. Others drift. A model can remain available while its supporting data grows stale. A hardware component can work while replacement stock becomes impossible to obtain. A contract can remain valid while a provider's change policy slowly removes the interface the buyer relied on. The later a signal arrives, the more expensive it is to interpret. Time is part of the dependency, not a note in the incident report.

Operations teams often call this observability. That word is useful only when it points to an action. A graph that looks healthy does not tell anyone what authority they have, which change caused the graph to move or what evidence should be preserved. The point of a failure map is to make a decision possible. If the evidence stream is incomplete, pause the affected action. If the model registry cannot verify an artefact, do not promote it. If a supplier changes a component outside the tested boundary, repeat the relevant evaluation. If a recovery test cannot restore the record, do not call the backup a recovery plan.

There is no universal threshold for these decisions. A research experiment, a public-facing service and a safety-critical workflow have different tolerances. The important thing is that the threshold belongs to the service owner, is visible to operators and can be revised when evidence changes. Otherwise the threshold will be set by the first person who notices the failure, which is a remarkably democratic way to run a system and a poor way to govern one.

Uma dependência não precisa de destruir o modelo para alterar o que o serviço pode afirmar com segurança.

Medir a capacidade sem esconder o denominador

A infraestrutura incentiva números impressionantes. Exaflops, petabytes, contagens de processadores, totais de investimento e o número de instalações num programa descrevem algo real. Nenhum deles é o serviço por si só. Um número torna-se útil quando o seu denominador e as suas condições são visíveis.

O desempenho máximo de computação não diz a um investigador com que rapidez uma determinada carga de trabalho obterá uma partição, moverá os seus dados, concluirá uma execução ou recuperará o resultado. O número de AI Factories não diz a uma pequena empresa se a sua aplicação receberá acesso nas condições de que necessita. Um total de investimento em semicondutores não diz a um operador qual componente estará disponível durante uma escassez. Uma percentagem elevada de disponibilidade não diz a uma instituição pública se esta pode recuperar a evidência de uma decisão contestada.

Uma descrição responsável de capacidade associa, portanto, o título ao caminho que lhe está subjacente. Nomeie a fronteira de hardware e software. Indique se o valor é máximo, sustentado, planeado ou observado. Descreva a carga de trabalho, o modelo de acesso e as exclusões. Diga quais dependências estão fora da medição. Mantenha a afirmação ligada ao lançamento, hardware, conjunto de dados e política sob os quais foi feita. O objetivo não é tornar cada página ilegível. É tornar as páginas importantes verificáveis.

Esta disciplina também melhora o argumento público. A Europa não precisa de escolher entre ambição e cautela. Pode construir grandes instalações, financiar investigação ambiciosa e ainda assim dizer onde a evidência termina. Um sistema público que nomeia as suas restrições é mais credível do que um que apresenta um número limpo sem qualquer via para o inspecionar. A restrição pode ser uma fila, uma interface, um fornecedor, uma lacuna de competências, um limite de energia ou uma fronteira legal. Nomeá-la não torna a capacidade menor. Diz às pessoas que tipo de capacidade é.

A incerteza não é uma admissão de derrota. É um sinal de manutenção. Se ninguém sabe como uma alteração de um fornecedor afetará uma carga de trabalho, o próximo passo é um teste ou uma suposição explícita, não um adjetivo maior. Se um registo não consegue distinguir um lançamento de modelo de uma configuração de serviço, o próximo passo é um melhor registo. Se uma instituição não consegue dizer qual pessoa pode parar uma operação, o próximo passo é um mapa de autoridade. A precisão é uma forma de decidir o que reparar.

As camadas silenciosas são onde a soberania se torna prática

A soberania europeia é por vezes discutida como se fosse uma bandeira colocada no topo de um centro de dados. Um serviço pode estar localizado dentro da União e ainda assim depender de componentes externos, do alcance jurídico estrangeiro, de interfaces proprietárias, de competências escassas ou de um fornecedor cujas decisões de alteração não podem ser contestadas. A localização é um dos fatores numa avaliação de soberania. O controlo prático depende de toda a cadeia.

O enfoque do Regulamento dos Circuitos Integrados na compreensão da cadeia de abastecimento global de semicondutores, a atenção da Diretiva REC às interdependências entre setores e os avisos da ENISA sobre dependências de software e pontos únicos de falha apontam todos na mesma direção. A soberania não é um interruptor único. É a capacidade de compreender de que depende um serviço, de decidir qual a dependência aceitável, de a substituir ou restringir quando necessário e de reter provas suficientes para defender a decisão.

Essa capacidade pode ser construída de formas simples. Um grupo de investigação público pode manter um inventário do runtime, do controlador e da versão de dados utilizados para um resultado. Uma equipa de aquisições pode exigir um caminho de exportação testado em vez de uma promessa de portabilidade. Uma equipa de operações pode definir um modo degradado e ensaiá-lo. Um regulador pode perguntar que registos estariam disponíveis após uma alteração de fornecedor. Um fornecedor pode publicar o limite do seu suporte e as condições em que uma atualização altera o comportamento. Nenhuma destas ações torna um sistema autónomo. Tornam-no menos misterioso.

Na Dweve, esta é a razão específica pela qual nos importamos com fundações abertas e com os elementos discretos que as rodeiam. Projetos como o Core e o Mesh só são úteis quando se inserem num limite operacional honesto, com registos claros, autoridade e limites. Não substituem a infraestrutura europeia, as instituições públicas ou a política de cadeia de abastecimento, e este artigo não afirma que resolvem esses problemas. A posição é mais modesta: um componente aberto é mais fácil de inspecionar, substituir e ensinar quando os seus contratos são explícitos. É um tijolo, não o edifício inteiro.

O edifício importa porque as pessoas encontram o último piso e vivem com as fundações. A resposta no ecrã pode ser fluente, mas o caráter real do serviço é decidido pelas camadas que determinam de onde veio a resposta, quem a poderia alterar, o que acontece quando uma dependência muda e se alguém consegue explicar o resultado mais tarde.

Construa o sistema que as pessoas ainda conseguem ver

O sistema de IA mais importante pode ser aquele que ninguém vê porque está distribuído por lugares que nunca foram chamados de IA. É a instalação de circuitos integrados e o circuito de arrefecimento. É o supercomputador e o escalonador. É o registo de pacotes, o fornecedor de identidade, a política de armazenamento, a rota de rede e a escala de manutenção. É o contrato que define o que acontece quando um fornecedor altera um componente. É a instituição que consegue pausar um fluxo de trabalho antes de um sinal fraco se tornar uma falha pública.

Nada disto reduz a importância da qualidade do modelo. Dá à qualidade do modelo um lugar onde importar. Um modelo só pode servir uma pessoa através de um sistema que consiga receber a entrada, executar o trabalho, preservar o registo relevante e devolver o resultado com contexto suficiente para que alguém o possa confiar ou contestar. O modelo é um componente importante desse sistema. Não é um país, uma cadeia de abastecimento, um plano de recuperação ou uma pessoa com autoridade para reparar as partes que não consegue ver.

Os programas de infraestrutura da Europa são uma oportunidade para tornar estas dependências visíveis enquanto a capacidade está a ser construída. A oportunidade é prática. Publique interfaces e limites operacionais. Financie a manutenção e as competências juntamente com o equipamento. Trate a aquisição como uma decisão de design. Ligue a cibersegurança à resiliência física. Dê às organizações mais pequenas um caminho para utilizarem a infraestrutura pública sem as forçar a tornarem-se especialistas em todas as camadas. Meça o acesso, a recuperação e as provas com o mesmo cuidado que o desempenho máximo.

Há um certo prazer europeu em descobrir que a resposta a uma grande questão tecnológica é um inventário, um manual de procedimentos e uma pessoa autorizada a parar a máquina. Não é glamoroso, mas tem a vantagem de sobreviver ao contacto com uma terça-feira. Quando o sistema oculto é suficientemente visível para ser inspecionado, o modelo pode fazer o seu trabalho sem carregar um mito que nunca foi feito para carregar.

Fontes