Il sistema di IA più importante potrebbe essere quello che nessuno vede

Il modello è lo strato visibile. La vera capacità dell’IA in Europa dipende dai chip, dalla potenza di calcolo, dalle reti, dai dati, dai contratti e dalle...

Il sistema di IA più importante potrebbe essere quello che nessuno vede

La macchina dietro la risposta

Il primo supercomputer exascale d'Europa non è una metafora. JUPITER è un sistema reale presso il Forschungszentrum Jülich, gestito dal Jülich Supercomputing Centre. L'impresa comune EuroHPC descrive la sua architettura BullSequana a raffreddamento diretto a liquido, una partizione flash ultraveloce da 20 petabyte e un design pensato per simulazioni impegnative e intelligenza artificiale ad alta intensità di calcolo. La descrizione è piena dei dettagli che rendono possibile un sistema: un'architettura di processori, un livello di storage, un metodo di raffreddamento, un'istituzione che lo gestisce e un percorso di accesso. Il modello che un giorno potrebbe girare sopra è solo una parte della frase.

Questa distinzione è facile da perdere perché la parte visibile dell'IA è una risposta. Una persona fa una domanda, un modello restituisce testo e lo schermo dà l'impressione che l'intelligenza sia arrivata in un unico pacco. Il lavoro nascosto è meno cinematografico. L'elettricità deve raggiungere l'edificio. I componenti devono arrivare nelle giuste condizioni. Un'immagine firmware deve essere attendibile. Le reti devono trasportare dati tra processori e storage. L'identità deve stabilire quale persona o servizio può usare quale risorsa. Uno scheduler deve trovare capacità. Un registro deve dire a un operatore quale modello, container e release di dati sono in uso. Il monitoraggio deve notare che il sistema è cambiato. Qualcuno deve ancora sapere come ripararlo in un martedì piovoso quando la documentazione del fornitore ha acquisito un nuovo numero di versione e l'unica persona che capiva quella vecchia è in ferie.

Il sistema di IA importante potrebbe quindi essere quello che nessuno vede. È la catena di approvvigionamento, il contratto energetico, la rete, il piano di manutenzione, l'albero delle dipendenze software, la decisione di approvvigionamento e la memoria istituzionale che permettono di usare un modello senza fingere che il modello sia l'intero servizio. Quando quel sistema nascosto è debole, un modello più capace non rende il servizio più forte. Dà al sistema debole un modo più impressionante di fallire.

Questo non è un argomento contro i modelli o i grandi programmi pubblici di calcolo. È un argomento per descriverli onestamente. L'Europa sta costruendo capacità attraverso il Chips Act, EuroHPC e il programma AI Factories. Le pagine politiche della Commissione parlano di dipendenze strategiche, resilienza della catena di approvvigionamento, accesso per le piccole imprese e infrastruttura necessaria per un'IA affidabile. Sono questioni di infrastruttura, non di branding. Se il continente vuole capacità utile piuttosto che una raccolta di dimostrazioni impressionanti, deve trattare gli strati silenziosi come parte della capacità.

La risposta è lo strato superiore. Il servizio dipende da ogni strato sottostante.

Un modello è un componente, non un paese

La discussione pubblica usa spesso un modello come abbreviazione per un'intera capacità. Un paese ha un modello, un'azienda ha un modello, un dipartimento ha un modello, e il modello viene trattato come se portasse con sé la propria catena di fornitura. Non è così. Un modello ha un file, parametri, un runtime e una serie di presupposti sul lavoro che ci si aspetta svolga. Il servizio che lo circonda si fa carico del resto degli obblighi.

Si consideri un sistema modesto che classifica i documenti in arrivo prima che un team umano li esamini. Servono un canale di ingresso, una coda, un parser, uno storage, il controllo degli accessi, un runtime per il modello, un archivio dei risultati, un percorso di notifica, un modo per annullare un rilascio e una registrazione di ciò che è accaduto. Il classificatore può essere accurato sul suo set di test e comunque inutilizzabile se il parser perde un campo, se il sistema di identità assegna il ruolo sbagliato, se il container del modello non può essere recuperato, o se l'operatore non riesce a capire quale versione ha formulato una raccomandazione. Nessuno di questi guasti è un'allucinazione del modello. Sono guasti nel servizio che ha reso il modello rilevante.

L'errore opposto è altrettanto comune. I team descrivono un intero servizio come resiliente perché il modello è stato valutato, lasciando le dipendenze fuori dal confine della valutazione. Un test del modello può verificare gli output per un carico di lavoro selezionato. Raramente verifica se un certificato scade nello stesso momento in cui un repository software cambia la sua chiave di firma, se un livello di storage ha capacità sufficiente per un documento più lungo del solito, o se una persona può recuperare il record di origine dopo che un fornitore modifica un'interfaccia di programmazione delle applicazioni. Queste preoccupazioni appartengono al sistema operativo. Fanno comunque parte di ciò che un utente sperimenta come AI.

La domanda utile non è se un modello sia buono in isolamento. È quali altre cose devono essere vere prima che l'output del modello possa essere considerato affidabile, e chi ha l'autorità per riparare quelle cose. Questa domanda sposta la conversazione da un catalogo di modelli a un confine di sistema. Crea anche un inventario meno lusinghiero ma più utile.

  • Quali risorse fisiche devono rimanere disponibili?
  • Quali componenti software e firmware devono arrivare intatti e rimanere supportati?
  • Quali servizi di identità, rete, storage e registro devono rispondere?
  • Quale organizzazione è responsabile quando la dipendenza cambia?
  • Quali prove consentono a un'altra persona di verificare la risposta in seguito?
  • Proposal for the Chips Act 2.0, Commissione europea, 3 giugno 2026.

Queste domande non sono teoriche. Sono la differenza tra una capacità che può essere gestita e una capacità che può essere dimostrata una volta. Le dimostrazioni sono piacevoli. I servizi essenziali devono sopravvivere alla prossima finestra di manutenzione.

Le catene di fornitura sono dentro il confine di sistema

Il lavoro di ENISA sull'integrità della catena di fornitura inizia con un'osservazione poco affascinante: governi, organizzazioni, aziende e consumatori dipendono sempre più da prodotti e servizi ICT, e quindi dalle catene di fornitura che li consegnano. Il suo rapporto nomina minacce che vanno dalla manomissione durante lo sviluppo, la distribuzione o il funzionamento alla sostituzione con componenti contraffatti o clonati. Il punto è più ampio di una checklist di sicurezza. La cosa fornita non è solo una scatola. È una sequenza di persone, codice, componenti, contratti e decisioni attraverso cui la scatola diventa abbastanza affidabile da essere usata.

Un servizio AI eredita quella sequenza. Un addestramento dipende da un'immagine di base, un compilatore, un driver, un kernel, uno scheduler e un dataset di origine. Un servizio di inferenza dipende dagli stessi livelli più un runtime di servizio, un indice, un gate di policy e un'interfaccia che possa continuare a funzionare quando il traffico non ha la forma del set di test. Un'istituzione pubblica può acquistare un servizio piuttosto che uno di questi componenti, ma la catena nascosta non scompare perché il contratto la chiama piattaforma.

L'aggiornamento prospettico ENISA del 2024 colloca il compromesso della supply chain software al primo posto della sua lista di minacce informatiche per il 2030. Colloca inoltre tra le principali preoccupazioni la carenza di competenze, l'errore umano negli ecosistemi cyber-fisici, i fornitori di servizi ICT transfrontalieri come punto unico di guasto e l'impatto fisico delle perturbazioni ambientali sulle infrastrutture digitali critiche. Non si tratta di affermazioni secondo cui ogni progetto di IA incontrerà tutte queste minacce. Sono un promemoria del fatto che la superficie di attacco è fatta di relazioni. Una patch, un fornitore, una persona e un'alluvione possono tutti influire sullo stesso servizio, anche se compaiono in registri di rischio diversi.

Il linguaggio dello stesso rapporto è utile perché resiste alla fantasia che il rischio informatico appartenga solo al team di sicurezza. Una dipendenza può essere compromessa nel software, ma le sue conseguenze possono arrivare attraverso un processo fisico, una scelta di approvvigionamento o una competenza mancante. Un servizio può diventare un punto unico di guasto perché il suo fornitore è tecnicamente eccellente e ampiamente utilizzato. La concentrazione non è la stessa cosa dell'incompetenza. È una proprietà della rete attorno a un servizio.

Questo crea un problema pratico di confine. Se un'organizzazione valuta solo il modello e il suo runtime immediato, il risultato può essere accurato per il confine scelto e fuorviante per il servizio che opera. Se valuta ogni fornitore con la stessa intensità, produrrà un foglio di calcolo che nessuno può mantenere. La risposta è una mappa delle dipendenze che segue le conseguenze. Identificare ciò che può alterare un output, interrompere un servizio, cancellare prove, ampliare l'autorità o impedire il ripristino. Poi chiedersi se la dipendenza è abbastanza visibile da essere monitorata e se esiste un'altra via.

Quella mappa dovrebbe includere materiali ordinari. Un server richiede memoria, dispositivi di archiviazione, conversione di potenza, apparecchiature di raffreddamento e pezzi di ricambio. Una rete richiede componenti ottici, switch, software di routing e persone che conoscono la topologia. Una supply chain software richiede manutentori, infrastruttura di build, registri di pacchetti, chiavi di firma e procedure di rilascio. Nessuno di questi diventa meno importante perché la brochure del prodotto dice intelligenza artificiale.

È tentante rispondere con un questionario per fornitori più ampio. Un questionario può essere utile, ma non è una mappa delle dipendenze. Registra ciò che un fornitore dice in un momento. La questione operativa è se l'acquirente può notare un cambiamento, interpretarlo e intraprendere un'azione proporzionata. Un elenco di certificati non sostituisce la conoscenza di quale componente fermerebbe il servizio se sparisse domani mattina. Le organizzazioni europee sono ammirevolmente brave a raccogliere documenti. L'arte più difficile è far sì che i documenti puntino a una decisione.

I chip rendono fisico l'invisibile

Il Chips Act europeo afferma un fatto che dovrebbe essere ovvio e che ha ancora bisogno di essere affermato: i semiconduttori sono elementi costitutivi dei prodotti elettronici e sono centrali per settori che vanno dalle comunicazioni e dall'elaborazione dei dati alla sanità, all'energia, ai trasporti e all'automazione industriale. L'Atto è entrato in vigore nel settembre 2023 e stabilisce obiettivi che includono il rafforzamento della ricerca e della leadership tecnologica, il potenziamento della capacità di progettazione, produzione e confezionamento, l'affrontare la carenza di competenze e lo sviluppo di una comprensione più profonda della supply chain globale dei semiconduttori.

Questo elenco è importante per l'IA perché la capacità di calcolo non è creata da un logo cloud. È creata da una catena di progetti, wafer, apparecchiature, confezionamento, test, distribuzione di potenza, raffreddamento, networking e manutenzione. Una carenza o un ritardo in una parte può cambiare ciò che un data centre può fornire anche quando i file del modello sono pronti. Se un componente ha un tempo di consegna lungo, un operatore non può risolvere il problema con un prompt intelligente. Se una dipendenza del firmware non può essere aggiornata in sicurezza, la scelta può essere tra una riduzione controllata del servizio e un tentativo non sicuro di mantenere tutto in funzione.

La panoramica della Commissione registra i tre pilastri del Chips Act. Il primo sostiene lo sviluppo di capacità e l'innovazione, incluse le linee pilota e i centri di competenza. Il secondo affronta la sicurezza dell'approvvigionamento e la resilienza attraverso la produzione, il packaging avanzato, il testing e l'assemblaggio. Il terzo crea meccanismi di monitoraggio e di risposta alle crisi, incluso un consiglio europeo per i semiconduttori che mappa e monitora la catena del valore e coordina le risposte alle crisi dei semiconduttori. L'impianto istituzionale è una correzione utile all'idea che la sovranità significhi produrre ogni componente a livello nazionale. La resilienza dipende in parte dalla capacità, in parte dalla visibilità e in parte dalla capacità di rispondere quando una dipendenza si sposta.

La pagina fornisce anche esempi concreti di impianti di prima categoria approvati a Catania, Crolles, Dresda, Novara, Premstätten, Milano e in altre località europee. Queste voci non dimostrano che l'Europa abbia risolto il problema dei semiconduttori. Dimostrano che la catena del valore ha luoghi fisici, tecnologie e decisioni di investimento che possono essere nominati. Nominarli cambia la conversazione. Permette di chiedere quale capacità aggiunge ogni impianto, su quali input fa ancora affidamento, quali competenze richiede e come verrebbe supportato durante un'interruzione.

La proposta della Commissione per un Chips Act 2.0, pubblicata a giugno 2026, afferma che l'Unione rimane dipendente da paesi terzi in settori chiave come la produzione avanzata di chip e la progettazione di semiconduttori. Per un articolo del 31 luglio, questa è una dichiarazione politica attuale, non una previsione su una futura legge. La sua implicazione pratica è semplice: un servizio europeo può essere ospitato in Europa e dipendere comunque da una catena globale le cui decisioni più importanti avvengono altrove. La localizzazione fisica ha valore. Non è la stessa cosa del controllo.

La politica sull'IA può diventare più seria quando adotta questo vocabolario fisico. Invece di chiedersi se un modello è europeo, bisogna chiedersi quali parti del servizio possono essere riparate, sostituite, ispezionate e messe in pausa all'interno delle istituzioni europee. Invece di chiedersi se un fornitore ha una regione europea, bisogna chiedersi come hardware, firmware, dipendenze software e autorità operativa si muovono attraverso il servizio. La risposta sarà disordinata. Bene. Le mappe disordinate sono spesso le prime oneste.

Il calcolo è una capacità pubblica

EuroHPC offre un caso utile perché rende visibile l'infrastruttura di calcolo senza trasformarla in un prodotto di consumo. La sua lista pubblica afferma che l'impresa comune ha acquisito dodici supercomputer all'avanguardia in tutta Europa. La lista nomina sistemi e host: JUPITER a Jülich in Germania, LUMI a Kajaani, Leonardo a Bologna, MareNostrum 5 a Barcellona, Karolina a Ostrava e Arrhenius presso l'Università di Linköping, tra gli altri. Le località contano meno come classifica e più come promemoria che il calcolo è incorporato in istituzioni, edifici, personale, sistemi di alimentazione, storage e programmi di ricerca.

JUPITER è descritto come il primo supercomputer exascale d'Europa, con un'architettura a raffreddamento diretto a liquido, una partizione flash da 20 petabyte e un modulo cluster che utilizza il processore SiPearl Rhea1 insieme a un booster accelerato da GPU. La pagina di LUMI descrive partizioni separate per CPU, GPU, analisi dei dati e cloud container, con un sistema di storage che combina flash, un filesystem parallelo e un servizio di gestione dei dati. Questi dettagli non sono solo curiosità per ingegneri. Dicono a un lettore di policy che un supercomputer è un insieme di risorse di forme diverse. Un carico di lavoro che si adatta a una partizione potrebbe non adattarsi a un'altra. Accesso, pianificazione e movimento dei dati fanno parte della capacità.

MareNostrum 5, ospitato dal Barcelona Supercomputing Center, e Arrhenius, in fase di installazione presso l'Università di Linköping e gestito dalla National Academic Infrastructure for Supercomputing in Svezia, dimostrano lo stesso concetto in modi diversi. Una capacità europea distribuita non è una macchina gigante unica. È un insieme di sistemi con processori, archivi, operatori, regole di accesso e comunità scientifiche differenti. La rete che li collega è importante, ma lo sono anche le giunzioni.

La politica delle AI Factories della Commissione descrive un programma costruito su questa realtà. Le AI Factories utilizzano la capacità di supercalcolo di EuroHPC per sviluppare IA generativa avanzata e collegare centri di calcolo, università, piccole e medie imprese, industria e attori finanziari. La pagina afferma che, al momento del suo aggiornamento dell'aprile 2026, diciannove AI Factories e tredici antenne erano operative, con almeno nove nuovi supercomputer ottimizzati per l'IA in programma. Descrive inoltre un investimento a lungo termine di dieci miliardi di euro attraverso EuroHPC nel periodo 2021-2027. Si tratta di accordi istituzionali, non di una garanzia che ogni progetto riceverà la capacità desiderata o che ogni modello sarà affidabile.

Il valore di tali accordi non risiede solo nella velocità. Il calcolo pubblico può creare uno spazio in cui ricercatori e aziende europee possono eseguire carichi di lavoro secondo regole e modalità di accesso visibili alle istituzioni pubbliche. Può sostenere sperimentazioni che altrimenti sarebbero escluse per motivi di costo e può rendere alcune conoscenze riproducibili tra siti diversi. Può anche introdurre nuove dipendenze se un programma si affida a un numero limitato di fornitori, a un unico stack software o a una forza lavoro insostituibile. La proprietà pubblica di un'infrastruttura non elimina il lavoro operativo. Rende la responsabilità più difficile da nascondere, il che è più sano.

Quando il calcolo diventa capacità pubblica, il suo successo dovrebbe essere misurato oltre le prestazioni di picco. Un gruppo di ricerca più piccolo può ottenere accesso? Un carico di lavoro sensibile può essere separato da uno generale? Un operatore può dimostrare quali software e hardware sono stati utilizzati? Un team può spostare un carico di lavoro quando una partizione è piena o una dipendenza viene ritirata? Un'autorità pubblica può spiegare le condizioni in cui un modello è stato addestrato? Una macchina veloce che non sa rispondere a queste domande è comunque utile per alcune scienze, ma non è ancora una base completa per l'IA pubblica.

Reti, archivi e identità fanno il lavoro silenzioso

I livelli più importanti sono spesso quelli che non compaiono in uno schema di IA. Un diagramma disegna un modello tra un input e un output. Un operatore vede una catena di percorsi di rete, classi di archiviazione, asserzioni di identità, code, certificati, registry, segreti, pipeline di osservabilità e controlli delle modifiche. Il diagramma non è sbagliato. È incompleto esattamente nel modo che produce sorprese costose.

Si cominci dalla rete. Un servizio di modelli di grandi dimensioni può spostare dati tra acceleratori, memoria, archivi e altri servizi. Un carico di lavoro di ricerca pubblica può trasferire dataset a un supercomputer e riportare i risultati a un'università. Un flusso di lavoro produttivo può attraversare un confine di policy prima di raggiungere un modello e un altro confine prima di restituire una decisione. Latenza, perdita di pacchetti, modifiche al routing e manutenzione possono alterare il comportamento dell'intero servizio senza cambiare un singolo parametro nel modello. Un timeout può diventare un retry, un retry può diventare lavoro duplicato e il lavoro duplicato può diventare un record errato. Il modello non ha deciso di riprovare. Lo ha deciso il sistema circostante.

Lo storage ha una propria grammatica nascosta. Ci sono il record sorgente, il record trasformato, l'indice, la cache, il log, il backup, il marcatore di cancellazione e l'evidenza che indica quale versione è stata usata. Un servizio può essere in grado di rispondere a una domanda pur non riuscendo a dimostrare quali dati hanno reso possibile la risposta. Conservazione e recupero non sono immagini speculari. Conservare tutto per sempre può violare un limite di finalità; cancellare la sorgente lasciando un derivato o una cache può creare un problema diverso. Un confine dati serio indica cosa viene conservato, per quanto tempo, da chi e come un revisore successivo può capire che il confine è stato rispettato.

L'identità non è una schermata di accesso. È il meccanismo che dà a una persona, a un servizio o a un agente l'autorità di compiere un'azione. Se un endpoint di inferenza può chiamare uno strumento, il sistema deve sapere quale principal ha fatto la richiesta, quale policy ha consentito la chiamata e a cosa lo strumento poteva accedere. Se un registry consente la promozione di un container, deve sapere chi può approvare la promozione e quali evidenze sono richieste. Se un certificato viene rinnovato automaticamente, il servizio deve comunque avere un modo per accorgersi che la relazione di identità è cambiata. Un segreto che resta valido dopo che la persona che lo ha richiesto se ne è andata è un problema di manutenzione con una conseguenza sulla sicurezza.

I registry sono la memoria di un sistema in movimento. Un model registry può contenere versioni e metadati. Un artefact registry può contenere container, pacchetti o release firmate. Un data registry può descrivere schemi e proprietà. Un inventario hardware può identificare una scheda, una versione del firmware e lo stato di sostituzione. Il punto non è creare un unico registry per tutto. Il punto è rendere esplicita la fonte autorevole per ogni affermazione. Se nessun sistema può dire quale modello, driver, release di dati e versione di policy erano attivi, una revisione successiva è costretta a dedurre la storia dai log che sono sopravvissuti.

L'osservabilità chiude il cerchio. Le metriche dicono a un operatore che una coda è cresciuta o che un dispositivo è caldo. Le trace mostrano il percorso seguito da una richiesta. I log trasportano contesto, anche se restano facili da fraintendere. Gli eventi e le attestazioni possono preservare decisioni e modifiche. Questi oggetti hanno funzioni diverse. Trattarli come intercambiabili produce o rumore o una falsa sensazione di prova. La domanda di progettazione è cosa una persona deve sapere quando il servizio è in ritardo, sbagliato, non disponibile o contestato, e quale record può rispondere a quella domanda senza un esercizio di ricostruzione.

Si può descrivere tutto questo come ingegneria noiosa. Non è un insulto. L'ingegneria noiosa è la parte che continua a funzionare dopo che il post di lancio è sceso nella home page. È anche la parte che determina se un nuovo modello può essere adottato senza riscrivere l'istituzione attorno ad esso.

La manutenzione è una capacità, non una voce di costo

Le storie sulle infrastrutture amano concludersi con il deployment. È in quel momento che il lavoro diventa un servizio. Un modello viene rilasciato, un cluster viene commissionato, una fabbrica apre, un contratto viene firmato e la narrazione passa all'annuncio successivo. Il sistema stesso continua attraverso patch, sostituzione di hardware, formazione, revisioni degli accessi, aggiornamenti, deprecazioni, gestione degli incidenti e la graduale scomparsa delle persone che ricordano perché è stata scelta una certa impostazione.

Il threat outlook dell'ENISA colloca la carenza di competenze tra le principali preoccupazioni a lungo termine. Non è solo una questione di mercato del lavoro. È una questione di resilienza. Un servizio le cui dipendenze non possono essere comprese da più di una persona ha un punto unico di guasto nascosto. Un'organizzazione può avere macchine di riserva e non avere comunque la capacità di usarle in sicurezza perché il runbook, il processo di build o il contratto dati vivono nella memoria di un solo ingegnere. Acquistare supporto può ridurre il rischio, ma l'acquirente deve comunque avere una comprensione sufficiente per contestare il fornitore e decidere quando fermarsi.

La manutenzione cambia anche il significato di una dichiarazione sulle prestazioni. Un benchmark eseguito su una release dice qualcosa su quella release nelle condizioni dichiarate. Non dice che il sistema avrà lo stesso comportamento dopo un aggiornamento del driver, un cambio di compilatore, un nuovo scheduler, un percorso di storage diverso o un nuovo carico di lavoro. Un servizio utile mantiene le condizioni delle proprie dichiarazioni. Registra versioni, input, hardware, policy e modifiche, così che qualcuno possa ripetere un test o spiegare perché la ripetizione non è più possibile.

C'è un costo umano nel fingere che la manutenzione sia una questione di ordine inferiore. Gli operatori ritardano gli aggiornamenti perché il grafico delle dipendenze non è chiaro. I team di sicurezza faticano a capire quale pacchetto sia effettivamente in produzione. Gli acquisti rinnovano un contratto perché nessuno ha provato un'uscita. I ricercatori non riescono a riprodurre un risultato perché l'ambiente è cambiato. Gli utenti incontrano errori intermittenti attribuiti al modello perché il servizio non ha un linguaggio condiviso per i livelli sottostanti. Il risultato non è un singolo fallimento drammatico. È una lenta riduzione della fiducia.

Un programma di manutenzione dovrebbe quindi includere più delle semplici date delle patch. Dovrebbe includere revisioni della titolarità, scadenze degli accessi, rotazione di certificati e chiavi, test di ripristino dei backup, revisione delle dipendenze, ciclo di vita dell'hardware, notifiche di cambiamento dei fornitori, ritiro dei modelli e le evidenze necessarie per ciascuno di questi aspetti. Alcune di queste attività possono essere automatizzate. La responsabilità non può essere automatizzata. Qualcuno deve decidere cosa conta come modifica sostanziale, chi riceve il segnale e quale autorità può sospendere il servizio.

L'istinto europeo di creare un comitato per un problema difficile viene talvolta deriso, spesso ingiustamente. Un comitato che possiede una mappa delle dipendenze, una regola di modifica e un percorso di escalation è più utile di una dashboard che non appartiene a nessuno. Il problema non è la governance. Il problema è una governance che non riesce a raggiungere la macchina.

Gli acquisti sono il punto in cui le dipendenze diventano impegni

I contratti trasformano una dipendenza in un impegno. Un acquirente sceglie un fornitore, un componente, un accordo di supporto, una localizzazione dei dati, un periodo di rinnovo e una condizione di uscita. La decisione può essere descritta come l'acquisto di un servizio di IA, ma l'acquirente sta anche acquistando il processo di aggiornamento del fornitore, la risposta agli incidenti, il modello di identità, la stabilità dell'interfaccia, la documentazione e la capacità di rimanere in attività. Questi non sono caratteristiche secondarie. Determinano quanta autorità mantiene l'acquirente.

Il documento del gruppo consultivo ENISA del 2025 sull'attuazione di NIS2 è insolitamente diretto su questo punto. Osserva che le aziende più piccole possono ricadere nel lavoro di conformità NIS2 perché forniscono entità che rientrano nell'ambito di applicazione. Sostiene un quadro europeo per la sicurezza della supply chain e gli acquisti, con una base di misure e un metodo comune di due diligence. Chiede inoltre una base di riferimento per gli acquisti con requisiti contrattuali minimi, clausole standard, approcci ai test di sicurezza e un modo semplice per il cliente di valutare i fornitori. Il documento è un parere consultivo, non un regolamento. Il suo valore qui è che nomina l'attrito operativo prodotto quando ogni acquirente inventa una versione diversa della diligence.

I team acquisti non devono pretendere che ogni fornitore riveli ogni dettaglio interno. Devono porre domande che si collegano alle conseguenze. Quali componenti sono essenziali per il servizio? Come vengono comunicate le modifiche? Come può l'acquirente verificare il software e il firmware in uso? Cosa succede se un fornitore o un subfornitore non può fornire un componente? Quali dati ed evidenze possono essere esportati? Per quanto tempo continua il supporto dopo il ritiro di una release? Chi può sospendere un'operazione e cosa succede al lavoro già in corso?

Queste domande sono meno appariscenti di una dimostrazione. Sono anche più difficili da fingere. Un fornitore può mostrare una risposta fluente in dieci minuti. È più difficile mostrare un inventario completo delle dipendenze, un ripristino testato, un percorso di migrazione e una persona autorizzata a dire di no al momento giusto. L'acquirente non dovrebbe trattare questa difficoltà come un motivo per evitare le domande. È il motivo per farle prima che il servizio diventi difficile da sostituire.

Il rischio di concentrazione merita un linguaggio accurato. Un fornitore molto diffuso non è automaticamente insicuro, e un piccolo fornitore non è automaticamente resiliente. La concentrazione diventa un rischio quando un fornitore, un repository di software, una rotta geografica, un'autorità di identità o un team di manutenzione comporta più conseguenze di quante l'organizzazione possa assorbire. Il rapporto di previsione dell'ENISA descrive i fornitori di servizi ICT transfrontalieri come un potenziale punto unico di guasto. La risposta appropriata non è fingere che la concentrazione possa essere eliminata. È identificare dove esiste, stabilire una dipendenza accettabile e provare cosa succede se la rotta non è disponibile.

Le clausole di uscita sono spesso scritte come arredi legali. Una vera clausola di uscita ha una forma tecnica. Nomina formati, interfacce, diritti di recupero, chiavi, log, prove, supporto durante la transizione, conferma di cancellazione e le informazioni minime necessarie per ricostruire un servizio altrove. È più solida quando è stata testata su un carico di lavoro ridotto. Il test non deve essere teatrale. Un'esportazione controllata, un ripristino in un ambiente indipendente e un confronto del comportamento risultante possono rivelare più di diverse pagine di assicurazioni.

Le infrastrutture critiche sono una rete di dipendenze

La direttiva sulla resilienza delle entità critiche compie una mossa simile a livello dei servizi essenziali. Definisce la resilienza come la capacità di un'entità di prevenire, proteggersi, rispondere, resistere, mitigare, assorbire, adattarsi e riprendersi da un incidente. Descrive le infrastrutture critiche come un bene, un impianto, un'attrezzatura, una rete o un sistema necessari per un servizio essenziale. La formulazione è volutamente più ampia di un edificio. Tratta un servizio come una relazione tra beni, persone e funzioni.

La direttiva afferma che gli Stati membri dovrebbero considerare i rischi intersettoriali e transfrontalieri, e sottolinea le crescenti interdipendenze tra infrastrutture e settori. Afferma inoltre che gli effetti sulla catena di approvvigionamento dovrebbero essere considerati quando si valuta la significatività di un incidente dirompente. Questo è rilevante per l'infrastruttura dell'IA perché il servizio in questione potrebbe non essere affatto etichettato come intelligenza artificiale. Un collegamento dati, un sistema elettrico, un servizio di identità, un sistema di cartelle cliniche o una rete di ricerca possono essere il livello che rende possibile un servizio abilitato all'IA.

La direttiva non è un manuale operativo per l'IA. Non classifica ogni servizio di modelli come critico e non sostituisce le norme specifiche del settore. Fornisce un modo di pensare alle conseguenze. Se un sistema supporta un servizio essenziale, la domanda non è solo se il modello ha superato una valutazione. È se l'entità può continuare a fornire il servizio essenziale quando un componente, un impianto, un fornitore, una rete o una condizione esterna cambia.

La direttiva NIS2 affianca questa visione fisica e organizzativa con obblighi di gestione del rischio di cybersicurezza e di notifica degli incidenti per le entità pertinenti. L'interazione giuridica è specifica e dipende dall'entità e dal settore. La lezione generale non è che una singola direttiva risolva la resilienza. È che le dipendenze informatiche e fisiche devono essere coordinate. Una rete può essere sicura contro un tipo di attacco e fallire comunque quando il raffreddamento non è disponibile. Un impianto può avere alimentazione ridondante e non essere comunque in grado di autenticare gli operatori. Un fornitore può notificare un incidente software mentre l'acquirente non dispone dei registri necessari per comprenderne l'effetto.

La resilienza richiede quindi un vocabolario per il servizio degradato, non solo per l'interruzione totale. Il sistema può accettare meno richieste? Può disattivare una funzione ad alto rischio preservandone una a basso rischio? Può passare a un modello più piccolo o a un percorso manuale? Può continuare a funzionare mentre una coda viene svuotata e una fonte viene verificata? Può dimostrare quale lavoro è stato ritardato o riprocessato? Queste sono decisioni operative. Determinano anche se cittadini, ricercatori e aziende sperimentano una limitazione controllata o una risposta misteriosa che arriva dopo che l'istituzione ha perso il contesto per esaminarla.

L'immagine utile è una rete i cui nodi hanno proprietari e i cui collegamenti hanno condizioni. Un collegamento può essere una connessione elettrica, una dipendenza software, un contratto, un trasferimento di dati o una relazione di autorità. Un design resiliente non presuppone che ogni collegamento rimanga disponibile. Registra il collegamento, monitora la condizione che conta e definisce una risposta prima che la pressione arrivi.

Un esempio composito illustrativo, non un rapporto di incidente

Aiuta a rendere concreto il problema delle dipendenze senza inventare un'interruzione reale. Quanto segue è un esempio composito illustrativo. Non descrive alcuna organizzazione, fornitore, struttura, persona, data o evento nominato. È un esperimento mentale costruito da relazioni infrastrutturali ordinarie.

Immagina un servizio di ricerca pubblico che consente ai team autorizzati di inviare un documento, eseguire un flusso di lavoro di classificazione e ricevere un risultato per la revisione umana. Il servizio è ospitato su infrastruttura europea. Il suo modello è archiviato in un registro di artefatti. I documenti sorgente vivono in un livello di archiviazione e l'indice in un altro. Un gateway verifica l'identità e inoltra il lavoro a una coda. I worker utilizzano un'immagine container e un driver hardware. I risultati vengono scritti in un archivio di record e in uno stream di evidenze. Una dashboard dice al team operativo se il sistema è sano.

Niente di tutto questo è insolito. È proprio questo il punto. Ora cambia una condizione alla volta. Il registro modifica la sua politica di firma. L'aggiornamento del driver richiede un nuovo runtime container. Un certificato scade per il servizio che scrive le evidenze, mentre l'archivio dei risultati continua ad accettare scritture. Una quota di archiviazione viene raggiunta per un indice derivato ma non per i documenti sorgente. Un fornitore modifica un'interfaccia e il consumatore della coda riprova un'operazione che non era stata progettata per essere ripetuta. Un operatore esperto se ne va e il runbook descrive ancora la distribuzione precedente. Nessuno di questi cambiamenti richiede che un modello produca una frase falsa. Ciascuno può modificare l'affidabilità del servizio o la sua capacità di spiegarsi.

Un'organizzazione che osserva solo l'accuratezza del modello potrebbe non vedere alcun avviso. Il set di test passa ancora. Un'organizzazione che osserva l'intero servizio vedrà segnali diversi: un errore di verifica, un conteggio di retry in aumento, un vuoto nello stream di evidenze, una soglia di archiviazione, una modifica non revisionata o un allarme di proprietà. I segnali non sono equivalenti e non richiedono tutti un'interruzione. Richiedono una regola su chi decide cosa succede dopo.

Supponiamo che il team scelga di ridurre la capacità mentre verifica la dipendenza. Non è un segno che il servizio abbia fallito il suo scopo. Potrebbe essere un segno che il servizio ha uno scopo più ampio del throughput. Se il sistema può preservare il record sorgente, contrassegnare il lavoro ritardato, prevenire retry non autorizzati e dare a una persona un percorso chiaro per ispezionare i casi interessati, si è degradato in modo controllato. Se continua a produrre risposte raffinate mentre il suo percorso di evidenze è interrotto, ha preservato l'apparenza del servizio a costo della fiducia.

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.

Una dipendenza non deve distruggere il modello per cambiare ciò che il servizio può dichiarare in modo sicuro.

Misurare la capacità senza nascondere il denominatore

Le infrastrutture incoraggiano numeri impressionanti. Exaflop, petabyte, numero di processori, totali di investimento e numero di strutture in un programma descrivono tutti qualcosa di reale. Nessuno di essi è il servizio in sé. Un numero diventa utile quando il suo denominatore e le sue condizioni sono visibili.

Le prestazioni di calcolo di picco non dicono a un ricercatore quanto rapidamente un carico di lavoro specifico otterrà una partizione, sposterà i suoi dati, completerà un'esecuzione o recupererà il risultato. Il numero di AI Factory non dice a una piccola azienda se la sua applicazione riceverà accesso alle condizioni di cui ha bisogno. Un totale di investimenti nei semiconduttori non dice a un operatore quale componente sarà disponibile durante una carenza. Una percentuale di disponibilità elevata non dice a un'istituzione pubblica se può recuperare le prove per una decisione contestata.

Una descrizione responsabile della capacità abbina quindi il titolo al percorso che sta dietro. Nomina il confine tra hardware e software. Indica se la cifra è di picco, sostenuta, pianificata o osservata. Descrivi il carico di lavoro, il modello di accesso e le esclusioni. Dì quali dipendenze sono al di fuori della misurazione. Mantieni l'affermazione legata alla release, all'hardware, al dataset e alla policy in base alla quale è stata fatta. L'obiettivo non è rendere illeggibile ogni pagina. È rendere verificabili le pagine importanti.

Questa disciplina migliora anche il dibattito pubblico. L'Europa non deve scegliere tra ambizione e cautela. Può costruire grandi strutture, finanziare ricerca ambiziosa e comunque dire dove finiscono le prove. Un sistema pubblico che nomina i suoi vincoli è più credibile di uno che presenta un numero pulito senza alcuna via per ispezionarlo. Il vincolo può essere una coda, un'interfaccia, un fornitore, un divario di competenze, un limite di potenza o un confine legale. Nominarlo non rende la capacità più piccola. Dice alle persone che tipo di capacità è.

L'incertezza non è un'ammissione di sconfitta. È un segnale di manutenzione. Se nessuno sa come il cambiamento di un fornitore influenzerà un carico di lavoro, il passo successivo è un test o un'ipotesi esplicita, non un aggettivo più grande. Se un registro non riesce a distinguere una release del modello da una configurazione di servizio, il passo successivo è una migliore registrazione. Se un'istituzione non può dire quale persona può fermare un'operazione, il passo successivo è una mappa delle autorità. La precisione è un modo per decidere cosa riparare.

Gli strati silenziosi sono dove la sovranità diventa pratica

La sovranità europea viene talvolta discussa come se fosse una bandiera posta sopra un data centre. Un servizio può trovarsi all'interno dell'Unione e dipendere comunque da componenti esterni, dalla portata giuridica di Paesi terzi, da interfacce proprietarie, da competenze scarse o da un fornitore le cui decisioni di modifica non possono essere contestate. L'ubicazione è uno degli elementi di una valutazione di sovranità. Il controllo pratico dipende dall'intera catena.

L'attenzione del Chips Act alla comprensione della catena globale di approvvigionamento dei semiconduttori, quella della direttiva CER alle interdipendenze tra settori e gli avvertimenti dell'ENISA sulle dipendenze software e sui punti unici di guasto indicano tutti la stessa direzione. La sovranità non è un singolo interruttore. È la capacità di capire da cosa dipende un servizio, di decidere quale dipendenza sia accettabile, di sostituirla o limitarla quando necessario e di conservare prove sufficienti a difendere la decisione.

Questa capacità può essere costruita in modi semplici. Un gruppo di ricerca pubblico può tenere un inventario del runtime, del driver e della versione dei dati usati per un risultato. Un team acquisti può richiedere un percorso di esportazione testato piuttosto che una promessa di portabilità. Un team operativo può definire una modalità degradata e provarla. Un regolatore può chiedere quali registrazioni sarebbero disponibili dopo un cambio di fornitore. Un fornitore può pubblicare il confine del proprio supporto e le condizioni in cui un aggiornamento modifica il comportamento. Nessuna di queste azioni rende un sistema autonomo. Lo rendono meno misterioso.

In Dweve, questo è il motivo ristretto per cui ci interessano le fondamenta aperte e i componenti silenziosi che le circondano. Progetti come Core e Mesh sono utili solo quando si collocano all'interno di un confine operativo onesto, con registrazioni, autorità e limiti chiari. Non sostituiscono le infrastrutture europee, le istituzioni pubbliche o le politiche sulla catena di approvvigionamento, e questo articolo non sostiene che risolvano questi problemi. La posizione è più modesta: un componente aperto è più facile da ispezionare, sostituire e insegnare quando i suoi contratti sono espliciti. Questo è un mattone, non l'intero edificio.

L'edificio conta perché le persone incontrano l'ultimo piano e convivono con le fondamenta. La risposta sullo schermo può essere fluida, ma il carattere reale del servizio è deciso dai livelli che determinano da dove proviene la risposta, chi potrebbe modificarla, cosa accade quando una dipendenza si sposta e se qualcuno può spiegare il risultato in seguito.

Costruire il sistema che le persone possono ancora vedere

Il sistema di IA più importante potrebbe essere quello che nessuno vede perché è distribuito in luoghi che non sono mai stati chiamati IA. È l'impianto di chip e il circuito di raffreddamento. È il supercomputer e lo scheduler. È il registro dei pacchetti, il provider di identità, la politica di archiviazione, la rotta di rete e il registro di manutenzione. È il contratto che stabilisce cosa accade quando un fornitore modifica un componente. È l'istituzione che può mettere in pausa un flusso di lavoro prima che un segnale debole diventi un fallimento pubblico.

Niente di tutto ciò riduce l'importanza della qualità del modello. Dà alla qualità del modello un posto dove contare. Un modello può servire una persona solo attraverso un sistema in grado di ricevere l'input, svolgere il lavoro, conservare la registrazione pertinente e restituire il risultato con abbastanza contesto perché qualcuno possa fidarsene o contestarlo. Il modello è un componente importante di quel sistema. Non è un Paese, una catena di approvvigionamento, un piano di ripristino o una persona con l'autorità di riparare le parti che non può vedere.

I programmi infrastrutturali europei sono un'opportunità per rendere visibili queste dipendenze mentre la capacità viene costruita. L'opportunità è pratica. Pubblicare interfacce e confini operativi. Finanziare manutenzione e competenze insieme alle attrezzature. Trattare gli acquisti come una decisione di progettazione. Collegare la cybersicurezza alla resilienza fisica. Dare alle organizzazioni più piccole un percorso per usare le infrastrutture pubbliche senza costringerle a diventare specialiste di ogni livello. Misurare accesso, ripristino e prove con la stessa attenzione riservata alle prestazioni di picco.

C'è un certo piacere europeo nello scoprire che la risposta a una grande domanda tecnologica è un inventario, un runbook e una persona autorizzata a fermare la macchina. Non è affascinante, ma ha il vantaggio di sopravvivere al contatto con il martedì. Quando il sistema nascosto è abbastanza visibile da poterlo ispezionare, il modello può fare il suo lavoro senza portare un mito che non è mai stato costruito per portare.

Fonti