Principi di responsible AI e conformità su residenza e movimento dei dati

Rivedere la soluzione: dai principi agli artefatti verificabili

Il Microsoft Responsible AI Standard non è una checklist di prodotto: è il documento che fissa i requisiti di policy che gli stessi team di ingegneria Microsoft seguono. La sua struttura chiede di Discover, Protect e Govern i rischi: scoprire i rischi di qualità, safety e sicurezza prima e dopo il rilascio, proteggere sia a livello di output del modello sia a livello di runtime dell’agente, governare con tracing, monitoraggio e integrazioni di conformità. Sopra ci stanno i pilastri responsible AI di Microsoft — fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability — che restano principi, non impostazioni configurabili.

Il lavoro dell’architetto è tradurre ogni principio in un artefatto che qualcuno possa leggere in un audit. Il Cloud Adoption Framework raccomanda di partire da un framework riconosciuto (i principi Microsoft, il NIST AI Risk Management Framework), di mappare i requisiti sulle policy aziendali già esistenti per data governance, security e risk management invece di creare un binario parallelo, e di incastrare i checkpoint responsible AI nei milestone di progetto già previsti: design review, fase di test, approvazione pre-lancio. Il Well-Architected Framework aggiunge la parte operativa: auditability delle attività dell’agente, role-based access control, e circuit breaker o escape hatch che permettano a un operatore umano di fermare un’esecuzione.

Qui va tenuta ferma una distinzione che l’esame usa spesso per costruire i distrattori. Responsible AI riguarda gli effetti sulle persone (equità, trasparenza, affidabilità). La security riguarda identità, rete, segreti, superficie d’attacco. La governance riguarda chi decide, chi approva e con quali policy. La compliance riguarda l’obbligo esterno che devi poter dimostrare. Sono quattro discipline che si intersecano, ma una domanda che chiede “quale controllo soddisfa il requisito di residenza” non si risolve con un content filter.

Un artefatto specifico da conoscere è la Transparency Note: il documento con cui Microsoft descrive capacità, usi previsti, limitazioni e considerazioni sulla scelta del caso d’uso di un servizio. Quella del Microsoft Foundry Agents service elenca esplicitamente gli scenari da evitare — impatti su status legale, credito, istruzione, lavoro, sanità, alloggio, assicurazioni — e i domini in cui le azioni sono irreversibili o altamente consequenziali. In revisione, la Transparency Note è il punto di partenza per dire se un caso d’uso è ammissibile prima ancora di discutere l’architettura.

L’evidenza cambia con la superficie di costruzione

Su Microsoft Foundry la revisione produce numeri. I risk and safety evaluators generati dal Foundry Evaluation service coprono hateful and unfairness, sexual, violence, self harm, protected materials, code vulnerability, ungrounded attributes e Indirect Attack (XPIA); per gli agenti esistono builtin.prohibited_actions e builtin.sensitive_data_leakage, entrambi in preview e supportati solo su target agent. L’AI Red Teaming Agent riusa gli stessi evaluator in scansioni automatiche. Attenzione a non confondere i tre piani: l’evaluation misura la qualità e il rischio su un dataset o su un target, il monitoring con tracce OpenTelemetry osserva ciò che succede in produzione, il testing verifica che il software faccia quello per cui è stato scritto. Un requisito di audit continuo non si soddisfa con una evaluation una tantum.

Sull’estensibilità di Microsoft 365 Copilot la revisione è in parte fatta dalla piattaforma: i controlli di RAI validation girano sui declarative agent durante la validazione del manifest — quando fai sideload o pubblichi — e durante l’elaborazione del prompt utente. Un agente che incoraggia azioni dannose, provoca conflitti, tenta di aggirare le linee guida o viola il copyright non si pubblica finché non correggi nome, descrizione e istruzioni. È un gate, non una raccomandazione: progettare come se la revisione fosse solo interna porta a scoprire il problema al momento della pubblicazione.

Terzo chiarimento lessicale: il content filter blocca contenuto in inferenza secondo severità configurate; l’abuse monitoring è un processo lato Microsoft che classifica pattern ricorrenti di uso potenzialmente abusivo e può portare a revisione automatica o umana e alla sospensione dell’accesso; il rilevamento di prompt injection indiretta è un rischio distinto, misurato dall’evaluator builtin.indirect_attack. Tre cose diverse, tre proprietari diversi.

La residenza è una proprietà della composizione, non una casella

La seconda firma è più insidiosa perché il dato archiviato e il dato elaborato seguono regole diverse. In Foundry Models, i dati at rest restano nella geography Azure designata, ma l’inferenza dipende dal deployment type: i tipi Global possono elaborare in qualsiasi region Azure, i tipi Data Zone solo dentro la data zone specificata (US, EU o APAC), i tipi a singola region nella region del deployment. Il tipo Developer, pensato per valutare modelli fine-tuned, non offre garanzie di data residency e ha vita di 24 ore. Non confondere il deployment type con il model router, che sceglie il modello: sono due decisioni indipendenti. Se la policy impone una zona, si vincola con Azure Policy sul valore di sku.name, non con una linea guida scritta.

Anche l’abuse monitoring incide: prompt e completion segnalati possono essere sottoposti a revisione, con eyes-on umano nei casi complessi; per i deployment nello Spazio economico europeo i dipendenti Microsoft autorizzati si trovano nello SEE. Se il caso d’uso tratta dati altamente sensibili, la leva architetturale è la richiesta di modified abuse monitoring, soggetta ai criteri di Limited Access.

Su Microsoft Copilot Studio e Power Platform la leva si chiama Move data across regions, un consenso che si dà per environment dal Power Platform admin center: attivarla significa accettare che input e output possano uscire dalla region verso la sede in cui la funzionalità generativa è ospitata. Tre dettagli che l’esame ama. Primo: il movimento di dati già avvenuto non si annulla deselezionando la casella. Secondo: dentro l’EU Data Boundary esiste Allow flex routing during periods of peak load, che consente inferenza LLM fuori dal confine nei picchi; toglierla mantiene l’inferenza dentro l’EUDB. Terzo: alcune funzionalità sfuggono comunque al perimetro — la Bing search è ospitata negli Stati Uniti per ogni region elencata, e le funzionalità basate su servizi Microsoft 365 archiviano i dati secondo i termini Microsoft 365, per esempio i dati storici di attività nella geography della mailbox Exchange dell’utente finale.

Uno scenario e ciò che l’esame verifica

Una banca europea vuole un agente di service con environment in Europa e un vincolo del CISO: nessuna inferenza LLM fuori dall’EU Data Boundary, nessuna eccezione nei picchi. La revisione firma se e solo se: flex routing disattivato, deployment Foundry di tipo Data Zone in EU e non Global, Azure Policy che vieta gli SKU globali, knowledge source rivista perché la ricerca Bing porterebbe elaborazione negli Stati Uniti, connettori verso sistemi non Microsoft trattati come responsabilità del maker, e Transparency Note letta per accertarsi che decisioni sul credito non finiscano in autonomia all’agente.

L’esame non chiede di ricordare la tabella delle region. Chiede di riconoscere che la residenza è una proprietà della composizione: cambia con il deployment type, con i tool e le knowledge source collegate, con il consenso al movimento dati e con i servizi Microsoft 365 coinvolti. La confusione tipica da evitare è credere che “i dati restano in Europa” sia una dichiarazione unica e verificabile in un punto solo; in una soluzione agentica va verificata separatamente per archiviazione, inferenza, grounding, telemetria e revisione degli abusi.