I principi di Responsible AI in Azure
Microsoft struttura il proprio approccio all’AI responsabile su sei principi: Fairness (equità, no bias sistematici), Reliability & Safety (comportamento affidabile e sicuro anche in condizioni impreviste), Privacy & Security, Inclusiveness, Transparency (spiegabilità, note di trasparenza, model cards) e Accountability (governance umana e supervisione). In sede d’esame questi principi non sono teoria astratta: si traducono in controlli concreti che devi saper collocare. La regola pratica è che ogni deployment di modello generativo passa per una pipeline di content moderation, e il tuo compito da architetto è scegliere dove e come applicarla.
Filtri di contenuto integrati in Azure OpenAI
Ogni deployment di Azure OpenAI (in Azure AI Foundry) è protetto di default da un content filter che ispeziona sia il prompt in ingresso sia la completion in uscita. Le categorie coperte sono quattro: hate, violence, sexual, self-harm, ciascuna con livelli di severità (safe, low, medium, high). Per default viene bloccato tutto ciò che è medium o high; puoi creare una content filter configuration personalizzata per alzare o abbassare le soglie per categoria (richiede approvazione per i livelli più permissivi).
Oltre alle categorie, i filtri integrati offrono:
- Blocklist custom (oltre a quelle predefinite tipo profanity) per bloccare termini o pattern specifici.
- Prompt Shields integrati contro jailbreak e prompt injection.
- Protected material detection per testo e codice (evita output che riproducono materiale protetto o codice da repository pubblici noti).
Concettualmente: i filtri integrati sono la prima linea, legata al singolo deployment, con severità configurabili e blocklist.
Azure AI Content Safety come servizio standalone
Azure AI Content Safety è un servizio a sé che puoi invocare da qualsiasi applicazione, anche quando il modello non è Azure OpenAI (es. contenuti generati dagli utenti, immagini caricate, un modello open source ospitato altrove). Espone API dedicate:
- Analyze Text e Analyze Image: restituiscono un livello di severità per categoria, utile per moderare contenuti user-generated prima di mostrarli o archiviarli.
- Prompt Shields: analizzano l’input e rilevano sia user prompt attacks (jailbreak diretti, es. “ignora le istruzioni precedenti”) sia document attacks (indirect prompt injection, istruzioni malevole nascoste in documenti/pagine web che il modello ingerisce via RAG).
- Groundedness detection: verifica l’output del modello confrontandolo con le fonti fornite, per individuare affermazioni non ancorate ai dati (allucinazioni).
- Custom categories e Protected material detection.
La distinzione chiave da fissare: Prompt Shields = protezione dell’input; Groundedness detection = verifica dell’output. Sono controlli complementari, non intercambiabili.
Monitoraggio e controllo dei costi
Per la governance operativa colleghi la risorsa Azure AI a Azure Monitor tramite diagnostic settings, esportando log e metriche (richieste, latenza, token consumati, esiti dei filtri) verso Log Analytics; da lì costruisci query e alert. Sul fronte spesa, il controllo primario è la quota TPM (tokens-per-minute) assegnata al deployment: limita throughput e quindi costo, e va dimensionata per workload. Monitorare il consumo di token e impostare alert sui picchi è la strategia attesa per il cost management.
Trappole tipiche d’esame
- Scenario: devi moderare immagini caricate dagli utenti, non passa da alcun LLM → risposta: Azure AI Content Safety (Analyze Image) standalone, non i content filter di Azure OpenAI, che agiscono solo sui deployment di modelli OpenAI.
- Scenario: un’app RAG legge documenti esterni che potrebbero contenere istruzioni nascoste per dirottare il modello → risposta: Prompt Shields con rilevamento di document attacks (indirect prompt injection), non la groundedness detection.
- Scenario: il modello inventa dettagli non presenti nei dati aziendali forniti → risposta: Groundedness detection (verifica dell’output), non i Prompt Shields.
- Scenario: devi bloccare parole/frasi aziendali specifiche in aggiunta alle categorie standard → risposta: blocklist custom nella content filter configuration, non una nuova categoria di severità.
- Scenario: serve consentire contenuti a severità low per un caso d’uso clinico → risposta: creare una content filter configuration personalizzata alzando la soglia per categoria (con l’apposita approvazione), non disabilitare del tutto il filtro.
- Scenario: bisogna tracciare token e costi nel tempo con alert → risposta: diagnostic settings verso Log Analytics + Azure Monitor e gestione della quota TPM.