La sicurezza dell'intelligenza artificiale in azienda rimane un terreno minato dove molti responsabili IT si muovono ancora al buio. Secondo Luca Sambucci, specialista in consulenza sulla sicurezza informatica, i guardrail tecnologici comunemente utilizzati rappresentano soltanto una risposta parziale e spesso insufficiente al problema. La domanda che ricorre più frequentemente nei suoi incarichi è una sola: come integrare davvero l'IA nel perimetro aziendale senza correre rischi inaccettabili? La risposta non sta in soluzioni magiche, ma in un approccio metodico mutuato dalle pratiche consolidate della cybersecurity tradizionale, riadattate alle peculiarità dei modelli linguistici.

Il punto di partenza obbligato è la mappatura delle traiettorie di minaccia all'interno della propria architettura. In gergo tecnico si parla di analisi source-to-sink, dove per source s'intendono tutti i canali attraverso cui dati esterni possono entrare nel sistema — file caricati dagli utenti finali, URL, allegati email, indici di banche dati esterne, webhook e risposte da API terze — e per sink si indicano invece i punti dove il modello può causare danni concreti, cioè database interni, ambienti di esecuzione codice, piattaforme cloud, sistemi di ticketing, pipeline di sviluppo e integrazioni con strumenti come Slack.

La sfida consiste nell'identificare ogni possibile sentiero attraverso cui un malintenzionato potrebbe spingere dati malevoli da una fonte esterna fino a un sink sensibile cui non avrebbe normalmente accesso. Un caso concreto riguarda i team di risorse umane che utilizzano agenti IA per vagliare curriculum e scrivere valutazioni direttamente nel gestionale aziendale: un CV contenente istruzioni nascoste di prompt injection potrebbe indurre il sistema a registrare note contraffatte in un database ad accesso ristretto. Ancora più subdolo è lo scenario in cui una knowledge base RAG indicizza pagine pubbliche del sito aziendale ritenute affidabili: un attaccante potrebbe compromettere una di quelle pagine o crearne una nuova, che il crawler catturerà e incorporerà nell'indice, alimentando successivamente il modello con contenuti ostili che poi verranno elaborati da strumenti privilegiati.

Un aspetto critico spesso trascurato è che questa mappa non è un documento statico da tracciare una sola volta. Ogni aggiunta di un nuovo tool, ogni collegamento con una fonte dati diversa, ogni cambio di modello o estensione di un flusso di lavoro trasforma potenzialmente le catene di rischio. Per questa ragione, l'analisi delle vulnerabilità deve diventare parte del ciclo di vita dello sviluppo, non una pratica episodica. I team devono quindi consolidare la disciplina di ripetere regolarmente questo esercizio di threat modeling, affinché nessuna nuova superficie d'attacco rimanga scoperta. Chi avesse difficoltà a navigare questi dettagli tecnici farebbe bene a coinvolgere il Chief Information Security Officer aziendale, che potrebbe riconoscere in queste raccomandazioni una struttura già nota a chi lavora nella difesa informatica tradizionale.