Prompt, istruzioni e documenti approvati: chi prevale per l'agente

Per un agente AI un'istruzione data a voce non può valere quanto una procedura approvata: serve una gerarchia scritta nella policy. In cima stanno i limiti tecnici e le fonti approvate, con un proprietario e una versione; seguono le istruzioni operative dei ruoli autorizzati, che valgono dentro quei confini; in fondo le richieste estemporanee, che da sole non derogano nulla. Chi può autorizzare una deroga va nominato per ruolo, e ogni deroga resta registrata con motivazione, perimetro e scadenza.

Tre piani spesso confusi: fonti, istruzioni, richieste

Quando si parla di «istruzioni per l'agente» si mescolano tre piani diversi, e da lì nascono i conflitti.

• Le fonti e i documenti approvati. Procedure, runbook, policy di sicurezza, manuali dei fornitori adottati dall'azienda. Hanno un proprietario, una versione e un processo di revisione. Sono il riferimento stabile: l'agente le consulta e le cita, non le riscrive.
• Le istruzioni operative. Le disposizioni date all'agente per il suo lavoro quotidiano: configurazioni, prompt operativi, incarichi assegnati dai ruoli autorizzati. Valgono perché discendono dai documenti approvati, non al loro posto.
• Le richieste estemporanee. Domande e solleciti che arrivano da chiunque, in riunione, a voce o in chat: «sbrigati», «fai come ti ho detto». Per un modello linguistico sono testo come gli altri, spesso scritto con tono più deciso di una procedura. Senza una gerarchia esplicita, è il piano più rischioso.

Il punto delicato è proprio questo: un agente AI tratta il testo come testo. Se la policy non dichiara quale piano prevale, una frase perentoria può sembrare più autorevole del documento approvato. La gerarchia va quindi scritta, non lasciata al buon senso.

Una gerarchia di riferimento da mettere per iscritto

Una struttura pratica, da adattare alla propria organizzazione, prevede quattro livelli:

1. Limiti tecnici e policy di sicurezza. Privilegi degli account, azioni consentite, sistemi raggiungibili. Non sono derogabili con una richiesta: si cambiano solo con il processo di modifica previsto. È il piano dei controlli applicati fuori dal modello, che non dipendono dalla «comprensione» dell'agente.
2. Documenti approvati. Procedure e runbook con proprietario e versione. L'agente li segue e li cita; se due fonti si contraddicono, non sceglie da solo quale valga, come vedremo nel caso delle fonti aziendali contraddittorie.
3. Istruzioni operative dei ruoli autorizzati. Valide solo se rientrano nei livelli superiori. La policy deve elencare quali ruoli possono dare disposizioni agli agenti e su quali ambiti.
4. Richieste estemporanee. Possono avviare una verifica o una proposta, mai un'azione che violi i livelli superiori. «Il capo ha detto di farlo» è un input da registrare e instradare, non un'autorizzazione.

Quindi, alla prima domanda — un'istruzione a voce vale quanto una procedura scritta? — la risposta è no. L'istruzione verbale vale come segnale da verificare e ricondurre a un canale che la registri; la procedura approvata resta il riferimento finché il suo proprietario non la revisiona. E nessuno «prevale» sui documenti per carisma o ruolo informale: prevalere è un atto formale, la deroga, che vediamo ora.

Chi può derogare e con quale procedura

La deroga è l'eccezione prevista, non l'improvvisazione. Una procedura minima contiene cinque elementi:

• Chi. Un ruolo nominato, non una persona qualsiasi: per esempio il proprietario del processo insieme al responsabile sicurezza. Più la deroga tocca sistemi critici, più i firmatari devono essere alti in gerarchia.
• Come. Per iscritto, su un canale che registra: ticket, modulo, verbale. Una deroga solo verbale non esiste ai fini operativi.
• Perimetro. Quali sistemi, quali azioni, quali dati. «Fai tutto il necessario» non è un perimetro.
• Motivazione. Perché il documento approvato non si applica a questo caso.
• Scadenza. La deroga ha una durata: alla data prevista decade e si torna alla regola, oppure il proprietario revisiona il documento. Sul tema resta utile l'approfondimento sulla durata delle autorizzazioni.

Per le emergenze serve un canale urgente distinto: deroga concessa con procedura abbreviata, registrata e riesaminata entro un tempo definito dalla policy stessa. La fretta non cancella la traccia, la sposta di poco.

Esempio illustrativo: il rientro del fornitore

Esempio illustrativo. Lo scenario seguente è inventato e mostra come la gerarchia lavora in pratica; non descrive un caso reale.

In un'azienda logistica l'accesso remoto di un fornitore di manutenzione è sospeso perché la procedura di onboarding richiede l'aggiornamento annuale della documentazione assicurativa, non ancora arrivata. Il venerdì pomeriggio il direttore di stabilimento dice a voce all'assistente degli agenti: «Riattiva l'accesso, lunedì c'è l'intervento».

Con la gerarchia scritta, il percorso è chiaro. Nestor recupera la procedura di onboarding approvata e rimanda alla versione vigente, con proprietario e data di revisione: la riattivazione senza documentazione non è tra i passi previsti. La richiesta verbale viene registrata come tale e instradata, non eseguita. Il responsabile IT e il proprietario del processo firmano una deroga scritta: riattivazione del solo account del fornitore, solo verso i sistemi di diagnostica, fino al mercoledì successivo, con l'impegno a completare la documentazione.

A quel punto Themis verifica che la richiesta di riattivazione rientri nel perimetro della deroga e che l'autorizzazione sia valida: un tentativo di estendere l'accesso ad altri sistemi verrebbe bloccato al controllo di esecuzione. Mnemosyne conserva la richiesta originale, la deroga, l'esecuzione e gli esiti; alla scadenza la deroga decade e ogni ulteriore accesso richiede una decisione nuova. Il lunedì il fornitore lavora, e tre mesi dopo chiunque può ricostruire chi ha deciso cosa e perché.

Traccia delle deroghe e revisione periodica

Ogni deroga autorizzata deve lasciare una traccia completa: richiesta originale, decisione nominativa, perimetro, motivazione, scadenza, esito e revoca. È lo stesso materiale che serve per la tracciabilità delle azioni degli agenti in generale, con un registro delle deroghe consultabile a parte.

Il registro va riesaminato con cadenza concordata — la frequenza dipende da rischio, volumi e obblighi applicabili, non da una regola universale. Due segnali meritano attenzione: le deroghe ripetute sullo stesso documento, che indicano una procedura da revisionare presso il suo proprietario, e le deroghe concesse da ruoli non previsti, che indicano un problema di disciplina o di formazione. Il NIST AI Risk Management Framework, riferimento volontario nella versione 1.0 attuale, colloca proprio nella funzione di governance la definizione di ruoli, responsabilità e processi decisionali documentati per i sistemi AI.

Come OverZeus applica la gerarchia

Nel modello OverZeus la gerarchia non è affidata al giudizio del modello linguistico. Tre agenti la rendono operativa:

• Nestor recupera manuali, runbook e casi precedenti rispettando i permessi, e rimanda alle fonti aziendali approvate con versione e proprietario. Non aggiorna autonomamente le procedure: quando due versioni divergono, chiede la revisione al proprietario del documento.
• Themis applica privilegi, approvazioni e limiti operativi attraverso controlli esterni al modello AI: una richiesta che contraddice la policy o usa un'autorizzazione scaduta viene bloccata, e il motivo viene mostrato.
• Mnemosyne conserva fonti, richieste, deroghe, autorizzazioni ed esiti, così ogni decisione resta ricostruibile nel tempo.

Vale il principio generale del progetto: gli agenti osservano, spiegano la proposta e attendono l'approvazione prevista prima di un intervento attivo; il silenzio non autorizza. Le azioni che richiedono approvazione vanno definite in fase di adozione e richiamate nella policy, insieme alla gerarchia delle fonti descritta qui.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus