Governance: chi può fare che cosa e quanto costa

Perché una piattaforma di IA ha bisogno di una propria gestione dei diritti

Una piattaforma di IA ha bisogno di una propria gestione dei diritti, perché una finestra di chat senza regole inoltra ogni domanda a ogni sistema collegato. Non appena l’IA è collegata a un sistema aziendale, la domanda non è più se qualcuno possa chattare, ma quali dati l’IA possa leggere per conto di quella persona.

Un divieto sposta soltanto l’uso, non lo elimina

Chi non ha una via autorizzata prende la prima alternativa. Un divieto sposta l’uso su account privati presso fornitori pubblici, dove non valgono né contratto, né registro, né diritto alla cancellazione. I dati aziendali finiscono così in un servizio che nessuno nella Sua organizzazione amministra e del cui trattamento non può dare prova.

La contromisura che funziona è una via autorizzata migliore di quella privata. Deve però rendere controllabili quattro aspetti, altrimenti il rischio viene soltanto spostato all’interno:

• Quali persone possono utilizzare la piattaforma e tramite quale accesso.
• Quali sistemi collegati e quali singoli strumenti sono accessibili a una persona.
• Che cosa è successo davvero, in modo dimostrabile ed esportabile.
• Quanto costa l’esercizio, in modo dettagliato e limitabile, prima che arrivi la fattura.

Proprio questi quattro punti di controllo costituiscono le aree del pannello di amministrazione di Kisuno: gestione utenti, regole di accesso, audit e consumo.

Da dove arrivano utenti, ruoli e gruppi

Utenti, ruoli e gruppi si gestiscono nel pannello di amministrazione oppure si importano da Entra ID. Un ruolo raggruppa i diritti funzionali, cioè ciò che una persona può fare nell’interfaccia. Un gruppo raggruppa le persone per le regole di accesso e di budget. I due livelli sono combinabili in modo indipendente.

Utenti locali e collegamento a Entra ID

Senza un provider di identità, Kisuno lavora con account locali: invito tramite link, password impostata dalla persona invitata. L’accesso tramite Entra ID o un altro provider OIDC è supportato dalla piattaforma e viene configurato per la Sua istanza. Una volta attivo, ogni persona accede tramite OIDC, l’account viene creato al primo accesso e le informazioni di gruppo e ruolo contenute nel token di accesso vengono mappate sui Suoi gruppi in Kisuno.

La revoca avviene quindi alla porta d’ingresso: chi è disattivato in Entra ID non entra più e perde così ogni accesso, anche ai sistemi collegati. Il provisioning e il deprovisioning automatici degli account tramite SCIM sono previsti, ma oggi non ancora disponibili.

Che cosa stabilisce un ruolo e che cosa un gruppo

Un ruolo governa i diritti funzionali nella piattaforma, per esempio se una persona può creare agenti, usare la ricerca web o aprire il pannello di amministrazione. Un gruppo governa a quali dati e strumenti si accede e su quale budget viene imputato il consumo.

Invito, assegnazione, disattivazione

L’invito viene inviato per e-mail o tramite link e può già indicare il gruppo di destinazione. L’appartenenza viene applicata non appena la persona invitata ha completato la registrazione. Così nessuno parte in uno stato intermedio senza diritti e non deve integrare nulla dopo ogni registrazione.

Per terminare l’accesso ci sono due strade. Il blocco mantiene l’account ma nega l’accesso. L’eliminazione rimuove account, conversazioni e voci dell’indice di ricerca; prima è possibile un export dei dati per la persona interessata, così da soddisfare sia le richieste di accesso sia quelle di cancellazione.

Diritti fino al livello del singolo strumento

Le chiamate agli strumenti passano dal gateway MCP, un componente tra la chat e il sistema collegato. Per la persona che effettua la richiesta, il gateway verifica se il server e lo specifico strumento sono consentiti, registra la decisione e inoltra la chiamata solo in caso di autorizzazione. Gli strumenti bloccati non compaiono nell’elenco degli strumenti dell’utente; dopo una modifica dei diritti ciò ha effetto con un breve ritardo. Il vero blocco è la verifica a ogni singola chiamata.

I sistemi vengono collegati tramite MCP, lo standard aperto per l’accesso agli strumenti da parte dei modelli di IA. Il gateway si colloca a monte, così l’autorizzazione viene decisa centralmente per persona, ruolo e gruppo e non resta dispersa nel sistema collegato. Quali sistemi si possono collegare e quali sono già pronti è indicato nella pagina Integrazioni; diritti senza strumenti non hanno oggetto.

L’esempio: leggere le fatture sì, leggere i salari no

Un ERP collegato non offre all’IA un unico accesso, ma molti strumenti distinti: cercare fatture, leggere dati dei clienti, leggere dati salariali, scrivere record. Al gruppo Contabilità vengono abilitati gli strumenti per le fatture, mentre quelli salariali restano riservati alle risorse umane. Stesso server, strumenti diversi, decisioni separate.

Al di sotto c’è un secondo confine. Se Kisuno accede al Suo ERP con l’identità della singola persona, restano determinanti le regole di accesso dell’ERP: chi lì può vedere solo determinati record non vede di più nemmeno tramite l’IA. Se il collegamento avviene con un account di servizio comune, il gateway è l’unico punto di applicazione e la selezione degli strumenti va quindi ritagliata in modo restrittivo.

I diritti all’interno di uno strumento, cioè su singoli campi o righe, non sono applicati da Kisuno. Se ne occupa la gestione dei diritti del sistema collegato. Uno strumento con un ambito funzionale ampio va quindi o non abilitato affatto oppure abilitato solo a un gruppo che può comunque vedere quei dati.

La catena di regole: utente prima del ruolo, del gruppo e del valore predefinito

I diritti vengono valutati in un ordine fisso: singolo utente, poi ruolo, poi gruppo, infine impostazione predefinita del server. Decide la prima regola corrispondente e la ricerca si ferma lì. Ogni decisione è quindi spiegabile e una singola abilitazione non richiede un ruolo speciale. Il fatto che i diritti valgano per singolo strumento è l’elemento distintivo nel confronto con altre piattaforme.

Che cosa succede se nessuna regola si applica

Se non si applica alcuna regola di utente, ruolo o gruppo, decide l’impostazione predefinita del server. Imposti questo valore su «nega» subito dopo aver collegato un sistema e abiliti poi in modo mirato i singoli gruppi. In questo modo un sistema appena collegato non può far vedere per errore più di quanto previsto.

Se la verifica dei diritti stessa non funziona, per esempio perché il database delle regole non è raggiungibile, il gateway nega la chiamata invece di lasciarla passare. Un guasto porta quindi a un messaggio di errore nella chat, non a un accesso libero. È previsto un interruttore di sola lettura per server che blocca in blocco gli strumenti di scrittura.

Audit: ogni accesso tracciabile

Ogni chiamata a uno strumento tramite il gateway viene registrata con data e ora, persona, sistema di destinazione, strumento e decisione, comprese quelle negate. La piattaforma tiene inoltre un registro concatenato in modo continuo di azioni amministrative, accessi e modifiche dei diritti. Entrambi i registri risiedono nella Sua istanza e sono esportabili in CSV.

Che cosa viene registrato

• Le chiamate agli strumenti dei sistemi collegati, con la decisione presa, consentita o negata.
• Gli accessi alla piattaforma e al pannello di amministrazione.
• Le modifiche a ruoli, gruppi, diritti e regole di accesso.
• Le modifiche alla configurazione dell’istanza.
• La creazione, l’invito, il blocco e l’eliminazione di account.

L’audit log è una prova degli accessi, non una trascrizione delle conversazioni. Indica chi ha chiamato quale strumento su quale sistema e quando. Le conversazioni stesse sono archiviate separatamente nel database della Sua istanza e sono soggette al periodo di conservazione impostato.

Per quanto tempo e dove si può esportare

I registri restano nella Sua istanza, nel Suo database. In self-hosting non lasciano la Sua infrastruttura. L’export avviene in CSV, filtrato per periodo e persona, ed è quindi consegnabile direttamente a una revisione, all’ufficio legale o a uno strumento di audit.

Il registro delle azioni amministrative è concatenato: ogni voce porta un checksum della voce precedente e un controllo integrato segnala quando la catena non torna più. L’eliminazione successiva di singole voci viene quindi rilevata. Per le conversazioni il periodo di conservazione è configurabile; i contenuti scaduti vengono rimossi insieme all’indice di ricerca.

Rendere visibili i costi e limitarli

Il consumo viene rilevato per persona, gruppo, modello e giorno e indicato sia in token sia in euro. Un budget mensile comune limita il totale per l’intera organizzazione, un limite mensile facoltativo per persona limita i singoli account. Quando un budget è esaurito, interviene un blocco morbido (soft block).

Consumo per persona, gruppo e modello

Il pannello di amministrazione mostra il consumo in euro, suddiviso per persona, per modello e per giorno, insieme alle singole richieste con modello e orario. Importi e suddivisione sono visibili all’amministrazione; gli utenti finali ricevono nella chat solo un avviso quando il budget è esaurito. Così la pressione sui costi esce dal lavoro quotidiano e i numeri restano visibili dove devono esserlo.

I prezzi sono registrati per modello, così l’analisi non si basa su un valore approssimativo. È più importante di quanto sembri: a parità di conversazione, tra un modello parsimonioso e uno molto grande il costo differisce di diverse volte. Una selezione curata dei modelli fa quindi parte del controllo dei costi, non è solo una questione di usabilità.

Budget mensile comune invece di limiti individuali

Il budget mensile vale per l’organizzazione nel suo insieme, non pro capite. Il motivo è pratico: il consumo non si distribuisce mai in modo uniforme. Chi usa intensamente la piattaforma resterebbe bloccato da un limite individuale rigido, mentre per altri il contingente scadrebbe inutilizzato. Un fondo comune compensa questo squilibrio senza che nessuno debba ritoccare i limiti.

Per i casi anomali esiste inoltre un limite mensile facoltativo per persona. È disattivato finché non lo imposta e viene applicato in modo rigido nello stesso confronto del budget complessivo. Uso tipico: un singolo account che invia richieste automatizzate non deve svuotare da solo il fondo comune.

Blocco morbido invece di sforamento silenzioso

Quando il budget è esaurito, interviene il blocco morbido: la richiesta successiva viene rifiutata, con un avviso nella chat invece di un addebito silenzioso. Una risposta già in corso viene comunque completata. L’amministratore può aumentare il budget in qualsiasi momento e l’attività riprende subito. Senza questo aumento non nasce alcun conguaglio.

Il confronto tra consumo rilevato e budget avviene ogni minuto e la stima preliminare di una richiesta non ne conosce la lunghezza esatta. Una singola risposta può quindi superare di poco il limite. Si tratta di un blocco morbido che impedisce l’esplosione dei costi, non di una prenotazione anticipata al secondo.

Abilitare gli agenti invece di vietarli

Agenti e skill vengono abilitati in modo curato, non consentiti né vietati in blocco. Gli account normali usano gli agenti loro assegnati e non vedono affatto il generatore di agenti. Un ruolo privilegiato crea e condivide gli agenti, mentre le skill vengono abilitate dall’amministratore persona per persona.

Il motivo sta nei diritti: un agente porta con sé istruzioni fisse e un insieme di strumenti. Se tutti potessero creare e condividere agenti propri, accanto alla Sua catena dei diritti nascerebbe un secondo canale di distribuzione incontrollato. La verifica dei diritti al gateway continuerebbe a valere per ogni chiamata, ma si perderebbe la visione d’insieme su chi lavora con che cosa.

In pratica questo produce pochi agenti ben curati per gruppo invece di molti a metà: uno per la creazione delle offerte, uno per le analisi dall’ERP, uno per la ricerca interna delle informazioni.

Domande frequenti