Il livello di verifica e governance per l'outreach IA
Gli AI SDR ottimizzano per il volume, e i modelli a passaggio singolo spediscono intatte affermazioni da fonte obsoleta, su entità sbagliata e eccessive. Il Veracity Engine consente a un LLM di redigere la bozza, poi controlli in puro Python rimuovono ogni affermazione non provata, valutano ciò che resta e lo instradano attraverso un policy gate calibrato sul rischio. Gli agenti consigliano, il codice decide.
100%
Integrità dell'invio quando un'affermazione sopravvive
Ogni affermazione nell'email inviata è supportata da fonti
25/25
Accuratezza del verdetto sul golden set etichettato
Deterministico e riproducibile (benchmark su 25 casi)
3
Controlli deterministici prima dell'invio
Grounding, corrispondenza dell'entità, validità temporale
Questa è una demo eseguibile. Retrieval, CRM e invio email sono simulati, e i lead sono sintetici tranne Werner Enterprises, i cui estratti del 10-K sono pubblici e reali.
La modalità di fallimento dietro i clamorosi flop degli AI SDR.
Gli AI SDR sono costruiti per inviare di più. Gli LLM a passaggio singolo allucinano una quota misurabile di affermazioni specifiche sul prospect, e gli strumenti di personalizzazione non riverificano mai l'affermazione risultante rispetto a una fonte attuale e corretta per l'entità. Così affermazioni da fonte obsoleta, su entità sbagliata e eccessive partono intatte, e la verifica è aggiunta dopo l'invio o non avviene affatto.
Il contesto di settore è netto. Gli LLM a passaggio singolo allucinano dal 12 al 18% delle affermazioni specifiche sul prospect (AI SDR Industry Report, 2026). Il churn degli AI SDR enterprise è dal 50 al 70% annuo (UserGems, 2026). 11x.ai ha raccolto $74M e è collassata nel 2025 con un churn dal 70 all'80% (TechCrunch). Solo il 7% delle imprese ha una governance specifica per l'agentic (Deloitte, 2026), e Gartner prevede che oltre il 40% dei progetti di IA agentica sarà abbandonato entro il 2027. Da novembre 2025, un tasso di spam superiore allo 0.3% innesca il rifiuto a livello SMTP di Gmail e un recupero del dominio di 6-12 settimane.
Il vero bug non è la grammatica sbagliata. La grammatica è perfetta, e questo la rende peggiore. Il pericolo è un'affermazione citata correttamente ma usata in modo fuorviante: un fatto vero tratto da una fonte obsoleta, un fatto vero sulla società omonima sbagliata, o un'affermazione del vendor che la fonte contraddice. Lo chiamiamo uso contestuale improprio, e i modelli base migliori non lo eliminano. Un modello perfetto non può comunque dimostrare a FINRA o al GDPR quale fonte attuale abbia supportato quale affermazione.
Un LLM redige la bozza. Il codice deterministico decide cosa parte. Questo è neurosimbolico: autorialità neurale, verifica simbolica.
La pipeline esegue Lead, poi Research (una Fact Sheet in cui ogni fatto è legato a una fonte datata), poi Draft (un Writer LLM vincolato alla sola Fact Sheet), poi Verify (controlli deterministici), poi un Policy Gate, poi una ricevuta di audit firmata, poi una riscrittura CRM simulata. Il passo di verifica non è un LLM che giudica un LLM. È puro Python, così lo stesso input produce lo stesso verdetto a ogni esecuzione.
Ogni affermazione fattuale è testata rispetto alla fonte citata. Il primo controllo che fallisce vince, in ordine di priorità: unsourced, poi contradicted, poi entity mismatch, poi stale.
L'affermazione è implicata da uno snippet di fonte? La sovrapposizione di token deve essere almeno 0.5 dei token di contenuto, e i token del nome dell'azienda sono esclusi così un'affermazione non può ottenere un punteggio alto solo ripetendo il nome dell'azienda.
La fonte riguarda questo prospect esatto, non un'altra società omonima? Una fonte su un'altra impresa con lo stesso nome fallisce, anche quando le parole coincidono.
Se l'affermazione usa un linguaggio di recency («recently», «just», «now», «this week»), la fonte deve essere entro 365 giorni. Le fonti più vecchie sono marcate stale, anche quando il fatto è vero.
Due ulteriori guardrail girano insieme a questi: un controllo di contraddizione del vendor, e una soglia di fedeltà della frase di 0.3 che impedisce a un LLM live di cavalcare un id di fatto valido su una frase allucinata. Il vocabolario dei verdetti guida i colori dell'interfaccia: supported (verde) passa; stale (ambra), entity_mismatch (rosso), contradicted (rosso) e unsourced (rosso) no.
Il gate rimuove ogni affermazione non supported, poi riporta due numeri. Il Veracity Score è le affermazioni supported divise per le affermazioni fattuali totali nella bozza, cioè quanto di ciò che l'IA ha scritto era effettivamente vero. L'integrità dell'invio è 100% ogni volta che almeno un'affermazione sopravvive, perché l'email inviata contiene allora solo affermazioni supportate da fonti. Questa è la garanzia di progettazione.
Il routing segue il rischio. L'email viene rivista se non sopravvive nulla di sicuro o la copertura della bozza scende sotto 0.5. Viene inviata a revisione umana se è ad alto valore (regolamentata, o C-suite, o una trattativa di almeno $100,000) anche su una bozza pulita al 100%. Altrimenti è idonea all'invio automatico. La modalità di confronto, AI SDR Standard, ricerca, redige e invia con 0 affermazioni verificate prima dell'invio; l'app lo mostra come un controllo ombra a posteriori di ciò che è già partito.
Tre lead dal corpus della demo (data di ancoraggio 2026-06-17). Ogni immagine sotto è uno screenshot dell'app in esecuzione.
Per il lead Northwind Logistics (un 3PL mid-market sintetico), la bozza afferma che l'azienda «recently expanded into APAC». La fonte è una vera notizia Northwind APAC, la sovrapposizione di grounding è 100% e l'entità è corretta. Ma la fonte è datata 2019-03-14, cioè 2,652 giorni (circa 7.3 anni) rispetto a una finestra di recency di 365 giorni, quindi la validità temporale fallisce e l'affermazione viene rimossa. Il Veracity Engine mantiene le affermazioni supported (in testa una spinta ad assumere sei amministratori Salesforce, evidenziata da un annuncio di lavoro datato 2026-06-09), intercetta le due affermazioni cattive e invia un'email supportata da fonti al 100%.
Werner Enterprises, Inc. è una società pubblica reale, e le fonti W1 e W2 sono estratti verbatim dal suo Form 10-K FY2023 (SEC EDGAR, CIK 0000793074, depositato il 2024-02-26). L'affermazione della bozza «recently growing your One-Way Truckload fleet to 2,735 trucks» è fattualmente reale, ma il filing ha più di due anni, quindi un inquadramento «recently» viene intercettato come stale. Questo è esattamente il divario di uso temporale improprio che gli strumenti di personalizzazione sui filing SEC lasciano aperto. (Il contatto e l'annuncio di lavoro in questo lead sono sintetici; solo Werner e i suoi estratti del 10-K sono reali.)
Di nuovo sul lead Northwind, la bozza afferma anche un «$40M Series B». La fonte citata è reale, ma riguarda «Northwind Inc.», una startup di cybersecurity di Austin, non «Northwind Logistics». Il controllo di corrispondenza dell'entità fallisce e l'affermazione viene rimossa prima che possa partire.
Atlas Capital Markets è un broker-dealer sintetico regolamentato FINRA, con un contatto Chief Revenue Officer e una trattativa da $220,000. Anche una bozza pulita al 100%, interamente supportata da fonti, è forzata alla revisione umana dal policy gate, perché è regolamentata, C-suite e sopra la soglia di $100,000. Una bozza pulita non è la stessa cosa di una inviabile.
Ogni email produce una ricevuta di audit JSON scaricabile: il provider e la versione del modello, il prospect e il livello di rischio, la fact sheet, il verdetto di ogni affermazione con lo span della fonte e le date, il veracity score, la regola di policy scattata e l'approvatore umano. Su un golden set etichettato di 25 casi, il verificatore deterministico ottiene 25/25 di accuratezza del verdetto: 10 su 10 affermazioni hard o cattive intercettate, 15 su 15 affermazioni pulite preservate. Quella riproducibilità è ciò che lo rende certificabile, e un giudice LLM no. Attribuiamo il 25/25 a questo benchmark etichettato, mai come garanzia open-world.
Lo stesso toggle con cui la demo confronta, affiancati.
| Dimensione | AI SDR Standard | Veracity Engine |
|---|---|---|
| Affermazioni verificate prima dell'invio | 0 | Ogni affermazione fattuale, in modo deterministico |
| Chi decide cosa parte | L'LLM invia ciò che ha redatto | Controlli in puro Python, non un LLM |
| Intercettazione di fonti obsolete | Nessuna | Validità temporale, finestra di 365 giorni |
| Entità omonima sbagliata | Nessuna | Controllo di corrispondenza dell'entità |
| Audit trail | Nessuno | Ricevuta JSON firmata per email |
| Gestione dell'alto rischio | Invia comunque | Instradata a revisione umana |
No. Non aggiungiamo un altro AI SDR al mercato. Il Veracity Engine è un livello di verifica e governance che si colloca dopo la bozza: un verificatore deterministico in puro Python controlla ogni affermazione scritta da un'IA rispetto a una fonte datata e corrispondente all'entità, rimuove qualsiasi cosa non provata e scrive una ricevuta di audit firmata prima che l'email sia autorizzata all'invio. Gli AI SDR ottimizzano per il volume; noi decidiamo cosa è sicuro spedire.
Ogni affermazione fattuale nella bozza passa attraverso tre controlli deterministici: grounding (l'affermazione è implicata da uno snippet di fonte, con sovrapposizione di token di almeno 0.5), corrispondenza dell'entità (la fonte riguarda questo prospect esatto, non una società omonima) e validità temporale (se l'affermazione usa un linguaggio di recency, la fonte deve essere entro 365 giorni). Solo le affermazioni che passano sono marcate supported e conservate; tutto il resto viene rimosso. Il verificatore è codice, non un LLM che giudica un LLM, quindi lo stesso input produce sempre lo stesso verdetto.
È esattamente la modalità di fallimento per cui l'abbiamo costruito, che la demo chiama uso contestuale improprio. In un lead lavorato la frase «recently expanded into APAC» è grounded e riguarda l'azienda giusta, ma l'unica fonte è datata 2019, quindi ha 2,652 giorni rispetto a una finestra di recency di 365 giorni e viene intercettata come stale e rimossa. Mostriamo lo stesso schema su un'affermazione reale di Werner Enterprises supportata dal suo 10-K SEC FY2023: fattualmente accurata, ma il filing ha più di due anni, quindi un inquadramento «recently» fallisce la validità temporale.
È lì che un livello di verifica e governance conta di più, perché un'affermazione allucinata o attribuita erroneamente comporta conseguenze normative. Nella demo, il policy gate instrada a revisione umana qualsiasi email regolamentata, inviata a un contatto C-suite, o legata a una trattativa di almeno $100,000, anche quando la bozza è interamente supportata da fonti. Qui la governance è una funzione del rischio, non solo della correttezza.
Ogni email produce una ricevuta di audit JSON scaricabile che registra il provider e la versione del modello, il prospect e il livello di rischio, la fact sheet, il verdetto di ogni affermazione con lo span della fonte e le date, il veracity score, l'esatta regola di policy scattata e l'approvatore umano. Qualsiasi affermazione si riconduce alla sua fonte in secondi. Un modello perfetto non può comunque dimostrare a un auditor quale fonte attuale abbia supportato quale affermazione; una ricevuta sì.
No, e questo è il punto duraturo. I modelli base migliori redigono comunque, e chiunque pretenda un tasso di allucinazione pari a zero non è onesto, quindi il bisogno di provare la provenienza, mantenere un audit trail e applicare un gate sul rischio non scompare. Provenienza, ricevute di audit e un policy gate sono proprietà durature; un writer più forte non elimina il requisito di verificare e governare ciò che scrive.
È una demo eseguibile che prova il meccanismo, non una pipeline in produzione. Le fonti di retrieval (EDGAR, LinkedIn, Greenhouse, notizie), la lettura e scrittura CRM e l'invio email sono simulati, e la fact sheet è pre-costruita; i lead sono sintetici tranne Werner Enterprises, i cui estratti del 10-K sono pubblici e reali. Il verificatore deterministico, il policy gate e la ricevuta di audit sono reali e girano esattamente come mostrato.
La ricerca dietro questa demo — l'architettura, il design della verifica e il blueprint enterprise.
Soluzione completa
Esplora la soluzione AI Sales Intelligence & Outreach Verificato →Il livello di verifica e governance è la parte difficile. Lo costruiamo noi.
Se il vostro team sta lottando su come mettere l'outreach IA di fronte ad acquirenti regolamentati senza rischiare un'affermazione allucinata, ci piacerebbe davvero sentire come ci state pensando. Il problema è di settore e le risposte lo saranno altrettanto.