Red Hat ha creato asago – AI Safety And Governance Orchestration, una community open source che affronta uno dei passaggi più complessi nella gestione dell’intelligenza artificiale aziendale: tradurre policy interne, requisiti normativi e framework di rischio in test, controlli di sicurezza e configurazioni applicabili ai sistemi AI in produzione.
asago coordina strumenti e processi oggi separati, utilizzando le soluzioni già disponibili nell’ecosistema open source e sviluppando i componenti necessari per integrarle in un workflow comune. Il progetto è concepito come interoperabile e indipendente da specifici vendor AI o piattaforme cloud, con una governance affidata alla community.
Quando un’impresa porta in produzione un nuovo agente AI, una policy può stabilire quali informazioni l’agente possa trattare, quali azioni gli siano consentite e quali comportamenti siano inaccettabili. Queste regole devono essere trasformate in rischi formalizzati, scenari di test, mitigazioni e configurazioni tecniche, coinvolgendo compliance officer, team di sicurezza, sviluppatori e responsabili dell’infrastruttura.
asago automatizza e rende tracciabile questa catena, mantenendo il collegamento fra la clausola della policy da cui nasce un requisito, il rischio associato, il test utilizzato per verificarlo e il controllo applicato al sistema. L’automazione mantiene comunque gli operatori nel processo: ogni passaggio può essere esaminato, modificato o reindirizzato da una persona, lasciando quindi la supervisione delle decisioni nelle mani dell’organizzazione.
Il progetto arriva inoltre in una fase significativa per le imprese europee. L’AI Act si applica dal 2 agosto 2026, secondo un calendario progressivo che prevede date differenti per alcune disposizioni e categorie di sistemi. La trasformazione dei requisiti normativi e delle policy aziendali in controlli tecnici verificabili entra quindi direttamente nella gestione operativa dei sistemi AI.
Dalle policy ai test costruiti sullo specifico agente
L’ecosistema open source della sicurezza AI dispone già di strumenti per evaluation, red teaming, guardrail, sicurezza degli agenti e gestione del rischio. asago li inserisce in un processo comune che parte dalle regole adottate dall’organizzazione e arriva fino ai controlli applicati in produzione, senza duplicare framework esistenti.
La prima fase estrae dalle policy i rischi teorici e procede quindi al risk triaging, cioè alla selezione di quelli pertinenti allo specifico agente e, tra questi, dei rischi tecnici che possono essere effettivamente sottoposti a test.
Una policy può infatti coprire un insieme molto ampio di questioni organizzative, normative e tecniche, mentre un determinato agente ne incontra soltanto una parte. Gli scenari di valutazione possono così essere costruiti intorno ai rischi associati al caso d’uso, anziché dipendere esclusivamente da benchmark generici.
Il workflow definito da Red Hat prosegue generando scenari specifici per l’agente, eseguendo evaluation e red teaming e utilizzando i risultati per individuare guardrail o altre misure di mitigazione. Il sistema viene quindi sottoposto nuovamente agli stessi test, creando un ciclo iterativo fra valutazione e correzione.
Una mappa strutturata collega il linguaggio aziendale ai framework di rischio
Il Policy Mapper analizza policy aziendali scritte in linguaggio naturale e associa le prescrizioni contenute nei documenti a identificatori di rischio utilizzabili dagli altri strumenti.
Può elaborare documenti non strutturati come PDF, file Word e pagine HTML, suddividerli in porzioni di testo e individuare le corrispondenze con i rischi raccolti da AI Risk Atlas Nexus, progetto open source che mette in relazione differenti tassonomie e framework per la sicurezza e la governance dell’AI.
La pipeline combina ricerca per parole chiave e ricerca semantica, seguite da ulteriori passaggi di selezione e verifica. Per ogni rischio identificato conserva inoltre i passaggi del documento che costituiscono l’evidenza dell’associazione e un confidence score, così che i mapping meno sicuri possano essere sottoposti a revisione umana.
Le corrispondenze permettono di collegare lo stesso rischio a classificazioni differenti, tra cui NIST AI Risk Management Framework, OWASP Top 10 for LLM Applications, OWASP Agentic Security Initiative e AILuminate. Una prescrizione espressa nel linguaggio interno dell’azienda viene così ricondotta a categorie condivise che possono essere utilizzate nei passaggi successivi di valutazione.
Il Policy Mapper comprende anche mapping verso azioni di mitigazione associate ad alcuni rischi, classificandole come tecniche, operative o di governance. Il passaggio dalla lettura della policy alla scelta dei controlli può quindi sfruttare una rappresentazione strutturata comune.
Gli scenari trasformano il rischio in una condizione da verificare
Una volta selezionati i rischi pertinenti, asago prevede la generazione di scenari specifici per l’agente da valutare. Lo Scenario Generator considera le caratteristiche dell’applicazione insieme al rischio individuato e determina quali condizioni e quale contesto siano necessari per verificarne il comportamento.
Gli scenari rimangono indipendenti dal particolare framework di evaluation e vengono successivamente trasformati negli artefatti richiesti dagli strumenti scelti per il test. Questo permette alla stessa descrizione del rischio di alimentare tecnologie differenti.
Gli artefatti vengono quindi eseguiti attraverso EvalHub sui framework di evaluation e red teaming pertinenti, utilizzando dataset e ambienti generati sinteticamente per ricreare le condizioni previste dagli scenari.
I risultati confluiscono in un Recommender, che propone possibili misure correttive. I guardrail costituiscono uno dei primi tipi di intervento previsti, insieme ad altre modifiche della configurazione che potranno interessare progressivamente differenti livelli dello stack.
Midojo verifica gli agenti esposti a prompt injection indirette
Un altro componente sviluppato dalla community, Midojo, è dedicato alla sicurezza degli agenti AI e in particolare alle indirect prompt injection.
In questo tipo di attacco, le istruzioni malevole non vengono fornite direttamente dall’utente, ma sono inserite nei dati che l’agente consulta mentre svolge il proprio compito. Possono trovarsi, per esempio, in una pagina web o in un documento apparentemente normale.
Midojo colloca un ambiente controllato e strumenti simulati fra l’agente e le risorse con cui dovrebbe interagire. I payload malevoli vengono inseriti nei dati utilizzati durante il test, mentre il framework osserva sia la capacità dell’agente di completare il compito sia la sua resistenza all’iniezione.
La verifica riguarda quindi ciò che l’agente fa quando incontra informazioni ostili durante un’attività legittima. È un aspetto particolarmente importante nei sistemi agentici, dove il modello può accedere a dati e applicazioni e utilizzare strumenti per compiere azioni.
I controlli entrano nei workflow DevOps e GitOps
Il passaggio finale porta le mitigazioni nell’ambiente di produzione. I controlli raccomandati vengono trasformati in configurazioni dichiarative distribuibili sull’infrastruttura, evitando che la decisione presa durante la valutazione debba essere reinterpretata manualmente dai platform engineer.
Red Hat indica Kubernetes Custom Resources e ConfigMap tra le modalità con cui questi componenti possono essere distribuiti e nuovamente sottoposti ai test. Il progetto contempla inoltre configurazioni per Kubernetes, Terraform e Ansible, così da mantenere gli stessi criteri di sicurezza su cloud differenti e ambienti on-premise.
Una misura di governance può così essere gestita attraverso meccanismi già comuni nei processi DevOps e GitOps: configurazioni versionate, revisioni, deployment automatizzati e tracciamento delle modifiche.
Questa continuità permette anche di costruire una traccia di audit end-to-end. Partendo da un controllo attivo nell’ambiente di produzione, diventa possibile risalire alla valutazione che ne ha motivato l’introduzione, al rischio sottoposto a test e alla clausola della policy da cui il processo era iniziato.
Una community aperta per un problema che cambia tra paesi e organizzazioni
asago nasce con licenza Apache 2.0 e una governance di community. Partecipano al progetto Red Hat, Alquimia AI, Brave Software, EvalEval coalition, IBM Research, Interdisciplinary Transformation University Austria, Microsoft, MIT Lincoln Laboratory, North Carolina State University, NVIDIA e The Alan Turing Institute.
La composizione eterogenea risponde anche alla natura del problema affrontato. Policy, regolamenti, lingue e condizioni di deployment cambiano tra organizzazioni e paesi: Red Hat considera quindi la rappresentanza geografica e linguistica una componente necessaria dello sviluppo della community, oggi avviata con partecipanti provenienti da Stati Uniti, Regno Unito ed Europa.
Il progetto prosegue inoltre il lavoro svolto da Red Hat e NVIDIA all’interno della Open Secure AI Alliance, ampliando l’attenzione dalla sicurezza dei singoli componenti alla relazione fra governance, valutazione e sistemi distribuiti.
Policy Mapper e Midojo permettono già a sviluppatori e ricercatori di iniziare a lavorare sui primi elementi del progetto, mentre la community costruirà progressivamente il workflow completo. Red Hat indica come riferimento una riduzione da mesi a giorni del percorso necessario per trasformare le policy in sistemi AI governati, attraverso la standardizzazione e l’automazione dei passaggi oggi manuali.
Per Steven Huels, vice president AI Engineering di Red Hat, “nel passaggio da progetti pilota di AI ad agenti autonomi duraturi, definire guardrail operativi diventa un requisito infrastrutturale critico per le organizzazioni”.
asago porta così la governance dentro il ciclo operativo dell’AI, collegando policy, rischio, test, mitigazione e controllo runtime in una catena verificabile, mantenendo al tempo stesso la possibilità di intervento umano e l’indipendenza dagli strumenti e dalle piattaforme utilizzate. “`
