La funzione non si esporta

Venerdì un team di sviluppo ha ricevuto una notizia che non riguardava nessuno dei suoi sistemi. Il 28 agosto OpenAI ha annunciato che interromperà la fornitura dei propri modelli a Cursor, invocando la clausola di cambio di controllo scattata con l’acquisizione da parte di SpaceX: accesso diretto chiuso il 12 novembre, il preavviso massimo che il contratto consente. Da oggi, settantacinque giorni.

Nessun attacco. Nessun outage. Nessun dato perduto, nessuna API violata. Cursor continua a esistere, i repository restano dove sono, gli altri modelli restano nel menu. È semplicemente successo che una funzione usata ogni giorno da migliaia di team sparirà dal loro ambiente per una decisione contrattuale presa fra due aziende terze.

Ora immaginiamo il CTO di quel team che apre il proprio inventario delle dipendenze. «GPT» non compare quasi da nessuna parte. Non è nel lock file. Non è nello SBOM. Non è nei diagrammi architetturali. Eppure una parte consistente del processo di sviluppo è stata calibrata per mesi sul comportamento di quel modello: la dimensione delle specifiche, la profondità delle review, il numero di iterazioni previste, perfino le stime date ai clienti. Tecnicamente il team non ha perso nulla. Organizzativamente deve ancora scoprire quanto ha perso.

L’azienda che aveva fatto tutto bene

Ho scritto pochi giorni fa che il lock-in non sarà più nei dati: fra i documenti e le decisioni si sta formando un terzo oggetto, lo stato che il sistema accumula lavorando per te, e il costo dell’uscita rischia di essere l’amnesia. La risposta era una disciplina architetturale precisa: ciò che è importante per il comportamento dell’agente dovrebbe esistere, quando possibile, fuori dall’agente.

Questa volta voglio concedere che quell’architettura abbia funzionato. Immaginiamo un’organizzazione che ha fatto tutto correttamente. Le specifiche sono nel repository. Le decisioni architetturali sono versionate. Le procedure importanti sono diventate skill esplicite. Gli strumenti passano per protocolli aperti. Il contesto di progetto non vive nella memoria privata del provider, gli eval sono indipendenti dal modello, i dati si esportano, la memoria rilevante si ricostruisce. Il sistema è stato progettato precisamente per poter sostituire Claude con GPT, GPT con Gemini, Gemini con un modello open-weight.

Poi, un lunedì mattina, il modello viene sostituito. Tutto continua tecnicamente a funzionare. Niente migrazione, niente incompatibilità, niente memoria dimenticata.

Eppure il processo peggiora. L’agente modifica più file di quanti ne servano. Interpreta le specifiche con meno disciplina. Ha bisogno di tre iterazioni dove prima ne bastava una. Non riconosce con la stessa affidabilità quando una richiesta è ambigua. Fa review tecnicamente corrette ma meno utili. Magari è più veloce, magari costa meno, e intanto produce più lavoro da assorbire. Oppure accade l’opposto: il nuovo modello è globalmente migliore, domina i benchmark pubblici, ed è peggiore proprio nella combinazione di comportamenti sulla quale l’organizzazione aveva costruito, senza saperlo, il proprio modo di lavorare.

L’azienda non ha perso i dati. Non ha perso la memoria. Non ha perso gli strumenti. Ha perso una funzione cognitiva.

La tesi, detta con precisione: nell’AI il lock-in può consistere non nell’impossibilità tecnica di cambiare fornitore, ma nella dipendenza organizzativa da una particolare distribuzione di capacità, errori, comportamenti e costi di supervisione che nessuna API standard garantisce di poter sostituire. Nel saggio precedente il costo dell’uscita era l’amnesia. Qui è più subdolo: si può perdere competenza operativa senza perdere un solo byte.

L’obiezione: non è lock-in, è qualità

Prima di andare avanti bisogna concedere quasi tutto all’obiezione più forte. Se sostituisco PostgreSQL con un database meno performante e l’applicazione rallenta, non ho scoperto una nuova forma di vendor lock-in: ho scelto un prodotto peggiore. Se sostituisco un ingegnere eccellente con uno mediocre, il processo peggiora, e nessuno direbbe che ero «locked in» sul primo. Se Claude esegue un task meglio di Gemini, la differenza di qualità non costituisce una dipendenza patologica. Questa obiezione deve restare in piedi: la parola lock-in ha valore solo se descrive qualcosa di più preciso della banale constatazione che i prodotti non sono identici.

Il problema compare quando le caratteristiche del prodotto smettono di essere prestazioni e diventano assunzioni incorporate nell’organizzazione. C’è differenza fra dire «questo modello scrive codice meglio» e dire: il nostro processo di review, la dimensione delle nostre specifiche, la granularità dei task, il numero di controlli umani e perfino il prezzo a cui vendiamo il lavoro presuppongono che questo modello mantenga una determinata affidabilità. Nel secondo caso la capacità del modello è diventata infrastruttura. La sostituzione resta tecnicamente possibile, ma richiede riprogettazione organizzativa.

Ed è esattamente la firma del lock-in vero: il costo di uscita non coincide con il costo di trasferire gli asset. Coincide con il costo di ricostruire altrove le condizioni da cui il sistema dipendeva.

Il modello è parte del processo

Il SaaS classico rendeva la portabilità almeno nominabile: database, file, configurazioni, API, workflow. Il problema era riportarli fuori in forma utilizzabile, ed è il problema che il Data Act aggredisce con switching, dati esportabili e functional equivalence. Nel saggio precedente era già comparso qualcosa di più sfuggente: lo stato dell’agente non è un archivio ma una trasformazione dell’archivio, e due sistemi con gli stessi dati possono comportarsi diversamente perché hanno consolidato diversamente l’esperienza.

Il passaggio successivo è più radicale. Anche due agenti con gli stessi dati, la stessa memoria, gli stessi tool, le stesse istruzioni e la stessa specifica restano sistemi funzionalmente diversi. Perché il modello non è un interprete neutrale del processo: è parte del processo. Decide implicitamente come distribuire l’attenzione, quanto esplorare prima di committarsi, quanto verificare, quando chiedere chiarimenti invece di procedere, quanto fidarsi del contesto, quanto seguire alla lettera un requisito e quanto generalizzarlo, come reagire a un test fallito, con quale facilità abbandonare la propria ipotesi, quando fermarsi.

Nessuna di queste proprietà è dichiarata nel contratto API. Nessuna vive nel nostro repository. Nessuna viene esportata. E soprattutto nessuna ha necessariamente un equivalente diretto nel modello concorrente. Un workflow agentico è la composizione di un processo esplicito e del comportamento implicito del modello: la prima parte può essere resa portabile con la disciplina del saggio precedente. La seconda no.

La falsa promessa dell’API compatibile

Nell’informatica tradizionale l’interfaccia compatibile ha un potere enorme. Se due database parlano SQL abbastanza bene, gran parte della dipendenza è ridotta. Se due object storage implementano la stessa API, il costo del cambio crolla. Se due runtime accettano lo stesso artefatto OCI, l’interoperabilità è reale. Con i modelli linguistici rischiamo di confondere compatibilità sintattica ed equivalenza comportamentale.

Due provider possono accettare gli stessi messaggi, gli stessi tool, lo stesso JSON schema, e restituire lo stesso formato. L’applicazione gira al primo colpo. Ma il vero contratto non era mai stato l’endpoint. Era una proprietà non scritta che suona così: quando ricevi una specifica di questo tipo, con questo repository, questi strumenti e questi eval, raggiungi un risultato accettabile con questa distribuzione di errori e questo costo umano di supervisione. Nessun protocollo standardizza questa proprietà. Un adapter compatibile può rendere banale cambiare endpoint e lasciare intatto il novanta per cento del costo reale della migrazione.

La portabilità delle API, da sola, è una forma cosmetica di sovranità.

Configurazione dinamica di un SaaS

Il caso Cursor è utile perché rende concreto un rischio che di solito resta astratto, ma sarebbe un errore costruirci sopra tutto il ragionamento: è un’anomalia, con dentro Musk, una acquisizione da 60 miliardi e una rivalità personale. La forma ordinaria del problema è molto più banale, e ha una data: dopodomani.

Il 1° settembre GitHub ritira sei modelli da Copilot, fra cui versioni di Claude Sonnet, Claude Opus e Gemini, su tutte le superfici del prodotto, indicando i successori come alternative. Dal punto di vista del fornitore è normale lifecycle management, e non c’è niente da rimproverare. Dal punto di vista dell’organizzazione significa una cosa precisa: un comportamento che ieri faceva parte del workflow domani non è più disponibile. E con la global model policy i nuovi modelli possono diventare disponibili per default se l’amministratore non ha scelto una politica più restrittiva: la funzione cognitiva accessibile al team è, letteralmente, una configurazione dinamica del SaaS.

Nel software tradizionale un upgrade modifica il codice che esegue determinate regole. Nell’AI un cambio di modello modifica la funzione che interpreta le regole stesse. Il machine learning classico ci ha abituati al drift: i dati cambiano, la distribuzione si sposta, le performance degradano. Qui accade qualcosa di diverso, che chiamerei con prudenza cognitive dependency drift: la tua applicazione non cambia, i tuoi dati non cambiano, la specifica non cambia, e il comportamento del sistema cambia lo stesso, perché è cambiato il componente cognitivo sottostante. Nuova versione, nuovo fine-tuning, nuove safety policy, nuovo routing, nuovo provider. Il repository resta immobile mentre la dipendenza cambia natura sotto un’interfaccia apparentemente stabile.

E la catena è più stratificata del SaaS: organizzazione, tool, broker di modelli, provider del modello. Ogni anello può rompersi indipendentemente dagli altri. Per Cursor non è servito che GPT venisse ritirato dal mondo: è bastato che sparisse dall’intersezione specifica fra tool, contratto e organizzazione su cui qualcuno aveva costruito il proprio processo.

La dipendenza che il grafo non registra

Un lock file mostra che dipendo da una libreria. Uno SBOM mostra una versione. Un digest identifica un artefatto. Con i modelli gestiti, la dipendenza più importante è semanticamente più ricca e completamente invisibile a questi strumenti. Non dipendo da «gpt-x»: dipendo dal fatto che quella versione comprenda bene specifiche lunghe, non modifichi i test per far passare il codice, riconosca le ambiguità, usi con parsimonia certi strumenti, faccia review con una certa severità, richieda in media un certo numero di iterazioni.

Il dependency management potrebbe dover evolvere di conseguenza. Non solo: quale versione usiamo? Ma: quali proprietà operative del processo stiamo implicitamente delegando a questa versione? Dopo lo SBOM, e con tutta la prudenza dovuta ai nomi nuovi, servirebbe una specie di Cognitive Bill of Materials: non un elenco delle intelligenze presenti, ma un inventario delle funzioni cognitive da cui il processo dipende. Interpretazione dei requisiti, generazione, ragionamento di sicurezza, review, pianificazione dei tool, classificazione, riconoscimento delle eccezioni. E per ciascuna: quale modello la esegue, quale affidabilità richiediamo, quali eval lo dimostrano, quale alternativa abbiamo, quale perdita accettiamo durante uno switching.

Oggi inventariamo i componenti perché un componente può sparire o diventare vulnerabile. Le capacità delegate possono sparire allo stesso modo. Solo che non compaiono in nessun inventario.

Gli eval come strumento di sovranità

Nel saggio precedente il test di uscita era: se domani sostituisco il provider, quanta capacità organizzativa perdo? Va aggiornato, perché quella domanda misurava ciò che porti via. La domanda nuova è: che cosa continua a funzionare dopo che sei uscito? Sono domande diverse. Puoi esportare tutto e avere comunque un processo inutilizzabile.

Il vero exit test di un sistema agentico, allora, è comportamentale. Una batteria di task rappresentativi del lavoro reale: stessa specifica, stessi strumenti, stessa memoria, stessi dati, modello alternativo. Si osserva che cosa sopravvive. Quanto cala il task success, quanto aumenta il rework umano, quali categorie di task smettono di funzionare, quali failure mode nuovi emergono, quanto cambia il costo, quanto tempo serve per tornare al livello precedente. Sono metriche di switching molto più oneste di «l’API è compatibile».

Qui gli eval cambiano mestiere. Normalmente li costruiamo per rispondere a «quale modello è migliore?». Ma rispondono a una domanda politicamente più interessante: quanto siamo dipendenti da questo modello? Se possiedo cento task rappresentativi e posso eseguirli contro più modelli, possiedo una misura della sostituibilità. Se non li possiedo, la dipendenza è invisibile: so che il sistema funziona oggi, ma non so quanta parte di quel funzionamento appartiene alla mia architettura, al mio contesto, alle mie specifiche, e quanta appartiene accidentalmente al comportamento del modello attuale. L’evaluation diventa una prova di portabilità cognitiva, l’equivalente del test di disaster recovery: non basta avere il backup, bisogna provare il restore. Non basta avere un secondo modello nel menu a tendina, bisogna provare la continuità della funzione.

C’è anche un modo semplice per rendere operativo il contratto vero, quello che l’API non scrive. Abbiamo SLO per disponibilità, latenza, error rate; un workflow AI può avere l’equivalente cognitivo: accettazione dei task sopra una soglia, allucinazioni critiche sotto una soglia, rework umano mediano sotto tot minuti, costo per task sotto tot, latenza sotto tot. Non serve che il termine diventi uno standard. Serve lo spostamento d’oggetto: il contratto reale con il modello non è il suo nome, sono le prestazioni minime che permettono al processo di esistere. Se due modelli rispettano quegli SLO, sono funzionalmente sostituibili per quel processo, per quanto diversi dentro. Questa è la vera astrazione. Non l’API: la soglia.

A quel punto si arriva alla frase verso cui converge tutto: il modello dovrebbe essere un dettaglio implementativo della capability aziendale, non l’identità della capability. Non «abbiamo un processo Claude», ma «abbiamo un processo di code review che oggi usa Claude perché soddisfa meglio i nostri SLO». La differenza sembra linguistica. È governance.

La ridondanza vera e quella finta

Per i database critici costruiamo ridondanza senza discutere: primary, replica, failover. Perché per le funzioni cognitive critiche consideriamo normale averne una sola? Un processo maturo potrebbe avere un modello primario, un secondario già validato sugli stessi eval, un routing per categoria di task, un fallback dichiaratamente degradato. Non per servire traffico in parallelo: per evitare che il piano B venga scoperto il giorno dell’incidente.

Ma anche qui l’obiezione va presa sul serio: il multi-model può essere una falsa sicurezza. Dire «supportiamo OpenAI, Anthropic e Google» non significa essere indipendenti. Se tutto il processo è stato scritto e calibrato sul modello A, i provider B e C sono adapter che nessuno usa: backup mai testati. O peggio: tre modelli possono dipendere dallo stesso hyperscaler, dallo stesso framework, dallo stesso control plane, e la ridondanza va valutata lungo tutta la catena. Tre voci nel model selector non sono un’architettura resiliente.

E c’è una dipendenza più quotidiana ancora, che non compare in nessuna discussione sul lock-in: i prompt. Prompt enormi, iperottimizzati per un singolo modello. System instruction che sfruttano comportamenti idiosincratici. Hack empirici, tramandati come folklore: «con Claude funziona solo se glielo dici così». Questa conoscenza produce un vantaggio locale reale, ed è capitale specifico del vendor. Nel SaaS era il fornitore a costruire la parte proprietaria che ti rendeva dipendente; nell’AI il cliente costruisce da solo una parte del proprio lock-in, un prompt alla volta. Migliaia di workaround, parser tarati su un formato di output, tool description calibrate su un modello: uno strato di compatibilità che nessuno ha chiesto e che alza il prezzo dell’uscita. Non significa smettere di ottimizzare. Significa distinguere la conoscenza del dominio, che va preservata, dalla conoscenza del comportamento contingente del modello, che va trattata come debito. Debito cognitivo specifico del vendor.

La disciplina che ne discende ha un nome che uso da tempo: specifiche, non prompt. Una specifica descrive che cosa deve essere vero indipendentemente dall’esecutore. Un prompt, troppo spesso, descrive come convincere un particolare esecutore a farlo. Più il processo si regge su requisiti, acceptance criteria, invarianti, test, policy ed evidenze, meno dipende dal comportamento implicito del modello; più si regge su trucchi, tono, few-shot specifici e strategie emergenti, più la funzione vive presso il provider. Lo sviluppo guidato dalle specifiche non è solo un modo per far lavorare meglio i coding agent: è una strategia di uscita.

L’errore simmetrico, però, è l’altro riflesso condizionato dell’ingegnere: costruire il gigantesco abstraction layer interno che nasconde ogni differenza fra i modelli. È spesso il modo migliore per spostare il lock-in dal vendor al proprio framework: un livello che insegue ogni feature, appiattisce le capacità migliori sul minimo comune denominatore, va mantenuto per sempre e diventa esso stesso una piattaforma. La strategia sensata è più minimale e somiglia al progressive enhancement del web: un nucleo portabile fatto di specifiche, contratti dei tool, eval e fallback, e sopra un livello di accelerazione vendor-specific che sfrutta senza vergogna le capacità migliori del provider, caching, reasoning avanzato, protocolli particolari. Se il provider sparisce, perdi l’accelerazione, non il sistema. L’architettura non deve rendere i modelli indistinguibili. Deve rendere misurabile ciò che accade quando smettono di esserlo.

Il prezzo, la latenza, la continuità

La funzione può diventare indisponibile anche senza essere ritirata. Può semplicemente uscire dall’economia del processo. Se vendo una pratica evasa a un euro e il workflow si regge su un modello che costa quindici centesimi a task, un listino triplicato non rompe nessuna API: rompe il conto economico. E lo stesso vale per la latenza: un agente customer-facing costruito attorno a novecento millisecondi di risposta muore con un sostituto da sei secondi, anche se la capability astratta è equivalente. La portabilità della funzione è una curva multidimensionale, qualità, costo, latenza, affidabilità, supervisione umana richiesta, non un numero solo. È lo stesso argomento che ho fatto sulle metriche di produttività: la sostituibilità non si certifica con un benchmark pubblico, si misura sul proprio lavoro.

Da qui una conseguenza che il procurement non ha ancora assorbito. Nei vendor assessment OpenAI e Anthropic compaiono ancora come «tool AI». Ma se una parte significativa del delivery dipende dalla loro disponibilità e dalle loro prestazioni, la categoria giusta è fornitore critico, con tutto ciò che ne segue: contratto, SLA, exit plan, monitoraggio, analisi dei subfornitori, business continuity. Altrimenti si arriva alla contraddizione di aziende che fanno assessment sofisticati sul cloud che conserva i dati e nessuna valutazione sulla società che fornisce la funzione con cui quei dati vengono interpretati.

Business continuity, appunto: è la parola che manca. Le aziende costruiscono piani di continuità per data center, database, connettività, persone chiave, fornitori strategici. Se una funzione aziendale viene progressivamente delegata a un modello, deve entrare nello stesso ragionamento. Quali processi si fermano se il modello non è disponibile, per quanto tempo, con quale fallback, con quale performance degradata accettabile. E con quale competenza umana residua: perché se per cinque anni un modello esegue una funzione, l’organizzazione può perdere la capacità umana di farla, non perché licenzi qualcuno ma perché nessuno la esercita più. Il lock-in cognitivo incontra il deskilling, e il nuovo provider diventa tecnicamente sostituibile mentre l’organizzazione scopre di non avere più una baseline umana a cui tornare.

C’è perfino un paradosso del successo. Se l’agente funziona male, lo controlliamo, manteniamo le procedure manuali, conosciamo le alternative. Se funziona perfettamente per anni, automatizziamo, eliminiamo i doppioni, riduciamo le competenze ridondanti, integriamo in profondità. Più funziona, più costerà uscirne. Non è una ragione per non automatizzare: è la ragione per trattare la reversibilità come un costo operativo, esattamente come il backup. Un secondo adapter mantenuto, eval aggiornati, una pipeline alternativa, competenze interne coltivate: tutto questo sembra spreco fino al giorno in cui serve. La libertà di uscita è un’opzione, e le opzioni hanno un premio. La scelta adulta non è pagarlo ovunque: è decidere quali funzioni meritano di pagarlo. Per alcune accetti una dipendenza forte perché il vantaggio è enorme; per i workflow commodity pretendi alta sostituibilità. Una classificazione onesta, portabile, portabile con degrado, dipendente dal provider, oggi insostituibile, vale più di qualunque casella «vendor-neutral: sì».

Perché il punto non è avere single point of failure. È non sapere di averlo.

Il criterio resta nostro

Il percorso di questi due saggi attraversa quattro oggetti. Il dato, che si esporta. Lo stato, che si può esternalizzare con disciplina. La funzione, che si sostituisce solo se esiste un’alternativa sufficientemente equivalente. E infine il criterio: perché per sapere se l’alternativa è sufficientemente equivalente serve qualcosa che l’organizzazione deve necessariamente possedere in proprio, la definizione operativa di che cosa significa che quella funzione è stata eseguita bene.

È qui che il discorso smette di essere tecnico. Se il provider possiede il modello, la memoria, il benchmark e la definizione del buon risultato, sei cliente di un servizio che puoi giudicare solo attraverso ciò che il servizio stesso ti racconta. Se possiedi specifica, eval, rubriche, confini di fallimento ed evidenze, puoi interrogare più modelli e decidere quale soddisfa la tua funzione. Il potere si sposta: chi possiede la definizione operativa di «abbastanza buono» possiede la possibilità di sostituire chi esegue il lavoro. Ho sostenuto che il fossato competitivo non è il dato ma il giudizio; questo ne è il corollario difensivo. Lo stesso corpus di eval che rende migliore la tua AI verticale è anche ciò che ti permette di cambiarla.

È esattamente ciò che facciamo con le persone, del resto. Esistono organizzazioni in cui un dipendente è formalmente sostituibile e praticamente no: non perché tenga in ostaggio i documenti, ma perché nessuno ha mai formalizzato che cosa rendesse buona la sua prestazione. Quando se ne va, l’azienda scopre di non aver mai definito il lavoro che gli aveva delegato. Con i modelli può succedere la stessa cosa su scala industriale: un agente che «funziona benissimo», senza che nessuno sappia dire esattamente perché, quali errori non commette, rispetto a quale confronto. Il giorno in cui sparisce, si scopre che il vero lock-in non era nel provider. Era nella nostra incapacità di descrivere il lavoro che gli avevamo affidato.

Per questo non trasformerei mai questo argomento in un attacco ai vendor. Un provider ha diritto di fare un modello migliore, cambiare listino, ritirare versioni secondo contratto. Il lock-in cognitivo è in buona parte autoindotto: più deleghiamo senza esplicitare obiettivi, criteri, confini ed evidenze, più ciò che rende il processo efficace vive nel comportamento privato dell’esecutore. E la contromisura regolatoria, se un giorno arriverà, non potrà obbligare il nuovo provider a pensare come il vecchio: sarebbe assurdo. Potrà semmai fare ciò che il Data Act ha fatto per i dati e ciò che il DMA fa per i mercati, preservare la contestabilità: trasparenza sulle versioni, periodi di deprecazione decenti, export del contesto, interoperabilità degli artefatti di valutazione. Non standardizzare l’intelligenza. Standardizzare le condizioni che permettono al cliente di verificare se un’altra intelligenza è abbastanza equivalente per il suo scopo. È una distinzione molto europea, e mi sembra quella giusta.

Abbiamo impiegato vent’anni a capire che il cloud non era portabile solo perché potevamo esportare un database. Poi abbiamo scoperto che portare via i documenti non basta, se lasciamo indietro ciò che il sistema ha imparato da quei documenti. Ora tocca al gradino successivo: si può portare via tutto, specifiche, memoria, istruzioni, strumenti, eval, ogni artefatto in nostro possesso, e scoprire che il processo aveva imparato a funzionare attorno a una proprietà mai formalizzata, il modo particolare in cui un certo modello trasformava quegli artefatti in giudizio e azione.

La sovranità, in questo campo, non consiste nel rifiutare le dipendenze. Consiste nel conoscerne il prezzo: sapere quale parte della funzione è nostra e quale la stiamo noleggiando, sapere che cosa succede se il noleggio finisce, e mantenere l’alternativa esercitabile, non teorica. Un’opzione reale, con i suoi eval eseguiti negli ultimi novanta giorni, non una voce nel menu. Nell’AI la clausola di uscita più importante potrebbe non essere scritta nel contratto: potrebbe essere un test. Un insieme di task che permette di dire: questo è il lavoro che avevamo delegato, questo è ciò che consideriamo corretto, questi sono gli altri sistemi capaci, oggi, di farlo. A quel punto il modello può essere eccezionale senza diventare insostituibile.

E forse la definizione più matura di sovranità cognitiva non sarà possedere un modello, addestrarne uno europeo o farlo girare nel proprio data center. Sarà una cosa molto meno spettacolare: possedere abbastanza bene la definizione del proprio lavoro da poter cambiare chi lo esegue. Perché un modello diventa lock-in non quando è tecnicamente difficile sostituirlo. Diventa lock-in quando l’organizzazione non sa più descrivere la funzione che dovrebbe sopravvivere alla sua sostituzione.

L'autore

Andrea MargiovanniAI

Seguo il rapporto fra AI e regolazione europea come fatto politico, non come spettacolo tecnico. Lavoro con team che devono renderla compatibile con AI Act, CRA, NIS2 senza ridurre la compliance a una checklist.

Vai al percorso →