Agenti Compositi:
Governance e affidabilità

Agenti Compositi: Governance Reale e Workflow AI

Oltre l'hype: la necessità del controllo

Siamo ormai giunti alla fine del 2025 e la conversazione attorno all'Intelligenza Artificiale nelle aziende e nella Pubblica Amministrazione è definitivamente maturata. In pratica, è ormai consolidata la capacità generativa delle AI ("Wow, scrive una poesia!"). Oggi siamo nella fase dell'ingegnerizzazione e della responsabilità, quella che produce (o dovrebbe produrre) valore.

Affidarsi a un singolo modello (LLM) per gestire processi critici è un rischio da evitare quando si parla di produzione e affidabilità. Un LLM monolitico può creare problemi ed è, soprattutto, opaco. In contesti regolati dall'AI Act, dal GDPR e/o da rigide policy aziendali, il "black box" non è per niente consigliabile.

La soluzione è il passaggio ai sistemi ad Agenti Compositi: architetture dove molteplici intelligenze specializzate (modelli o componenti AI) collaborano, orchestrate da regole deterministiche scritte in codice e non (solo) in linguaggio naturale.

L'architettura della "responsabilità" (con Mastra)

Per dimostrare che la governance non è solo teoria, abbiamo rilasciato una demo tecnica pubblica basata su Mastra AI, un framework molto apprezzato per la sua capacità di unire la flessibilità degli LLM con il rigore di TypeScript.

Il concetto alla base è semplice: dividere i compiti per mantenere il controllo. Nell'esempio (un flusso di validazione documentale per la PA), non esiste un unico "cervellone", ma tre agenti distinti:

  1. Classifier: Identifica il tema della richiesta (Welfare, Tasse, Urbanistica).
  2. Compliance Officer: Non scrive risposte, ma valuta. Assegna un punteggio (0-100) e lista i rischi.
  3. Approver: Genera la risposta ufficiale solo se autorizzato.

La barriera: una logica deterministica

Nel progetto demo, la decisione di approvare o respingere una pratica non è presa dall'AI, ma da una logica deterministica scritta in TypeScript all'interno del Workflow.

Guardiamo un estratto reale dal file `src/workflow.ts` del nostro progetto:

const governanceStep = createStep({
  id: "governanceDecision",
  // Usiamo Zod per garantire che i dati siano strutturati
  inputSchema: z.object({
    score: z.number(),
    riskFactors: z.array(z.string()),
  }),
  execute: async ({ inputData, getInitData }) => {
    const { score, riskFactors } = inputData;
    
    // GOVERNANCE DETERMINISTICA
    // Se lo score è inferiore a 80, l'AI NON PUÒ approvare.
    // Non importa quanto il modello sia "convinto": il codice vince.
    // Tuttavia, lo score è calcolato dalla AI questo può esser cambiato per renderlo ancora più robusto (in base ai casi)
    if (score < 80) {
      return {
        status: "REJECTED_MANUAL_REVIEW",
        message: `Governance Alert: Score ${score}/100 too low. Risks: ${riskFactors.join(", ")}`,
        score,
        riskFactors,
      };
    }
    // Solo se il check passa, attiviamo l'agente di approvazione
    const approvalResponse = await approvalAgent.generate(
      `Request is compliant (Score: ${score}). Generate approval.`
    );
    return {
      status: "APPROVED",
      message: approvalResponse.text,
      score,
      riskFactors,
    };
  },
});

Perché questo approccio è migliore?

Analizzando il codice sopra e l'output della demo (trovate il file nel repository, link in fondo all'articolo), emergono alcune scelte proprie per uno sviluppo "tailor-made":

  1. Sicurezza dei tipi (Type Safety): Utilizzando zod, definiamo schemi rigidi. L'agente Compliance non può rispondere con un testo vago; è costretto a restituire un oggetto JSON con un numero (score) e un array di stringhe (riskFactors). Se non lo fa, il sistema genera un errore tecnico gestito, invece di una risposta allucinata all'utente.
  2. Logica deterministica: La condizione if (score < 80) è invalicabile. Questo garantisce che, indipendentemente dalla creatività del modello linguistico, le regole di business (Business Logic) vengano rispettate al 100%. Ovviamente nella demo questa validazione è semplice, ma può diventare molto complessa e robusta per evitare situazioni spaicevoli.
  3. Separazione delle responsabilità: L'agente che approva (approvalAgent) viene invocato solo se il semaforo è verde. Non ha nemmeno accesso alle pratiche scartate, riducendo il rischio di errori contestuali.

I risultati: Bad Request vs Formal Request

Eseguendo la demo, il sistema gestisce due scenari opposti con coerenza:

  • Scenario "Bad Request": Una richiesta informale e sospetta ("Guadagno 2M€ al mese ma voglio il bonus"). L'agente Compliance rileva incongruenze, assegna un punteggio basso e il workflow si blocca in stato REJECTED_MANUAL_REVIEW.
  • Scenario "Formal Request": Una PEC completa di dati e riferimenti normativi. Il punteggio supera la soglia e solo allora l'agente Approver genera la lettera ufficiale del Comune.

Un ecosistema solido

Usare gli agenti compositi non è una visione per il futuro, è ingegneria applicata disponibile e applicabile già da oggi. Il codice che abbiamo mostrato è una forte semplificazione, ma rappresenta il nucleo di come si possono costruire soluzioni che siano: solide, trasparenti e molto più robuste rispetto a un singolo "prompt" che si spera ben scritto.

Mettiamo a disposizione il codice di questo progetto su GitHub per chiunque voglia esplorare come Mastra AI possa abilitare una governance reale.

Se volete passare da sperimentazioni isolate a un'architettura AI governata, scalabile e sicura, siamo qui per disegnarla insieme a voi.

Per ulteriori informazioni si possono consultare le seguenti risorse:

Condividi l'articolo

Tag: Development, AI

Data di pubblicazione: 24 dicembre 2025

Ultima revisione: 24 dicembre 2025