Il livello di verifica e governance per l'outreach IA

Un verificatore deterministico decide cosa il vostro outreach IA è autorizzato a inviare.

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.

Il volume senza verifica distrugge più pipeline di quanto ne crei

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.

Come funziona il Veracity Engine

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.

I tre controlli deterministici

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.

1. Grounding

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.

2. Corrispondenza dell'entità

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.

3. Validità temporale

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 policy gate

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.

Il caso, dimostrato da capo a fondo

Tre lead dal corpus della demo (data di ancoraggio 2026-06-17). Ogni immagine sotto è uno screenshot dell'app in esecuzione.

Un fatto vero da una fonte obsoleta è comunque la cosa sbagliata da inviare

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%.

Risultato del Veracity Engine per il lead Northwind: il 100% dell'email inviata è supportato da fonti, il 60% della bozza è verificabile, due affermazioni intercettate e rimosse con le ragioni mostrate in linea.
Risultato del Veracity Engine: integrità dell'invio 100%, bozza verificabile 60%, due affermazioni intercettate e barrate con le ragioni.
Pannello di evidenza che mostra grounding al 100% e entità OK, ma il controllo temporale che fallisce: l'età della fonte di 2,652 giorni supera i 365 giorni per un'affermazione di recency, quindi il verdetto è stale.
Il pannello di evidenza: il grounding passa, l'entità passa, la validità temporale fallisce (età della fonte 2,652 giorni oltre la finestra di 365 giorni). Verdetto: stale.

Lo stesso divario su un vero filing SEC

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.)

Un'affermazione reale di Werner Enterprises supportata dal suo 10-K SEC FY2023, intercettata come stale perché il filing ha più di due anni rispetto alla finestra di recency di 365 giorni.
Un'affermazione reale dal 10-K di Werner, fattualmente accurata, intercettata come stale su un inquadramento di recency.

Una collisione di entità omonime

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.

Pannello di evidenza che mostra un fallimento di corrispondenza dell'entità: la fonte di funding citata riguarda Northwind Inc., una startup di cybersecurity di Austin, non Northwind Logistics.
Entity mismatch: la fonte di funding descrive Northwind Inc., non Northwind Logistics.

La governance riguarda il rischio, non solo la correttezza

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.

Atlas Capital Markets instradata a revisione umana perché è regolamentata, C-suite e una trattativa da $220,000, anche se la bozza è interamente supportata da fonti.
Atlas instradata a revisione umana su una bozza pulita al 100%: regolamentata, C-suite, trattativa sopra $100,000.

Una ricevuta firmata, e un benchmark riproducibile

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.

La ricevuta di audit JSON scaricabile con traccia per ciascun controllo, versione del modello, verdetti, span delle fonti, date e la regola di policy scattata.
La ricevuta di audit JSON firmata, con la traccia completa per ciascun controllo.
Il golden set etichettato di 25 casi che ottiene 25 su 25 di accuratezza del verdetto, deterministico e riproducibile.
Il golden set di 25 casi: accuratezza del verdetto 25/25, stesso risultato a ogni esecuzione.

AI SDR Standard versus il Veracity Engine

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

Cosa questa demo non fa

  • ✓ Non rivendica un tasso di allucinazione pari a zero. L'LLM redige comunque la bozza; la garanzia è che le affermazioni non provate vengono rimosse prima dell'invio. Chiunque pretenda un tasso di allucinazione pari a zero non è onesto.
  • ✓ Non usa connettori live. EDGAR, LinkedIn, Greenhouse, il retrieval delle notizie, lettura e scrittura CRM e l'invio email sono stubbati o simulati, e la Fact Sheet è pre-costruita.
  • ✓ Non presenta Northwind o Atlas come società reali. Sono sintetiche. Solo Werner Enterprises e i suoi estratti W1/W2 del 10-K sono pubblici e reali.
  • ✓ Non riporta l'intervallo di allucinazione dal 12 al 18% come risultato misurato di questo prodotto. Quella cifra è contesto di mercato; il titolo della demo è la copertura della provenienza e il tasso gestito automaticamente.
  • ✓ Non porta clienti, case study, testimonianze o cifre di ROI. Non ne esistono ancora. Questa è una demo che prova il meccanismo, non un deployment.

Domande che gli acquirenti fanno davvero

È solo un altro AI SDR (come 11x)?

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.

Come verificate le affermazioni delle email di vendita generate dall'IA prima che vengano inviate?

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.

Come intercetta un'affermazione tecnicamente vera ma fuorviante?

È 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'outreach IA può essere usato in settori regolamentati come i servizi finanziari / FINRA?

È 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.

Come dimostrate quale fonte ha supportato un'affermazione, per un audit di compliance?

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ì.

Un modello IA migliore/più recente risolverà semplicemente il problema dell'allucinazione?

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.

È un prodotto live o una demo?

È 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.

Ricerca tecnica

La ricerca dietro questa demo — l'architettura, il design della verifica e il blueprint enterprise.

Mettete l'outreach IA di fronte ad acquirenti regolamentati?

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.

Assessment di verifica

  • ✓ Mappare dove il vostro outreach IA può spedire un'affermazione non provata
  • ✓ Definire regole di grounding, entità e temporali per i vostri dati
  • ✓ Progettare i livelli di rischio e il gate di revisione umana
  • ✓ Specificare la ricevuta di audit di cui ha bisogno il vostro team di compliance

Costruire il livello

  • ✓ Un verificatore deterministico sulle vostre fonti reali
  • ✓ Un policy gate calibrato sui vostri verticali regolamentati
  • ✓ Ricevute di audit firmate e scaricabili per ogni invio
  • ✓ Autorialità intercambiabile sul modello (Anthropic, OpenAI, Gemini, Ollama)
Social

Pubblicato anche su