Chi può usare quale modello AI? Il problema dell'IAM

In breve

• Con l'AI generativa l'access control si divide in quattro accessi: alla chat (quali modelli), ai dati (cosa l'AI legge per conto di chi chiede), alle azioni (Agenti e integrazioni) e via API (chiavi e budget).
• In Userbot un amministratore accende e spegne i modelli per l'intera area di lavoro, può abilitare modelli Global fuori UE solo se lo vuole, e può riservare un modello a gruppi e persone scelti.
• Con la connessione personale, che è quella di partenza, l'AI raggiunge solo ciò a cui la persona ha già accesso; creare integrazioni e condividere connessioni sono permessi della matrice dei ruoli.
• I tetti di spesa sono limiti di budget, non strumenti di sorveglianza: il Registro di audit traccia le modifiche alla configurazione, non le conversazioni.

Nelle aziende moderne la gestione delle identità (IAM) è ormai una consuetudine: un semplice “chi può aprire quale cartella” è sufficiente a regolare l’accesso alle risorse. Con l’avvento dell’intelligenza artificiale generativa, però, questa logica lineare non basta più. Tra l’utente e i dati si inserisce un modello capace di leggere, sintetizzare, scrivere e persino compiere azioni per conto del soggetto. Nascono quindi nuove domande che quel sistema non copre: quali modelli sono accesi e dove girano, chi può usare quelli più costosi, quali documenti l'AI può leggere per conto di chi chiede, chi crea e condivide Agenti, chi collega nuovi strumenti, chi usa le chiavi API.

Nelle aziende il rischio è che queste decisioni non le prenda nessuno: restano le impostazioni di partenza, oppure ognuno usa un account personale. Qui le separiamo in quattro accessi, vediamo cosa si imposta in Userbot per ciascuno e cosa va deciso nella policy, perché lo strumento da solo non lo fa.

Perchè l'IAM tradizionale non basta più?

L’IAM classico risponde a una singola interrogazione: “questa persona può accedere a questa risorsa?”
Quando, invece, un modello di linguaggio entra in gioco, la risposta si complica: il modello non è solo un “lettore” passivo, ma agisce come un interlocutore capace di trasformare informazioni, produrre contenuti e lanciare comandi verso altri sistemi. Di conseguenza si introducono quattro tipologie di accesso, che vanno ben oltre la semplice apertura di cartelle:

L'OWASP, nella sua lista dei rischi per le applicazioni basate su LLM, ne dedica due a questo terreno: la divulgazione di informazioni sensibili, contenuta dando a ognuno solo i dati che gli servono, e l'eccessiva autonomia (Excessive Agency), che nasce quando un sistema ha troppe funzioni, troppi permessi o troppa libertà di agire senza controlli.

Come gestisce Userbot i quattro accessi?

Accesso alla chat – i modelli

In Userbot, l’attivazione dei modelli è una decisione dell’amministratore, per l'intera area di lavoro. Alcuni modelli sono accesi di partenza, altri restano spenti finché un amministratore non li accende. Un modello nuovo entra nel catalogo spento: non compare nel selettore di nessuno finché qualcuno non lo abilita.

Ogni modello riporta dove è ospitato. Per impostazione predefinita, tutti i modelli disponibili sono in sede UE; solo mediante una valutazione con il team privacy è possibile attivare i modelli contrassegnati come Global, cioè ospitati fuori dall’Unione europea. Il quadro è nell'articolo su data residency e agenti AI in UE.

Da notare che il modello di riserva GPT-OSS 120B rimane sempre attivo: quando i limiti di consumo di altri modelli vengono superati, le risposte vengono instradate verso questo “fallback”.

Per il resto la lista è vostra, ed è il senso dell'approccio model agnostic: più fornitori nello stesso abbonamento, ma scelti da voi.

Come si riserva un modello costoso a chi ne ha bisogno?

Per ogni modello l'amministratore sceglie chi lo usa: tutta l'area di lavoro, solo gruppi e persone indicati, solo amministratori oppure nessuno. Il modello compare nel selettore soltanto di chi è ammesso, e la restrizione vale anche dentro gli Agenti: chi non è fra gli ammessi riceve un errore.

L'ufficio tecnico che analizza capitolati lunghi ha un motivo per usarlo, la segreteria che riscrive una mail no. Invece di spegnerlo per tutti, lo lasciate acceso per il gruppo che ne ha bisogno.

I tetti di spesa sono limiti, non controlli

Ogni posto include un budget di consumo; superato quello, le risposte passano a un modello economico invece di bloccarsi. Con l'utilizzo extra attivo, la spesa oltre l'incluso è governata da tetti: uno per l'area di lavoro, uno predefinito per tipo di posto e, come eccezione, uno per singola persona.

Sono limiti di budget, pensati per evitare sorprese in fattura. Non servono a leggere le conversazioni e non vanno usati come sorveglianza: un controllo individuale dell'uso dell'AI dei dipendenti è un tema di rapporto di lavoro, da affrontare con chi se ne occupa. Per leggere l'adozione guardate l'uso aggregato per team o area di lavoro.

Accesso ai dati – la Knowledge Base

L’AI opera, per default, con la connessione personale. Il principio da pretendere è che l'AI non diventi una scorciatoia: se una persona non può aprire un file, l'AI che lavora per lei non deve poterlo leggere.

Per gli strumenti collegati (la Conoscenza aziendale cerca in Google Drive, OneDrive, Outlook, Gmail, Google Calendar e Jira) vale l'impostazione di partenza: l'AI usa il vostro account e non raggiunge niente a cui non abbiate già accesso. La connessione condivisa mette invece a disposizione di chi usa un Agente l'account di chi l'ha creato, con i suoi permessi. La imposta solo chi ha il permesso apposito, di norma gli amministratori, e ha senso solo per account di servizio con permessi minimi.

I file caricati nella Libreria vivono in cartelle, e la cartella è l'unità di condivisione: privata, condivisa con persone e gruppi come Proprietario, Editor o Visualizzatore, oppure aperta a tutta l'area di lavoro. Chi amministra non vede le cartelle private degli altri. La ricerca non esce dall'area di lavoro, e in chat si può restringere a basi di conoscenza scelte. Il permesso Scaricare documenti altrui permette di rendere consultabile un contratto senza che se ne possa esportare l'originale. Decidete prima cosa entra in una base condivisa: una pratica HR non va caricata in una cartella aperta a tutti perché è comodo.

Accesso alle azioni – agenti e integrazioni

Qui si decide cosa l'AI può fare, non solo cosa legge, ed è dove un errore costa di più. In Userbot i permessi sono una matrice a tre ruoli, dove ogni casella è un interruttore e la modifica vale subito per tutti coloro che hanno quel ruolo. I valori di partenza:

Prima di allargare un permesso chiedetevi che cosa succede se la persona sbaglia: un Agente sbagliato condiviso con tutti sbaglia in tutti i reparti. E togliere un permesso non ritira ciò che è già stato condiviso: gli Agenti già visibili a tutti restano visibili finché qualcuno non li ritira uno per uno.

Sopra i permessi ci sono le Regole, scritte in italiano. Le linee guida orientano l'AI, che può interpretarle; ciò che richiede approvazione è invece un vincolo: il compito non parte senza il sì di una persona. Valgono anche per Agenti e automazioni. È la risposta pratica a Excessive Agency: l'AI prepara un ordine a un fornitore, l'invio aspetta un'approvazione.

Accesso via API – le chiavi

Le chiavi portano i modelli dentro i vostri software, e un uso fuori controllo è difficile da vedere perché non passa dall'interfaccia. L'amministratore regola quattro cose.

1. Chi ha creare/visualizzare chiavi: spento, tutta l'area di lavoro o gruppi e persone scelti. Per creare una chiave personale serve anche il permesso apposito.
2. Quali chiavi esistono: quelle dell'area di lavoro le creano e le revocano solo gli Admin, con permessi (completamenti, embedding) e indirizzi IP ammessi. Il valore si vede una sola volta.
3. Quali modelli si chiamano: un elenco dell'area di lavoro, separato da quello della chat. È un controllo dell'area di lavoro, non della singola chiave.
4. Quanto si spende: un tetto mensile per l'area di lavoro e un budget per persona; raggiunto il limite, le chiamate ricevono un errore.

Creazione e revoca delle chiavi finiscono nel Registro di audit, con il nome della chiave.

Come si entra: SSO e passkey su quali piani?

L'accesso con Google e Microsoft (OIDC) e la passkey sono disponibili su tutti i piani. L'SSO su misura verso provider aziendali, come Keycloak, è riservato al piano Enterprise. L'accesso per dominio, che fa entrare senza invito chi ha un indirizzo verificato, si può disattivare qualore si ritenga opportuno limitare l'ingresso libero.

Cosa conviene decidere nella policy?

Userbot, con i suoi strumenti, permette di applicare le decisioni aziendali, ma qualcuno deve prenderle. E ci sono cose che Userbot, per scelta, non fa: per esempio il Registro di audit traccia le modifiche alla configurazione (ruoli, integrazioni, chiavi, Agenti), non il testo delle conversazioni né la lettura dei documenti. È una scelta di impostazione: la tutela sta nei permessi decisi prima, non nella sorveglianza dopo.

Il NIST AI RMF, un quadro volontario per gestire i rischi dell'AI, mette il governo al primo posto: ruoli, responsabilità, regole. Nella vostra policy scrivete almeno questi punti.

1. Quali modelli sono ammessi, chi li abilita, se si ammettono modelli fuori UE e per quali dati.
2. Quali modelli grandi sono riservati a quali reparti, e perché.
3. Quali dati non entrano mai in una base di conoscenza condivisa.
4. Chi crea e condivide Agenti e chi li approva prima dell'uso generale.
5. Chi collega nuovi strumenti e con quale tipo di connessione.
6. Chi gestisce le chiavi API e ogni quanto si ruotano.

Il quadro generale è nella guida su cosa significa governare l'AI in azienda; per scrivere regole che le persone seguano c'è l'articolo sulla AI policy aziendale.

Gli errori che vediamo più spesso

• Lasciare tutto com'è. Le impostazioni di partenza non sono una decisione: il tetto di spesa complessivo, per esempio, parte illimitato.
• Dare il tuolo Admin a chi serve un solo permesso. Gli Admin hanno sempre tutto e non si limitano; di solito basta il ruolo Editor.
• Credere che vietare basti. Se lo strumento governato è scomodo, le persone tornano agli account personali: è il problema dello Shadow AI.

Marco Mantovani, CTO di Userbot

Guida la tecnologia di Userbot e il team che sviluppa la piattaforma. Sul blog racconta il passaggio da un bot a struttura fissa a una piattaforma di Agenti AI e scrive di RAG e ricerca ibrida.