Il cloud sovrano non ha le chiavi di casa

Il cloud sovrano promette controllo ma lascia al vendor la gestione del piano operativo

L’ultima scommessa del cloud sovrano si gioca su un token JWT. Il gateway serverless A2A per agent discovery, routing e access control descritto nella documentazione AWS ha un meccanismo di controllo accessi che farebbe invidia a molti sistemi on-premise: un authorizer Lambda del gateway A2A per la sicurezza ispeziona gli scope JWT nel token per l’autorizzazione riga per riga e genera policy IAM che concedono o negano l’accesso a percorsi come /agents/agent-a/*. È elegante, profondo, quasi artigianale nella precisione. Ma è anche il dettaglio che svela il paradosso: l’intelligence del governo si affida a un meccanismo di autorizzazione definito, eseguito e gestito da un vendor privato su un runtime commerciale.

I modelli OSS su Bedrock GovCloud per carichi governativi sono arrivati con un annuncio che ha il peso specifico delle cose che contano: open-weight di OpenAI e NVIDIA Nemotron, dai 9 fino ai 120 miliardi di parametri, eseguibili all’interno di regioni AWS GovCloud (US) per dati sensibili fisicamente localizzate negli Stati Uniti e amministrate esclusivamente da cittadini statunitensi. Il tutto incorniciato da certificazioni FedRAMP High e DoD SRG Impact Level 5 per la conformità che includono ITAR e CJIS, il massimo che si possa chiedere a un cloud regolamentato.

Lo zero operator access e l’illusione del controllo

Sotto il cofano, il motore di inferenza di nuova generazione adotta un design zero operator access per i dati di inferenza: nessun operatore umano può leggere prompt o completions. Il dato rimane confinato in un perimetro crittografato, servito da Amazon Bedrock per l’inferenza gestita, un servizio completamente amministrato dove l’inferenza gira su infrastruttura operata da AWS. Anche l’ultima istruzione, il log, il peso del modello, tutto transita su un piano di controllo che resta fuori dalla portata del cliente.

Il governo può eseguire i modelli, sì. Può spegnerli, cambiarli, isolarli in una VPC. Ma non può accendere l’hardware senza passare dalla chiave di chi possiede il data center.

Modelli aperti, dipendenza chiusa

Qui si consuma il cortocircuito. I pesi sono aperti — chiunque può scaricarli, modificarli, farne il fine-tuning su un cluster proprio. Ma la loro esecuzione su GovCloud avviene all’interno di un perimetro operativo di cui lo stato acquirente non ha il controllo ultimo. Non è una questione di fiducia nel vendor: è un problema strutturale di dipendenza dal piano di controllo. Se domani un ordine esecutivo impone nuove regole di accesso amministrativo alle regioni GovCloud, l’ente governativo che ha costruito l’intera pipeline su Bedrock si trova con un’architettura non portabile, perché il valore non sta nel modello ma nell’integrazione con i servizi nativi.

Chi progetta oggi sistemi per la pubblica amministrazione ha una scelta architetturale netta. Può abbracciare Claude Fable 5 su Amazon Bedrock per la scalabilità e godere di un ambiente integrato, scalabile, compliant. Oppure può accettare un costo di complessità maggiore e costruire su Kubernetes bare metal, dove l’open-weight diventa davvero indipendente e il ciclo di vita dell’inferenza non dipende da un amministratore terzo. Non esiste una terza via. Ed è esattamente questo il punto: chiamiamo “sovrano” un cloud che ci lascia usare modelli aperti, ma che non ci lascia mai veramente le chiavi del piano di controllo.