Vantaggi per il business Pubblicato il 2026-06-03 · 6 min di lettura

Perché i deployment di AI on-prem si bloccano in fase di procurement (e l'inquadramento che risolve il blocco)

Il procurement di AI in azienda si blocca sugli obblighi del deployer, non sulla tecnologia. Le proprietà dell'architettura di deployment che risolvono il blocco nel 2026, e perché "siamo SOC 2" è la risposta sbagliata alla domanda che i team di compliance pongono oggi.

Entro il 2 dicembre 2027, gli obblighi del deployer ai sensi dell'EU AI Act si applicano ai sistemi di AI ad alto rischio utilizzati in biometria, infrastrutture critiche, istruzione, lavoro, migrazione, asilo e controllo delle frontiere ^[1]. I team di compliance nel 2026 non aspettano dicembre 2027 per posizionarsi. Stanno già scrivendo questionari di due diligence per i fornitori, e il procurement di AI in azienda si sta bloccando su tali questionari a un ritmo che ha ben poco a che fare con la tecnologia oggetto dell'acquisto. La soluzione non è una demo migliore. È un riinquadramento di che cosa riguardi realmente la conversazione di procurement.

Come appare effettivamente il "blocco" nel 2026

Il proof-of-concept tecnico viene superato. Il modello produce output utili sul carico di lavoro del cliente. Il valutatore tecnico scrive una nota positiva e consegna il dossier al procurement. Poi il dossier resta fermo. Tre settimane dopo, il team di compliance del cliente torna con un memo: "Non possiamo dimostrare i nostri obblighi di deployer su questo workflow se l'inferenza avviene su un endpoint che non controlliamo".

Il sondaggio enterprise di a16z ha individuato la forma di questo schema mentre stava prendendo piede: cicli di trattativa che "in passato richiedevano oltre un anno per chiudersi vengono spinti a 2 o 3 mesi" per prodotti che soddisfano i nuovi requisiti ^[4]. L'implicazione vale anche nel senso opposto. Il procurement di prodotti che non soddisfano i nuovi requisiti richiede ancora l'intero anno. Pilot tecnici solidi non cambiano questo dato.

Cosa il procurement deve effettivamente dimostrare

L'EU AI Act distingue tra il provider di un sistema di AI e il suo deployer ^[1]. Una banca che utilizza un'API LLM di terzi per valutare richieste di prestito è il deployer. Gli obblighi del deployer comprendono supervisione umana, monitoraggio, segnalazione degli incidenti e dimostrazione di tali capacità su richiesta. Questi obblighi si applicano alla banca, non al fornitore dell'LLM, e il team di procurement della banca è la superficie in cui la selezione del fornitore decide se gli obblighi siano praticabili.

Questa direzione non riguarda solo l'UE. Il NIST ha pubblicato una concept note per un AI RMF Profile sull'AI affidabile nelle infrastrutture critiche il 7 aprile 2026 ^[2], il primo inquadramento federale degli obblighi del deployer secondo l'AI RMF per gli operatori di infrastrutture critiche negli Stati Uniti. L'OECD AI Policy Observatory mantiene un repository in continuo aggiornamento "da oltre 80 giurisdizioni e organizzazioni" ^[3]. La convergenza tra giurisdizioni sugli obblighi lato deployer è la tendenza, non un'eccezione.

I team di procurement nei settori regolamentati leggono questi segnali e si pre-posizionano. Non possono attendere il 2 dicembre 2027 per scoprire se l'architettura di un fornitore consentirà loro di soddisfare i propri obblighi.

Perché "siamo SOC 2" è la risposta sbagliata

La risposta sui controlli del fornitore che storicamente risolveva le conversazioni di procurement aziendale — SOC 2 Type II, ISO 27001, DPA allineato al GDPR — affronta i controlli lato fornitore. Sono necessari. Non sono sufficienti per gli obblighi del deployer che stanno entrando in vigore oggi.

Gli obblighi del deployer richiedono al deployer di dimostrare, su richiesta, quali dati siano transitati attraverso il sistema di AI. Questa è una domanda sui log del deployer stesso, non del fornitore. Un fornitore con SOC 2 in regola che conserva prompt e risposta in un cloud gestito non può colmare questo divario, perché il divario si trova sul lato del deployer rispetto al confine: il deployer non può produrre un log di qualcosa che non vede.

È questo il disallineamento strutturale che blocca la conversazione di procurement. Il team di compliance scrive un memo sugli obblighi del deployer. Il fornitore risponde con certificazioni lato fornitore. Le due navi si incrociano senza incontrarsi.

L'inquadramento che risolve il blocco

Tre proprietà dell'architettura di deployment, dichiarate apertamente nel questionario del fornitore, fanno crollare il blocco:

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 compare nella riga di audit. La riga è l'evidenza; il contenuto è del deployer, conservato secondo la propria policy di retention.
Identità tramite l'IdP del deployer. OIDC verso Microsoft Entra ID o Google Workspace. I controlli di accesso e le policy SSO esistenti del deployer si applicano invariati.

Non sono proprietà del fornitore da certificare. Sono proprietà dell'architettura di deployment da specificare. Una volta inquadrato il questionario del fornitore su queste basi, il memo di compliance si scrive da solo: ogni obbligo del deployer ha una proprietà architetturale corrispondente che il deployer può indicare.

Come appare nella forma con cui distribuiamo

AI Suite di Software Tailor viene distribuito come installer desktop che dialogano con un processo di inferenza locale. AI Admin Console è la superficie di gestione che il team IT del deployer utilizza per applicare policy, gestire licenze e rendere visibile l'audit. Sei clienti Fortune Global 500 nei settori farmaceutico, finanziario, pubblico, legale, della difesa e dell'energia hanno effettuato deployment su questa forma dal 2007 (clienti passati), e ognuno di questi incarichi è passato attraverso una versione dell'inquadramento di cui sopra prima della firma del contratto.

Il modo più rapido per renderlo concreto è percorrerlo su un carico di lavoro reale. Un pilot gratuito di 1 settimana mette il modello sull'hardware del cliente, la riga di audit nel SIEM del cliente e l'identità tramite l'IdP del cliente — quanto basta perché il team di compliance scriva il memo sugli obblighi che effettivamente lo riguardano.

Riferimenti

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Consultato il 2026-06-03.
NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-06-03. La concept note Critical Infrastructure è stata pubblicata il 7 aprile 2026.
OECD AI Policy Observatory. "Policy Navigator dashboards." oecd.ai/en/dashboards. Consultato il 2026-06-03.
Andreessen Horowitz. "State of Generative AI in the Enterprise." a16z.com/generative-ai-enterprise-2024. Pubblicato il 21 marzo 2024. Consultato il 2026-06-03.

Percorri un carico di lavoro reale attraverso l'inquadramento.

Un pilot gratuito di 1 settimana mette modello, riga di audit e identità all'interno del perimetro del cliente, e consente al team di compliance di scrivere il memo sugli obblighi che effettivamente lo riguardano.

Avvia un pilot gratuito di 1 settimana