AWS Bedrock: la checklist compliance da fare prima di adottarlo

AWS Bedrock è un'alternativa all'inferenza diretta sui server dei singoli vendor di modelli: invece di firmare un contratto a parte con ciascun provider, si accede a più modelli di terzi — Anthropic, Meta, Amazon Titan e altri — sotto un'unica interfaccia AWS. Ma l'unica interfaccia non elimina i caveat contrattuali, li sposta: Bedrock non è un modello, è uno scaffale, e prima di firmare un team legal deve aver già letto almeno due documenti che non sono il DPA di AWS.

Cos'è Bedrock, e perché questo cambia la due-diligence

Bedrock come layer multi-modello

Chi valuta un tool AI di solito verifica un fornitore e un contratto. Con Bedrock non basta: ogni modello abilitato in Bedrock porta con sé un provider terzo, con termini propri. Il DPA firmato con AWS copre l'infrastruttura — non sostituisce i termini del model provider usato in quella specifica chiamata.

Perché i termini "si sommano": AWS + model provider terzo

Non è un dettaglio implicito: è scritto nei Service Terms di AWS. La sezione 50.12.1 definisce i modelli di terzi come "Third-Party Content" e subordina l'uso all'accettazione dei relativi termini. La sezione 50.16, dedicata a "Claude Platform on AWS", è ancora più esplicita: l'uso di Claude su AWS è soggetto ai Commercial Terms of Service di Anthropic, al suo Data Processing Addendum e alla sua Usage Policy — oltre, ovviamente, ai termini AWS. Dal lato Anthropic, i Commercial Terms of Service (in vigore dal 17 giugno 2025) confermano che i dati sono trattati secondo il DPA Anthropic, incorporato per riferimento — ma non citano AWS o Bedrock nel testo contrattuale: il collegamento esplicito è stabilito dai termini AWS, non da quelli Anthropic. Per questo la verifica va fatta su entrambe le fonti, non su una sola.

Il DPA con AWS: cosa verificare

Ambito del Data Processing Addendum e ruoli controller/processor

Il DPA di AWS è incorporato nei Service Terms (sezione 1.14.4) e copre il trattamento dei dati sull'infrastruttura AWS. Un punto spesso sottovalutato: secondo la pagina GDPR Center di AWS, "AWS acts as both a data processor and a data controller under the GDPR" — il ruolo non è unico e fisso, dipende dal trattamento specifico. Prima di procurement, va chiarito per iscritto quale ruolo assume AWS per ciascun flusso di dati che passa da Bedrock, non presunto in automatico come "processor".

Base giuridica GDPR e finalità del trattamento dichiarate

Il GDPR Center di AWS è il punto di partenza per capire come AWS descrive il proprio ruolo e le proprie responsabilità — ma resta un documento generico AWS, non specifico di Bedrock. Chi valuta il servizio deve chiedere esplicitamente ad AWS come si applica al caso d'uso concreto: quali dati transitano, con quale finalità, e su quale base giuridica si fonda il trattamento lato cliente.

I termini del model provider: il livello che si aggiunge

Esempio: termini Anthropic via AWS Marketplace

Anthropic è un caso utile perché è documentato su entrambi i lati. Un dato tecnico rilevante, verificato sulla documentazione Bedrock: i model provider terzi non hanno accesso ai prompt e alle completions dei clienti. AWS gestisce ogni provider tramite un "Model Deployment Account" dedicato, uno per provider per region, di proprietà e sotto il controllo del team Bedrock — i provider non vi accedono. È una garanzia tecnica utile, ma non sostituisce la verifica contrattuale dei termini specifici del provider.

Domande da porre prima di abilitare un modello in produzione

Prima di attivare un modello su Bedrock in produzione: chi sono i model provider effettivamente coinvolti nella pipeline (anche se il codice chiama solo "Bedrock")? Sono stati letti i loro termini specifici, non solo quelli AWS? Esiste un DPA anche lato model provider, o solo lato AWS? Cosa succede ai log e ai dati in caso di disabilitazione del modello?

Dove vivono davvero i dati: region EU e cross-region inference

Region disponibili in EU per Bedrock

Oggi Bedrock è disponibile in sei region europee che sono effettivamente nell'Unione: Francoforte (eu-central-1), Irlanda (eu-west-1), Milano (eu-south-1), Parigi (eu-west-3), Spagna (eu-south-2) e Stoccolma (eu-north-1). Attenzione a un dettaglio che genera confusione: AWS elenca anche Londra (eu-west-2) e Zurigo (eu-central-2) sotto l'etichetta "Europe" — ma Regno Unito e Svizzera non sono Stati UE. Se il requisito interno è "region UE", queste due vanno escluse esplicitamente in fase di configurazione.

Il rischio silenzioso del cross-region inference

Bedrock offre due modalità di cross-region inference: Geographic, che vincola l'instradamento all'interno di un perimetro geografico scelto (per esempio l'UE), e Global, che instrada ovunque nel mondo con un risparmio di circa il 10%. Per requisiti di data residency, AWS raccomanda esplicitamente il profilo Geographic. Un'attenuante tecnica: i dati trasmessi in cross-region restano sulla rete AWS, non attraversano internet pubblico, e sono cifrati in transito; ogni richiesta cross-region è tracciata in CloudTrail con la region di inferenza effettiva. Ma il punto resta: senza una scelta esplicita del profilo Geographic, l'elaborazione può uscire dalla region selezionata — non è un comportamento di default da dare per scontato.

EU AI Act: il ruolo di Bedrock come infrastruttura

Perché Bedrock non è "il modello" ai fini della classificazione — e cosa resta comunque in capo a chi lo usa

L'articolo 3 del Regolamento UE 2024/1689 definisce "provider" chi sviluppa un sistema AI o un modello general-purpose e lo immette sul mercato con il proprio nome, e "deployer" chi usa un sistema AI sotto la propria autorità. La definizione più pertinente per chi costruisce su Bedrock è probabilmente quella di "downstream provider": un provider che integra un modello AI fornito da un'altra entità in base a un rapporto contrattuale. Il testo dell'Art. 3 non contiene una categoria esplicita "infrastructure provider" o un riferimento diretto a servizi "AI-as-a-service": il ruolo di chi usa Bedrock va quindi argomentato caso per caso — spesso deployer, talvolta downstream provider a seconda di cosa si costruisce sopra — non dedotto da una citazione diretta del regolamento su questo punto specifico.

Checklist pratica: le domande da portare in procurement

• Quale ruolo assume AWS (controller o processor) per ciascun trattamento che passa da Bedrock?
• I termini di ogni model provider abilitato sono stati letti separatamente dal DPA AWS?
• La region configurata è effettivamente UE (esclusi Londra e Zurigo)?
• Il cross-region inference è impostato su profilo Geographic, se serve vincolare i dati all'UE?
• Dove vengono conservati log, prompt e completions, e per quanto tempo?
• Il proprio ruolo ai fini dell'EU AI Act (deployer o downstream provider) è stato definito per il caso d'uso specifico?

Conclusione

Bedrock non è un solo contratto da firmare: è un DPA AWS più, per ogni modello attivato, i termini di un provider terzo che non spariscono solo perché la chiamata passa da un'unica API. La due-diligence corretta non è più lenta di quella su un singolo vendor — è solo distribuita su due o più fonti. Prima del prossimo procurement Bedrock, verifica ruoli, region e termini del model provider con lo stesso rigore: è un lavoro di un pomeriggio, molto meno costoso di scoprirlo dopo.

Fonti

• AWS Service Terms, sezioni 50.12.1 e 50.16 ("Claude Platform on AWS"); sezione 1.14.4 per il Data Processing Addendum.
• Anthropic, Commercial Terms of Service, in vigore dal 17 giugno 2025.
• AWS GDPR Center.
• AWS, "Data protection in Amazon Bedrock" (Model Deployment Account).
• AWS, "Cross-Region inference in Amazon Bedrock".
• AWS, "Amazon Bedrock endpoints and quotas" (region disponibili).
• Regolamento (UE) 2024/1689 (EU AI Act), art. 3, definizioni.