Controllo degli accessi e sicurezza dei dati

Un copilota aziendale che trova in pochi secondi un contratto riservato, una condizione commerciale o una previsione finanziaria è utile solo se lo mostra alla persona autorizzata. Qui si gioca il valore reale del controllo degli accessi e sicurezza dei dati: non mettere un lucchetto intorno all’AI, ma permetterle di lavorare entro confini verificabili.

Quando un sistema AI viene collegato a documenti, ERP, CRM, email, database e applicazioni proprietarie, eredita la complessità dell’azienda. I dati non sono tutti uguali, gli utenti non hanno le stesse responsabilità e le azioni consentite cambiano per ruolo, società, sede, commessa o stato di un processo. Una demo può ignorare questi dettagli. Un sistema destinato alla produzione no.

Perché l’AI rende il controllo degli accessi più critico

Nei software tradizionali, un’autorizzazione determina spesso l’accesso a una schermata o a una funzione. Nei sistemi intelligenti, la stessa autorizzazione deve governare almeno tre livelli: quali fonti l’AI può consultare, quali contenuti può restituire e quali operazioni può eseguire tramite strumenti integrati.

Un agente che risponde a una domanda sullo stato di un ordine può dover leggere il CRM, verificare una disponibilità nel gestionale e preparare una comunicazione. Se dispone di privilegi troppo estesi, il rischio non è solo la visualizzazione di dati non pertinenti. Può trasformarsi in una modifica non autorizzata, nell’invio di un’email errata o nell’esecuzione di una procedura fuori policy.

La sicurezza, quindi, non coincide con la riservatezza. Riguarda anche integrità, disponibilità, tracciabilità e responsabilità delle azioni. Per un CIO o un responsabile di funzione, la domanda corretta non è “l’AI può accedere ai nostri dati?”, ma “a quali dati, per chi, in quale contesto e con quale evidenza dell’azione svolta?”.

Controllo degli accessi e sicurezza dei dati: il modello da progettare

La base è il principio del minimo privilegio: utenti, servizi e agenti AI ricevono esclusivamente le autorizzazioni necessarie per il compito assegnato. Non è un’impostazione una tantum. Va tradotta in policy tecniche coerenti con l’organizzazione e mantenuta nel tempo, quando cambiano ruoli, processi, fornitori o strutture societarie.

Identità verificata, ruoli chiari, attributi contestuali

Un modello basato sui ruoli consente di definire profili come commerciale, buyer, responsabile qualità, amministrazione o manutenzione. È indispensabile, ma non sempre sufficiente. In molte realtà enterprise, le autorizzazioni dipendono anche da attributi dinamici: business unit, territorio, cliente assegnato, livello di riservatezza, turno di lavoro, progetto o fase di approvazione.

Un responsabile commerciale può consultare le offerte del proprio portafoglio, ma non quelle di tutte le filiali. Un tecnico può interrogare manuali e schede di impianto, ma non accedere alle condizioni retributive del personale. L’AI deve applicare queste regole prima del retrieval e non limitarsi a filtrare la risposta finale. Se recupera documenti non autorizzati, il perimetro di sicurezza è già stato violato, anche se il testo generato appare innocuo.

Per questo l’identità dell’utente deve essere propagata lungo l’intera richiesta: dall’accesso al portale fino ai connettori che interrogano fonti e strumenti. L’agente non dovrebbe operare come un superutente generico. Deve agire in delega, con credenziali tecniche limitate, scope definiti e policy applicate al contesto specifico.

Sicurezza del retrieval nei sistemi RAG

Un sistema RAG enterprise non è semplicemente un modello linguistico collegato a una cartella di file. Richiede una pipeline che acquisisca documenti, estragga contenuti, normalizzi metadati, indicizzi le informazioni e recuperi soltanto le fonti pertinenti e consentite.

I metadati di sicurezza sono parte del dato. Classificazione del documento, proprietario, reparto, società, progetto, scadenza della validità e gruppi autorizzati devono accompagnare il contenuto durante indicizzazione e ricerca. In caso contrario, la ricerca semantica può trovare un documento altamente rilevante ma vietato all’utente che ha posto la domanda.

Serve inoltre gestire il ciclo di vita delle autorizzazioni. Un file spostato, archiviato o reso riservato deve riflettere rapidamente il nuovo stato nell’indice AI. Latenze e sincronizzazioni non gestite possono creare finestre di esposizione. Il livello di aggiornamento richiesto dipende dalla criticità delle fonti: un catalogo prodotti tollera spesso un aggiornamento programmato, dati finanziari o documenti legali potrebbero richiedere controlli molto più ravvicinati.

Agenti AI che agiscono entro confini definiti

La distinzione più rilevante è tra un sistema che informa e uno che opera. Un agente AI capace di creare ticket, aggiornare record CRM, preparare ordini o interrogare API interne necessita di autorizzazioni operative separate da quelle di sola lettura.

Ogni strumento esposto all’agente dovrebbe avere azioni esplicite, parametri validati e limiti di utilizzo. Non basta autorizzare l’accesso a un ERP: occorre stabilire se l’agente può leggere una giacenza, proporre una modifica, creare una bozza oppure confermare una transazione. Per le attività con impatto economico, normativo o reputazionale, l’approvazione umana è spesso la scelta più razionale.

L’automazione totale non è un obiettivo universale. Su processi ripetitivi e a basso rischio può aumentare velocità e qualità. Su eccezioni, deroghe commerciali, dati sensibili o decisioni irreversibili, un workflow con validazione umana offre un rapporto migliore tra efficienza e controllo. AI che agisce, non soltanto risponde, significa anche AI che sa quando fermarsi.

Audit, monitoraggio e risposta agli incidenti

Senza log strutturati, non esiste una governance credibile. Un’azienda deve poter ricostruire chi ha posto una richiesta, quale identità è stata verificata, quali fonti sono state consultate, quali documenti sono stati recuperati, quale policy ha autorizzato l’operazione, quali strumenti sono stati usati e quale risultato è stato prodotto.

Questa tracciabilità non serve solo dopo un incidente. È essenziale per valutare qualità e adozione. Se un copilota restituisce risposte non utili, i log aiutano a distinguere tra un problema di conoscenza disponibile, ricerca, autorizzazioni troppo restrittive, prompt o integrazione. La sicurezza ben progettata diventa anche uno strumento di miglioramento operativo.

Il monitoraggio deve includere anomalie: richieste fuori orario o volume, tentativi ripetuti di accedere a contenuti negati, chiamate anomale a strumenti, escalation di privilegi e comportamenti incoerenti con il ruolo dell’utente. Non tutte le anomalie indicano un attacco, ma tutte meritano una classificazione e una gestione definite.

Errori che indeboliscono l’architettura

Il primo errore è creare un account tecnico unico con accesso completo alle fonti aziendali. Semplifica l’integrazione iniziale, ma annulla la segmentazione e rende difficile attribuire le azioni. Il secondo è trattare documenti e database come una conoscenza indistinta, senza metadati di classificazione e policy di accesso.

Un terzo errore frequente è affidarsi soltanto alle istruzioni nel prompt, per esempio chiedendo al modello di non mostrare informazioni riservate. Le istruzioni sono utili per guidare il comportamento, ma non sostituiscono controlli applicativi, autorizzazioni sul retrieval e verifiche lato tool. Le policy devono essere applicate dall’architettura, non sperate nella risposta del modello.

Infine, molte aziende dimenticano la gestione delle identità nel tempo: dipendenti che cambiano funzione, consulenti temporanei, utenti disattivati e gruppi non aggiornati. L’integrazione con identity provider e processi di provisioning riduce questo rischio, purché la revisione degli accessi sia periodica e assegnata a responsabili precisi.

Dal requisito di sicurezza al sistema in produzione

Un progetto efficace parte dalla mappa dei dati e dei processi, non dalla scelta del modello linguistico. Occorre identificare fonti, livelli di riservatezza, ruoli, operazioni consentite, vincoli normativi, dipendenze applicative e casi d’uso prioritari. Da qui nasce una matrice di autorizzazione che collega persone, dati e azioni.

La fase successiva è ingegneristica: integrazione con i sistemi di identità, connettori controllati, segmentazione delle fonti, gestione sicura dei segreti, cifratura, logging centralizzato, ambienti separati e test basati su scenari reali. I test devono provare anche il diniego: cosa accade quando un utente chiede un dato che non può vedere, quando un agente tenta un’azione non prevista o quando una fonte non è disponibile?

PurpleSoft progetta questa architettura come parte del sistema AI, non come un’aggiunta finale. Perché software, dati e intelligenza artificiale devono lavorare in un’unica struttura controllabile, capace di integrarsi con i processi reali e di fornire evidenze misurabili.

Il risultato da cercare non è un assistente che può fare tutto. È un sistema intelligente che sa esattamente cosa può fare, per chi può farlo e quando deve chiedere conferma. È da questa disciplina progettuale che nascono fiducia, adozione e automazioni che reggono davvero il passaggio dalla demo alla produzione.