L'approvvigionamento enterprise di AI nel 2024 aveva un'impostazione predefinita: cloud-first. A metà 2026 l'impostazione si è invertita. Gli obblighi del deployer previsti dall'EU AI Act, la direzione per le infrastrutture critiche del NIST e il toolkit politico dell'OCSE hanno spostato la decisione architetturale prima di quella sul fornitore. Residency-first — mantenere il contenuto di inferenza dove il deployer già gestisce tutto il resto — è il nuovo standard. Il cambiamento ha richiesto 24 mesi.

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

L'era cloud-first e cosa ha funzionato

Nel corso del 2023 e fino all'inizio del 2024, l'acquisto enterprise di AI ha seguito il modello più ampio del software cloud. Un fornitore offriva un'API gestita per LLM, il deployer si integrava con essa, l'inferenza avveniva sull'infrastruttura del fornitore e il team di compliance del deployer accettava le certificazioni del fornitore (SOC 2, ISO 27001, DPA conforme al GDPR) come prova sufficiente. Era semplice da procurare, veloce da valutare e ben allineato a come le imprese avevano acquistato SaaS nel decennio precedente.

Il sondaggio enterprise di a16z di marzo 2024 ha catturato il momento finale del cloud-first: il 72% delle imprese usava un'API per accedere al proprio modello, oltre la metà utilizzava il modello ospitato dal proprio provider cloud e "gli accordi che prima richiedevano oltre un anno per chiudersi ora vengono conclusi in 2 o 3 mesi" per prodotti che soddisfano i nuovi requisiti [3]. Anche a metà 2024 i nuovi requisiti stavano già iniziando a influenzare la curva degli accordi.

Cosa è cambiato

L'EU AI Act è entrato in vigore nell'agosto 2024. Le pratiche AI proibite sono diventate efficaci il 2 febbraio 2025, gli obblighi di governance e GPAI il 2 agosto 2025, gli obblighi di trasparenza sono previsti per agosto 2026 e gli obblighi per i deployer ad alto rischio che rimodellano l'architettura degli approvvigionamenti si applicano dal 2 dicembre 2027 [1]. L'accordo politico omnibus del 7 maggio 2026 ha riconfermato la scadenza del 2 dicembre 2027 e ha aggiunto nuove proibizioni [2], eliminando ogni speranza per i team di approvvigionamento che la scadenza potesse slittare.

Il Regolamento distingue tra fornitore e deployer di un sistema AI. Gli obblighi del deployer includono supervisione umana, monitoraggio, conservazione dei log e dimostrazione di queste capacità su richiesta [1]. Cruciale è che l'obbligo ricade sul deployer — la banca, l'ospedale, l'agenzia — non sul fornitore di LLM.

Questo singolo fatto legale ha ribaltato l'architettura. Un obbligo del deployer non può essere soddisfatto da una certificazione del fornitore. L'approvvigionamento cloud-first assumeva che le certificazioni del fornitore fossero un proxy per la postura di conformità del deployer. L'approvvigionamento residency-first è ciò che il deployer fa quando questa assunzione non regge più.

I segnali che lo hanno confermato

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

Profilo infrastrutture critiche NIST AI RMF, 7 aprile 2026. [4] La prima definizione federale USA degli obblighi del deployer AI RMF per gli operatori di infrastrutture critiche. Fase di concept-note, non finalizzata, ma la direzione è inequivocabile: gli appalti federali USA si stanno orientando verso lo stesso inquadramento degli obblighi del deployer che l’UE ha codificato.

Toolkit di politica AI OCSE, 3 giugno 2026. [5] Linguaggio OCSE per “i principi sono definiti; il collo di bottiglia è l’implementazione”. L’inquadramento del Toolkit corrisponde abbastanza da vicino alla traiettoria UE e USA, tanto che un’impresa multinazionale che progetta una volta per la giurisdizione più severa ora soddisfa tutte le altre.

Compressione del ciclo di trattative a16z in corso. Il sondaggio 2024 [3] ha colto la forma iniziale; nel 2026 i prodotti che rispettano i requisiti degli obblighi del deployer superano le gare d’appalto in settimane, mentre quelli che non li rispettano impiegano ancora un anno o più. Il segnale di mercato è la velocità stessa della decisione di acquisto.

Aspetto architetturale di residency-first

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

  1. Inferenza locale al deployer. Sia sul dispositivo dell’utente sia su un server gestito dal deployer. Prompt e risposte non lasciano mai il perimetro del deployer.
  2. Log di audit privi di contenuto di proprietà del deployer. Ogni azione amministrativa è registrata con timestamp e attore nel SIEM del deployer. Nessun prompt o risposta nella riga di audit; la riga è la prova, il contenuto è da conservare a cura del deployer.
  3. Identità tramite IdP del deployer. OIDC contro Microsoft Entra ID o Google Workspace; i controlli di accesso esistenti si applicano senza modifiche.
  4. Nessun tenant di inferenza gestito dal fornitore. Il fornitore non gestisce il runtime del modello né riceve contenuti di inferenza su questo percorso. Servizi di licensing, identità, policy, fleet, uso aggregato e supporto possono comunque essere gestiti dal fornitore e devono essere inclusi nella revisione del flusso dati e della disponibilità.

Le API LLM cloud possono implementare con sforzo le proprietà 1–3. La proprietà 4 è la distinzione architetturale: gestire il runtime di inferenza è ciò che le rende un’API LLM cloud. Residency-first non significa che ogni record del piano di controllo sia locale, quindi gli acquirenti devono valutare separatamente quei servizi residui.

Cosa significa questo per un’impresa che acquista AI nel 2026

Tre implicazioni concrete.

Primo, i questionari per i fornitori devono essere riformulati. 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 descritte. I team di approvvigionamento che non hanno ancora riscritto il loro modello sono quelli che segnalano cicli di acquisto bloccati — vedi Perché i deployment AI on-premise si bloccano negli approvvigionamenti per il quadro completo.

Secondo, la giurisdizione più rigorosa determina l'architettura. Un deployer multinazionale che progetta in conformità agli obblighi del Regolamento AI UE del 2 dicembre 2027 [1] non fallirà i requisiti di USA, Regno Unito, Giappone o Singapore — vedi l'articolo Conformità al Regolamento AI UE per la mappatura per obbligo. La convergenza tra giurisdizioni documentata dall'OECD Toolkit [5] è ciò che rende un'architettura valida.

Terzo, la matematica del ciclo di approvvigionamento è cambiata. I prodotti che rispettano la priorità di residenza si chiudono in 2–3 mesi; quelli che non la rispettano impiegano 12+ [3]. Le aziende che acquistano AI nel 2026 dovrebbero valutare l'idoneità architetturale prima del costo per postazione — un ritardo di approvvigionamento di 9 mesi è più costoso di qualsiasi differenziale per postazione.

Riferimenti

  1. Commissione Europea. "Regolamento AI — Quadro normativo sull'AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Accesso 22-07-2026.
  2. Commissione Europea. "Accordo politico omnibus sul Regolamento AI, 7 maggio 2026." https://digital-strategy.ec.europa.eu/. Accesso 22-07-2026.
  3. Andreessen Horowitz. "Stato dell'AI Generativa nelle Imprese." https://a16z.com/generative-ai-enterprise-2024/. Pubblicato 21 marzo 2024. Accesso 22-07-2026.
  4. NIST. "Framework di Gestione del Rischio AI." https://www.nist.gov/itl/ai-risk-management-framework. Accesso il 22-07-2026. Nota concettuale sulle Infrastrutture Critiche pubblicata il 7 aprile 2026.
  5. Osservatorio Politiche AI dell'OCSE. "Toolkit per le Politiche AI." https://oecd.ai/en/wonk. Accesso il 22-07-2026. Pubblicato il 3 giugno 2026.