AAIF Linux Foundation governa MCP: come questo cambia le RFP e i contratti enterprise italiani

A fine aprile 2026 ho avuto sotto gli occhi tre capitolati di RFP italiane di tre ambiti diversi (un'azienda manifatturiera del nord-est, una società di servizi finanziari del centro Italia, un ente locale del Mezzogiorno) che chiedevano integrazioni AI-driven con specifiche tecniche sui protocolli agentic. Sul mio Hetzner CCX33 (8 vCPU AMD EPYC 9454P, 32 GB RAM DDR5) li ho letti uno dopo l'altro con un occhio specifico: come sono trattati MCP, UCP, ACP, A2A, e come è inquadrato il vincolo di vendor-neutralità. Risultato: due dei tre capitolati menzionavano "MCP di Anthropic" come tecnologia di riferimento; uno scriveva esplicitamente "compatibilità con Claude API" come requisito non funzionale obbligatorio; nessuno dei tre riconosceva il fatto che dal 9 dicembre 2025 MCP è stato donato da Anthropic alla Agentic AI Foundation sotto la Linux Foundation, e che dal punto di vista governance è oggi protocollo standard vendor-neutral con co-fondatori Anthropic, Block e OpenAI, supporter Google, Microsoft, AWS, Cloudflare, Bloomberg.

Il gap fra realtà tecnica del protocollo nel 2026 e formulazione delle RFP italiane è la finestra di opportunità per il consulente che sa portare consulenza di procurement sopra la consulenza tecnica. Le clausole contrattuali italiane scritte fra 2024 e prima metà 2025 inquadrano MCP come tecnologia proprietaria Anthropic, e questo distorce sistematicamente la valutazione delle offerte: penalizza fornitori che propongono MCP server custom (perché "dipendono da Anthropic"), favorisce indebitamente offerenti che propongono integrazioni proprietarie alternative, blocca lo scambio di prerogative fra clienti del settore pubblico e privato. La diagnosi di questo gap, e la sua correzione operativa con template di clausola passati dal legale, è il punto di valore distintivo che propongo come deliverable nei contratti con clienti enterprise italiani nel Q2/Q3 2026.

Cosa è successo a dicembre 2025 e perché cambia la cornice contrattuale

La cronologia ufficiale è semplice. Il 9 dicembre 2025 Anthropic annuncia la donazione del Model Context Protocol alla Agentic AI Foundation, directed fund sotto la Linux Foundation. Co-fondatori AAIF: Anthropic, Block (l'azienda di Jack Dorsey ex-Square), OpenAI. Steering committee con i tre co-fondatori plus rappresentanti dei major supporter. Linux Foundation come steward neutrale per garanzia di governance vendor-neutral. Sister project sotto Linux Foundation: Kubernetes, Node.js, PyTorch (l'hosting nello stesso umbrella organizzativo è di per sé segnale di posizionamento strategico equivalente a quello degli infra building block del 2010-2025). I numeri di adoption confermano il momentum: ~2 milioni di download mensili SDK al lancio, 22 milioni dopo l'adozione OpenAI (aprile 2025), 45 milioni dopo Microsoft Copilot Studio (luglio 2025), 68 milioni dopo AWS (novembre 2025), oltre 97 milioni a marzo 2026. Active public MCP server: oltre 10.000 a dicembre 2025.

Per la consulenza italiana questo cambia tre cose contrattuali concrete. Primo, MCP non è più "tecnologia Anthropic": è standard aperto governato da fondazione neutrale, esattamente come HTTP è governato da W3C/IETF e non è "tecnologia Tim Berners-Lee". Le clausole RFP che lo trattano come tecnologia proprietaria sono tecnicamente errate e il consulente che le vede deve farlo notare al cliente. Secondo, l'argomento "vendor lock-in MCP" perde fondamento: l'SDK è disponibile in tutti i major language, ci sono implementazioni di server MCP indipendenti (alcune sviluppate da membri europei AAIF), e la spec del 25 novembre 2025 è un riferimento tecnico stabile e pubblico. Terzo, l'investimento in un MCP server custom diventa un asset di lungo termine ammortizzabile su qualsiasi modello backbone (Claude, GPT, Gemini, Mistral) tramite client compliant alla spec.

Se gestisci procurement IT in PMI o ente che valuta integrazioni AI

Nel mio hub dedicato all'AI per aziende, sezione integrazione raccolgo articoli sui pattern multi-stack e sulle scelte architetturali che incidono sui contratti. La scrittura dei capitolati AI nel 2026 è un'arte specifica che richiede di conoscere i protocolli emergenti, le loro governance reali e la traduzione in clausole legali italiane esecutive. Il consulente serio porta sul tavolo modelli concreti, non opinioni generali.

I tre gap tipici delle RFP italiane post-donazione

Dalla mia lettura di capitolati e bandi italiani del Q1-Q2 2026 emergono tre gap ricorrenti che vale la pena nominare esplicitamente.

Gap uno: identificazione di MCP come tecnologia "Anthropic". Versione errata: "L'integrazione deve essere realizzata mediante MCP, protocollo Anthropic, garantendo l'interoperabilità con Claude API". Versione corretta: "L'integrazione deve essere realizzata mediante Model Context Protocol (MCP), specifica aperta governata dalla Agentic AI Foundation sotto Linux Foundation, garantendo conformità alla versione di spec attualmente vigente al momento del go-live e capacità di integrazione con qualsiasi LLM compatibile". La differenza non è cosmetica: la prima formulazione blocca offerenti che vorrebbero servire il cliente con backbone Mistral 3 europeo (data sovereignty) o Gemini, la seconda apre il mercato senza perdere i vincoli di interoperabilità.

Gap due: assenza di clausole su evoluzione della spec MCP. La spec MCP è in evoluzione attiva: rilascio del 25 novembre 2025, prossima release annunciata per metà 2026 con SEP-1442 (rimozione handshake initialize per stateless agent). I capitolati che fissano "MCP versione X" senza prevedere meccanismo di aggiornamento contrattuale rischiano di obbligare il fornitore a mantenere una versione obsoleta della spec, con costi di maintenance crescenti. La clausola corretta prevede aggiornamento automatico alla minor version successiva e processo di review concordato per major version.

Gap tre: confusione fra MCP, UCP, ACP, A2A. I capitolati italiani spesso trattano questi protocolli come alternative competitive, mentre nella realtà 2026 sono complementari: MCP è cross-cutting per tool integration generale, UCP copre commerce end-to-end (Google + Shopify + 20 partner), ACP è chat-to-buy in AI assistant (OpenAI + Stripe), A2A è inter-agent communication. Per un e-commerce agentic-ready servono MCP più UCP o ACP a seconda della surface, non l'uno escludente l'altro. Il capitolato che chiede "scegli fra MCP e ACP" sta facendo una falsa dicotomia.

Template di clausola contrattuale vendor-neutral

Riporto qui sotto una clausola tipo che ho fatto passare da legale specializzato in IT procurement italiano nel Q2 2026, utilizzabile come base in capitolati pubblici e privati. La clausola va naturalmente adattata al perimetro specifico dell'incarico ma il formato resta valido.

Articolo X - Conformità a protocolli agentic standard
1. Il fornitore garantisce che l'integrazione realizzata sia conforme alla specifica
   Model Context Protocol (MCP), governata dalla Agentic AI Foundation sotto la
   Linux Foundation, nella versione corrente alla data di go-live e successive
   minor version compatibili.
2. Il fornitore mantiene il sistema aggiornato alle minor version successive
   senza oneri aggiuntivi entro 60 giorni dal rilascio ufficiale della
   specifica. Le major version (es. v2.0 -> v3.0) richiedono review congiunta
   con il Cliente entro 30 giorni dall'annuncio ufficiale per definire piano e
   compenso di adeguamento.
3. Il fornitore garantisce che il sistema sia compatibile con qualsiasi modello
   linguistico (LLM) backbone che implementi un client conforme alla
   specifica MCP. Non sono ammessi vincoli di esclusività verso un singolo
   vendor di LLM.
4. Il fornitore documenta in fase di consegna l'elenco completo degli MCP
   server esposti, con le rispettive capability dichiarate, e fornisce script
   di test conformi alla specifica MCP che il Cliente può eseguire in
   autonomia per verificare la compliance.
5. In caso di evoluzione della governance del protocollo (es. cessione del
   progetto a fondazione diversa, biforcazione della specifica), il fornitore
   notifica il Cliente entro 14 giorni e propone piano di adeguamento entro
   60 giorni.

Le cinque clausole coprono i tre gap descritti sopra e aggiungono due salvaguardie contro scenari di evoluzione della governance, scenari oggi improbabili ma non impossibili nel medio termine. Il punto chiave è il punto 3: non ammettere vincoli di esclusività verso un singolo vendor di LLM. Questa clausola da sola elimina il rischio di lock-in tecnologico nel medio termine, e l'approccio "one backend, multiple LLM via MCP" che ne deriva è documentato nel mio pezzo sul confronto fra Claude Managed Agents e harness self-hosted come pattern architetturale di riferimento.

Particolarità italiane: mercato pubblico, AgID, codice contratti

C'è una specificità italiana che vale la pena trattare a parte: le RFP della pubblica amministrazione e degli enti locali. Il quadro di riferimento è il Codice dei Contratti Pubblici (D.Lgs. 36/2023) come riformato dal correttivo 2024, le linee guida AgID per IA nella PA (Determinazione 43/2026 del 10 marzo 2026, in consultazione fino all'11 aprile) e gli obblighi di interoperabilità derivanti dal Piano Triennale per l'informatica nella PA. Per la PA italiana, l'esistenza di un protocollo aperto governato da fondazione neutrale ha conseguenze contrattuali specifiche: gli articoli del codice contratti sull'interoperabilità e sul divieto di vendor lock-in (art. 41, art. 35 sui livelli minimi di servizio) trovano applicazione concreta nella scelta MCP-vs-proprietario. Una soluzione AI proprietaria che non esponga MCP server compliant è oggi più difficile da giustificare in un capitolato pubblico rispetto a sei mesi fa. Le linee guida AgID Determinazione 43/2026 entrano nel dettaglio di procurement AI, exit strategy e data portability, ed è quasi certo che la versione finale farà riferimento esplicito a standard agentic aperti come MCP, A2A, AP2.

Per un consulente che lavora sia con clienti privati che con la PA italiana, il framework MCP-aware diventa un asset commerciale doppiamente valido: parla la lingua dei capitolati pubblici (interoperabilità, vendor neutralità, exit strategy) e parla la lingua dei contratti privati (TCO, audit, futuro-proofing). Pochi competitor italiani in posizione tecnica equivalente sanno parlare entrambe le lingue contemporaneamente, e questo crea spazio commerciale specifico per chi lo sa fare nel biennio 2026-2027 prima che il pattern diventi commodity di mercato.

Argomenti commerciali per il consulente che vende MCP nel 2026

Il consulente serio che porta MCP a un cliente PMI italiano dovrebbe usare nel 2026 tre argomenti specifici, mappati sul cambio di governance.

Argomento uno: "Stiamo investendo in standard governato da Linux Foundation, esattamente come Kubernetes lo è per i container. Non è una scelta di vendor; è una scelta di infrastruttura". Questa formulazione disinnesca la prima obiezione del committente PMI italiano ("ma se Anthropic chiude/cambia direzione cosa succede?") con un parallelo che il decision maker conosce: chi ha scelto Kubernetes nel 2017 non ha avuto sorprese di governance nel 2025.

Argomento due: "MCP è il riferimento per l'interoperabilità. Se domani vuoi cambiare backbone (per costo, per sovereignty, per performance) non ti tocca rifare l'integrazione, ti tocca cambiare un client". Questa formulazione affronta il rischio percepito di lock-in e lo trasforma in vantaggio competitivo della soluzione proposta. Il pattern OWASP ASI03 Identity & Privilege Abuse che ho descritto nel pezzo sull'OWASP Top 10 for Agentic Applications è anche più gestibile su un'architettura MCP-aware perché i tool sono dichiarati esplicitamente nel server MCP, non inferiti.

Argomento tre: "Le PMI italiane che hanno integrato AI nel 2024-2025 con tecnologie proprietarie ora stanno pagando il debito. Chi parte oggi con MCP non avrà quel problema". Questo argomento si appoggia sul dato dell'Osservatorio Politecnico Milano 2026 secondo cui solo il 9% delle grandi imprese italiane ha governance AI strutturata e il 71% ha avviato almeno un progetto, gap che si traduce spesso in soluzioni proprietarie veloci da deployare ma costose da mantenere. Posizionarsi come consulente che evita il debito tecnico futuro è un differenziatore concreto, particolarmente convincente quando si possono mostrare i numeri di evoluzione di MCP da 2 milioni a 97 milioni di download in 12 mesi e l'integrazione di major player come AWS, Google e Microsoft come supporter. Il pattern che vedo emergere nei progetti consulenziali del 2026 è "diagnosi del lock-in attuale + roadmap di estrazione + ricostruzione su MCP", un servizio che molte PMI italiane di settore mid-market scoprono di aver bisogno solo dopo aver esaminato seriamente i contratti firmati nei due anni precedenti.

Per chiudere, la donazione MCP alla Linux Foundation non è un dettaglio di governance esoterica ma un punto di svolta del mercato italiano enterprise AI. Le RFP scritte oggi con la cornice contrattuale corretta valgono per i prossimi 18-36 mesi; quelle scritte con la cornice del 2024-2025 invecchieranno male e produrranno contenzioso. Per gli enti pubblici italiani che pubblicano bandi nel Q3-Q4 2026, il rischio di pubblicare un capitolato non aggiornato è particolarmente alto perché i tempi di gara sono lunghi e il vincolo contrattuale firmato vale per anni. Per le PMI medie con CIO interno che firma il contratto, la conseguenza di un capitolato lock-in si manifesta tipicamente al terzo anno, quando il switching cost diventa cristallino e troppo tardi per essere assorbito senza dolore commerciale. Il consulente che porta sul tavolo del cliente PMI italiana questa rilettura del procurement, con template clausola legalmente solido e argomenti commerciali ancorati al dato di mercato, fa esattamente quello che il momento storico richiede. Se vuoi una conversazione tecnica per fare un'analisi del tuo capitolato in scrittura, una review del contratto in negoziazione, oppure una valutazione del lock-in attuale di un'integrazione AI già firmata, il modulo di preventivo gratuito è il punto da cui inquadrare la richiesta in due minuti, sette domande.