L'affermazione era vera. L'ho uccisa comunque.
La prima email che mi sono rifiutato di inviare era completamente accurata.
Ricordo la frase perché l'ho riletta una quarantina di volte: "Ho visto che avete recentemente portato la flotta One-Way Truckload a 2.735 camion." Ogni parola era vera. Werner Enterprises aveva davvero riportato quella flotta, nel proprio Form 10-K, depositato presso la SEC. E seduto davanti alla demo che stavo costruendo, ho ucciso comunque quell'affermazione.
Quella decisione mi è sembrata sbagliata per circa un giorno. Poi mi è sembrata il punto di tutto.
Avevo iniziato questo progetto credendo, come quasi tutti quelli che costruiscono nell'AI sales in questo momento, che il nemico fosse l'allucinazione. Il modello inventa qualcosa, la cosa falsa finisce nell'email, il prospect se ne accorge, la tua credibilità muore. Intercetta le fabbricazioni e hai vinto. Quella cornice è limpida, funziona bene in demo, e ora penso che sia silenziosamente responsabile di tanti domini di invio bruciati. La frase su Werner non conteneva alcuna fabbricazione. Era comunque un'affermazione che non avrei mai lasciato uscire dall'edificio.
Questo è un saggio su ciò che mi ha fatto cambiare idea, raccontato come è successo davvero, cioè lentamente e con una settimana imbarazzante in mezzo. Se vuoi vedere ciò che alla fine ho costruito, vive qui: veriprajna.com/it/demos/ai-sales-intelligence-e-outreach-verificato. Ma il prodotto è la parte noiosa. La parte interessante è perché una frase vera non è una frase sicura, e perché ho smesso di fidarmi del modello per dire la differenza.
La settimana in cui ho provato a far correggere al modello i propri compiti
Ho passato circa una settimana a cercare di far intercettare al language model le proprie citazioni obsolete, e voglio essere onesto: non ha funzionato.
L'impianto sulla carta era ragionevole. Un agente ricercatore estrae i fatti. Un agente redattore scrive la bozza dell'email, vincolato a usare solo quei fatti. Poi un agente fact-checker legge la bozza contro le fonti e segnala tutto ciò che non regge. Tre agenti, una pipeline ordinata, il tipo di architettura che in una design review ti fa fare un cenno di assenso. Mi aspettavo davvero che il fact-checker fosse la parte facile.
È stata la parte che si è rotta. Non con rumore. Quello era il problema. Il fact-checker leggeva la bozza su Werner, vedeva una frase sui 2.735 camion, trovava una fonte che diceva 2.735 camion e la approvava con sicurezza. Cosa corretta, se l'unica domanda è "una fonte sostiene questo numero." Il modello non aveva un senso duraturo del fatto che la fonte avesse più di due anni e che la frase dicesse "recentemente." Quando lo spingevo a ragionare sulle date, a volte intercettava l'obsolescenza e a volte la lasciava passare, e non riuscivo a prevedere quale. Un checker che non puoi prevedere non è un checker. È una seconda opinione.
Il momento in cui mi è davvero calato è stato a tarda sera, quando ho fatto passare la stessa bozza dal fact-checker tre volte e ho ottenuto due approvazioni e un rifiuto, senza alcun cambiamento all'input. Ci ho fissato per un po'. Stavo chiedendo a un sistema probabilistico di essere il gate deterministico su un altro sistema probabilistico.
Stavo chiedendo a un LLM di essere l'arbitro affidabile di un LLM, e chiamavo il risultato "verifica."
Quella non è verifica. Sono due modelli che concordano, che è una cosa diversa e molto più debole. Se l'intera ragione per cui ti serve un checker è che l'output del modello non può essere preso per buono al valore facciale, allora l'output di un secondo modello non può essere la cosa di cui ti fidi per controllarlo. Avevo costruito una sala degli specchi e ci avevo messo sopra un adesivo di compliance.
Cosa è peggio, un fatto inventato o uno vero?
Ciò che mi ha sorpreso di più mentre costruivo questo è stato capire che le fabbricazioni non erano mai i fallimenti spaventosi. Lo erano le affermazioni vere ma usate male.
Pensa a cosa succede davvero quando un AI SDR allucina un dettaglio aziendale. Spesso è nonsense, palesemente fuori, il tipo di cosa che un prospect legge e cancella. Imbarazzante, certo. Ma l'affermazione che ti mette nei guai seri è quella verificabile e corretta eppure sbagliata nel contesto. Passa ogni filtro "è inventata?" proprio perché non è inventata. La grammatica è perfetta. Il numero è reale. Ed è una bugia sul tempo presente.
Ho iniziato a chiamarlo uso improprio contestuale, e una volta che gli avevo dato un nome lo vedevo dappertutto nella demo che stavo assemblando. Ha più di una forma, ma ogni versione condivide la proprietà che lo rende pericoloso: ciascuna è un'affermazione vera.
La forma che mi ha insegnato di più è la fonte obsoleta, e Werner è dove l'ho vista chiaramente per la prima volta. "Di recente è cresciuta a 2.735 camion" cita un vero 10-K, ma quel filing è arrivato il 2024-02-26, e rispetto alla data di lavoro della demo ha ben più di due anni. Il numero non ha smesso di essere vero. La parola "recentemente" ha smesso di essere vera. Non sono lo stesso fatto, e un controllo di matching sulle fonti li tratta come identici.
Ho ricostruito la stessa forma una seconda volta con un lead sintetico, una azienda di logistica mid-market chiamata Northwind, così potevo mostrare il pattern senza fingere che un'azienda reale avesse detto qualcosa che non aveva detto. La bozza affermava che Northwind aveva "di recente espanso in APAC." C'è una fonte dall'aspetto reale. La fonte è datata marzo 2019, che nella demo corrisponde a circa 2.652 giorni, più di sette anni. La sovrapposizione di grounding tra affermazione e fonte è un netto 100%. L'entità corrisponde. Ed è comunque il tipo di frase che fa pensare a un prospect che non lo guardi dal Mondiale scorso.
Un fatto vero su una fonte obsoleta è comunque una bugia sul presente. La data fa parte dell'affermazione, che la frase lo ammetta o no.
L'altra forma è la collisione di omonimia, e anche quella l'ho tenuta come caso sintetico. "Northwind Logistics ha appena raccolto un Series B da 40 milioni di dollari" ha una fonte reale dietro. La fonte parla di Northwind Inc., una startup di cybersecurity di Austin, un'azienda completamente diversa che capita di condividere un nome. Ogni parola è accurata su una Northwind. Niente di tutto ciò è accurato su questa.
Nota cosa hanno in comune tutti e tre gli esempi. Nessuno di loro è un'allucinazione. Se costruissi tutta la tua storia di safety intorno all'intercettare le fabbricazioni, spedirresti tutti e tre. Questa è la modalità di fallimento dietro i fallimenti clamorosi degli AI-SDR che tutti citano e che nessuno spiega davvero. Gli strumenti single-pass allucinano una fetta misurabile di affermazioni specifiche sul prospect, da qualche parte nell'intervallo del 12-18 percento secondo un conteggio di settore (AI SDR Industry Report, 2026), ma le fabbricazioni sono i fallimenti che almeno puoi immaginare di intercettare. Le affermazioni vere-ma-obsolete, vere-ma-entità-sbagliata sono quelle che sembrano un successo fino al momento in cui ti costano.
Cosa mi ha fatto smettere di fidarmi del modello e iniziare a fidarmi di una sottrazione di date
La cosa che alla fine ha funzionato era quasi offensivamente semplice, e ci ho resistito più a lungo di quanto avrei dovuto.
Se il problema con l'affermazione su Werner è che "recentemente" punta a una fonte più vecchia di una finestra di attualità sensata, allora il controllo non è un compito di ragionamento. È aritmetica. Prendi la data della fonte, prendi la data di lavoro, sottrai. Se l'affermazione usa linguaggio di attualità e il gap è maggiore di 365 giorni, l'affermazione è obsoleta e non viene inviata. Età della fonte 2652 giorni maggiore di 365 giorni su un'affermazione di attualità, quindi fallisce. Non c'è prompt, non c'è temperature, non c'è "as an AI language model." C'è un numero e una soglia.
Una volta che mi sono permesso di scrivere quello, anche il resto dei controlli voleva essere codice. L'affermazione è davvero entailata da uno snippet di fonte, misurata come sovrapposizione di token sulle parole di contenuto, con il nome stesso dell'azienda escluso così che una frase non possa ottenere un punteggio alto solo ripetendo "Werner, Werner, Werner"? Codice. La fonte parla di questa entità e non di un'altra omonima? Codice. Il language model è ancora l'autore, ed è un autore genuinamente bravo. Semplicemente non è il giudice.
Alla fine ho formulato il principio in due modi che ora ripeto di continuo. Uno è "gli agenti consigliano, il codice decide." L'altro è "non un LLM che giudica un LLM." La rete neurale gestisce ciò in cui le reti neurali sono brave, cioè scrivere una bozza fluente e umana. Un verificatore deterministico, in puro Python, gestisce ciò in cui il codice è bravo, cioè applicare la stessa regola allo stesso modo ogni singola volta. Autorialità neurale, verifica simbolica. La parola di settore per quell'accoppiata è neurosimbolico, anche se mi interessa meno l'etichetta della proprietà che mi compra.
Modelli migliori scrivono frasi migliori. Non rendono recente un filing di due anni. Quello non è un gap di capacità. È un errore di categoria.
E la proprietà che compra è la riproducibilità. Quando faccio girare il verificatore sullo stesso input, ottengo lo stesso verdetto, ogni volta. Sembra una piccola cortesia di engineering. In realtà è tutto il gioco, perché la riproducibilità è ciò che rende una decisione certificabile. Posso consegnarti la traccia. Età della fonte 2652 giorni, maggiore di 365, linguaggio di attualità presente, verdetto obsoleta, affermazione rimossa. Puoi rieseguirla e ottenere il risultato identico. Un giudice LLM, anche uno buono, non può prometterti quello. Ho vissuto la sera delle tre-esecuzioni-due-verdetti. Non sto costruendo una storia di compliance sopra quella.
Non è solo un problema di allucinazione mascherato?
Mi fanno qualche versione di questa domanda in quasi ogni conversazione, di solito da qualcuno tecnico, e la mia risposta col tempo si è accorciata. No. E il motivo per cui non lo è, è il motivo per cui penso che questo lavoro sopravviva alla generazione attuale di modelli.
La cornice dell'allucinazione assume silenziosamente che la soluzione sia un modello migliore. Contesto più grande, training più pulito, tasso di fabbricazione più basso, e alla fine il problema si riduce a niente. Forse è vero per la fabbricazione pura. Non fa nulla per i fallimenti a cui tengo davvero. Un modello perfetto, uno che non inventa mai un solo fatto, scriverà comunque allegramente "recentemente" sopra un filing del 2024, perché dall'interno della bozza quella frase è vera e fluente ed esattamente ciò che hai chiesto. Il modello non ha alcun obbligo verso il calendario. Il gap tra "cresciuta a 2.735 camion" e "di recente cresciuta a 2.735 camion" non è un gap che la scala chiude.
È qui che il mercato continua a insegnare la lezione nel modo più duro. La categoria AI-SDR ha ottimizzato a fondo per volume e per personalizzazione basata sui segnali, e ha per lo più saltato lo step in cui si riverifica l'affermazione risultante rispetto a una fonte corrente e corretta sull'entità. L'economia non è stata gentile. Il churn enterprise degli AI-SDR gira da qualche parte intorno al 50-70 percento l'anno (UserGems, 2026). La storia ammonitrice più citata, 11x.ai, ha raccolto 74 milioni di dollari e poi si è sfasciata nel 2025 con un churn riportato nell'intervallo del 70-80 percento (TechCrunch). Non pubblichi quei numeri perché il tuo modello ha allucinato di tanto in tanto. Li pubblichi perché l'output sembrava personalizzato e non era affidabile, e gli acquirenti alla fine sentono la differenza anche quando non sanno come chiamarla.
Quindi la tesi a cui continuo a tornare è secca. La personalizzazione non è verifica. Il tuo AI SDR non ha principalmente un problema di allucinazione. Ha un problema di verifica, e un modello base migliore non lo risolverà, perché verifica e provenienza non sono capacità del modello. Sono proprietà del sistema che costruisci intorno al modello.
La personalizzazione non è verifica. Verifica e provenienza non sono capacità del modello. Sono proprietà del sistema che costruisci intorno al modello.
Cosa può significare davvero il "100%"
Voglio stare attento qui, perché è esattamente il punto in cui un founder è tentato di esagerare nelle affermazioni, e l'azienda che sto costruendo prende il nome dall'istinto opposto.
Ci sono due numeri nella demo e non sono lo stesso numero. Il primo è il Veracity Score, che è semplicemente le affermazioni supportate divise per il totale delle affermazioni fattuali nella bozza. Risponde a "quanto di ciò che l'AI ha scritto si è rivelato vero," e su una bozza reale spesso è ben sotto il 100, che è la cosa onesta e utile di quel numero. L'email su Werner perde l'affermazione in evidenza. L'email su Northwind ne perde due. Quello è il sistema che funziona, non che fallisce.
Il secondo numero è l'integrità dell'invio, ed è al 100% per costruzione ogni volta che sopravvive anche solo qualcosa, perché il policy gate rimuove ogni affermazione non supportata prima che l'email sia autorizzata all'invio. La garanzia non è "l'AI aveva sempre ragione." La garanzia è "l'email che esce contiene solo affermazioni supportate da fonti." Sono promesse molto diverse, e ho visto persone confonderle in una molto più grande e molto più falsa.
C'è anche un benchmark, ed ecco la frase che mi rifiuto di accorciare: su un golden set fisso e etichettato a mano di 25 casi, il verificatore deterministico ottiene 25 verdetti giusti su 25. Quello è il 100% su quel benchmark etichettato. Non è un'affermazione sul mondo aperto, non è una promessa sulla tua casella di posta, e non è assolutamente "zero allucinazione," una frase che penso nessuno di onesto dovrebbe dire. Il modello scrive ancora le bozze. Le bozze contengono ancora affermazioni non provate. Il punto è che quelle non provate vengono intercettate e rimosse, e l'intercettazione è abbastanza deterministica da certificare. Chiunque ti venda una garanzia di zero-allucinazione ti sta vendendo la cosa che ho passato una settimana a non riuscire a costruire.
Dirò anche chiaramente, perché il brief a cui mi attengo lo richiede, che i connettori della demo sono simulati. Il pull EDGAR, il retrieval delle news, il write-back CRM, l'invio effettivo, tutti stubbati. Ciò che è reale è il meccanismo: i check, il gate, l'audit trail, e gli estratti del 10-K di Werner, che sono genuini atti di pubblico registro. Ti sto mostrando come decide il motore, non una pipeline di produzione con i tuoi dati dentro. Se vuoi guardarlo decidere, è qui ancora una volta: veriprajna.com/it/demos/ai-sales-intelligence-e-outreach-verificato.
La domanda con cui resto
Ho scoperto che l'ultima cosa che questo build ha cambiato in me era più piccola della tesi, ed è quella che è rimasta più a lungo.
C'è un terzo lead nella demo, un broker-dealer sintetico regolamentato FINRA, e la sua bozza esce completamente pulita. Ogni affermazione supportata, niente rimosso, un Veracity Score perfetto. E il policy gate lo instrada comunque a un umano, perché è regolamentato e C-suite e un deal grande, e la regola dice che un umano guarda quelli a prescindere da quanto sia pulita la bozza. La prima volta che ho visto un'email impeccabile tenuta in revisione, il mio istinto è stato che il sistema avesse fatto un errore. Non l'aveva fatto. Avevo solo assunto, senza accorgermene, che correttezza e sicurezza fossero la stessa proprietà.
Non lo sono. Un'affermazione può essere vera e non sicura. Una bozza può essere pulita e avere comunque bisogno di una persona. Tutto il lavoro si è rivelato separare quelle idee e costruire per entrambe, invece di comprimerle in un unico numero che fa un bel titolo.
Quindi la domanda che ti lascerei è quella che ora mi pongo prima che qualsiasi cosa scritta dall'AI lasci le mie mani. Non "è vera," a cui di solito posso rispondere e che di solito non basta. Quella più dura: posso dimostrare, proprio adesso, quale fonte corrente sostiene questa esatta affermazione, e quella prova sopravviverebbe a qualcuno che volesse farla fallire?
Se la risposta è no, non importa quanto il modello diventi bravo. La frase non è pronta per essere inviata.
