--- title: "Progettare un sistema AI ISO-ready: cosa preparare prima di sviluppare" url: https://zerofive.ai/blog/compliance/progettare-sistema-ai-iso-ready canonical: https://zerofive.ai/blog/compliance/progettare-sistema-ai-iso-ready language: it published: 2026-09-10 updated: 2026-09-18 author: "ZeroFive.AI" tags: ISO IEC 42001, AI by design, progettazione sistemi AI, AIMS, governance AI abstract: "Progettare un sistema AI ISO-ready: cosa non si recupera a posteriori, logging e supervisione come scelte di design, gate con criteri di uscita e cosa chiedere al fornitore." --- # Progettare un sistema AI ISO-ready: cosa preparare prima di sviluppare Il momento in cui un progetto AI scopre di dover rispondere a ISO/IEC 42001 arriva quasi sempre troppo tardi, di solito quando il sistema è già in staging e qualcuno chiede se è stato fatto un risk assessment. Da lì partono due o tre settimane di ricostruzione a ritroso, con un team che cerca di documentare decisioni prese mesi prima e un lancio che slitta. La parte fastidiosa è che una porzione di quel lavoro non è recuperabile in nessun modo, per quanto tempo ci si metta. ## Cosa non si può ricostruire a posteriori Policy, procedure, manuali d'uso si scrivono anche a fine progetto. Sono documenti che descrivono uno stato, e lo stato è verificabile in qualsiasi momento. Quattro cose invece esistono solo se sono state prodotte mentre il sistema veniva costruito. La prima è la provenienza dei dati usati per addestrare o mettere a punto il modello. Se nessuno ha tracciato da dove arriva ciascun insieme di dati, con quale base e con quali diritti d'uso, dopo sei mesi quella catena non si ricostruisce, si può solo dichiarare. Un auditor conosce la differenza. La seconda sono le alternative scartate. La domanda su perché sia stata scelta questa architettura, questo modello, questo fornitore, ha una risposta credibile solo se le opzioni erano sul tavolo nello stesso momento. Ricostruirla dopo produce una giustificazione, che è un'altra cosa. La terza è la baseline del processo prima dell'introduzione del sistema. Quanto durava, quanti errori produceva, quanto costava. Senza quel numero misurato prima, il monitoraggio successivo non ha un termine di paragone e nessuno può dire se il sistema stia migliorando o peggiorando la situazione. È anche il motivo per cui molti progetti AI non riescono a dimostrare il proprio ritorno: nessuno ha registrato il punto di partenza. La quarta sono i criteri di accettazione. Stabilire cosa deve essere vero perché il sistema si consideri riuscito, prima di vedere i risultati, è una cosa. Stabilirlo dopo, guardando le metriche che sono uscite, è un esercizio che si adatta a qualsiasi esito. ## Decisioni tecniche con conseguenze di conformità Alcune scelte che nel piano di progetto sembrano puramente architetturali determinano se il sistema potrà essere governato o no. Cambiarle dopo significa rimettere mano al codice, non alla documentazione. **Il logging.** L'articolo 12 dell'AI Act chiede che i sistemi ad alto rischio consentano tecnicamente la registrazione automatica degli eventi per tutta la durata di vita del sistema, e l'articolo 26(6) impone al deployer di conservare quei log per almeno sei mesi. Il punto operativo però non è attivare i log, è decidere cosa registrano. Un log che contiene solo l'output non permette di ricostruire una singola decisione a distanza di mesi. Per farlo servono l'input ricevuto, la versione del modello attiva in quel momento, l'esito prodotto e l'eventuale intervento umano con il suo autore. Aggiungere questi campi dopo tocca lo schema dati, spesso la latenza, a volte l'intera pipeline. **La supervisione umana.** L'articolo 14 chiede che i sistemi ad alto rischio siano progettati in modo da poter essere effettivamente sorvegliati da persone. Nella pratica questo si traduce in tre domande di design: chi può fermare il sistema, in quanto tempo, e con quali informazioni davanti nel momento in cui deve decidere. Un operatore che vede solo l'esito senza gli elementi che lo hanno prodotto non è in condizione di contestarlo, e l'articolo 13 sulla trasparenza verso chi utilizza il sistema esiste proprio perché una supervisione senza comprensione resta formale. **Il livello di spiegabilità.** Quanto il sistema debba saper motivare i propri esiti dipende da cosa decide e su chi ricade. È un requisito che vincola l'architettura: scegliere un modello non interpretabile per un caso d'uso che richiede una motivazione è una decisione che nessuna quantità di documentazione successiva annulla. **Il percorso di ricaduta.** Cosa succede quando il sistema è indisponibile, o quando produce un esito che l'operatore rifiuta. Se non esiste un percorso manuale praticabile, il sistema di fatto non è disattivabile, e un sistema non disattivabile è un rischio che nessun controllo compensa. ## Quando una scelta tecnica cambia il vostro ruolo giuridico Nel pezzo sull'inventario abbiamo visto che l'articolo 25 dell'AI Act elenca tre situazioni in cui chi utilizza un sistema ne diventa il fornitore, assumendo gli obblighi dell'articolo 16. Due di quelle tre situazioni nascono da decisioni che si prendono in fase di progettazione. Il fine-tuning su dati proprietari e la modifica di una soglia decisionale possono ricadere nella nozione di modifica sostanziale. Cambiare la finalità di un sistema non classificato come ad alto rischio in modo che lo diventi produce lo stesso effetto. La riclassificazione non richiede una notifica o una registrazione, si verifica quando ricorrono le condizioni. La conseguenza pratica è che la frase "partiamo dal modello del fornitore e lo adattiamo ai nostri dati" non è solo una scelta di implementazione. Va presa sapendo cosa comporta, e la fase in cui va posta la domanda è il design, quando cambiare strada costa una riunione. ## Le domande da porre, e cosa fare se la risposta è vaga Un elenco di domande serve poco se non si sa riconoscere una risposta insufficiente. Queste sei hanno tutte un criterio di uscita. - **Esiste un'alternativa non basata su AI, e perché è stata scartata?** Se nessuno ha considerato l'alternativa, il progetto non ha ancora un caso, ha un'ipotesi. Questa domanda ferma più progetti di tutte le altre messe insieme, ed è la ragione per cui va posta per prima. - **Che decisione produce il sistema, e su chi ricade?** La risposta determina la classificazione di rischio e quindi tutto il resto. Se la risposta è "supporta l'operatore", va chiesto quante volte l'operatore si discosta dal suggerimento: sotto una certa soglia, il sistema decide. - **Chi ne è owner in produzione?** Serve un nome, non un reparto. Se nessuno accetta il ruolo prima del rilascio, nessuno lo accetterà dopo. - **Qual è la baseline attuale, misurata?** Senza un numero raccolto prima, il monitoraggio successivo non è confrontabile con nulla. - **Cosa deve essere vero perché il sistema si consideri riuscito?** Scritto prima, con soglie numeriche, altrimenti a valle si troverà sempre una metrica che conferma la decisione già presa. - **Cosa succede quando sbaglia?** Chi se ne accorge, in quanto tempo, e cosa fa. Se la risposta è che se ne accorgerà l'utente finale, il progetto ha un problema di design, non di documentazione. ## I gate e i criteri per superarli Servono pochi passaggi di controllo, ma con criteri di uscita espliciti, altrimenti diventano riunioni in cui si prende atto di quello che è già stato deciso. Al **kickoff** si risponde alle prime due domande sopra e si prende una posizione sulla classificazione di rischio attesa e sul ruolo che l'organizzazione assumerà. È il gate più economico e quello che viene saltato più spesso. Alla **design review** si verificano le scelte con conseguenze di conformità: cosa registrano i log, come è progettata la supervisione, quale livello di spiegabilità è richiesto, quale percorso di ricaduta esiste. Uscire da questo gate con uno di questi punti aperto significa che verrà chiuso male e in fretta più avanti. **Prima della produzione** si controllano evidenze, non intenzioni: la baseline misurata, i log attivi e verificati su un caso reale ricostruito end-to-end, l'owner nominato, la riga aperta nell'inventario dei sistemi AI, il piano di monitoraggio con le sue soglie. **A trenta o novanta giorni dal lancio** si confronta il comportamento reale con la baseline e con i criteri di accettazione fissati all'inizio. È il gate che quasi nessuno mette in calendario, ed è quello che dice se il sistema sta facendo quello per cui è stato costruito. ## Se il sistema non lo costruite voi La maggior parte delle organizzazioni non sviluppa da zero, compra o integra. Le stesse domande valgono, ma vanno poste al fornitore in fase di selezione, perché dopo la firma il potere negoziale è finito. Le informazioni da chiedere in gara sono cinque: la documentazione tecnica del sistema, il ruolo che il fornitore dichiara di assumere rispetto all'AI Act, quali log produce il sistema e in che formato sono accessibili, quali test di validazione sono stati eseguiti e con quali risultati, e con quale preavviso viene comunicato un cambio del modello sottostante. Un fornitore che non risponde a queste domande in fase di gara non risponderà nemmeno dopo, e quell'assenza di risposta è a sua volta un'informazione utile per la decisione. ## Perché qui una policy non basta Su buona parte dei controlli dell'Annex A di ISO/IEC 42001, una procedura scritta e approvata è evidenza sufficiente. Sull'area A.6, quella dedicata al ciclo di vita del sistema, non lo è. I controlli di quest'area riguardano la documentazione delle scelte di progettazione, la verifica e validazione, il rilascio, il monitoraggio operativo e la registrazione degli eventi. Per ciascuno, un auditor chiede il record prodotto dal sistema mentre funzionava, non il documento che descrive come dovrebbe funzionare. Un piano di test vale se esistono i risultati dei test. Una procedura di rilascio vale se esiste la traccia dei controlli fatti prima dell'ultimo rilascio. Questa distinzione cambia cosa bisogna costruire, e soprattutto quando. Le evidenze di quest'area si producono solo mentre il sistema viene sviluppato e usato, il che riporta al punto di partenza. ## Gli errori più frequenti Il più comune di tutti è il proof of concept che scivola in produzione senza passare da nessun gate, perché funzionava e c'era fretta. Nasce come esperimento, quindi senza documentazione, e si ritrova a gestire casi reali con un livello di controllo pensato per una demo. Il secondo è la supervisione umana nominale, l'operatore che approva trecento casi al giorno e che nei fatti timbra. Formalmente il presidio esiste, sostanzialmente il sistema decide da solo, e la differenza emerge al primo incidente. Il terzo è la documentazione scritta per l'auditor invece che per chi manterrà il sistema. Si riconosce perché nessuno del team la consulta mai, e perché invecchia senza che nessuno se ne accorga. ## Il legame con il resto della serie Chi progetta sapendo fin dall'inizio che il sistema dovrà rispondere a queste domande non fa un lavoro in più, lo fa in un ordine diverso e più economico. Le stesse informazioni servono comunque: la differenza è che raccolte durante costano ore, ricostruite dopo costano settimane, e in quattro casi non si raccolgono affatto. Il prossimo pezzo di questa serie lascia la documentazione tecnica e passa alle persone, con quello che la norma chiede in tema di competenze e con il motivo per cui è un requisito verificabile quanto un registro dei rischi.