Klarna ha sostituito 700 persone con l'AI. Poi le ha richiamate tutte. Ecco cosa dovrebbe imparare ogni azienda.

Ero al telefono con un potenziale cliente del settore bancario quando è scoppiata la notizia di Klarna. Metà 2025. Il mio telefono ha vibrato — un collega mi aveva inoltrato l'articolo con una sola riga: "È letteralmente quello che vai dicendo."

Il cliente era a metà di una frase, mi stava spiegando come avessero costruito un chatbot per il servizio clienti sopra GPT-4 e come stesse "funzionando alla grande". Gli ho chiesto come fossero i suoi punteggi CSAT. Lunga pausa. "Non lo monitoriamo ancora."

Quella pausa mi ha detto tutto. Perché Klarna l'aveva monitorato. E ciò che hanno scoperto era abbastanza devastante da far annullare una delle implementazioni di AI più pubblicizzate nella storia del fintech.

Ecco la versione breve: Klarna, il colosso svedese del buy-now-pay-later da 14,6 miliardi di dollari, ha sostituito circa 700 agenti del servizio clienti con un assistente AI costruito su OpenAI. L'hanno annunciato come un giro d'onore — l'AI gestiva il 75% di tutte le chat con i clienti in 35 lingue. Il costo per transazione è sceso del 40%. Wall Street ne è andata pazza. Poi i punteggi di soddisfazione dei clienti sono calati del 22%. L'azienda ha registrato una perdita netta di 99 milioni di dollari nel primo trimestre del 2025. E il CEO Sebastian Siemiatkowski ha ammesso pubblicamente che la ricerca dell'efficienza aveva sventrato la qualità del servizio, producendo output che ha definito "generici" e incapaci di gestire qualsiasi cosa richiedesse un vero discernimento.

Hanno ricominciato ad assumere. Hanno persino riassegnato ingegneri del software e addetti al marketing a rispondere al telefono.

Costruisco sistemi di AI neuro-simbolica in Veriprajna ormai da anni, e ho visto azienda dopo azienda cadere nella stessa trappola. Non perché la tecnologia sia scadente — i large language model sono davvero notevoli. Ma perché c'è una confusione fondamentale tra sembrare corretti ed essere corretti, e nei settori regolamentati quella confusione, prima o poi, ti costerà tutto.

La notte in cui ho capito che "abbastanza buono" non basta

Prima di entrare nell'architettura, voglio raccontarti un momento che ha cambiato il mio modo di pensare a questo problema.

Stavamo conducendo un pilota per un sistema di compliance legale — non assistenza clienti, ma analisi documentale. Il tipo di lavoro in cui si analizzano atti e documenti depositati presso le autorità di vigilanza e si allineano le politiche interne ai mandati esterni. Avevamo un prototipo che usava un setup standard di retrieval-augmented generation. Ricerca vettoriale, retrieval top-k, GPT che generava il riassunto. Era veloce. Gli output si leggevano splendidamente.

Una delle nostre ingegnere — Priya — è rimasta fino a tardi a testare casi limite. Verso le 23 ha scritto sul nostro canale Slack allegando uno screenshot. Il sistema aveva generato un paragrafo perfettamente fluido che citava una specifica clausola normativa. La clausola non esisteva. Non una citazione sbagliata, non una parafrasi — una fabbricazione completa. E si leggeva in modo così convincente che, se non eri un esperto di quella specifica normativa, non l'avresti mai colta.

Ricordo di essere rimasto seduto alla scrivania a fissare quello screenshot pensando: questo è il prodotto che stiamo per rilasciare. Un sistema che mente con la sicurezza di un socio anziano di uno studio legale.

Abbiamo fermato il pilota. Ricostruito l'architettura da zero. Persi tre mesi. È stata la decisione migliore che abbiamo mai preso.

Quando un sistema di AI fabbrica una citazione legale con perfetta sicurezza, il problema non è un bug — è l'architettura. Nessun prompt engineering può salvarti da una base fondamentalmente probabilistica.

Che cos'è la "trappola del wrapper" e perché continua a intrappolare aziende intelligenti?

Lascia che ti spieghi cosa è successo davvero a Klarna in termini tecnici, perché la stampa economica l'ha per lo più interpretato male. L'hanno inquadrato come "l'AI non è ancora pronta". Non è questo il punto. Il punto è quale tipo di AI e come è stata implementata.

Un "wrapper" è un sottile strato software che si colloca sopra un large language model di terze parti. Gestisce la formattazione, amministra le chiamate API, magari aggiunge un po' di parsing dell'output strutturato. Ma il pensiero vero e proprio — il ragionamento, il discernimento, il processo decisionale — è interamente esternalizzato all'LLM. Il tuo wrapper invia un prompt, il modello prevede i token successivi più probabili e tu ricevi qualcosa che suona come una risposta.

Funziona splendidamente per una demo. Funziona in modo adeguato per compiti a bassa posta in gioco. E fallisce catastroficamente per qualsiasi cosa richieda certezza.

L'architettura Transformer che alimenta questi modelli usa un meccanismo di self-attention per pesare la rilevanza dei token in una sequenza e prevedere ciò che viene dopo. Questo è pattern matching — pattern matching straordinariamente sofisticato, ma pur sempre pattern matching. Non esiste alcun meccanismo interno per verificare i fatti rispetto a una fonte di verità esterna. Il modello non sa le cose. Prevede come una risposta competente dovrebbe apparire.

L'AI di Klarna sapeva reimpostare le password in modo impeccabile. Ma quando un cliente aveva una controversia complessa che coinvolgeva un rimborso parziale, un disaccordo con un esercente e normative di tutela del consumatore in due giurisdizioni? Il modello ripiegava su quello che io chiamo slop-spinning — generare risposte dal suono plausibile che giravano in tondo, senza mai risolvere nulla, esasperando i clienti in quello che un analista ha descritto come un "loop kafkiano".

Ed ecco la parte che dovrebbe terrorizzare ogni leader d'impresa: le metriche di costo sembravano ottime per tutto il tempo in cui l'esperienza si stava deteriorando. Il costo per transazione è sceso da 0,32 a 0,19 dollari. Il tempo di risoluzione delle chat è passato da 11 minuti a meno di 2. Se guardavi solo la dashboard, avresti pensato di stare vincendo — fino al momento esatto in cui i tuoi clienti hanno iniziato ad andarsene.

Perché non basta aggiungere guardrail migliori a un LLM?

Questa è la domanda che mi fanno più spesso, e rivela il fraintendimento di fondo. La gente pensa che la soluzione siano prompt migliori, più esempi few-shot, istruzioni di sistema più stringenti. "Basta dire al modello di non allucinare."

È come dire a un modello di previsioni meteorologiche di non sbagliare. La natura probabilistica non è un difetto da correggere con una patch — è il meccanismo fondamentale del funzionamento del sistema.

Una volta un investitore mi ha detto, senza mezzi termini: "Basta usare GPT e aggiungere qualche regola sopra." Gli ho chiesto se si fiderebbe di una calcolatrice corretta nel 95% dei casi. Ha riso. Gli ho detto: "È questo che stai proponendo per la compliance bancaria." Ha smesso di ridere.

Le modalità di fallimento tecnico vanno più a fondo dell'allucinazione. Ai wrapper manca quella che chiamerei persistenza dello state-schema. Man mano che una conversazione procede, la finestra di contesto si riempie. Le informazioni delle prime fasi della conversazione vengono compresse o scartate. Il modello può contraddirsi all'interno di una singola sessione senza avere alcuna consapevolezza di averlo fatto. Nel servizio clienti, questo significa che l'agente potrebbe verificare la tua identità al turno 3 e poi chiederti di verificarla di nuovo al turno 15 — o peggio, saltare del tutto la verifica perché il flusso della conversazione l'ha "persuaso" che la verifica fosse già avvenuta.

Questa è la vulnerabilità che chiamo Infinite Freedom Fallacy. Poiché l'LLM non ha vincoli strutturali rigidi su ciò che può dire o fare, un utente sufficientemente astuto — o una situazione sufficientemente complessa — può spingerlo in stati che violano regole di business, requisiti normativi o la logica di base. Non puoi risolvere questo con il prompting. Serve un tipo di architettura completamente diverso.

Ho scritto di questo problema in modo approfondito nella versione interattiva della nostra ricerca, ma l'intuizione di fondo è semplice: bisogna separare la voce dal cervello.

Il 20% che manda tutto in frantumi

C'è uno schema che ho visto in ogni settore in cui lavoriamo, e credo spieghi perché così tante implementazioni di AI seguono la traiettoria di Klarna.

Nel 2025 l'AI può gestire con competenza circa l'80% delle interazioni di routine ad alta frequenza. Reimpostazioni di password, controlli sullo stato degli ordini, risposte a FAQ di base — sono problemi risolti. Il restante 20% delle interazioni è quello che conta davvero. Sono le controversie complesse, i casi limite, i momenti in cui un cliente è esasperato o confuso o spaventato. E sono i principali driver della reputazione del marchio e della responsabilità finanziaria.

Klarna ha ottimizzato per l'80% e ignorato il 20%. Il calcolo sembrava ovvio: automatizza le cose facili, risparmia milioni. Ma il 20% è dove la fiducia si costruisce o si distrugge. Un cliente che reimposta la password senza intoppi non lo racconta a nessuno. Un cliente che passa 45 minuti intrappolato in un loop di AI cercando di risolvere un errore di fatturazione lo racconta a tutti.

L'80% delle interazioni che l'AI gestisce bene è invisibile al tuo marchio. Il 20% che gestisce male è l'unico che tutti ricordano.

L'ironia è che i 10 milioni di dollari di risparmi iniziali di Klarna derivanti dalla riduzione del personale sono stati quasi certamente surclassati dal customer lifetime value che hanno distrutto con esperienze degradate. Quando sei un'azienda da 14,6 miliardi di dollari che si prepara a un'IPO, un calo del 22% nella soddisfazione dei clienti non è un problema di metriche — è un problema esistenziale.

Che cosa significa davvero "AI deterministica"?

Quindi, se i wrapper sono il problema, qual è la soluzione? Qui devo diventare leggermente tecnico, ma prometto di restare concreto.

In Veriprajna costruiamo quella che si chiama AI neuro-simbolica. Il nome suona accademico, ma il concetto è intuitivo: si prende la fluidità linguistica di una rete neurale e la si vincola dentro la logica rigida di un motore di ragionamento simbolico. La rete neurale si occupa del lavoro "morbido" — comprendere il linguaggio naturale, generare risposte leggibili dagli esseri umani, interpretare query ambigue. Il motore simbolico si occupa del lavoro "duro" — far rispettare le regole, validare la logica, garantire che ogni output sia tracciabile fino a una fonte verificata.

Noi lo chiamiamo il Sandwich Neuro-Simbolico. Prima che una query raggiunga l'LLM, uno strato di validazione dell'intento la confronta con i vincoli di policy e la filtra alla ricerca di input avversariali. Dopo che l'LLM ha generato una risposta, un motore di validazione — tipicamente una macchina a stati finiti o un solver logico — verifica ogni affermazione rispetto al knowledge graph e ogni azione rispetto alle regole di business. Se la risposta viola un qualsiasi vincolo, non passa. Punto.

C'è una tecnica che usiamo, chiamata constrained decoding — nota anche come token masking — che trovo particolarmente elegante. Invece di lasciare che il modello generi liberamente e poi controllare l'output, impediamo fisicamente che certi token vengano generati fin dall'inizio. Se il modello sta producendo un report di compliance fiscale, lo strato simbolico garantisce che ogni numero corrisponda a un calcolo verificato. Il modello letteralmente non può allucinare un numero, perché i token allucinati vengono mascherati fuori dalla distribuzione di probabilità prima che avvenga la generazione.

Non si tratta di "aggiungere guardrail". È un'architettura fondamentalmente diversa in cui l'LLM è la voce e il motore simbolico è il cervello, e alla voce non è mai permesso parlare senza l'approvazione del cervello.

Quando il knowledge graph ci ha salvati da un errore da 2 milioni di dollari

Il RAG standard — retrieval-augmented generation — ha un problema di cui la maggior parte delle persone non parla. Si basa sulla similarità vettoriale per trovare i documenti rilevanti. Ma la similarità vettoriale non comprende la direzionalità. "L'azienda A ha citato in giudizio l'azienda B" e "L'azienda B ha citato in giudizio l'azienda A" potrebbero avere embedding vettoriali quasi identici, eppure descrivono situazioni legali completamente opposte.

L'abbiamo scoperto a nostre spese durante un pilota legale. Il nostro sistema stava analizzando lo storico dei contenziosi per un cliente aziendale, e il setup RAG standard continuava a confondere i ruoli di attore e convenuto. Gli output erano fluidi, ben strutturati e pericolosamente sbagliati.

È stato allora che siamo passati a quello che chiamiamo Citation-Enforced GraphRAG. Invece di riversare i documenti in un vector store, li analizziamo trasformandoli in un knowledge graph — entità collegate da relazioni tipizzate e direzionali. Quando il sistema formula un'affermazione, deve poterla ricondurre a nodi e archi specifici del grafo. Se il grafo non può sostenere l'affermazione, il sistema non la formula.

Il miglioramento in accuratezza è stato drammatico — dal 30 al 35% superiore al RAG standard su compiti complessi di ragionamento multi-hop. Ma, cosa più importante, ci ha dato qualcosa che nessuna quantità di prompt engineering avrebbe potuto darci: un audit trail. Ogni output può essere ricondotto all'esatto percorso di ragionamento, da entità a entità, da relazione a relazione. Un responsabile della compliance può vedere perché il sistema è giunto a una conclusione, non solo cosa ha concluso.

Per l'analisi tecnica completa di come questa architettura funziona nei diversi domini — bancario, legale, manifatturiero — vedi il nostro approfondimento tecnico.

La discussione che ha quasi spaccato il mio team

Voglio essere onesto su una cosa. Costruire in questo modo è più difficile. Significativamente più difficile. E c'è stato un momento, forse diciotto mesi fa, in cui il mio team ha avuto una vera discussione sul fatto che stessimo sovraingegnerizzando.

Eravamo in una sala riunioni — lavagne coperte di diagrammi di architettura — e uno dei nostri ingegneri senior sosteneva che avremmo dovuto rilasciare un MVP basato su wrapper per un cliente manifatturiero. "Portiamo dentro i ricavi, dimostriamo il concetto, irrobustiamo l'architettura dopo." Era un argomento ragionevole. Il cliente era entusiasta. La tempistica era stretta. E ogni concorrente nel nostro spazio stava rilasciando prodotti wrapper e chiudendo contratti.

Ricordo il silenzio dopo che aveva finito. Poi Priya — la stessa ingegnere che aveva scovato la citazione fantasma — ha aperto una slide che teneva da parte. Mostrava tre casi reali del trimestre precedente in cui sistemi di AI basati su wrapper avevano generato output che, se seguiti, avrebbero violato requisiti normativi. Non violazioni ipotetiche. Reali, colte solo perché per caso c'erano degli esseri umani nel processo.

Ho deciso di mantenere la rotta. Abbiamo perso quel contratto a favore di un concorrente che ha rilasciato più in fretta. Sei mesi dopo, il sistema di quel concorrente ha prodotto una violazione di compliance che è costata al loro cliente un intervento di remediation a sette cifre. Il cliente è venuto da noi.

La velocità senza correttezza non è un vantaggio competitivo. È un rischio a scoppio ritardato.

Non racconto questa storia per sembrare preveggente. La racconto perché la pressione a rilasciare in fretta e iterare dopo è enorme, e nella maggior parte dei contesti software è l'istinto giusto. Ma nei settori regolamentati — bancario, sanitario, legale, manifatturiero — "iterare dopo" significa "sistemarlo dopo la violazione". E le violazioni in questi domini non prevedono un periodo di grazia.

Perché il 2026 è l'anno in cui arriva il conto

Ecco il quadro macro. McKinsey ha rilevato che, mentre l'88% delle organizzazioni usa l'AI, solo il 39% può indicare un impatto positivo sugli utili a livello aziendale. Quel divario sta per diventare insostenibile.

La fase "investi e impara" dell'adozione dell'AI è finita. I CFO non chiedono più "Stiamo usando l'AI?". Chiedono "Qual è l'impatto sull'EBIT?". E per la maggior parte delle organizzazioni la risposta onesta è: "Abbiamo risparmiato un po' di tempo su compiti amministrativi."

Non basta. Risparmiare tempo su email e presentazioni è "Productivity AI" — utile ma incrementale. Ciò di cui le imprese hanno davvero bisogno è l'"Operational AI" — sistemi che eliminano l'attrito in denaro reale nell'economia fisica. Prevenire le rotture di stock. Cogliere le violazioni di compliance prima che accadano. Ridurre gli 890 miliardi di dollari di costo annuo dei resi nel retail fornendo una prova virtuale accurata invece di immagini fantasiose generate dall'AI che sembrano bellissime ma non riflettono come il tessuto cade realmente su un corpo umano.

La storia di Klarna è istruttiva qui perché le loro metriche sembravano un ROI. Costo per transazione giù del 40%! Ma stavano misurando la cosa sbagliata. Hanno misurato il tempo risparmiato e il personale ridotto. Non hanno misurato la fiducia erosa e i clienti persi. Quando si considerano i costi di riassunzione, il danno al marchio e la perdita di 99 milioni di dollari del primo trimestre, i "risparmi" evaporano.

Le imprese che vinceranno nel 2026 sono quelle che misurano le perdite operative evitate, non le ore risparmiate. Quelle che implementano un'AI capace di simulare 10.000 scenari di interruzione della supply chain nell'arco di una notte e di costruire playbook di ripresa dalle crisi che nessun team umano potrebbe produrre in un decennio. Quelle i cui sistemi di AI sanno dimostrare il proprio ragionamento a un regolatore, non solo produrre un paragrafo convincente.

E gli esseri umani?

Le persone contestano sempre questa impostazione. "Se l'AI diventa così brava, che ne sarà delle persone?"

Penso che la risposta sia l'opposto di ciò che la maggior parte delle persone si aspetta. Le organizzazioni che implementano un'AI profonda e architetturalmente solida non hanno bisogno di meno persone: hanno bisogno di persone diverse. La tradizionale piramide della consulenza, con la sua enorme base di analisti junior che fanno sintesi di dati e costruiscono presentazioni, sta crollando. L'AI fa quel lavoro più velocemente e meglio. Ma il bisogno del discernimento delle figure senior, di pensiero strategico, di supervisione etica e di empatia umana autentica non solo sopravvive — si sta intensificando.

Ciò che sta emergendo è quello che il settore chiama il modello "Obelisco": team più snelli e più densi di esperti, dove i professionisti a inizio carriera sono "facilitatori di AI" che progettano e gestiscono i workflow di AI, i professionisti a metà carriera sono "architetti dell'ingaggio" che definiscono i problemi che vale la pena risolvere, e i leader senior si concentrano sul lavoro profondamente umano di costruire fiducia e navigare l'ambiguità.

L'assistente AI interno di McKinsey, "Lilli", è usato dal 72% della sua forza lavoro e ha ridotto del 30% i tempi di ricerca. "Deckster" di BCG automatizza la creazione di presentazioni. Ma nessuna delle due società si sta rimpicciolendo. Si stanno ristrutturando — sostituendo il volume con la precisione, sostituendo le ore fatturate con i risultati consegnati.

L'errore di Klarna non è stato usare l'AI. È stato usare l'AI come sostituto degli esseri umani invece che come amplificatore delle capacità umane. Quella distinzione sembra sottile. Non lo è. È la differenza tra un risparmio di 10 milioni di dollari e una perdita di 99 milioni di dollari.

L'architettura della fiducia

Voglio chiudere con qualcosa che mi ronza in testa da quella notte in cui Priya ha trovato la citazione fantasma.

Stiamo vivendo un momento in cui i sistemi di AI possono produrre output indistinguibili dal lavoro di un esperto umano — e che tuttavia sono completamente sbagliati, e sbagliati con assoluta sicurezza. Non è una limitazione temporanea che verrà risolta da GPT-6 o GPT-7. È una proprietà intrinseca del funzionamento dei modelli linguistici probabilistici. Ottimizzano per la plausibilità, non per la verità. E nei domini in cui la verità conta — dove una risposta sbagliata significa una violazione di compliance, una diagnosi errata, un precedente legale fabbricato — la plausibilità è la cosa più pericolosa al mondo.

La soluzione non è abbandonare l'AI. La soluzione è costruire sistemi di AI in cui la verità è imposta architetturalmente, non sperata probabilisticamente. Dove ogni affermazione è riconducibile a una fonte verificata. Dove il sistema letteralmente non può generare un output che violi le regole del dominio in cui opera. Dove l'audit trail non è una funzionalità — è la base.

È questo che costruiamo in Veriprajna. Non perché l'AI deterministica sia più facile — è considerevolmente più difficile. Non perché faccia una figura migliore in demo — i wrapper fanno demo splendide. Ma perché nei settori che non possono permettersi di tirare a indovinare, l'unica architettura sostenibile è quella che rende impossibile indovinare.

Klarna ha imparato questa lezione al costo di 700 posti di lavoro, un calo del 22% del CSAT e una perdita trimestrale di 99 milioni di dollari. La domanda per ogni leader d'impresa che sta leggendo è semplice: vuoi impararla dalla loro storia o dalla tua?

Il futuro dell'AI aziendale non riguarda il rendere i modelli linguistici più intelligenti. Riguarda il renderli responsabili — architetturalmente, dimostrabilmente, immutabilmente responsabili.

L'era dei wrapper è finita. Ciò che verrà dopo sarà più difficile da costruire, più lento da rilasciare, e varrà ogni mese in più di ingegneria. Perché alla fine l'unico sistema di AI che vale la pena implementare è quello su cui scommetteresti la tua azienda. E non dovresti mai scommettere la tua azienda su un sistema che non sa mostrare il proprio lavoro.