Questa pagina è mostrata in inglese mentre viene preparata una traduzione revisionata per la tua lingua.

Perché trattiamo l'intento dell'agente come un contratto di governance, non come uno stato d'animo

Una prospettiva di Perspectis AI in linguaggio semplice: dove si colloca l'intento dell'agente nell'IA aziendale (politiche, identità, strumenti, osservabilità) – non solo nei prompt – e come concepiamo i livelli di rischio e l'inserimento dei prompt.

6 min di lettura2026-04-15

Una nota in linguaggio semplice per leader, responsabili del rischio e team clienti (aprile 2026)

La risposta breve

I sistemi "agentici" sono al centro dell'attenzione: assistenti che pianificano, richiamano strumenti e agiscono con meno supervisione. Crediamo che le idee alla base di questo cambiamento debbano essere pubblicate come prospettiva di settore, perché la questione cruciale non è se i modelli possano sembrare sicuri di sé, ma se un'organizzazione sia in grado di difendere chi è stato autorizzato a fare cosa e perché, quando qualcosa va storto o quando un ente regolatore lo richiede.

Perspectis AI è progettato in modo che l'intento (quale lavoro viene richiesto e sotto quale autorità) sia contenuto in punti favorevoli alla governance – identità, policy, limiti degli strumenti e osservabilità – e non solo nel prompt del modello. Ecco come noi allineiamo l'energia dell'"assistente disponibile" con il dovere di diligenza negli ambienti professionali.

Cosa noi intendiamo per "intento" in parole semplici

Nel linguaggio di tutti i giorni, l'intento è semplicemente l'obiettivo di una richiesta: "riassumere questa questione", "scrivere una bozza di emAIl", "creare una fattura", "eseguire un controllo di conformità".

In una piattaforma seria, l'intento è anche strutturale:

Chi ha avviato il lavoro (una persona, un ruolo, un servizio).
Quale funzionalità è autorizzata ad essere eseguita (ad esempio, il percorso Rappresentante dell'Agente Personale rispetto a un'attività in background).

Quale classe di azione è coinvolta (lettura di documenti, modifica degli stessi, movimentazione di denaro o operazioni amministrative irreversibili).

Nessuno di questi aspetti dovrebbe essere sottinteso solo da formule accattivanti in una chat. Noi lo consideriamo un'informazione che la piattaforma deve comprendere e applicare, quindi il modello non è l'unico luogo in cui esiste l'"intento". ---

Perché l'intento non può risiedere solo all'interno del modello

Un modello linguistico complesso può interpretare il linguaggio; non può, di per sé, essere il sistema di riferimento per le autorizzazioni, la riservatezza o le politiche di fatturazione.

Progettiamo secondo un principio semplice: la governance appartiene al piano applicativo e dei dati, non solo alle istruzioni impartite a un modello.

Questo significa che:

I controlli delle policy (funzionalità, ruoli, confini organizzativi) decidono se un'azione può essere eseguita, anche se il modello "accetta" una richiesta dannosa o ambigua.
I registri degli strumenti e delle azioni stabiliscono quali funzionalità esistono e quanto rischiosa è ciascuna; il modello non può inventare nuovi endpoint privilegiati tramite testi persuasivi.
Le barriere informative e controlli simili si applicano comunque quando un assistente recupera o riassume materiale sensibile, perché le regole di accesso non sono negoziabili nel linguaggio naturale.

Questo approccio è il modo in cui noi riduciamo un'intera classe di modalità di errore in cui una risposta fluida sembra autorizzata ma non lo è.

Come noi consideriamo il rischio senza sommergere nessuno di tecnicismi

Azioni diverse comportano rischi diversi nel mondo reale. Noi raggruppiamo questo concetto in una scala pratica che molti team già conoscono:

| Idea semplice | Cosa tende a significare nelle operazioni |

| --- | --- |

Leggere | Consultare informazioni; richiede comunque regole di accesso e riservatezza corrette, ma non rappresenta di per sé un cambiamento duraturo. |

Agire (modificare i dati) | Creare o aggiornare record; richiede una chiara responsabilità e spesso una fase di conferma nei canali a rischio più elevato. |

Effettuare transazioni (denaro o fatturazione) | Attività finanziarie o correlate alla fatturazione; richiede una conferma esplicita e un'autorizzazione forte, perché gli errori diventano eventi commerciali e reputazionali. |

Irreversibile o distruttivo | Operazioni di tipo amministrativo o difficili da annullare; Merita i controlli più rigorosi e, nella nostra direzione progettuale, non il tipo di lavoro che vogliamo venga svolto silenziosamente attraverso i canali a mani libere più rischiosi, come la voce, senza ulteriori misure di sicurezza.

Oltre al rischio per singola azione, ci preoccupa anche dei modelli di intervento umano a livello di prodotto: dove è necessaria l'approvazione di un essere umano, dove un essere umano monitora e può intervenire e dove l'autonomia è intenzionalmente limitata. Non si tratta di burocrazia fine a se stessa; è il modo in cui le organizzazioni regolamentate e sensibili alla reputazione operano con prove concrete.

Iniezione di prompt e comportamento "emergente": cosa succede realmente

L'iniezione di prompt (tentativi di dirottare o confondere un assistente con testo ostile) è una nota preoccupazione del settore. Noi la prendiamo sul serio e siamo onesti: nessun filtro di testo è una bacchetta magica.

Ciò che noi sottolineiamo AI clienti è la strategia di difesa a più livelli:

La mitigazione al confine del modello (rilevamento, sanificazione, registrazione) riduce la quantità di testo dannoso che raggiunge il modello senza subire modifiche.
I controlli rigidi nel software continuano a decidere se gli strumenti vengono eseguiti, se i fondi vengono trasferiti o se i dati riservati vengono restituiti, in modo che un modello manipolato non diventi una sovrascrittura silenziosa delle policy aziendali.

Questa combinazione è il modo in cui noi parliamo di sicurezza senza fingere che il modello sia infallibile.

Confronto a colpo d'occhio (strutturale, non un punteggio settimanale delle funzionalità)

Questa tabella è pensata per le conversazioni con gli stakeholder: posizionamento, non un confronto a caselle di spunta. I prodotti cambiano rapidamente; l'intento dell'architettura cambia più lentamente.

|--|--: |--|--: |

Dove deve risiedere l'intento | Identità, policy, registri, richieste strutturate, osservabilità | Principalmente nella conversazione | Qualunque cosa implementi ciascun team |

Chi è responsabile dell'applicazione | Il livello della piattaforma che noi distribuiamo e sviluppiamo | Il prodotto del fornitore + le scelte di amministrazione del tenant | I team di ingegneria e sicurezza dell'organizzazione che adotta |

Attività che comportano trasferimenti di denaro e sono irreversibili | Definizione esplicita del rischio, conferme, vincoli di canale nella nostra direzione | Spesso fuori ambito o generico | Completamente personalizzato: potente e con grandi responsabilità |

Protocollo di contesto del modello e strumenti | Noi trattiamo gli strumenti come funzionalità governate, non come superpoteri silenziosi | Varia a seconda del prodotto | Dipende interamente dalla qualità dell'implementazione |

Storia dell'audit | Progettata per "chi ha approvato cosa e perché" come aspetto della piattaforma | Varia; spesso più semplice | Completamente personalizzato |

Il miglior modello mentale in una sola riga | Assistente governato all'interno di una piattaforma operativa | Superficie di conversazione utile | Stack di agenti personalizzato |

Perché pubblichiamo questo tipo di prospettiva

I nostri clienti non acquistano semplicemente "una funzionalità di IA". Il vero impegno è un funzionamento difendibile: continuità, separazione dei compiti e una narrazione che regga anche in caso di malfunzionamenti. Investiamo in una presentazione pubblica e chiara, insieme a materiale tecnico più approfondito per i colleghi esperti di sicurezza e architettura, perché i nostri clienti meritano chiarezza su cosa sia di marketing e cosa sia strutturale.

L'Ambiente Demo di Perspectis AI esiste in parte per rendere tangibile questa differenza: non un singolo thread dimostrativo accattivante, ma un ampio catalogo di scenari realistici in cui intento, policy e flusso di lavoro sono considerati elementi di primaria importanza.

Fonti (esterne, per un contesto generale del settore)

Questo documento è destinato a lettori esterni non tecnici. Valutazioni tecniche più approfondite dei controlli, dello stato di implementazione e delle prove sono disponibili nella nostra documentazione di sicurezza e architettura per clienti e auditor.