Codici di costruzione per l'AI agente: come il NIST sta scrivendo le regole di sicurezza del software autonomo

Dai Cantieri ai Cluster: La Metafora Strutturale della Sicurezza AI

L'immaginario collettivo associa ancora l'intelligenza artificiale a chatbot che allucinano citazioni legali o generano codice buggato. Ma nel 2026 la frontiera si è spostata: parliamo di AI agente, sistemi che non si limitano a rispondere, ma agiscono. Prenotano voli, ribilanciano portafogli, gestiscono flussi logistici, interagiscono con API bancarie e, sempre più spesso, controllano processi industriali fisici. In questo scenario, la domanda non è più "quanto è bravo il modello?", ma "quanto è sicuro l'edificio che stiamo costruendo sopra questo modello?".

La risposta sta arrivando da un luogo inaspettato: l'ingegneria civile. Il National Institute of Standards and Technology (NIST), l'ente federale USA che definisce gli standard per tutto, dalla crittografia quantistica alla resistenza al fuoco dei grattacieli, ha recentemente ribadito il suo approccio metodologico per le indagini sui disastri strutturali. Come emerso dagli aggiornamenti del National Construction Safety Team, "le presentazioni hanno evidenziato l'importanza per NIST di applicare la propria competenza e quella altrui attraverso collaborazioni e contratti" (NIST News). È una frase burocratica che nasconde un cambio di paradigma epocale: la sicurezza dell'AI agente sta uscendo dall'informatica per entrare nel diritto delle costruzioni.

Non è una metafora letteraria. Quando un agente autonomo negozia contratti energetici in tempo reale o gestisce il routing di un data center critico, il suo fallimento non genera un messaggio di errore: genera un blackout, una perdita finanziaria sistemica, un rischio per la sicurezza fisica. Trattare questi sistemi come "software da testare" è obsoleto. Vanno trattati come infrastrutture da certificare. E NIST sta scrivendo il codice di costruzione per questa nuova architettura invisibile.

L'Architettura della Fiducia: Standard, Test Bed e "Crash Test" Algoritmici

Il cuore del problema è che l'AI agente non è un monolite. È una catena di componenti eterogenei: un LLM per il ragionamento, un orchestratore per la pianificazione (spesso basato su grafi o PDDL), tool esterni (browser, terminali, API), memorie vettoriali, sistemi di identità e accesso (IAM). Ogni anello ha una superficie d'attacco e una modalità di fallimento diversa. Il NIST AI Risk Management Framework (AI RMF 1.0) ha fornito il vocabolario (Govern, Map, Measure, Manage), ma il 2026 segna il passaggio dal "cosa" al "come".

Stiamo assistendo alla nascita di Test Bed federali per agenti, l'equivalente digitale delle camere di prova al fuoco o delle tavole vibranti sismiche. In questi ambienti controllati — gestiti da NIST in collaborazione con NSA, CISA e partner accademici — gli agenti vengono sottoposti a stress test sistemici: iniezione di prompt avversari tramite toolchain compromesse, simulazione di hallucination cascading in piani a 20 step, attacchi di tool hijacking dove un'API maliziosa dirotta l'agente verso azioni distruttive.

La novità non è il red teaming — praticato da anni — ma la standardizzazione delle metriche di resilienza. Proprio come un acciaio deve certificare la sua yield strength e ultimate tensile strength secondo ASTM A36, un agente che gestisce pagamenti SEPA Instant dovrà presto certificare il suo Mean Time To Containment (MTTC) sotto attacco di indirect prompt injection, o la sua Action Reversibility Rate in scenari di tool failure.

Questo richiede una strumentazione radicalmente nuova: runtime monitor che non si limitano a loggare, ma calcolano invariant violations su grafi di esecuzione in tempo reale; circuit-breaker kernel-level (eBPF/WASM) capaci di bloccare una syscall sospetta dell'agente in microsecondi; provenance ledger immutabili (spesso basati su Sigstore/Transparency Logs) che firmano crittograficamente ogni decisione, input tool e output tool, rendendo l'agente auditable by design.

La Catena di Fornitura del Rischio: SBOM, Provenance e Responsabilità a Cascata

Se l'agente è l'edificio, la supply chain è la filiera dei materiali. E qui il parallelo con l'edilizia diventa letterale. Il Software Bill of Materials (SBOM), obbligatorio per il software critico USA (EO 14028) e spinto dal Cyber Resilience Act in Europa, non basta più. Un SBOM statico dice quali librerie Python sono nel container. Non dice quale versione del prompt di sistema è stata usata, quale policy di routing era attiva, quale dataset di fine-tuning ha plasmato il comportamento dell'orchestratore.

Nasce così l'AI Bill of Materials (AI-BOM): un manifesto dinamico che include model cards firmate, data cards, prompt templates versionati, tool manifests con hash delle specifiche OpenAPI, e policy bundles (OPA/Rego) che definiscono i guardrail. NIST sta spingendo per formati interoperabili (CycloneDX, SPDX 3.0 con profili AI) affinché un acquirente — o un assicuratore cyber — possa verificare il pedigree dell'agente prima del deploy.

La responsabilità diventa a cascata. Se un agente finanziario causa un flash crash per aver eseguito un ordine su un'API price feed compromessa, chi risponde? Il vendor dell'agente? Il fornitore del feed? Chi ha scritto il prompt "massimizza liquidità"? Il Cyber Resilience Act europeo e la futura AI Liability Directive spostano l'onere della prova sul deployer: **dimostrare di aver fatto due diligence sulla catena di fornitura dell'agente**. Significa richiedere attestazioni (in-toto, SLSA Level 3+) non solo sul build del container, ma sulla training pipeline, sul red teaming report, sui runtime guardrail attivi.

Per le aziende italiane, abituate a gestire fornitori software con contratti SaaS standard, è uno shock contrattuale. Non si compra più una licenza; si commissiona un'infrastruttura autonoma con obblighi di continuous monitoring, incident reporting (entro 72 ore per NIS2), e model drift detection documentato. Chi non adegua i processi di vendor risk management a questa granularità si espone a sanzioni e, peggio, alla uninsurability del rischio AI.

Verso un "Permesso di Costruire" per gli Agenti Autonomi: Implicazioni per l'Impresa Italiana

L'Italia, con il suo tessuto di PMI manifatturiere, energetiche e finanziarie ad alta regolamentazione (Banca d'Italia, IVASS, ARERA, ACN), è il laboratorio naturale per questa transizione. Il Piano Nazionale AI e l'attuazione dell'AI Act (in vigore pieno dal 2026 per i sistemi ad alto rischio) richiedono che ogni sistema agentivo usato in credit scoring, grid balancing, diagnostica medica o logistica portuale passi una Valutazione di Conformità da parte di un Organismo Notificato.

Non esiste ancora un "bollino CE" per l'AI agente, ma la traiettoria è chiara: certificazione per casi d'uso, non per modelli. Un agente general purpose (es. un LLM con tool use) non si certifica. Si certifica l'istanza in produzione: il prompt di sistema fissato, la policy OPA attiva, la allowlist di tool firmati, il monitor runtime configurato, il playbook di incident response testato. È esattamente come per un impianto antincendio: non certifichi l'estintore, certifichi l'impianto installato in quel palazzo, con quelle tubature, quella manutenzione, quel responsabile.

Per un CISO o un CTO italiano oggi, l'agenda operativa è triplice:

1. Inventario degli Agenti Ombra: Mappare ogni workflow dove un LLM prende decisioni operative (anche solo "invia questa email", "aggiorna questo record CRM"). La maggior parte gira in shadow IT su account personali o sandbox non governate.
2. **Architettura *Guardrail-First***: Spostare la logica di sicurezza fuori dal prompt. Usare policy engine esterni (OPA, Cedar, custom WASM) che intercettano ogni tool call dell'agente prima dell'esecuzione, validando parametri, privilegi, coerenza con intenti dichiarati. Il prompt è UX; la policy è codice edilizio.
3. Contratti e Assicurazioni: Rinegoziare SLA e DPA con i vendor AI includendo clausole su model version pinning, red teaming evidence, runtime telemetry access, indemnity per decisioni autonome. Coinvolgere i broker assicurativi ora: le polizze AI Error & Omission stanno nascendo, ma richiedono evidence di secure development lifecycle per agenti (SDLC-A).

Il messaggio che arriva da Gaithersburg, Maryland — dove NIST coordina le indagini sui crolli strutturali da decenni — è semplice e ingegneristico: non si improvvisa la sicurezza delle infrastrutture critiche. Si definiscono requisiti, si testano campioni, si ispeziona l'installazione, si monitora la vita operativa, si indaga ogni incidente per aggiornare il codice. L'AI agente ha appena ricevuto il suo avviso di deposito del progetto. Le imprese italiane che iniziano a costruire "a regola d'arte" oggi — con SBOM dinamici, guardrail architetturali, contratti allineati all'AI Act — non solo eviteranno sanzioni. Avranno accesso ai mercati regolamentati, premi assicurativi inferiori, e la fiducia di clienti che chiedono, semplicemente: "È sicuro entrare in questo edificio?"