{"id":23099,"date":"2026-09-03T17:03:08","date_gmt":"2026-09-03T15:03:08","guid":{"rendered":"https:\/\/www.fabriziogiancola.eu\/?p=23099"},"modified":"2026-09-03T17:03:08","modified_gmt":"2026-09-03T15:03:08","slug":"ai-security-si-protegge-il-sistema-non-il-modello","status":"publish","type":"post","link":"https:\/\/www.fabriziogiancola.eu\/index.php\/2026\/09\/03\/ai-security-si-protegge-il-sistema-non-il-modello\/","title":{"rendered":"AI security: si protegge il sistema, non il modello"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\"><em><strong>Appunti di AI security, riletti con gli occhi di chi fa incident response.<\/strong><\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">In questo articolo raccolgo in maniera pi\u00f9 ordinata gli appunti di un corso introduttivo di <strong>AI security<\/strong>. Quello che va detto fin da subito \u00e8 che non non troverete un elenco di attacchi ma piuttosto &#8220;<em>uno spostamento del punto di osservazione<\/em>&#8220;.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La domanda con cui la maggior parte dei team affronta il tema \u00e8: <strong><em><mark>il nostro modello \u00e8 sicuro?<\/mark><\/em><\/strong> \u00c8 la domanda sbagliata, o meglio: \u00e8 una domanda troppo piccola. Un modello perfettamente allineato, valutato e messo a punto con criterio pu\u00f2 stare al centro di un prodotto insicuro. Se i dati di addestramento non hanno provenienza tracciabile, se i prompt vengono trattati come contenuto innocuo, se l\u2019API \u00e8 sovra-privilegiata, se un plugin pu\u00f2 fare pi\u00f9 di quanto serve, se dopo il rilascio nessuno guarda pi\u00f9 niente &#8230; il rischio resta tutto l\u00ec, intatto.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La domanda giusta \u00e8 un\u2019altra: <strong><em><mark>cosa entra, cosa decide, cosa il sistema pu\u00f2 effettivamente raggiungere?<\/mark><\/em><\/strong><\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-1\"><strong>Tre strati, non uno<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Il modo pi\u00f9 economico che conosco per ragionare su un sistema AI \u00e8 dividerlo in tre strati.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dati e prompt<\/strong>: dataset di addestramento, corpus di retrieval, prompt di sistema, set di valutazione. \u00c8 ci\u00f2 che entra.<\/li>\n\n\n\n<li><strong>Modello e logica<\/strong>: pesi, fine-tune, policy, agenti, orchestrazione. \u00c8 ci\u00f2 che decide.<\/li>\n\n\n\n<li><strong>Ambiente operativo<\/strong>: applicazioni, API, utenti, plugin, storage, log. \u00c8 ci\u00f2 che il sistema pu\u00f2 toccare ed esporre.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Gli incidenti reali attraversano quasi sempre pi\u00f9 di uno strato. E l\u2019attaccante non sceglie lo strato pi\u00f9 sofisticato: sceglie quello pi\u00f9 facile. Un chatbot RAG costruito su un modello di frontiera, ma con un retriever che pu\u00f2 leggere la knowledge base HR e un\u2019integrazione Slack con permessi di scrittura ampi, ha il suo problema nel workflow, non nei pesi.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-2\"><strong>Prima del modello c\u2019\u00e8 il dato<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Non serve rubare un modello o entrare in produzione per fare danni. A volte basta influenzare ci\u00f2 che il modello impara.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Il data poisoning \u00e8 l\u2019ingresso di esempi malevoli, di bassa qualit\u00e0 o fuorvianti in un training set, in un fine-tune o in un corpus di retrieval, in modo da alterare il comportamento del sistema pi\u00f9 avanti. Pu\u00f2 essere grossolano oppure chirurgico: colpire solo un ristretto insieme di prompt, entit\u00e0 o argomenti. Due pattern classici: il <em>label flipping<\/em> (campioni che andrebbero etichettati come pericolosi vengono marcati come innocui) e il <em>backdoor<\/em> (una frase-trigger rara, un watermark, una patch in un\u2019immagine fanno fallire il modello solo in una condizione specifica, mentre nel resto dei casi si comporta normalmente).<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Le porte d\u2019ingresso sono tre, e vale la pena tenerle distinte perch\u00e9 richiedono controlli diversi:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>dato raccolto<\/strong>: web crawl, feed di fornitori, upload utente, dati di partner;<\/li>\n\n\n\n<li><strong>dato preparato<\/strong>: etichettatura, filtraggio, fine-tuning, embedding, versionamento (fase che pu\u00f2 intercettare il problema o amplificarlo silenziosamente);<\/li>\n\n\n\n<li><strong>conoscenza distribuita<\/strong>: il contesto a runtime: corpus di retrieval, vector store. Qui il problema di fiducia si ricrea <em>dopo<\/em> il deployment.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Dal punto di vista investigativo questa \u00e8 la classe di problemi peggiore, perch\u00e9 l\u2019evento che rende visibile il danno \u00e8 lontanissimo dalla compromissione originaria. Un assistente di supporto che comincia a raccomandare una procedura deprecata per una sola linea di prodotto, a causa di un articolo avvelenato indicizzato mesi prima, si presenta come un edge case bizzarro, non come un incidente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La domanda di controllo: &#8220;<strong><mark><em>Se domani il modello cambia comportamento, siamo in grado di dimostrare quale dato lo ha cambiato?<\/em><\/mark><\/strong>&#8220;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Se la risposta \u00e8 no, la supply chain dei dati \u00e8 gi\u00e0 un problema di sicurezza, a prescindere dal fatto che un incidente sia avvenuto. In pratica servono manifest dei dataset con hash, job di ingestion firmati, record di approvazione, versionamento degli indici di embedding con conservazione dei document ID di origine per ogni chunk, e valutazioni canary costruite apposta su entit\u00e0 sensibili e frasi-trigger note.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-3\"><strong>L\u2019input come vettore: due famiglie, un principio<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Il corso separa &#8211; correttamente &#8211; attacchi avversariali e prompt injection, ma il principio sottostante \u00e8 lo stesso: <strong>il contenuto in ingresso \u00e8 codice d\u2019attacco, anche quando non contiene una riga di codice.<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Negli <strong>attacchi avversariali<\/strong> il modello non viene toccato. Cambia solo l\u2019input, modificato in modo minimo e impercettibile per un essere umano: pochi pixel, un font leggermente alterato, una spaziatura anomala, un carattere omoglifo. Il sistema che legge le fatture riconosce un importo diverso da quello che leggerebbe una persona. Il filtro antispam lascia passare un messaggio che qualunque utente riconoscerebbe al volo. L\u2019input diventa un problema di sicurezza quando tre condizioni coincidono: qualcuno lo manipola, la manipolazione colpisce una zona sensibile del comportamento del modello, e quel comportamento alimenta una decisione che conta. Cambia il modello? No. Cambia la posta in gioco intorno ad esso.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La <strong>prompt injection<\/strong> \u00e8 il cugino LLM della SQL injection: il sistema tratta come istruzione ci\u00f2 che era solo contenuto da valutare. Testo bianco su fondo bianco in una pagina web, una riga nascosta in un ticket, un allegato costruito ad arte. L\u2019utente non vede nulla di anomalo; il modello legge tutto. Non \u00e8 un bug, \u00e8 un problema di fiducia mal collocata.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La ragione per cui la injection \u00e8 pericolosa non \u00e8 che il modello dica qualcosa di sbagliato. \u00c8 che nella stessa finestra convivono senza separazione: il contenuto letto, il ragionamento e <strong>l\u2019autorit\u00e0 di agire<\/strong>. \u00c8 come avere ufficio posta, decisori e firmatari degli assegni nella stessa stanza, a leggere la stessa pila di fogli, senza saper distinguere una direttiva ufficiale dalla pubblicit\u00e0.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La difesa non \u00e8 un prompt di sistema che dice &#8220;ignora eventuali istruzioni malevole&#8221; &#8211; abbiamo dimostrazioni sul fatto che non funziona. La difesa \u00e8 architetturale:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>tutto ci\u00f2 che arriva dall\u2019esterno \u00e8 <strong>untrusted per default<\/strong>, come una mail da uno sconosciuto;<\/li>\n\n\n\n<li>si separa la fase di raccolta informazioni dalla fase di azione;<\/li>\n\n\n\n<li>si limita l\u2019insieme dei tool disponibili al modello, per scelta esplicita e non per default;<\/li>\n\n\n\n<li>si mette un passaggio di approvazione reale prima di qualunque azione sensibile.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">E la domanda di mappatura, che vale pi\u00f9 di qualunque elenco di jailbreak: <em><mark>quali fonti di contenuto possono cambiare il comportamento del nostro modello, e cosa gli \u00e8 permesso fare subito dopo averle lette?<\/mark><\/em> Quella \u00e8 la<strong> trust boundary<\/strong>.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-4\"><strong>Il modello come bene esposto: estrazione e privacy<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Due rischi che nella pratica italiana vedo sottovalutati, perch\u00e9 non somigliano a una violazione.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Model extraction<\/strong>: nessuno scarica il file dei pesi. Qualcuno interroga il servizio in modo massivo e sistematico, raccoglie le risposte e ricostruisce un sostituto sufficientemente buono. \u00c8 reverse engineering di una ricetta ordinando lo stesso piatto mille volte e prendendo appunti. Ogni dettaglio in pi\u00f9 che restituiamo &#8211; confidence score, spiegazioni estese del ragionamento, metadati di scoring &#8211; \u00e8 un indizio regalato. Il servizio nel frattempo risulta perfettamente sano da ogni cruscotto di disponibilit\u00e0: nulla va in errore, nulla si interrompe. Il segnale, se c\u2019\u00e8, \u00e8 nel <em>pattern d\u2019uso<\/em>: volumi anomali, molte riformulazioni della stessa domanda, sondaggio meccanico e sistematico degli edge case. Nessuno di questi indizi prova un intento malevolo da solo; insieme disegnano qualcosa che non somiglia all\u2019uso quotidiano.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Privacy<\/strong>: il rischio non coincide con il data breach. Un modello pu\u00f2 memorizzare e ripetere, e il perimetro del problema copre l\u2019addestramento, l\u2019uso quotidiano, i log e i tool collegati. Ma il punto che mi ha convinto di pi\u00f9 \u00e8 un altro: <strong>non serve alcuna memorizzazione perch\u00e9 ci sia un problema di privacy<\/strong>. Se il sistema attorno al modello pu\u00f2 recuperare on demand un documento sensibile per la persona sbagliata, il danno \u00e8 gi\u00e0 fatto. E una volta che un dato ha plasmato il comportamento di un modello, non lo si rimuove come si cancella un file. Ecco perch\u00e9 la minimizzazione va fatta all\u2019ingresso, non a posteriori, e la review di privacy deve coprire anche output e log, non solo il training set.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-5\"><strong>Non l\u2019hai costruito tu<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Quasi nessuno costruisce un sistema AI da zero: lo si assembla. Modelli di terze parti, dataset, toolkit, plugin, vector database, servizi gestiti, infrastruttura altrui. Il che significa che le nostre decisioni di fiducia non si fermano al bordo del nostro codice.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La frase che ricordo di questa sessione \u00e8: <strong><mark>la fiducia non \u00e8 un logo<\/mark>.<\/strong> Il fatto che il nome sia noto non dice nulla su cosa faccia quel componente e su dove finiscano i nostri dati dopo averlo attraversato. E i problemi di supply chain quasi mai iniziano con un componente palesemente malevolo: iniziano con un componente reputato, adottato per andare pi\u00f9 veloci &#8211; decisione ragionevole, all\u2019epoca &#8211; messo in produzione senza review perch\u00e9 &#8220;il fornitore \u00e8 serio&#8221;, e poi un default debole, un aggiornamento che cambia cosa viene loggato, un connettore che dopo un disservizio viene ricollegato con permessi pi\u00f9 ampi di prima.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">L\u2019antidoto \u00e8 noioso e funziona: un <strong>AI Bill of Materials<\/strong> <strong>(AIBOM)<\/strong>. Cio\u00e8 l\u2019abitudine disciplinata di tenere un elenco. Quale modello \u00e8 in uso adesso, quale versione del dataset lo ha prodotto, quale prompt template \u00e8 vivo in produzione, quali tool esterni sono collegati, chi ha approvato ciascuna di queste scelte, e &#8211; soprattutto &#8211; quale workflow pu\u00f2 essere riportato indietro se la fiducia in un componente viene meno.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-6\"><strong>La produzione \u00e8 dove il lavoro comincia<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Questa \u00e8 la parte che parla direttamente al nostro mestiere. Il rilascio non \u00e8 la fine del lavoro di sicurezza: \u00e8 l\u2019inizio.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Gli incidenti AI in produzione, nella stragrande maggioranza, non assomigliano a una breach cinematografica. Assomigliano a questo: <em>una funzionalit\u00e0 viene rilasciata con permessi generosi, ha successo, gli utenti la usano in modi che il testing non aveva previsto, dopo qualche mese viene collegata una nuova fonte dati, l\u2019assistente inizia a leggere pi\u00f9 di prima e a chiamare i tool in un ordine diverso, i log mostrano prompt strani \u2014 e nessuno \u00e8 sicuro di chi sia il proprietario di quel workflow n\u00e9 di quali evidenze esistano<\/em>. Il contenimento richiede molto pi\u00f9 tempo del dovuto. Nessuno ha fatto niente di drammatico: una modifica ordinaria ha incontrato un monitoraggio insufficiente.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">La domanda migliore dell\u2019intero corso, quella che riscriverei sopra la lavagna di ogni SOC:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong><mark><em>Se una nostra funzionalit\u00e0 AI si comportasse male oggi, quali evidenze avremmo nei primi quindici minuti?<\/em><\/mark><\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tradotta in requisiti operativi, per come la vedo io dal lato forense:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>kill switch<\/strong> per disattivare immediatamente l\u2019uso dei tool, separato dalla disattivazione dell\u2019intera funzionalit\u00e0;<\/li>\n\n\n\n<li><strong>log ricostruibili<\/strong>: prompt, risposta, tool invocati, versione del modello e del prompt template, identificativi dei documenti recuperati. Senza questi campi non c\u2019\u00e8 ricostruzione possibile, solo congetture;<\/li>\n\n\n\n<li><strong>capacit\u00e0 di attribuzione<\/strong>: saper distinguere se il problema nasce dal modello, dal dato o dal workflow attorno. Sono tre risposte a incidente diverse;<\/li>\n\n\n\n<li><strong>identit\u00e0 separate<\/strong> per lettura, generazione e azione, cos\u00ec che un elemento compromesso non consegni tutto il resto;<\/li>\n\n\n\n<li><strong>rilevazione della permission creep<\/strong>, cio\u00e8 dei privilegi che si allargano silenziosamente nel tempo;<\/li>\n\n\n\n<li><strong>owner designato<\/strong> per gli incidenti AI-specific e una response plan provata <em>prima<\/em> del primo incidente reale.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Senza questo anello chiuso &#8211; vedere, capire, contenere &#8211; l\u2019hardening di produzione \u00e8 solo speranza travestita da piano.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-7\"><strong>La governance \u00e8 ci\u00f2 che impedisce ai controlli di decadere<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Nessuno dei controlli tecnici sopravvive a lungo se nessuno possiede il processo, nessuno conserva le evidenze e nessuno aggiorna la policy quando le cose cambiano.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Tre pezzi, e se ne manca uno il programma \u00e8 debole: <strong>policy e rischio<\/strong> (cosa ci si aspetta), <strong>controlli tecnici<\/strong> (chi realizza l\u2019aspettativa), <strong>evidenze e oversight<\/strong> (chi dimostra a posteriori che funziona). Policy senza controlli \u00e8 performativa; controlli senza oversight vanno in deriva o vengono aggirati quando diventano scomodi; oversight senza policy \u00e8 arbitrario.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Cinque domande a cui un programma di AI governance dovrebbe saper rispondere per ogni sistema, ripetutamente &#8230; e ciascuna dovrebbe corrispondere a un documento reale, non a una buona intenzione:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-dark-gray-color has-light-gray-background-color has-text-color has-background has-link-color has-fixed-layout\"><thead><tr><td><strong>Domanda<\/strong><\/td><td><strong>Documento corrispondente<\/strong><\/td><\/tr><\/thead><tbody><tr><td>Quali sistemi AI sono in uso e chi ne \u00e8 owner?<\/td><td>Inventario dei sistemi<\/td><\/tr><tr><td>Quali rischi contano per questo caso d\u2019uso e questa audience?<\/td><td>Risk assessment<\/td><\/tr><tr><td>Quali controlli servono prima del rilascio e quali devono restare attivi dopo?<\/td><td>Architettura e record di approvazione<\/td><\/tr><tr><td>Quali evidenze dimostrano che funzionano davvero?<\/td><td>Test, log, report di monitoraggio<\/td><\/tr><tr><td>Come gestiamo incidenti, eccezioni e aggiornamenti di policy?<\/td><td>Deroghe nominali con data di scadenza<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Quell\u2019ultimo dettaglio non \u00e8 formale: un\u2019eccezione concessa una volta e mai pi\u00f9 rivista \u00e8 il modo pi\u00f9 comune in cui un controllo muore.<\/p>\n\n\n\n<h2 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-8\"><strong>Sui framework, con un aggiornamento<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Il corso cita NIST AI RMF, ISO\/IEC 42001, le linee guida OWASP e l\u2019AI Act. Vale la pena precisare dove siamo oggi:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NIST AI RMF<\/strong>: la 1.0 (AI 100-1, gennaio 2023) resta l\u2019unica versione finalizzata del core framework, in revisione ma senza una 2.0 pubblicata. NIST ha esteso il framework tramite <em>profili<\/em>, tra cui il Generative AI Profile (AI 600-1) e, dall\u2019aprile 2026, un concept note per un profilo sulle infrastrutture critiche. Utile per ragionare in termini di govern, map, measure, manage. (<a href=\"https:\/\/www.nist.gov\/itl\/ai-risk-management-framework\" target=\"_blank\" rel=\"noopener\">pagina NIST<\/a>)<\/li>\n\n\n\n<li><strong>ISO\/IEC 42001<\/strong>: la controparte certificabile, orientata a costruire un sistema di gestione ripetibile e non uno sforzo una tantum.<\/li>\n\n\n\n<li><strong>OWASP<\/strong> (progetto Generative AI): il livello applicativo, con la lista aggiornata dei rischi concreti &#8211; prompt injection in testa.<\/li>\n\n\n\n<li><strong>AI Act (Reg. UE 2024\/1689)<\/strong>: qui l\u2019aggiornamento \u00e8 sostanziale e riguarda direttamente chi lavora in Italia. Il Digital Omnibus ha riscritto il calendario: <strong>dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell\u2019art. 50, il regime sanzionatorio e l\u2019enforcement nazionale<\/strong>, mentre <strong>gli obblighi sui sistemi ad alto rischio slittano al 2 dicembre 2027<\/strong> (sistemi autonomi, Allegato III) e <strong>al 2 agosto 2028<\/strong> (sistemi integrati in prodotti regolamentati, Allegato I). Restano pienamente in vigore i divieti dell\u2019art. 5 e l\u2019obbligo di alfabetizzazione IA. Da tenere presente: il regolamento non riguarda solo chi sviluppa modelli, ma anche &#8211; e per il tessuto produttivo italiano soprattutto &#8211; chi li utilizza sotto la propria autorit\u00e0, i deployer. (<a href=\"https:\/\/www.altalex.com\/documents\/2026\/07\/31\/act-cambia-davvero-2-agosto-2026-imprese-professionisti\" target=\"_blank\" rel=\"noopener\">sintesi Altalex<\/a>)<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">I framework guadagnano il loro spazio quando cambiano il comportamento quotidiano di chi progetta e revisiona, non quando stanno in una slide che nessuno apre.<\/p>\n\n\n\n<h1 class=\"wp-block-heading has-dark-gray-color has-very-light-gray-to-cyan-bluish-gray-gradient-background has-text-color has-background has-link-color has-medium-font-size wp-elements-9\"><strong>Cosa farei luned\u00ec mattina<\/strong><\/h1>\n\n\n\n<p class=\"wp-block-paragraph\">Se dovessi ridurre i capitoli precedenti a una lista operativa:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Censire.<\/strong> Quali casi d\u2019uso AI esistono davvero, compresi quelli che nessuno ha mai formalmente autorizzato. Quali fonti dati usano, quali modelli, quali tool possono raggiungere.<\/li>\n\n\n\n<li><strong>Mappare l\u2019ingresso dell\u2019untrusted.<\/strong> Dove entra contenuto non controllato nel workflow, e cosa il modello \u00e8 autorizzato a leggere, scrivere, invocare o innescare subito dopo.<\/li>\n\n\n\n<li><strong>Verificare la ricostruibilit\u00e0.<\/strong> Cosa viene loggato, chi approva le azioni sensibili, come verrebbe rilevato un incidente e con quali evidenze nei primi quindici minuti.<\/li>\n\n\n\n<li><strong>Separare i privilegi.<\/strong> Service account distinti per lettura, generazione e azione; token separati per read e write; niente credenziali condivise.<\/li>\n\n\n\n<li><strong>Versionare tutto ci\u00f2 che influenza il comportamento.<\/strong> Dataset, fine-tune, indici di embedding, prompt template. Con un percorso di rollback provato, non teorico.<\/li>\n\n\n\n<li><strong>Assegnare un owner<\/strong> agli incidenti AI-specific e mettere la review dei permessi in calendario, non nelle buone intenzioni.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">Niente di tutto questo \u00e8 appariscente. \u00c8 esattamente la disciplina ingegneristica ordinaria che rende un sistema difendibile &#8211; e, per chi come me arriva dall\u2019incident response, \u00e8 anche l\u2019unica cosa che rende un sistema <em>analizzabile<\/em> dopo il fatto. Il primo lavoro dell\u2019AI security \u00e8 vedere l\u2019intero sistema con chiarezza. Una volta che lo si vede tutto, i rischi reali diventano molto pi\u00f9 facili da valutare.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Appunti di AI security, riletti con gli occhi di chi fa incident response. In questo articolo raccolgo in maniera pi\u00f9 ordinata gli appunti di un corso introduttivo di AI security. Quello che va detto fin da subito \u00e8 che non non troverete un elenco di attacchi ma piuttosto &#8220;uno spostamento del punto di osservazione&#8220;. La &hellip; <a href=\"https:\/\/www.fabriziogiancola.eu\/index.php\/2026\/09\/03\/ai-security-si-protegge-il-sistema-non-il-modello\/\" class=\"more-link\">Leggi tutto<span class=\"screen-reader-text\"> &#8220;AI security: si protegge il sistema, non il modello&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[114,12,14],"tags":[108,136,134,133,116,135,119],"class_list":["post-23099","post","type-post","status-publish","format-standard","hentry","category-ai","category-cyber-security","category-digital-forensics","tag-ai","tag-aibom","tag-attacchi-adversarial","tag-data-poisoning","tag-prompt","tag-prompt-injection","tag-reverse-prompt-engineering"],"_links":{"self":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/23099","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/comments?post=23099"}],"version-history":[{"count":25,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/23099\/revisions"}],"predecessor-version":[{"id":23154,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/posts\/23099\/revisions\/23154"}],"wp:attachment":[{"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/media?parent=23099"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/categories?post=23099"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fabriziogiancola.eu\/index.php\/wp-json\/wp\/v2\/tags?post=23099"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}