AI Program Governance: Guida al Day-30 Go/No-Go Gate 2026

Se sei un Chief Procurement Officer, un category lead dell'ufficio del CFO o un buyer di Group Strategy che ha già pagato uno o due incarichi di consulenza AI conclusisi con una presentazione e poco altro, la domanda che ti stai ponendo oggi è strutturale, non vendor per vendor. La domanda è: quale meccanismo allinea davvero gli incentivi del partner di consulenza ai nostri risultati? La risposta è la AI program governance, e il meccanismo di governance più importante in assoluto è un day-30 go/no-go gate con clausola contrattuale di no-fee-for-Phase-II se la prova non è all'altezza dei criteri concordati. Questa guida spiega cos'è la AI program governance, perché la maggior parte dei programmi AI enterprise fallisce proprio su questo punto, i cinque meccanismi di governance che funzionano davvero, e il linguaggio contrattuale che le funzioni procurement possono inserire nel prossimo RFP trimestrale.

Cos'è davvero la AI Program Governance (e cosa non è)

L'espressione AI program governance viene utilizzata per indicare due cose completamente diverse, e questa sovrapposizione è costosa. Il primo significato — chiamiamolo "AI model governance" o semplicemente "AI governance" — copre etica, model risk, conformità all'EU AI Act, bias auditing, acceptable-use policy, data lineage e gli artefatti che il vostro General Counsel deve approvare. È importante. Ma non è ciò di cui parla questa guida.

Il secondo significato — quello operativo — riguarda la cadenza operativa, la struttura dei diritti decisionali e i termini commerciali risk-share che determinano se il programma produce davvero un risultato. Quella è AI program governance. Non è un documento di policy. È la risposta a quattro domande molto specifiche:

• Chi decide quando un'opportunità passa dalla discovery alla fase di build, e sulla base di quali evidenze?
• Chi gestisce l'escalation quando la BU A blocca la priorità della BU B, e verso chi, con quale tempistica?
• Chi paga, in quali tranche, contro quali proof point — e cosa succede se i proof point non vengono raggiunti?
• Chi è il responsabile dell'intelligence layer, della patterns library e della cadenza di aggiornamento dopo la fine dell'incarico?

I programmi con una solida documentazione di AI governance ma una debole AI program governance producono splendidi raccoglitori di policy da 90 pagine e zero automazioni rilasciate. I programmi con il mix opposto producono risultati concreti e poi inseriscono lo strato di policy in Phase III. Entrambi sono necessari. Non sono la stessa cosa, e la funzione procurement che li confonde acquista lo scope sbagliato.

Perché la maggior parte dei programmi AI fallisce sulla governance, non sulla tecnologia

Lo State of AI 2025 di McKinsey riporta che circa il 70% delle iniziative AI enterprise non raggiunge mai la produzione su scala significativa. L'Institute for Business Value di IBM colloca al 25% la quota di progetti che "raggiunge il ROI atteso" e al 16% quella che "scala a livello enterprise". Questi numeri non sono una condanna della tecnologia — i foundation model migliorano ogni sei mesi da tre anni. Sono una condanna della governance.

I pattern di fallimento sono notevolmente coerenti tra i diversi post-mortem:

• Nessun diritto decisionale. Lo steering committee si riunisce mensilmente, esamina lo stato, pone buone domande e non autorizza nulla. Il programma va alla deriva.
• Nessun percorso di escalation. La BU A vuole che il LLM customer-care sia addestrato sui propri dati; la BU B si rifiuta di condividerli. Non esiste un arbitro documentato. Il lavoro si blocca.
• Termini commerciali disallineati. Il fornitore viene pagato 40% all'inizio, 30% a metà percorso, 30% al "final deliverable acceptance". L'incentivo del fornitore è raggiungere i milestone, non produrre valore. La presentazione arriva nei tempi previsti e viene archiviata.
• Nessuna source attribution. Le raccomandazioni non possono essere ricondotte a specifiche interviste, segnali di telemetria o documenti. Quando un MD di BU mette in discussione una raccomandazione, il consulente fa riferimento ai "benchmark di settore". La raccomandazione muore.
• Nessun owner post-programma. L'incarico finisce. L'intelligence layer è un PDF. Sei mesi dopo, nessuno ricorda quali opportunità erano state prioritizzate o perché.

Ognuno di questi è un fallimento di AI program governance, non un fallimento tecnologico. Il modello funzionava. La struttura procurement no. È per questo che il ciclo RFP 2026 per l'AI enterprise sta spostandosi da "mostrateci l'accuratezza del vostro modello" a "mostrateci la vostra governance e i vostri termini risk-share".

I cinque meccanismi di governance che funzionano davvero

Negli incarichi AI enterprise che hanno effettivamente prodotto risultati — ovvero almeno due automazioni production-grade attive e misurate rispetto al baseline a 12 mesi dal kickoff — ricorrono cinque meccanismi. I programmi a cui manca uno di essi hanno un problema recuperabile. Quelli a cui ne mancano tre o più producono una presentazione e si fermano.

1. Executive sponsorship con reale autorità di budget

Lo sponsor deve essere il CFO, il COO o l'Office of the CEO — qualcuno con autorità di budget cross-BU e il peso politico per superare l'obiezione di un MD di BU. La sponsorship affidata al solo CIO è il pattern di fallimento più comune: il programma deriva verso decisioni di tooling perché quella è la lente naturale del CIO, e il redesign dei workflow cross-BU — dove vive il vero ROI — non viene mai autorizzato. Il compito dello sponsor non è partecipare allo steering committee mensile. È prendere tre o cinque decisioni binarie nel corso del programma che nessun altro ha l'autorità di prendere.

2. Steering committee cross-BU con diritti di escalation espliciti

Un MD per ogni BU in scope, più Group Risk, Group Data e l'executive sponsor. Si riunisce ogni due settimane durante Phase I e II. Ha un percorso di escalation esplicito e documentato verso ExCo per i conflitti cross-BU. Il fallimento più comune: uno steering committee che esiste nell'organigramma ma si riunisce mensilmente, esamina slide e non risolve mai un conflitto. Uno steering committee reale è scomodo. Se il vostro non lo è, è teatro.

3. Fasi gated con decisioni go/no-go condivise

Il programma si svolge per fasi con una decisione binaria a ciascun gate. Il gate più importante è quello al giorno 30. I gate successivi avvengono alla fine di Phase I, alla fine della pianificazione di Phase II e a ciascun cluster di implementazione. "Go/no-go" significa esattamente questo — o i criteri sono soddisfatti e la fase successiva viene autorizzata, oppure non lo sono e il programma viene sospeso, ridotto di scope o cancellato. I gate senza una reale opzione "no-go" non sono gate. Sono review meeting con un nome ricercato.

4. Termini commerciali risk-share

La struttura di pagamento del fornitore deve includere una tranche significativa subordinata a risultati condivisi — non al completamento di milestone, non all'accettazione di deliverable, non alla "client satisfaction". Nello specifico: nessuna fee per Phase II se la prova al giorno 30 non raggiunge i criteri concordati. È l'unica clausola contrattuale che allinea gli incentivi di un fornitore di consulenza ai risultati del buyer più di qualsiasi altra. È anche rara nella categoria, ed è per questo che gli officer procurement la fotografano quando la trovano.

5. Lifecycle del deliverable con source attribution

Ogni raccomandazione nel deliverable deve essere riconducibile a evidenze di origine specifiche — un'intervista nominata, un pattern di telemetria, una sezione di documento — e l'artefatto deve essere persistente e aggiornabile dai team interni dopo la fine dell'incarico. È un meccanismo di governance, non un'estetica di delivery. Impedisce che "benchmark di settore travestiti da insight su misura" entrino nel catalogo, consente l'audit post-incarico e rende la patterns library un asset vivente anziché un PDF congelato.

Il Day-30 Go/No-Go Gate: meccanica e ragione del suo funzionamento

Il day-30 gate è il meccanismo centrale di AI program governance perché è l'unico che trasferisce realmente il rischio dal buyer al fornitore in modo che il procurement possa farlo valere. Tutto il resto — steering committee, percorsi di escalation, source attribution — è disciplina operativa. Il gate è un impegno contrattuale.

Quale prova è richiesta

Prima della firma, buyer e fornitore concordano per iscritto, nello SOW, i criteri precisi che il day-30 gate deve superare. Una generica "client satisfaction" o "alignment on direction" non è un criterio — è una via di fuga. I criteri concreti hanno questo aspetto:

• Numero minimo di opportunità validate emerse nel pilot cluster — ad esempio, 30 candidati ranked, scored e source-attributed.
• Saving addressable aggregato minimo tra queste opportunità — ad esempio, EUR 4M di impatto identificato su costi o ricavi annualizzati.
• Soglia minima di qualità delle evidenze — ad esempio, l'80% delle top-10 opportunità supportate da almeno due fonti indipendenti (intervista + telemetria, oppure survey cluster + documento).
• Tasso minimo di operator validation — ad esempio, top-10 opportunità stress-tested da un named senior operator che abbia eseguito quel tipo di workflow a scala enterprise.

Chi decide

La decisione go/no-go viene presa congiuntamente dall'executive sponsor (CFO/COO) e dall'engagement lead del fornitore. Non per consenso dello steering committee — produce deriva. Non dal solo fornitore — è un conflitto di interessi. Non dal solo buyer — non è un gate condiviso. La struttura è binaria: entrambe le parti esaminano l'evidence pack del giorno 30, entrambe firmano il documento di decisione del gate, e il programma o avanza all'espansione di scope di Phase I oppure si ferma.

Cosa succede se la prova non è all'altezza

L'incarico termina. Il buyer paga la fee concordata per i giorni 1-30 di Phase I — tipicamente il 30-40% del valore complessivo del contratto Phase I + II — e non c'è alcuna fee per Phase II. Il buyer mantiene tutti gli artefatti prodotti nei primi 30 giorni. Il fornitore se ne va. È l'impegno strutturale che distingue un programma da un incarico di advisory a tempo indeterminato.

Perché questo allinea gli incentivi

Un incarico di consulenza tradizionale con fatturazione a milestone 40/30/30 paga il fornitore indipendentemente dal fatto che il buyer valorizzi o meno il lavoro. L'incentivo economico del fornitore è gestire lo scope e raggiungere i milestone, non produrre valore che il buyer voglia finanziare ulteriormente. Un day-30 gate con clausola no-Phase-II-fee ribalta tutto. L'incentivo economico del fornitore diventa: "produrre 30 giorni di lavoro che il buyer ritenga abbastanza valido da finanziare le successive 9 settimane". È esattamente l'incentivo che il buyer vuole che il fornitore abbia. È l'unica struttura commerciale in cui fornitore e buyer vogliono la stessa cosa durante la fase più rischiosa del programma.

Template di linguaggio contrattuale

Clausola suggerita per l'adattamento da parte del procurement:

"Al giorno 30 di Phase I, il Cliente e il Fornitore esamineranno congiuntamente l'evidence pack rispetto ai Day-30 Acceptance Criteria stabiliti nello Schedule [X]. La decisione di procedere all'espansione di scope di Phase I e a Phase II sarà presa congiuntamente dall'Executive Sponsor del Cliente e dall'Engagement Lead del Fornitore, e sarà documentata nel Day-30 Gate Decision Memo. Se i Day-30 Acceptance Criteria non sono soddisfatti, il Cliente potrà risolvere il presente Contratto a propria esclusiva discrezione mediante preavviso scritto entro dieci (10) giorni lavorativi, nel qual caso il Fornitore non avrà diritto ad alcuna fee per Phase II e l'unica obbligazione finanziaria del Cliente sarà la fee per i Giorni 1-30 di Phase I già fatturata. Tutti i work product prodotti durante i Giorni 1-30 resteranno di proprietà del Cliente."

Risk-Share vs Time-and-Materials vs Fixed-Fee

Il problema strutturale dei termini di pagamento della consulenza tradizionale è che l'incentivo economico del fornitore non coincide con il risultato del buyer. Di seguito il confronto che i team procurement dovrebbero applicare a qualsiasi proposta di programma AI in arrivo — la colonna AI consulting day 30 gate è quella che riduce materialmente il rischio dell'incarico.

Modello commerciale	Incentivo economico del fornitore	Risultato tipico per il buyer	Trasferimento del rischio
Time & materials	Massimizzare le ore fatturabili; espandere lo scope	L'incarico dura più del previsto; la profondità del deliverable varia; gli sforamenti di costo sono frequenti	Nessuno — rischio interamente sul buyer
Fixed fee, deliverable-based	Minimizzare lo sforzo fino all'accettazione del deliverable; resistere allo scope creep	Deliverable essenziale che rispetta la lettera dello SOW; poca flessibilità rispetto a insight emergenti	Parziale — il fornitore assorbe lo sforamento, il buyer assorbe il rischio sul risultato
Fatturazione a milestone (40/30/30 ecc.)	Raggiungere i milestone per attivare le fatture; le definizioni dei milestone diventano il lavoro	Il fornitore produce ciò che serve per fatturare; il valore per il buyer è accessorio	Nessuno — il fornitore è pagato indipendentemente dal risultato
Pure outcome-based (% sui saving)	Massimizzare i saving misurabili — talvolta a scapito dell'integrità della misurazione	Dispute su cosa conti come "saving"; il fornitore seleziona i risultati più facili	Alto — ma genera una guerra di misurazione
Risk-share con day-30 gate	Produrre 30 giorni di lavoro che il buyer ritenga abbastanza valido da finanziare le successive 9 settimane	Il fornitore investe oltre le proprie possibilità nei primi 30 giorni; il buyer o chiude a basso costo o acquista con piena fiducia	Alto — pulito, applicabile, senza dispute di misurazione

Il modello risk-share-with-gate non è un impegno parziale né una versione attenuata del pricing outcome-based. È un trasferimento binario e contrattualmente applicabile della fase più rischiosa dell'incarico sul fornitore. Lo scenario peggiore per il buyer è pagare la fee per i giorni 1-30 a fronte di un evidence pack che non ha raggiunto i criteri — tipicamente il 30-40% del valore complessivo del contratto. Lo scenario migliore per il buyer è finanziare Phase II con la prova documentata in mano. Non esiste lo scenario in cui il buyer paga l'intero contratto per un incarico i cui primi 30 giorni non hanno prodotto risultati.

Cadenza di governance per un programma di 14 settimane

La cadenza operativa è il secondo pilastro della AI program governance dopo la struttura commerciale. Di seguito il pattern di cadenza usato nei programmi enterprise che producono risultati — le riunioni sono brevi, le decisioni vengono documentate, le escalation hanno tempistiche esplicite. Il pattern presuppone un Phase I + II di 14 settimane.

Settimana	Steering committee	Decisioni di gate	Percorso di escalation ExCo
Settimana 1	Kickoff: conferma dello scope, percorsi di escalation documentati, criteri day-30 firmati	Selezione del pilot cluster	N/A
Settimana 2	Status bisettimanale: avanzamento discovery, log dei blocker	—	Slot fisso se necessario
Settimana 3	—	Inizia la stesura dell'evidence pack day-30	Review delle escalation ogni venerdì
Settimana 4	Review pre-gate con lo sponsor	DAY 30 GO/NO-GO GATE	Lo sponsor riferisce all'ExCo sull'esito del gate entro 5 giorni
Settimane 5-6	Status bisettimanale: avanzamento dell'espansione di scope	—	Slot fisso
Settimana 7	Checkpoint a metà Phase I: review delle dipendenze cross-BU	Decisioni di consolidamento fornitori	Conflitti cross-BU escalati entro 48h
Settimana 8	Chiusura Phase I: handover dell'intelligence layer	Gate di fine Phase I	Lo sponsor riferisce all'ExCo sul go-ahead di Phase II
Settimane 9-11	Bisettimanale: pianificazione dell'implementazione, costruzione della RACI	Decisioni di gate per ciascun cluster	Slot fisso
Settimana 12	Review del design dell'operating model	Allocazione delle risorse	Conflitti di risorse cross-BU escalati
Settimana 13	Review del piano di cultura e upskilling	Approccio di change management	—
Settimana 14	Chiusura Phase II: handover agli owner interni di Phase III	Gate di fine incarico	Lo sponsor presenta a ExCo / Board

Ciò che questa cadenza impone è velocità decisionale. Gli steering committee bisettimanali battono quelli mensili perché quattro settimane sono troppe per scoprire che una BU sta bloccando l'accesso. Le tempistiche di escalation documentate battono quelle informali perché "questo deve salire di livello" senza una scadenza marcisce. Le review pre-gate battono i gate meeting a sorpresa perché le decisioni di gate prese alla prima esposizione all'evidenza sono decisioni cattive.

La disciplina della Source Attribution

La source attribution è un meccanismo di governance travestito da standard di documentazione. La regola: ogni raccomandazione, ogni prioritizzazione, ogni opportunità scored nel deliverable deve essere collegata all'evidenza specifica che l'ha prodotta — l'ID dell'intervista, la firma del pattern di telemetria, il survey cluster, la sezione del documento.

Questo è importante per tre ragioni di governance:

• Impedisce che il pattern matching diventi il deliverable. Senza source attribution, un consulente può inserire nel catalogo raccomandazioni "benchmark di settore" e nessuno può metterle in discussione. Con essa, ogni raccomandazione deve sopravvivere alla domanda "quale evidenza nella nostra organizzazione ha prodotto questo?" I benchmark compositi travestiti da insight su misura non superano quel test.
• Abilita l'audit post-incarico. Quando un MD di BU contesta una raccomandazione sei mesi dopo l'handover, l'audit trail esiste. La raccomandazione è arrivata da queste tre interviste, da questo segnale di telemetria, da questo documento. La contestazione può essere valutata sull'evidenza, non sulla memoria.
• Rende l'intelligence layer durevole. Una raccomandazione senza fonte è una congettura che invecchia nel momento stesso in cui il consulente se ne va. Una raccomandazione con cinque link alle fonti è un asset che i team interni possono ri-validare, estendere o ritirare man mano che l'organizzazione evolve.

La disciplina della source attribution è la differenza tra un deliverable che sopravvive a Phase III e uno che viene archiviato e dimenticato. È anche uno dei meccanismi di governance più economici da specificare — basta una singola clausola di SOW — e uno di quelli a massimo effetto leva.

Struttura di risoluzione dei conflitti cross-BU

Ogni programma AI cross-BU produce lo stesso conflitto entro la settimana 6. La BU A vuole la capacità AI X; la BU B dice "l'abbiamo costruita nel 2024 e non funziona, non metterla sulla nostra roadmap." Oppure: la BU A vuole condividere i propri customer data con un LLM group-wide; il legal team della BU B lo blocca. Oppure: BU A e BU B vogliono entrambe la priorità nella coda di implementazione e c'è capacità per una sola.

Se il meccanismo di arbitrato viene improvvisato alla settimana 6, il conflitto o degenera emotivamente (le relazioni si rompono) o si blocca silenziosamente (entrambe le BU deprioritizzate, niente viene rilasciato). La soluzione di governance è documentare il meccanismo di arbitrato alla settimana 1, prima che esista qualsiasi conflitto. La struttura standard:

• Tier 1 — l'engagement lead del fornitore risolve i conflitti che sono domande di chiarimento dello scope, non conflitti di risorse. Documentati nello status settimanale, nessuna escalation.
• Tier 2 — lo steering committee risolve i conflitti cross-BU di risorse o scope in cui entrambe le BU sono al tavolo. Cadenza bisettimanale; se non risolto entro un ciclo, escala automaticamente al Tier 3.
• Tier 3 — l'executive sponsor (CFO/COO) risolve i conflitti che lo steering committee non è riuscito a chiudere. SLA di 48 ore. La decisione è vincolante e documentata.
• Tier 4 — ExCo o Board risolve i conflitti che lo sponsor escala, tipicamente perché il conflitto è strategico anziché operativo. Raro. Lento. Da evitare se il Tier 3 può chiuderlo.

Documentare questo alla settimana 1 significa che quando il conflitto emerge alla settimana 6, entrambe le BU sanno già come verrà risolto. La discussione riguarda il merito, non chi abbia l'autorità per decidere. Ecco come si presenta in pratica una AI program governance matura: non l'assenza di conflitto, ma la presenza di un meccanismo prevedibile per risolverlo.

Handoff di governance post-programma

La maggior parte degli incarichi di consulenza si conclude con una read-out finale e una fattura. L'intelligence layer finisce in una cartella SharePoint. La patterns library è un PDF. Sei mesi dopo, l'organizzazione non riesce a trovare metà di ciò che è stato prodotto e non può aggiornare la metà che riesce a trovare. È un fallimento di governance, non un fallimento di delivery.

I programmi con una solida governance post-incarico progettano l'handoff come un workstream a sé, non come un'aggiunta tardiva. I componenti:

• Trasferimento di ownership dell'intelligence layer. L'artefatto vive in un sistema di cui il cliente è proprietario e che il cliente può aggiornare. Non una dashboard hosted dal fornitore. Non un PDF. La source attribution resta intatta dopo l'handover.
• Protocollo di manutenzione della patterns library. Team interno designato come owner. Cadenza trimestrale per aggiungere nuove opportunità emerse dalle operations. Stessa ontologia, stessi vettori di scoring, stessa tassonomia di governance class.
• Cadenza di review trimestrale. Lo steering committee non si scioglie alla fine dell'incarico. Si riduce — riunioni trimestrali, agenda più snella — e rivede l'evoluzione del catalogo. Nuove opportunità aggiunte, opportunità rilasciate ritirate, opportunità bloccate riprese in scope.
• Documentazione dei diritti di aggiornamento. Chi può aggiungere al catalogo, chi può modificare lo scoring, chi può promuovere un'opportunità a implementazione attiva. Senza questo, il catalogo si calcifica; con esso, il catalogo si compone nel tempo.

Il test strutturale per qualsiasi partner potenziale: "Sei mesi dopo la fine dell'incarico, cosa sarà concretamente diverso nel modo in cui la nostra organizzazione lavora con questo catalogo, rispetto a come lavora oggi con le strategy deck che abbiamo sullo scaffale?" Se il partner non sa rispondere concretamente, la governance post-programma è assente — e il catalogo andrà a raggiungere le strategy deck sullo scaffale.

Clausole contrattuali pronte per il procurement

Le clausole seguenti sono redatte per essere incollate direttamente nel template standard di SOW del procurement, con parentesi per i termini specifici dell'organizzazione. Ciascuna copre uno dei cinque meccanismi di AI program governance. Gli officer procurement che affrontano un RFP per un programma AI 2026 dovrebbero confrontare qualsiasi proposta in arrivo con queste clausole — il linguaggio mancante è trasferimento di rischio mancante.

Tema della clausola	Linguaggio di esempio
Day-30 go/no-go gate	"Al giorno 30 di Phase I, il Fornitore presenterà un evidence pack misurato rispetto ai Day-30 Acceptance Criteria nello Schedule [X]. Se i criteri non sono soddisfatti, il Cliente potrà recedere senza ulteriori fee oltre ai Giorni 1-30. Tutti i work product restano di proprietà del Cliente."
Requisito di source attribution	"Ogni raccomandazione, prioritizzazione e opportunità scored nel Deliverable dovrà essere tracciabile, tramite un audit trail documentato, allo specifico ID dell'intervista, pattern di telemetria, cluster di risposte survey o sezione di documento che l'ha prodotta. I benchmark di settore compositi non sono accettabili come unica fonte."
Trasferimento di ownership dell'intelligence layer	"L'artefatto Intelligence Layer, inclusi tutti i dati, la scoring logic, l'ontologia e i link di source-attribution, sarà consegnato in un formato di cui il Cliente è proprietario e che può aggiornare senza ulteriore coinvolgimento del Fornitore. Il Fornitore garantirà una finestra di knowledge transfer di 60 giorni successivi alla chiusura di Phase II."
Diritti di aggiornamento post-incarico	"Il Cliente mantiene diritti perpetui di aggiornamento, estensione e modifica dell'Intelligence Layer, della Patterns Library e di tutti gli artefatti associati. Le rivendicazioni di IP del Fornitore sono limitate alla metodologia generale e non potranno gravare sull'uso operativo del Deliverable da parte del Cliente."
Cadenza dello steering committee	"Lo Steering Committee si riunirà con cadenza bisettimanale durante Phase I e II, con un percorso di escalation documentato all'Executive Sponsor del Cliente entro 48 ore per i conflitti cross-BU e all'ExCo entro 5 giorni lavorativi per i conflitti strategici che lo Sponsor non riesce a risolvere."
Requisito di operator validation	"Le top-10 opportunità prioritizzate a ciascun gate dovranno essere stress-tested da un Named Senior Operator con esperienza documentata nell'esecuzione di quel tipo di workflow a scala enterprise. Nome ed esperienza dell'Operator saranno forniti nello Schedule [Y] prima dell'inizio dell'incarico."

Queste sei clausole, insieme, convertono ciò che altrimenti è un incarico di advisory a tempo indeterminato in un programma strutturato con governance misurabile. Non sono un linguaggio procurement aggressivo. Sono protezioni minime per una categoria che ha passato tre anni a produrre presentazioni invece di risultati.

SUPALABS First-Party Data

FAQ

Cos'è l'AI program governance e in cosa differisce dall'AI governance?

Le due espressioni vengono usate come sinonimi, e non dovrebbero esserlo. "AI governance" tipicamente si riferisce a etica, model risk, conformità all'EU AI Act, bias auditing e acceptable-use policy — gli artefatti che il vostro General Counsel deve approvare. La AI program governance è operativa: è la cadenza, i diritti decisionali, i percorsi di escalation e i termini commerciali risk-share che determinano se il programma produce davvero risultati. I programmi possono avere una solida AI governance e una debole AI program governance — producono splendidi raccoglitori di policy e zero automazioni rilasciate. La funzione procurement che confonde le due acquista lo scope sbagliato.

Perché un day-30 go/no-go gate è così importante?

Perché è l'unico meccanismo contrattuale che allinea gli incentivi di un fornitore di consulenza ai risultati del buyer durante la fase più rischiosa del programma. La fatturazione tradizionale a milestone paga il fornitore indipendentemente dal valore consegnato — l'incentivo del fornitore è raggiungere le definizioni di milestone, non rilasciare qualcosa che il buyer voglia finanziare ulteriormente. Un day-30 gate con clausola no-Phase-II-fee ribalta quell'incentivo: il fornitore deve produrre 30 giorni di lavoro che il buyer ritenga abbastanza valido da autorizzare le successive 9 settimane. È l'impegno strutturale che gli officer procurement fotografano, perché è raro nella categoria e trasferisce materialmente il rischio dal buyer al fornitore.

Come devono essere fatti i day-30 acceptance criteria?

Specifici e misurabili, non "alignment on direction". Esempi concreti: un numero minimo di opportunità source-attributed emerse (es. 30), un saving addressable aggregato minimo (es. EUR 4M annualizzati), una soglia minima di qualità delle evidenze (es. l'80% delle top-10 supportate da due fonti indipendenti) e un tasso minimo di operator validation (es. top-10 stress-tested da un named senior operator). Criteri generici trasformano il gate in teatro; criteri specifici lo rendono applicabile. I criteri devono essere concordati per iscritto nello SOW prima della firma, non negoziati alla settimana 4 quando una parte ha leva sull'altra.

Cosa succede se il day-30 gate non viene superato?

L'incarico termina. Il buyer paga la fee per i Giorni 1-30 — tipicamente il 30-40% del valore complessivo del contratto Phase I + II — e non c'è alcuna fee per lo scope restante. Tutti gli artefatti prodotti nei primi 30 giorni restano di proprietà del buyer. Il fornitore se ne va. È l'impegno strutturale che separa un programma da un incarico di advisory a tempo indeterminato. Un fornitore che si rifiuta di inserire questa clausola nello SOW sta segnalando, chiaramente, di non essere abbastanza fiducioso nel proprio output al giorno 30 da mettervi a rischio la propria fee. I team procurement dovrebbero leggere quel segnale di conseguenza.

Come evitiamo che il gate diventi un timbro di conferma?

Tre protezioni strutturali. Primo, i criteri di accettazione sono scritti nello SOW prima del kickoff, non alla settimana 3 quando una parte ha leva. Secondo, la decisione di gate è presa congiuntamente dall'executive sponsor (CFO/COO) e dall'engagement lead del fornitore, entrambi firmano un Day-30 Gate Decision Memo — non per consenso dello steering committee, che produce deriva, e non unilateralmente da una delle parti. Terzo, l'evidence pack è esaminato in una sessione pre-gate alla fine della settimana 3, in modo che la decisione al giorno 30 sia presa sull'evidenza documentata, non sulla reazione di prima impressione. Senza queste protezioni, i gate vengono di default a "go" perché nessuno vuole essere quello che ha fermato l'incarico.

Come funzionano questi meccanismi di governance per organizzazioni che hanno già team AI interni?

Diventano più importanti, non meno. I team interni che gestiscono lavoro di programma AI senza una governance esplicita producono la stessa deriva dei consulenti esterni — cataloghi di opportunità che invecchiano, raccomandazioni senza source attribution, conflitti cross-BU che si bloccano. I cinque meccanismi (executive sponsorship, steering committee, fasi gated, termini commerciali risk-share dove applicabili, lifecycle del deliverable con source attribution) si applicano allo stesso modo ai programmi interni. La variante del day-30 gate per i programmi interni è una decisione "finanziare Phase II o riassegnare il team" — la conseguenza è una riallocazione interna anziché la risoluzione del contratto, ma la disciplina è la stessa. La AI program governance riguarda il programma, non se chi lo gestisce abbia un datore di lavoro esterno o interno.

Fonti e riferimenti