Tendenze AI Pubblicato il 2026-07-22 · 7 min di lettura

Il passaggio dall'acquisto di AI enterprise cloud-first a quello data-residency-first

Il procurement di AI in azienda nel 2024 aveva un default: cloud-first. A metà 2026 il default si è ribaltato. Gli obblighi del deployer previsti dall'EU AI Act, l'indirizzo del NIST sulle infrastrutture critiche e il policy toolkit dell'OCSE hanno spostato la decisione architetturale prima della decisione sul fornitore. Residency-first — mantenere il contenuto dell'inferenza dove il deployer gestisce già tutto il resto — è il nuovo default. Il passaggio ha richiesto 24 mesi.

Questo articolo traccia i segnali e cosa significhino per un'azienda che acquista AI nel 2026.

L'era cloud-first e cosa ha funzionato

Per tutto il 2023 e fino agli inizi del 2024, l'acquisto di AI in azienda seguiva lo schema più ampio del software cloud. Un fornitore offriva un'API LLM gestita, il deployer ci si integrava, l'inferenza avveniva sull'infrastruttura del fornitore e il team di compliance del deployer accettava le certificazioni del fornitore (SOC 2, ISO 27001, DPA allineato al GDPR) come evidenza sufficiente. Era semplice da acquistare, rapido da valutare e ben adattato al modo in cui le aziende avevano comprato SaaS nel decennio precedente.

Il sondaggio enterprise di a16z del marzo 2024 ha catturato il momento del tardo cloud-first: il 72% delle aziende utilizzava un'API per accedere al proprio modello, oltre la metà utilizzava il modello ospitato dal proprio cloud-service provider e "le trattative che impiegavano oltre un anno per chiudersi vengono spinte a 2 o 3 mesi" per i prodotti che soddisfano i nuovi requisiti ^[3]. Già a metà 2024 i nuovi requisiti stavano iniziando a piegare la curva delle trattative.

Cosa si è rotto

L'EU AI Act è entrato in vigore in agosto 2024. Le pratiche di AI vietate sono diventate efficaci il 2 febbraio 2025, gli obblighi sulla governance e sui GPAI il 2 agosto 2025, gli obblighi di trasparenza sono attesi per agosto 2026 e gli obblighi del deployer per i sistemi ad alto rischio, che ridisegnano l'architettura di procurement, si applicano dal 2 dicembre 2027 ^[1]. L'accordo politico omnibus del 7 maggio 2026 ha riconfermato il traguardo del 2 dicembre 2027 e ha aggiunto nuovi divieti ^[2], rimuovendo qualsiasi speranza dei team di procurement di uno slittamento della scadenza.

L'Act distingue tra il provider e il deployer di un sistema di AI. Gli obblighi del deployer comprendono supervisione umana, monitoraggio, retention dei log e dimostrazione di tali capacità su richiesta ^[1]. In modo cruciale, l'obbligo è in capo al deployer — la banca, l'ospedale, l'agenzia — non al fornitore dell'LLM.

Quel singolo fatto giuridico è ciò che ha ribaltato l'architettura. Un obbligo del deployer non può essere soddisfatto da una certificazione del fornitore. Il procurement cloud-first presumeva che le certificazioni del fornitore fossero un proxy per la postura di compliance del deployer. Il procurement residency-first è ciò che il deployer fa quando quel presupposto non regge più.

I segnali che hanno confermato il passaggio

Tre segnali nel 2026 hanno confermato il residency-first come direzione cross-giurisdizionale, non come peculiarità europea.

Profilo NIST AI RMF Critical Infrastructure, 7 aprile 2026. ^[4] Il primo inquadramento federale statunitense degli obblighi del deployer secondo l'AI RMF per gli operatori di infrastrutture critiche. Allo stadio di concept note, non finalizzato, ma la direzione è inequivocabile: il procurement federale statunitense si sta muovendo verso lo stesso inquadramento degli obblighi del deployer che l'UE ha codificato.

AI Policy Toolkit OCSE, 3 giugno 2026. ^[5] Linguaggio OCSE per "i principi sono assestati; il collo di bottiglia è l'implementazione". L'inquadramento del Toolkit corrisponde alla traiettoria di UE e USA in modo abbastanza stretto da consentire a un'azienda multinazionale che progetti una sola volta per la giurisdizione più rigorosa di soddisfare anche le altre.

Compressione continua dei cicli di trattativa secondo a16z. Il sondaggio del 2024 ^[3] ha colto la forma iniziale; entro il 2026 i prodotti che soddisfano i requisiti degli obblighi del deployer superano il procurement in poche settimane, mentre i prodotti che non lo fanno continuano a richiedere un anno o più. Il segnale di mercato è la velocità stessa della decisione di procurement.

Come appare il residency-first dal punto di vista architetturale

L'architettura su cui convergono i segnali ha quattro proprietà:

Inferenza locale al deployer. Sul dispositivo dell'utente o su un server gestito dal deployer. Prompt e risposte non lasciano mai il perimetro del deployer.
Log di audit privi di contenuto e di proprietà del deployer. Ogni azione amministrativa registrata con timestamp e autore, nel SIEM del deployer. Nessun prompt o risposta nella riga di audit; la riga è l'evidenza, il contenuto è del deployer e va conservato.
Identità tramite l'IdP del deployer. OIDC verso Microsoft Entra ID o Google Workspace; i controlli di accesso esistenti si applicano invariati.
Nessun tenant lato fornitore. Il fornitore non gestisce il runtime, non vede i dati, non è un point of failure per la postura di compliance.

Le API LLM cloud possono implementare le proprietà 1–3 con sforzo. La proprietà 4 strutturalmente non possono — gestire il runtime è ciò che le rende API LLM cloud. Il residency-first tratta questo come un vincolo architetturale, non come un criterio di selezione del fornitore.

Cosa significa per un'azienda che acquista AI nel 2026

Tre implicazioni concrete.

Primo, i questionari per i fornitori vanno ridisegnati. Le domande che un deployer poneva nel 2024 riguardavano le certificazioni del fornitore. Le domande che un deployer pone nel 2026 riguardano le proprietà dell'architettura di deployment sopra elencate. I team di procurement che non hanno ancora riscritto il proprio template sono quelli che segnalano cicli di acquisto bloccati — vedi Perché i deployment di AI on-prem si bloccano in fase di procurement per lo schema completo.

Secondo, la giurisdizione più rigorosa fissa l'architettura. Un deployer multinazionale che progetti rispetto agli obblighi dell'EU AI Act del 2 dicembre 2027 ^[1] non mancherà i requisiti statunitensi, britannici, giapponesi o singaporiani — vedi l'articolo sulla conformità all'EU AI Act per la mappatura obbligo per obbligo. La convergenza cross-giurisdizione che il Toolkit OCSE ^[5] documenta è ciò che rende viabile un'unica architettura.

Terzo, la matematica dei cicli di procurement è cambiata. I prodotti che soddisfano il residency-first chiudono in 2–3 mesi; quelli che non lo fanno richiedono 12+ mesi ^[3]. Le aziende che acquistano AI nel 2026 dovrebbero valutare l'aderenza architetturale prima del costo per posto — un ritardo di procurement di 9 mesi è più costoso di qualsiasi differenziale per posto.

Riferimenti

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Consultato il 2026-07-22.
European Commission. "AI Act omnibus political agreement, 7 May 2026." digital-strategy.ec.europa.eu. Consultato il 2026-07-22.
Andreessen Horowitz. "State of Generative AI in the Enterprise." a16z.com/generative-ai-enterprise-2024. Pubblicato il 21 marzo 2024. Consultato il 2026-07-22.
NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-07-22. Concept note Critical Infrastructure pubblicata il 7 aprile 2026.
OECD AI Policy Observatory. "AI Policy Toolkit." oecd.ai/en/wonk. Consultato il 2026-07-22. Pubblicato il 3 giugno 2026.

Percorri il cambiamento architetturale attraverso un carico di lavoro reale.

Distribuire la piattaforma nel tuo ambiente mette le quattro proprietà residency-first — inferenza, audit, identità, nessun tenant del fornitore — dove puoi metterle alla prova, con il team di compliance che scrive il memo sugli obblighi del deployer a partire dai propri log.

Parlaci di AI on-prem