L’AI responsabile in Microsoft Foundry è un insieme di componenti configurabili che fanno quattro cose diverse: filtrano il contenuto mentre passa, misurano il rischio su dataset o su traffico campionato, registrano cosa è successo, limitano ciò che un agente può fare da solo. Confonderli è l’errore più costoso in sede d’esame: filtro ed evaluator hanno nomi simili ma vivono in momenti diversi del ciclo di vita.

Il guardrail: rischio, punto di intervento, azione

Un guardrail è una collezione con un nome di controls, e ogni control è una tripletta: rischio da rilevare, punto in cui scansionarlo, azione da prendere. I punti di intervento sono quattro: user input, il prompt in arrivo; output, la risposta finale; tool call e tool response (preview), cioè ciò che l’agente manda a uno strumento e ciò che lo strumento restituisce, che valgono solo per gli agenti.

Le azioni sono due: Annotate, che si limita ad annotare, e Annotate and block. Sui modelli valgono entrambe; agli agenti si applica solo la seconda. Sui rischi di contenuto — odio, sessuale, autolesionismo, violenza — la soglia va da Low a High, e Low è la più restrittiva perché segnala anche la severità bassa. Non tutti i rischi valgono ovunque: groundedness detection e Spotlighting si applicano ai modelli ma non agli agenti, mentre user prompt attack, indirect attack, protected material, PII e task adherence coprono entrambi.

Due regole a memoria. Il guardrail predefinito dei modelli è Microsoft.DefaultV2, e un agente senza guardrail proprio eredita quello del suo deployment. E quando all’agente ne è assegnato uno, quello sovrascrive completamente il guardrail del modello: se il modello ha Violence su High e l’agente su Low senza control sui tool, l’agente scansiona input e output a Low e non scansiona affatto le chiamate agli strumenti.

Restano poi le API di Content Safety usate direttamente, utili per moderare contenuto che non passa da un modello: la scala che restituiscono è numerica da 0 a 7, non Low/Medium/High. Lì si aggiungono le blocklist personalizzate, con termini esatti o espressioni regolari.

Misurare invece di filtrare: evaluator e red teaming

Il filtro agisce a runtime sulla singola chiamata; l’evaluator gira su un dataset o su traffico registrato e produce un punteggio aggregabile. Rispondono a domande diverse: «questa risposta va bloccata?» contro «quanto spesso sbaglio?».

Gli evaluator di rischio e sicurezza sono builtin.violence, builtin.sexual, builtin.self_harm, builtin.hate_unfairness, builtin.protected_material, builtin.code_vulnerability, builtin.ungrounded_attributes, builtin.indirect_attack (solo modelli) e, in preview e solo per agenti, builtin.prohibited_actions e builtin.sensitive_data_leakage. I quattro evaluator di contenuto usano una scala 0-7 con soglia predefinita 3 — pari o sotto soglia è pass — mentre gli altri restituiscono pass o fail; a livello di sistema conta il defect rate aggregato. Girano su modelli ospitati dal servizio di valutazione, quindi non richiedono un deployment_name, a differenza degli evaluator LLM-as-judge.

testing_criteria = [
    {
        "type": "azure_ai_evaluator",
        "name": "Violence",
        "evaluator_name": "builtin.violence",
        "data_mapping": {"query": "{{item.query}}", "response": "{{item.response}}"},
    },
]

Le stesse valutazioni girano anche in continuo: una evaluation rule campiona il traffico a ogni risposta completata, con un tetto orario, mentre una valutazione schedulata rigira periodicamente un golden dataset. Per cercare i problemi invece di aspettarli c’è l’AI Red Teaming Agent, costruito su PyRIT e sugli stessi evaluator: attacca il sistema con strategie di offuscamento e tentativi multi-turno e riporta l’Attack Success Rate in una scorecard. Come avverte la transparency note, sono strumenti di misura, non certificati di conformità.

Tracciare: audit, provenienza e approvazioni

L’audit poggia sul tracing, disattivato per impostazione predefinita e attivabile collegando al progetto una risorsa Application Insights. Una traccia contiene input dell’utente, input e output di modello e agente, chiamate agli strumenti, passi intermedi e metadati di esecuzione: tempi, latenza, token, errori. Segue le convenzioni OpenTelemetry, quindi anche un agente che gira altrove può mandare telemetria nello stesso posto.

Le tracce contengono quindi dati personali e contenuto del cliente, con tre conseguenze: retention e costi ereditano la configurazione di Application Insights e Log Analytics; l’accesso si restringe con RBAC, perché serve un ruolo di lettura sui log; il contenuto sensibile va mascherato prima di essere scritto. Le operazioni amministrative si tracciano invece con la categoria di log Audit.

La provenienza è il terzo pezzo: il Content Provenance Detection verifica manifest C2PA firmati crittograficamente e un watermark invisibile, ma riconosce solo i contenuti generati da sistemi AI di Microsoft, e l’assenza di segnale non dimostra che un contenuto non sia generato. Gli approval workflow sono il punto in cui l’audit incontra il controllo: sui tool MCP si dichiara quali chiamate richiedono approvazione, e il pattern human-in-the-loop sospende l’agente in attesa di una decisione umana.

Governare l’agente: cosa può fare e con cosa

Un agente aggiunge due superfici che un modello non ha: gli strumenti e l’autonomia. Sugli strumenti si agisce su tre livelli. Sul contenuto valgono i control su tool call e tool response. Sull’accesso c’è il toolbox, che raggruppa i tool dietro un endpoint gestito con autenticazione, versionamento e governance centralizzati, fuori dal codice dell’agente. Sulla rete, un hosted agent può avere egress control che limitano le destinazioni raggiungibili in uscita, configurati nello stesso guardrail.

Sull’autonomia la scala va dall’agente che agisce da solo a quello che si ferma prima di ogni azione irreversibile, e la posizione dipende dal costo dell’errore: lettura e sintesi possono essere autonome, scrittura su sistemi di record no. Che il confine regga lo dicono gli evaluator agentici e il versionamento dell’agente, che permette di confrontare due versioni prima di promuoverne una.

Da ricordare per l’esame

  • Un guardrail è una collezione di controls: rischio, punto di intervento, azione. Tool call e tool response esistono solo per gli agenti, ai quali si applica solo Annotate and block.
  • Il guardrail dell’agente sovrascrive quello del modello; senza guardrail proprio l’agente eredita quello del deployment. Il predefinito è Microsoft.DefaultV2.
  • Filtro contro evaluator: il primo agisce a runtime sulla singola richiesta, il secondo misura su dataset o traffico campionato e produce un defect rate.
  • Gli evaluator di sicurezza usano la scala 0-7 con soglia 3 e non richiedono un deployment_name; prohibited_actions e sensitive_data_leakage sono solo per agenti, indirect_attack solo per modelli.
  • Il tracing è off by default e si accende collegando Application Insights; la provenance C2PA riconosce solo contenuti generati da AI Microsoft, e la sua assenza non prova nulla.