Progettare un assistente IA delimitato: strumenti, permessi e limiti di contesto

Un assistente IA è davvero delimitato soltanto quando il suo contratto di servizio eseguibile impedisce ciò che il prompt gli vieta. Se possiede comunque uno strumento e una credenziale capaci di inviare un messaggio, una frase come «non inviare» non costituisce un controllo d’autorizzazione. Il confine reale nasce invece da dati ammessi, identità, operazioni ristrette, permessi nei sistemi a valle, approvazioni puntuali, condizioni di arresto e prove osservabili.

Che cosa deve poter fare l’assistente?

Il team deve prima scrivere una carta del servizio in una sola frase e poi suddividerla in capacità visibili all’utente. Una formula utile è: «Per [utenti idonei], l’assistente può [famiglia di compiti] usando [informazioni approvate] per produrre [risultato ammesso], ma non può [non-obiettivi o decisioni rilevanti]». Prima di collegare strumenti, la carta chiarisce ambiente d’impiego, supervisione umana, proprietario del rischio e risultati vietati.

Verbi come «aiutare» o «gestire» nascondono autorità molto diverse. Occorre trasformarli in operazioni verificabili: cercare un caso, riassumerlo, raccomandare un passo, preparare una bozza, aggiornare un campo, inviare un messaggio, cancellare un record oppure approvare una decisione. La conversazione può restare unica, ma ciascuna operazione deve avere dati, identità, strumenti, tetto d’azione, prove e responsabile propri.

• Utenti e modalità di autenticazione ammessi.
• Compiti supportati, ambiente d’impiego e risultato atteso.
• Fonti e classi di dati utilizzabili.
• Supervisione, proprietario del servizio e proprietario del rischio.
• Non-obiettivi, decisioni vietate e conseguenze che richiedono un processo separato.

Questo metodo per capacità è una sintesi editoriale pratica, non un requisito imposto da NIST o OWASP. È però coerente con l’AI RMF, che invita a documentare scopi, compiti, limiti di conoscenza, ambito, supervisione e tolleranze al rischio, e con la raccomandazione OWASP di offrire la funzionalità minima necessaria. Il risultato è una specifica che prodotto, sicurezza e responsabili operativi possono esaminare prima dell’implementazione.

Quali informazioni può usare ogni capacità?

Ogni capacità deve avere un perimetro informativo, non soltanto un limite tecnico alla finestra di contesto. La specifica deve indicare sistemi approvati, tipi di record, classificazioni, filtri per oggetto, intervalli temporali, aspettative di aggiornamento, diritti dell’utente e dati esclusi. Una finestra più ampia non conferisce accesso, non rende attuale una fonte obsoleta e non trasforma un’affermazione priva di supporto in un fatto.

Messaggi esterni, allegati, documenti recuperati e risposte API vanno trattati come contenuti non fidati: possono fornire dati, ma non modificare silenziosamente le istruzioni del servizio. Il sistema deve mantenere separati istruzioni e contenuti, convalidare gli input e applicare i diritti dell’utente durante il recupero. Se la prova necessaria è inaccessibile, assente o superata, la risposta deve fermarsi, qualificarsi oppure chiedere un’informazione ammessa.

• Fonti, record, campi, date e classificazioni idonei.
• Filtri per utente, conto, pratica, sede o altro oggetto protetto.
• Classe di fiducia e controlli per messaggi, allegati e risultati recuperati.
• Cronologia della sessione separata dalla memoria persistente.
• Dati mai memorizzabili, scadenza, dimensione, cancellazione e isolamento della memoria.

Sessione e memoria persistente richiedono regole diverse. La prima può servire alla continuità del dialogo senza diventare automaticamente un archivio; la seconda esige idoneità esplicita, convalida prima della persistenza, isolamento fra utenti e sessioni, integrità, scadenza e cancellazione. Valori concreti per durata e dimensione dipendono dal servizio, dalla protezione dei dati e dalla gestione documentale: copiarli da un esempio tecnico creerebbe una falsa garanzia.

Come devono imporre il confine identità, strumenti e permessi?

Autenticazione, autorizzazione e approvazione devono restare tre decisioni distinte, applicate fuori dal modello. L’autenticazione stabilisce chi sia l’utente, il client o il carico di lavoro; l’autorizzazione decide quale operazione possa compiere su una risorsa protetta; l’approvazione accetta una proposta precisa. Il gateway degli strumenti e il sistema destinatario devono verificare identità, verbo, risorsa e parametri: un prompt o un guardrail linguistico non può sostituirli.

Per ogni operazione occorre scegliere esplicitamente fra autorità delegata dell’utente e identità di servizio controllata. L’assistente non deve ereditare in silenzio il conto privilegiato di un operatore. È preferibile esporre funzioni ristrette, come «leggi il riepilogo del caso» o «crea una bozza», invece dell’accesso generale a casella postale, banca dati, browser o shell. Verbi, record, campi, destinatari, durata delle credenziali e risorsa prevista dal token vanno limitati nel percorso esecutivo.

La specifica MCP rende concreta questa separazione per le integrazioni MCP protette: distingue client, risorsa e server di autorizzazione, raccomanda ambiti minimi e consente token destinati a una risorsa precisa. Non è però un modello obbligatorio per ogni strumento. Indipendentemente dal protocollo, il servizio deve inoltre fissare limiti propri per frequenza, tentativi, catene, lotti, spesa e tempo, insieme a idempotenza, rollback e interruttori di sicurezza adeguati all’operazione.

La conversazione può essere continua; la sua autorità deve restare suddivisa in capacità piccole e applicate indipendentemente.

Quanta autonomia deve avere una capacità?

Ogni capacità necessita di un tetto d’azione esplicito, con controlli indipendenti più forti quando passa dall’informare al modificare uno stato esterno. Una scala pratica distingue risposta o sintesi, raccomandazione, bozza, scrittura reversibile e circoscritta, azione esterna rilevante e decisione vietata. È una sintesi editoriale fondata sui principi di funzionalità minima, privilegio minimo, separazione fra decisione ed esecuzione e salvaguardie esterne.

• Rispondere o riassumere senza cambiare sistemi esterni.
• Raccomandare o preparare una proposta ispezionabile.
• Creare un artefatto modificabile in stato di bozza.
• Scrivere campi ammessi in un processo reversibile.
• Inviare, pubblicare, cancellare o produrre un altro effetto esterno rilevante.
• Rifiutare una decisione che il servizio non è autorizzato a prendere.

Bozza e invio non sono due fasi della medesima autorizzazione. La prima può scrivere soltanto in uno spazio non definitivo; il secondo richiede un’operazione distinta, un destinatario autorizzato e un contenuto approvato. Anche un aggiornamento reversibile va separato da una modifica distruttiva. Pagamenti, concessioni d’accesso, cambiamenti in produzione, eliminazioni, impegni esterni materiali e giudizi professionali ad alto rischio devono restare sotto controllo umano qualificato e politiche deterministiche adeguate.

Prima di un’azione rilevante, l’utente deve vedere una proposta ispezionabile. L’approvazione va legata ad attore, strumento, risorsa, parametri normalizzati, momento e scadenza, quindi verificata immediatamente prima dell’esecuzione. Se cambiano destinatario, contenuto o altro parametro, serve una nuova convalida. L’approvazione non concede un permesso mancante, non amplia l’autorità permanente e non trasforma una decisione vietata in una decisione consentita.

Che cosa deve accadere quando l’assistente raggiunge un confine?

Rifiuto, aiuto parziale sicuro, passaggio a una persona ed escalation di sicurezza devono essere risultati espliciti del servizio, con vere condizioni di arresto. Il messaggio spiega il confine in linguaggio semplice senza rivelare dettagli sensibili delle politiche. Soprattutto, non deve mai sostenere che una fonte sia stata verificata, una chiamata eseguita, un’approvazione ottenuta o una scrittura completata quando il relativo passaggio è fallito.

• Compito fuori ambito.
• Informazioni non idonee o prova assente e obsoleta.
• Autorizzazione insufficiente o approvazione necessaria.
• Giudizio specialistico o decisione di politica richiesti.
• Strumento indisponibile o limite operativo raggiunto.
• Segnale di sicurezza rilevato.

Quando possibile, l’assistente offre soltanto la parte sicura: una bozza non inviata, una checklist o una richiesta dei dati mancanti. Il passaggio al responsabile include obiettivo originario, contesto non sensibile rilevante, capacità tentata, motivo, prove disponibili o mancanti, prossimo passo e identificativo di traccia. L’esecuzione resta sospesa mentre il responsabile agisce; una modifica alla proposta impedisce la ripresa automatica e impone una nuova verifica.

Il normale passaggio all’operatore, l’approvazione aziendale e l’incidente di sicurezza hanno proprietari e urgenze differenti. Un problema di qualità dei dati può andare al responsabile del servizio; una promessa commerciale richiede il decisore aziendale; tentativi di escalation dei privilegi, esfiltrazione, avvelenamento della memoria o abuso ricorsivo degli strumenti possono attivare il percorso d’incidente. Il piano deve prevedere risposta, contenimento, revoca, rimedio e registrazioni utili a persone preparate.

Come trasformare questi confini in un progetto operativo?

Il team deve compilare una riga del canvas per ogni operazione visibile all’utente e collegarla a controlli applicabili, evidenze, prove, metriche e responsabilità. La riga specifica attore, autenticazione, perimetro informativo, sessione e memoria, strumento ristretto, identità agente, risorsa, tetto d’azione, approvazione, limiti operativi, rifiuto, registrazione, scenari di valutazione, segnali di produzione e proprietario. Se un campo non ha un meccanismo esecutivo o un responsabile, resta soltanto documentazione.

Si consideri un assistente interno per il personale di supporto. Può riassumere pratiche che il collaboratore vede già, preparare risposte basate su contenuti approvati e inviare soltanto una risposta approvata. Non decide compensazioni, non cambia diritti del cliente e non formula determinazioni regolamentari. Le tre capacità condividono la conversazione, ma non accesso, credenziali, tetto d’azione, prove o destinazione delle escalation.

Quali prove servono per rilasciare e continuare a operare?

Il rilascio richiede prove che funzionino sia il servizio permesso sia i dinieghi attesi in condizioni simili all’impiego reale. Accanto ai casi positivi vanno provati accessi tra conti, strumenti non autorizzati, fonti obsolete, contenuti recuperati avvelenati, dati vietati, elusione dell’approvazione, parametri modificati, ritenti duplicati, dipendenze indisponibili, tentativi di esfiltrazione e catene incontrollate. I limiti e le modalità di guasto note devono essere comunicati a utenti e operatori.

Le registrazioni devono ricostruire chi ha chiesto che cosa, quale capacità e versione di politica si applicavano, quali classi di fonti e strumenti sono intervenute, quali decisioni di autorizzazione e approvazione sono state prese e quale esito ne è seguito. Non serve conservare ogni prompt o documento per intero: segreti e contesto sensibile vanno oscurati o esclusi, mentre accesso e durata seguono le regole organizzative di privacy, sicurezza e gestione documentale.

• Uso inatteso di strumenti e sequenze d’azione anomale.
• Dinieghi ripetuti, errori d’autorizzazione e approvazioni cambiate.
• Deriva, latenza, consumo di risorse, guasti e dipendenze instabili.
• Esiti per capacità, con proprietari autorizzati a sospendere, correggere o ritirare il servizio.

La garanzia non termina con il rilascio. Cambiamenti materiali a modello, prompt, recupero, memoria, strumenti, permessi, politiche, dati, fornitore o contesto operativo devono riaprire le prove delle capacità interessate e la relativa decisione di rilascio. Conviene iniziare dalla capacità utile più piccola, ampliarne l’autorità soltanto tramite una modifica riesaminata e coinvolgere i responsabili di sicurezza, identità, privacy, documenti, rischio e servizio quando sono toccati dati sensibili, accessi privilegiati o effetti esterni.

Il proprietario del comportamento del servizio, quello delle concessioni d’accesso, il responsabile dei passaggi aziendali e il referente degli incidenti possono essere persone diverse. Ognuno deve poter sospendere il proprio ambito, chiedere nuove prove e revocare una capacità non più controllabile. Questioni legali, regolamentari o altri giudizi professionali ad alto rischio vanno invece indirizzati a specialisti qualificati e a un processo governato separatamente, non trasformati in una nuova istruzione per il modello.