Nel maggio 2026, il Software Engineering Institute (SEI) della Carnegie Mellon University ha pubblicato un aggiornamento del proprio documento di riferimento sull’ingegneria dell’intelligenza artificiale, intitolato “AI
Engineering: Twelve Foundational Practices“.
Hanno introdotto una nuova pratica e promosso la valutazione come disciplina autonoma.
Ecco una sintesi e un’analisi critica del documento rivolta ai ricercatori e agli sviluppatori impegnati nello studio della sicurezza dei sistemi di IA.
Indice degli argomenti
L’aggiornamento del documento
Il documento non si concentra sulle singole prescrizioni, che sono volutamente agnostiche rispetto alla tecnologia, ma sul fatto che il comportamento dei sistemi di IA emerge dai dati e non dalla specifica.
Ciò ha conseguenze rilevanti sulle loro proprietà di sicurezza e affidabilità.
Si discutono inoltre i limiti dell’impianto proposto, in particolare il contrasto tra la neutralità tecnologica e l’operatività delle raccomandazioni, e si individuano alcuni possibili ambiti di ricerca con un’attenzione particolare ai sistemi agentici.
Il contesto
Nel 2019, il Software Engineering Institute (SEI) della Carnegie Mellon University ha pubblicato AI Engineering: 11 Foundational Practices, un documento rapidamente diventato un punto di riferimento per le organizzazioni che intendono portare in produzione sistemi che incorporano l’intelligenza artificiale [1].
L’aggiornamento del 2026, che porta il numero delle pratiche a dodici, non rappresenta una semplice revisione editoriale, ma la conferma di un mutamento strutturale del panorama tecnologico [2].
Dal punto di vista ingegneristico, il cambiamento più rilevante riguarda le modalità con cui le organizzazioni acquisiscono capacità di IA.
Se nel 2019 “usare l’IA” significava quasi sempre addestrare un modello di apprendimento automatico, oggi le stesse capacità si realizzano attraverso percorsi eterogenei:
- addestramento di modelli su misura,
- consumo di foundation models tramite API,
- fine-tuning di open-weight models,
- o assemblaggio di sistemi composti che orchestrano più componenti.
Ciascun percorso comporta implicazioni distinte per la gestione dei dati, la sicurezza, il collaudo e il controllo operativo, aspetti che meritano particolare attenzione nell’ambito della ricerca sulla sicurezza.
L’analisi delle 12 best practice dell’ingegneria dei sistemi di AI
L’intento è quello di perseguire due obiettivi. In primo luogo, fornire una sintesi accurata e fedele delle dodici pratiche, così da rendere disponibile una mappa concettuale per i professionisti dell’IA.
In secondo luogo, proporre una lettura critica che metta in luce i punti di forza dell’impianto, le sue tensioni interne e le questioni ancora aperte alla ricerca.
Il comportamento emerge dai dati
Il presupposto teorico che attraversa l’intero documento è la distinzione tra software tradizionale e sistemi di IA.
Mentre nel software convenzionale il comportamento discende da una specifica, nei sistemi di IA emerge dai dati: le prestazioni cambiano in base alle distribuzioni e i componenti tendono a un’interconnessione reciproca che ostacola la modularità.
Poiché i modelli apprendono relazioni approssimate dai dati di addestramento, anziché implementare regole esatte, possono produrre risultati inaffidabili quando si trovano di fronte a input diversi da quelli osservati.
Questa premessa, apparentemente nota, ha implicazioni che la letteratura sulla sicurezza tende ancora a sottovalutare.
Se il comportamento è appreso e non specificato, allora le proprietà di sicurezza non possono essere verificate una sola volta e date per acquisite, ma devono essere costantemente monitorate lungo l’intero ciclo di vita.
È in questo contesto che si inserisce la novità più significativa dell’aggiornamento: la promozione della valutazione come pratica autonoma. Nel 2019 la valutazione si riduceva essenzialmente all’accuratezza di un set di test, mentre oggi comprende il rilevamento del drift, la misurazione degli sbilanciamenti, il tracciamento degli output non validi, i test di sicurezza e il monitoraggio continuo in produzione.
Sintesi delle 12 pratiche: la tabella
La tabella seguente presenta in forma sinottica le dodici pratiche, ciascuna accompagnata da una sintesi del rispettivo contenuto ingegneristico.
Le pratiche non vanno intese come una sequenza procedurale o una checklist, ma come un quadro di riferimento per le decisioni progettuali.
| N. | Pratica | Sintesi del contenuto ingegneristico |
| 1 | Idoneità del problema e scelta dell’approccio | Verificare che il problema sia effettivamente adatto all’IA e selezionare l’approccio (regole, ML classico, modelli fondazionali, sistemi composti o agentici) in base al contesto e al costo totale di proprietà. |
| 2 | Team interfunzionali | È necessario integrare competenze di dominio, ingegneria dei sistemi, valutazione e prompt engineering. Il dominio è un aspetto critico: il 43% delle “cascate di dati” deriva da una conoscenza insufficiente del dominio. |
| 3 | Gestione del dato sull’intero ciclo di vita | Occorre trattare con rigore non solo i set di addestramento, ma anche i dati di recupero, di affinamento, di benchmark e di contesto per l’inferenza, e bisogna controllare la provenienza e il drift. |
| 4 | Selezione guidata dai requisiti, non dalla tecnologia | Scegliere l’approccio più semplice che soddisfi i requisiti; fissare presto i requisiti di interpretabilità e progettare per la sostituibilità. |
| 5 | Sicurezza sull’intera superficie di minaccia | Difesa in profondità contro attacchi training-time e runtime: data poisoning, input avversari, furto del modello, rischi di supply chain, prompt injection, agency eccessiva. |
| 6 | Tracciabilità e versioning di tutti gli artefatti | Tracciare i modelli, i dati, i prompt, le configurazioni di retrieval, i guardrail e le definizioni di tool; progettare per la verificabilità fin dall’inizio. |
| 7 | Interazione e supervisione umana proporzionate al rischio | È necessario calibrare il pattern di oversight in base alla posta in gioco e al tempo operativo, e contrastare l’automation complacency e il «cognitive surrender» con safeguard tecnici. |
| 8 | Incertezza del modello come concern di prima classe | Quantificare e comunicare l’incertezza; gestire l’asimmetria per cui gli output errati appaiono indistinguibili da quelli corretti nei modelli generativi. |
| 9 | Modularità e resilienza operativa | Decomporre in moduli debolmente accoppiati con contratti espliciti; osservabilità estesa, rilevamento del drift, rollback e gestione del debito tecnico. |
| 10 | Pianificare e finanziare il cambiamento continuo | Bilanciare costi operativi ricorrenti (monitoraggio, retraining, dipendenze di terzi); «FinOps for AI» per il governo dei costi computazionali. |
| 11 | Ingegneria della safety pratica | Applicare hazard analysis, identificazione dei failure mode, safety case e safeguard operativi adattati alle caratteristiche dei componenti IA. |
| 12 | Valutazione come obiettivo progettuale primario | Promuovere la valutazione a pratica autonoma: evaluation-driven development, benchmark di dominio, valutazione continua in produzione. |
La sicurezza come superficie estesa
Per il progettista focalizzato sulla sicurezza, le pratiche 5 e 11 costituiscono il fulcro del tema e il documento ha il merito di distinguerle chiaramente.
La pratica 5 affronta il tema della sicurezza ovvero la difesa contro l’azione avversaria. Invece la pratica 11 affronta il tema della safety ovvero la prevenzione del danno anche in assenza di un attacco.
Non è meramente terminologica la distinzione: i sistemi di IA possono causare danni producendo output erroneamente fiduciosi in contesti ad alta criticità, comportandosi in modo imprevedibile di fronte a input nuovi o intraprendendo azioni autonome con conseguenze indesiderate.
Per quanto riguarda la sicurezza, il documento recepisce l’evoluzione del modello di minaccia.
Alle minacce classiche, quali il poisoning dei dati di addestramento, gli input malevoli e il furto del modello, si aggiungono i rischi della supply chain (peso compromesso, pacchetti open source avvelenati e artefatti non verificati) e, per i sistemi basati su foundation models, ulteriori categorie quali prompt injection, il system prompt leakage, l’agency eccessiva e le debolezze dei vettori e degli embedding.
Il riferimento alle tassonomie OWASP e ai principi della Coalition for Secure AI fornisce un collegamento ai concetti ormai consolidati.
Il documento adotta, programmaticamente, un registro neutrale rispetto alla tecnologia e raccomanda il red teaming «come una componente di un programma di sicurezza più ampio», riconoscendone i limiti [6].
Questa cautela è metodologicamente corretta, ma lascia allo sviluppatore l’onere di tradurre il principio in controlli operativi.
Per la ricerca, ciò segnala uno spazio aperto: la formalizzazione di metriche di efficacia degli stessi meccanismi di sicurezza, oggi più evocata che codificata.
I limiti della supervisione umana
Tra i contributi più rilevanti dell’aggiornamento figura il trattamento della supervisione umana (pratica 7).
Il documento supera la rassicurante formula del “human in the loop” e ne critica l’efficacia: la sola presenza di un revisore umano, infatti, non garantisce un controllo effettivo.
Si richiamano due fenomeni:
- l’automation complacency ovvero la tendenza ad accettare le raccomandazioni dell’IA senza un’adeguata verifica, accentuata dalla fiducia crescente;
- e un fenomeno più occulto, definito cognitive surrender, in cui l’utente non solo si affida al sistema, ma rinuncia al proprio processo di ragionamento.
Si tratta di un’osservazione di rilievo per la ricerca sulla sicurezza socio-tecnica, in quanto sposta il problema dall’architettura del sistema all’ergonomia cognitiva della supervisione [7].
La raccomandazione conseguente, ovvero misurare l’efficacia della supervisione tramite indicatori quali i tassi di override e il tempo dedicato al compito, anziché assumerla, è metodologicamente solida e, a giudizio di chi scrive, una delle più immediatamente operative dell’intero documento.
Resta tuttavia da indagare come calibrare tali indicatori nei sistemi ad alta autonomia, nei quali la frequenza stessa dell’intervento umano si riduce
per definizione.
Neutralità contro operatività
La principale criticità del documento, riconosciuta esplicitamente dagli autori, risiede nella scelta di preservare la brevità e la neutralità tecnologica.
Questa scelta garantisce longevità: le raccomandazioni del 2019, infatti, si sono rivelate durevoli proprio perché non sono ancorate a tecnologie specifiche.
Il prezzo da pagare, però, è che molte indicazioni restano a livello di principio e necessitano di un complesso lavoro di traduzione in pratica ingegneristica. Gli stessi autori ne sono consapevoli e qualificano il testo come «un quadro per le decisioni progettuali, non una guida all’implementazione né una checklist».
Per la ricerca, questa astrazione è più feconda che problematica: ciascuna pratica individua, in negativo, un tema di approfondimento.
La pratica 8 sull’incertezza, ad esempio, segnala l’asimmetria per cui, negli output generativi, un risultato errato non può essere distinto da uno corretto. Questa proprietà invalida le tradizionali assunzioni sulla gestione dell’errore e richiede strumenti di calibrazione della confidenza ancora immaturi.
Allo stesso modo, la pratica 9 sulla resilienza richiama il debito tecnico che i sistemi di IA accumulano in forme inedite, come le dipendenze di dati intrecciate e i loop di retroazione che alterano silenziosamente il comportamento.
Prospettive di ricerca: i 3 ambiti più promettenti
Le dodici raccomandazioni del SEI rappresentano, nel loro complesso, una sistematizzazione dello stato dell’arte più che una proposta originale.
È proprio in questa funzione di sintesi che risiede il loro valore: il documento, infatti, offre un linguaggio condiviso e una mappa dei temi ingegneristici riguardanti la sicurezza, la gestione dei dati, la supervisione e la valutazione dei sistemi di IA.
Riconosciuta esplicitamente nella sezione prospettica del documento, la sfida attuale è costituita dai sistemi agentici, ovvero sistemi che pianificano, utilizzano strumenti e agiscono in modo autonomo.
Questi sistemi sollecitano quasi tutte le pratiche attuali:
- la valutazione dell’idoneità deve considerare i compiti aperti,
- la sicurezza deve affrontare lo sfruttamento dell’uso degli strumenti e le catene di attacco multi-step,
- infine la supervisione deve definire confini di autonomia significativi e la valutazione deve misurare i comportamenti emergenti su sequenze d’azione sempre più lunghe.
Dall’analisi sono emersi tre ambiti che sembrano particolarmente promettenti per la ricerca futura.
La prima è l’evaluation-driven development, una nuova pratica in cui i criteri e i casi di prova vengono definiti prima della costruzione del sistema [8].
Inoltre, la seconda riguarda la sicurezza della supply chain dell’IA, che il documento indica come in mutamento «dalla guida alla necessità operativa» a seguito di incidenti documentati relativi a componenti compromessi [9].
Invece la terza riguardalo spostamento della governance dalla documentazione all’automazione, con l’incorporamento dei controlli di conformità e meccanismi di audit direttamente nelle pipeline di sviluppo e rilascio.
Sintetizzando, l’aggiornamento del SEI conferma una tesi che merita di essere chiave di lettura: un’ingegneria solida non ostacola la rapidità di adozione, ma ne è la condizione necessaria.
In assenza di queste best practice, la velocità non genera un vantaggio, ma un rischio.
Il documento non fornisce risposte definitive, ma delinea con precisione i dubbi ancora irrisolti nella ricerca sulla sicurezza informatica.
Riferimenti bibliografici
- Gaston, M., Heim, E., Barmer, H. (2026). AI Engineering: Twelve Foundational Practices. Carnegie Mellon University, Software Engineering Institute. Licenza CC BY-NC 4.0 (DM26-0412).
- Gaston, M., Heim, E., Barmer, H. (2019). AI Engineering: 11 Foundational Practices. Carnegie Mellon University, Software Engineering Institute.
- National Institute of Standards and Technology (2023, 2024). Artificial Intelligence Risk Management Framework (AI RMF 1.0) e Generative AI Profile (AI 600-1).
- Sambasivan, N. et al. (2021). Everyone Wants to Do the Model Work, Not the Data Work: Data Cascades in High-Stakes AI. Proceedings of the CHI Conference.
- Coalition for Secure AI (2025). Establish Risks and Controls for the AI Supply Chain, v1.0; Principles for Secure-by-Design Agentic Systems. OASIS Open.
- OWASP Gen AI Security Project (2024, 2025). Top 10 for Large Language Model Applications; Top 10 for Agentic Applications for 2026.
- Shaw, S. D., Nave, G. (2026). Thinking — Fast, Slow, and Artificial: How AI Is Reshaping Human Reasoning and the Rise of Cognitive Surrender. Wharton School, University of Pennsylvania.
- Xia, B. et al. (2025). Evaluation-Driven Development and Operations of LLM Agents: A Process Model and Reference Architecture. arXiv:2411.13768v3.
- National Security Agency et al. (2026). AI/ML Supply Chain Risks and Mitigations. Joint Cybersecurity Information Sheet.
Partecipa alla community