Modellazione Causale e Controfattuale
Pipeline di inferenza causale che rispondono a domande di intervento e controfattuali da dati osservazionali quando i test A/B sono impossibili o insufficienti.
La maggior parte dei sistemi di ML aziendale risponde alla domanda «cosa accadrà?» — ma nel momento in cui qualcuno chiede «cosa succede se aumentiamo i prezzi del 10%?» o «quali clienti reagiscono davvero a questa promozione rispetto a chi avrebbe acquistato comunque?», il modello predittivo tace. L'inferenza causale risponde a una domanda diversa: qual è l'effetto di fare X sull'esito Y, per quali sottogruppi, e quanto si può essere certi che fattori non misurati non stiano guidando il risultato? Il nostro approccio costruisce pipeline causali di produzione progettate per sopravvivere al contatto con dati osservazionali reali, alla revisione regolamentare e al giorno in cui il data scientist lascia l'azienda.
Perché il vostro modello predittivo non riesce a rispondere alla domanda del vostro business
Il vostro modello di pricing prevede la domanda. Il vostro modello di churn valuta il rischio. Il vostro modello di marketing mix attribuisce i ricavi. Tutti sono stati addestrati su correlazioni nei dati storici — e cambiare l'intervento rompe quelle correlazioni. Ecco perché, secondo le stime di BCG, oltre il 50% delle strategie promozionali non produce alcun incremento rilevante: ottimizzare gli interventi con modelli correlazionali significa spendere su clienti che avrebbero comunque convertito e perdere quelli il cui comportamento si sarebbe potuto effettivamente cambiare.
L'inferenza causale risolve un problema diverso dalla previsione. Risponde a quale sia l'effetto di fare X sull'esito Y, per quali sottogruppi, e quanto si possa essere certi che fattori non misurati non stiano guidando il risultato. Fondiamo le nostre pipeline in entrambi il framework dei modelli causali strutturali e la tradizione degli esiti potenziali, perché nella pratica sono necessari entrambi: i DAG identificano cosa si può stimare, i framework degli esiti potenziali indicano come stimarlo. Tralasciare uno dei due significa stimare la quantità sbagliata, o quella giusta con il metodo sbagliato.
Dove la scoperta causale automatizzata fallisce e dove inizia l'expertise di dominio
Il discorso di vendita per l'IA causale spesso inizia con la scoperta automatizzata: si inseriscono i dati in NOTEARS o DECI, e l'algoritmo produce un grafo causale. La realtà è meno ordinata. La ricerca interna di CausaLens ha dimostrato che NOTEARS non ha invarianza di scala — riscalare una variabile da metri a centimetri cambia il grafo scoperto. DECI gestisce le relazioni non lineari ma fatica con dati di tipo misto e valori mancanti che sono la norma nei dataset aziendali. Ogni algoritmo di scoperta automatizzata presuppone l'assenza di confounder non misurati, e ogni dataset aziendale viola questa ipotesi.
Iniziamo i progetti causali con l'elicitazione di esperti di dominio, non con la scoperta automatizzata. Ci sediamo con le persone che comprendono il processo generatore di dati, costruiamo il grafo causale in modo collaborativo, quindi verifichiamo formalmente l'identificabilità usando il do-calcolo e i criteri backdoor/frontdoor prima di stimare qualsiasi cosa. La scoperta automatizzata ha il suo posto come generatore di ipotesi, portando alla luce archi candidati che gli esperti possono validare o rifiutare — ma il grafo che va in produzione deve essere portante, non decorativo (vedi la nostra ricerca sull'integrità algoritmica). Quando un grafo è sbagliato, ogni stima a valle eredita quell'errore, e l'analisi di sensitività non può salvarvi da una struttura causale mal specificata.
Stima dell'effetto del trattamento che sopravvive al contatto con dati reali
Il divario tra una stima CATE da tutorial e una pipeline di effetti del trattamento di livello produzione è dove la maggior parte dei progetti di IA causale si blocca. Tre modalità di fallimento dominano.
Double/debiased machine learning che si adatta eccessivamente
Le pipeline DML si rompono quando i modelli nuisance del primo stadio si adattano eccessivamente. La procedura di cross-fitting che lo previene richiede un'attenta suddivisione del campione, e la maggior parte delle implementazioni rapide la salta o la implementa in modo errato — producendo stime dell'effetto del trattamento che sono artefatti dell'overfitting piuttosto che segnali causali. Implementiamo DML con validazione esplicita del cross-fitting, monitorando la qualità delle previsioni del primo stadio e segnalando quando le prestazioni del modello nuisance scendono sotto la soglia in cui l'ortogonalizzazione regge.
Violazioni della positività che invalidano silenziosamente le stime
Se certi segmenti di clienti non hanno mai ricevuto il trattamento nei vostri dati osservazionali, non potete stimare gli effetti del trattamento per quei segmenti senza estrapolazione. La ponderazione inversa standard per la propensione amplifica il rumore per score di propensione vicini a zero. Diagnostichiamo le violazioni della positività prima della stima, applichiamo pesi di sovrapposizione o troncatura dove appropriato, e documentiamo chiaramente quali sottopopolazioni hanno stime affidabili rispetto a quelle estrapolate.
Analisi di sensitività trattata come opzionale
Ogni stima causale osservazionale dipende dall'ipotesi di aver misurato tutti i confounder — un'ipotesi mai completamente verificabile. Calcoliamo E-values e limiti di Rosenbaum per ogni stima dell'effetto del trattamento, quantificando esattamente quanto forte dovrebbe essere il confounding non misurato per annullare ciascun risultato (vedi la nostra ricerca sulla responsabilità algoritmica). Una decisione aziendale basata su una stima CATE senza analisi di sensitività è una decisione senza intervallo di confidenza.
Ragionamento controfattuale per pricing, politica e conformità normativa
Le domande controfattuali portano l'inferenza causale un passo oltre: non solo «qual è l'effetto medio del trattamento?» ma «cosa sarebbe successo a questa specifica entità con un intervento diverso?» Questo richiede la procedura in tre fasi di abduzione-azione-previsione — inferire le caratteristiche latenti dell'entità dalle prove osservate, modificare il modello causale per riflettere l'intervento ipotetico e calcolare l'esito nel modello modificato.
Nel pricing, i modelli di domanda controfattuale permettono di stimare quale sarebbe stata la domanda a un prezzo che non è mai stato applicato. Un approccio di previsione causale che combina DML con modelli basati su transformer supera le previsioni tradizionali in scenari off-policy — esattamente il regime rilevante per l'ottimizzazione dei prezzi, dove si vuole sapere cosa succede a prezzi non ancora sperimentati, non solo prevedere la domanda ai prezzi attuali.
Nella conformità normativa, il ragionamento controfattuale risponde alla domanda che i regolatori pongono sempre più spesso: «questa persona avrebbe ricevuto la stessa decisione se il suo attributo protetto fosse stato diverso?» Il Colorado AI Act, in vigore dal 30 giugno 2026, impone a chi implementa sistemi AI ad alto rischio di adottare misure ragionevoli contro la discriminazione algoritmica, inclusi test documentati sull'impatto disparato tra classi protette. Il EU AI Act impone obblighi per i sistemi ad alto rischio a partire dal 2 agosto 2026, con sanzioni fino a 35 milioni di EUR o il 7% del fatturato globale. Dimostrare che un sistema non discrimina causalmente richiede metodi causali — la disparità statistica da sola non distingue tra fattori di rischio legittimi e proxy per caratteristiche protette.
Dai notebook di ricerca alle pipeline causali di produzione
Un'analisi causale che vive in un notebook Jupyter e muore quando il data scientist se ne va non è una capacità causale. Progettiamo pipeline causali di produzione (dettagliate nel nostro whitepaper tecnico sull'architettura aziendale post-wrapper) attorno a quattro componenti:
- Registro del grafo causale — memorizza il DAG validato con documentazione di ogni arco, ogni arco escluso e la motivazione di dominio per ciascuno.
- Motore di stima — implementa il metodo appropriato per ciascuna struttura di problema: metodi con punteggio di propensione per trattamenti binari con forte sovrapposizione, DML per confounder ad alta dimensionalità, variabili strumentali per l'endogeneità, controllo sintetico per studi di caso comparativi, e meta-learner o causal forest per effetti del trattamento eterogenei su scala.
- Strato di refutazione — esegue test di falsificazione automatizzati (trattamenti placebo, cause comuni casuali, stabilità dei sottoinsiemi di dati) su ogni stima prima che raggiunga un decisore.
- Strato di monitoraggio — traccia la validità delle ipotesi nel tempo: le distribuzioni delle covariate si spostano, le condizioni di positività si erodono e i meccanismi di assegnazione del trattamento cambiano. Una stima causale che era valida sei mesi fa potrebbe non esserlo oggi.
Causal Forest contro Meta-Learner su scala aziendale
Per la stima degli effetti del trattamento eterogeneo in particolare, la scelta tra causal forest e meta-learner è rilevante per il deployment in produzione. Il recente benchmarking su larga scala su 13,98 milioni di record clienti ha mostrato che S-Learner con LightGBM ha raggiunto le migliori prestazioni di uplift, con il 20% superiore dei clienti classificati per CATE previsto che ha catturato il 77,7% di tutte le conversioni incrementali. I causal forest affrontano vincoli computazionali che richiedono il subsampling su scala aziendale. Valutiamo entrambi gli approcci sui dati e i requisiti di scala di ciascun cliente, anziché adottare per default il metodo che il team ha già utilizzato.
Dove l'IA causale delle piattaforme si ferma e dove inizia l'ingegneria personalizzata
CausaLens offre una piattaforma di Decision Intelligence con capacità di scoperta causale, stima degli effetti e ottimizzazione. Databricks fornisce un acceleratore di IA causale per l'ottimizzazione degli incentivi. Dataiku integra algoritmi di previsione causale. Queste piattaforme gestiscono il livello di strumenti — accesso agli algoritmi, visualizzazione e gestione dei flussi di lavoro.
Ciò che non fanno è la metodologia. Non si siedono con i vostri esperti di dominio per elicitare il grafo causale che riflette il vostro processo aziendale reale. Non diagnosticano se i vostri dati soddisfano le ipotesi richieste dallo stimatore scelto dalla piattaforma. Non vi dicono che la vostra pipeline DML sta producendo risultati scadenti perché i vostri strumenti sono deboli, o che le vostre stime CATE per un segmento di clienti chiave sono inaffidabili perché la positività è violata per quel sottogruppo. Non costruiscono l'analisi di sensitività che dice a un regolatore quanto siano robuste le vostre affermazioni causali al confounding non misurato.
Il 10–15% delle aziende che ha implementato con successo l'IA causale in produzione ha generalmente dipeso da team altamente specializzati, spesso con competenze a livello di dottorato nell'inferenza causale. I nostri incarichi sono strutturati per fornire quella metodologia — elicitazione del grafo, implementazione, validazione e deployment in produzione — progettati per integrarsi con qualsiasi piattaforma dati già in uso dal cliente.
Punti chiave
- I modelli predittivi si rompono nel momento in cui si interviene; l'inferenza causale stima l'effetto di fare X su Y, per quali sottogruppi, e quanto quell'effetto sia robusto al confounding non misurato.
- Costruiamo il grafo causale con esperti di dominio e verifichiamo l'identificabilità tramite do-calcolo e criteri backdoor/frontdoor — la scoperta automatizzata (NOTEARS, DECI) serve solo come generatore di ipotesi.
- La credibilità in produzione si basa sul cross-fitting DML esplicito, sulla diagnostica della positività con pesi di sovrapposizione o troncatura, e su E-values e limiti di Rosenbaum per ogni stima.
- Il ragionamento controfattuale supporta il pricing off-policy e soddisfa la prova causale di non-discriminazione richiesta dal Colorado AI Act (30 giugno 2026) e dall'EU AI Act (2 agosto 2026).
- Le piattaforme forniscono gli strumenti; noi forniamo la metodologia portante, la validazione e la pipeline di produzione su cui si basa effettivamente il 10–15% delle aziende che ha successo con l'IA causale.
Modellazione Causale e Controfattuale
Equità dell'AI negli Approvvigionamenti & Conformità alla Diversità dei Fornitori | Veriprajna
Verificate i bias della vostra AI negli approvvigionamenti. Veriprajna realizza audit di equità indipendenti dal fornitore per lo scoring di SAP Ariba, Coupa, GEP e Ivalua, garantendo la conformità alla FAR Part 19 e un'equità algoritmica dimostrabile.
AI Etica per la Retention degli Abbonamenti | Veriprajna
Amazon ha pagato 2,5 miliardi di dollari per un flusso di cancellazione che richiedeva 6 clic. Uber è sotto indagine da parte di 21 procuratori generali statali per i 23 schermate necessarie alla cancellazione.
Governance dell'IA per Medicare Advantage & conformità algoritmica | Veriprajna
Verifica, spiega e difendi l'IA del tuo piano Medicare Advantage. Middleware di explainability, architettura di conformità CMS-0057-F e prontezza al contenzioso per gli algoritmi delle assicurazioni sanitarie.
Domande Frequenti
Quanto costa un progetto di inferenza causale rispetto a eseguire più test A/B?
Il confronto dei costi dipende da cosa si cerca di apprendere e se la sperimentazione è anche possibile. I test A/B sono il gold standard quando si può randomizzare, ma molte decisioni aziendali non possono essere testate: non si possono assegnare prezzi in modo casuale ai segmenti di clienti per mesi, aprire o chiudere negozi a caso, o negare prestiti a caso per misurare l'impatto disparato. In quei casi il confronto non è tra inferenza causale e test A/B, ma tra inferenza causale e ipotesi. Per le decisioni in cui si possono eseguire esperimenti, l'inferenza causale dai dati osservazionali spesso integra i test A/B misurando gli effetti a lungo termine, stimando gli effetti eterogenei del trattamento tra i sottogruppi e colmando il divario quando le dimensioni del campione dell'esperimento sono troppo piccole per un'analisi affidabile dei sottogruppi. L'ambito del progetto varia tipicamente da un'analisi causale focalizzata su un singolo trattamento (elicitazione del grafo, stima, analisi di sensitività, documentazione) a una pipeline causale di produzione con monitoraggio automatizzato. Il caso ROI è più chiaro quando il costo dell'intervento è elevato: se si spendono milioni in promozioni, variazioni di prezzo o cambiamenti di politica, sapere quali sottogruppi rispondono effettivamente rispetto a chi avrebbe agito comunque rende rapidamente redditizio il progetto.
Abbiamo provato NOTEARS per la scoperta causale automatizzata e il grafo cambia ogni volta che riscaliamo le variabili. È un bug?
Questa è una limitazione nota, non un bug. CausaLens ha pubblicato ricerche che dimostrano che NOTEARS non ha invarianza di scala: cambiare le unità di una variabile (da metri a centimetri, da dollari a migliaia) altera il grafo scoperto. L'algoritmo utilizza una penalità L1 sui pesi degli archi, e il riscalamento cambia quei pesi, il che cambia quali archi sopravvivono alla penalizzazione. DECI e altri metodi di scoperta causale neurale affrontano parzialmente questo problema ma introducono i propri problemi con dati di tipo misto e valori mancanti. Il problema più profondo è che la scoperta causale completamente automatizzata dai soli dati osservazionali rimane un problema di ricerca aperto. Questi algoritmi assumono l'assenza di confounder non misurati, che nessun dataset aziendale può garantire. Usiamo la scoperta automatizzata come generatore di ipotesi: eseguiamo, portiamo alla luce archi candidati, poi facciamo validare o rifiutare ciascuno dagli esperti di dominio. Il grafo di produzione viene costruito collaborativamente con le persone che comprendono il processo generatore di dati, con verifiche formali di identificabilità prima di iniziare qualsiasi stima.
La nostra pipeline DML fornisce stime CATE molto diverse a seconda di come suddividiamo i dati. Come lo correggiamo?
Quasi sempre si tratta di un problema di implementazione del cross-fitting. Il double/debiased machine learning richiede che i modelli nuisance (propensione al trattamento e regressione dell'esito) siano addestrати su fold di dati diversi da quelli usati per la stima causale finale. Se il cross-fitting non è implementato correttamente, o se il numero di fold è troppo piccolo, i modelli nuisance si adattano eccessivamente al campione di stima e le stime CATE risultanti sono guidate da quell'overfitting piuttosto che dall'eterogeneità reale dell'effetto del trattamento. Diagnostichiamo questo controllando la qualità delle previsioni del primo stadio tra i fold, testando la stabilità delle stime sotto diversi conteggi di fold e seed casuali, e verificando che la condizione di ortogonalità di Neyman regga in pratica. Se i modelli del primo stadio sono deboli predittori del trattamento o dell'esito, l'ortogonalizzazione che fa funzionare DML si rompe. In tal caso la soluzione non sono più fold ma modelli nuisance migliori, o il passaggio a un metodo che non dipenda da una forte previsione del primo stadio.
L'IA causale può aiutarci a dimostrare che il nostro modello di prestito non discrimina, per la conformità al Colorado AI Act?
I metodi causali sono l'approccio corretto qui perché la domanda regolamentare è intrinsecamente causale: l'attributo protetto causa l'esito negativo, o la disparità statistica è spiegata da fattori di rischio legittimi? Il Colorado AI Act, in vigore dal 30 giugno 2026, impone a chi implementa sistemi AI ad alto rischio di adottare misure ragionevoli contro la discriminazione algoritmica, inclusi test documentati sull'impatto disparato tra classi protette. L'analisi della disparità statistica (confronto dei tassi di approvazione tra i gruppi) dice se esiste un divario. L'analisi causale dice perché esiste: se il divario è guidato dall'attributo protetto stesso, da proxy ad esso correlati, o da fattori di sottoscrizione legittimi che per caso sono distribuiti diversamente tra i gruppi. Costruiamo questo come un'analisi di mediazione causale: costruendo il DAG di come gli attributi del richiedente fluiscono attraverso il modello alla decisione, identificando percorsi causali diretti e indiretti dagli attributi protetti agli esiti, e quantificando quanto della disparità osservata fluisca attraverso ciascun percorso.
Qual è la differenza tra causal forest e meta-learner, e quali funzionano meglio su scala aziendale?
Entrambi stimano gli effetti medi condizionali del trattamento (CATE), che dicono chi beneficia di più di un trattamento. I causal forest (Athey e Imbens) suddividono i dati per massimizzare direttamente l'eterogeneità dell'effetto del trattamento. I meta-learner (S-Learner, T-Learner, X-Learner) riutilizzano modelli ML standard per la stima causale addestrando modelli di esito e calcolando gli effetti del trattamento come differenze nelle previsioni. Su scala aziendale, i meta-learner vincono attualmente in termini di praticità. Un recente benchmark su larga scala su 13,98 milioni di record clienti ha mostrato S-Learner con LightGBM con le migliori prestazioni di uplift, con il 20% superiore dei clienti che ha catturato il 77,7% di tutte le conversioni incrementali. I causal forest richiedono il subsampling a quella scala a causa di vincoli computazionali. I meta-learner si integrano anche più naturalmente nelle pipeline ML esistenti poiché usano learner supervisionati standard come modelli base. Valutiamo entrambi sui dati di ciascun cliente perché il metodo migliore dipende dalla struttura dell'effetto del trattamento.
Come gestiamo le violazioni della positività quando certi segmenti di clienti non hanno mai ricevuto il trattamento?
Le violazioni della positività significano che per alcune combinazioni di covariate, ogni unità osservata o ha ricevuto o non ha ricevuto il trattamento. La ponderazione inversa standard per la propensione amplifica il rumore in modo catastrofico per score di propensione vicini a zero, producendo stime dell'effetto del trattamento dominate da una manciata di pesi estremi. Diagnostichiamo la positività prima della stima esaminando la distribuzione dello score di propensione e segnalando regioni con minima sovrapposizione tra gruppi trattati e di controllo. La soluzione dipende dal tipo di violazione. Per le violazioni pratiche (certi segmenti sono raramente trattati ma il trattamento è possibile), i pesi di sovrapposizione o il troncamento limitano la stima alla regione in cui entrambi i bracci del trattamento hanno rappresentanza adeguata. Per le violazioni strutturali (certi segmenti non possono mai ricevere il trattamento), la domanda causale stessa è mal definita per quei gruppi.
Possiamo usare metodi di controllo sintetico per misurare l'impatto dell'apertura di un nuovo negozio senza un gruppo di controllo?
Questo è uno dei casi d'uso più forti per il controllo sintetico. Si ha un'unità trattata (il mercato dove il nuovo negozio ha aperto) e nessun controllo randomizzato. Il metodo del controllo sintetico costruisce una combinazione ponderata di mercati non trattati che corrisponde alla traiettoria pre-intervento del mercato trattato sugli esiti chiave. L'effetto del trattamento è la divergenza tra le performance post-apertura effettive del mercato trattato e le performance previste dal controllo sintetico. Il metodo funziona bene quando si hanno abbastanza mercati donatori con caratteristiche simili e un periodo pre-intervento sufficientemente lungo per validare la corrispondenza. Si rompe quando nessuna combinazione di mercati di controllo riesce a riprodurre il trend pre-intervento del mercato trattato, o quando altri interventi colpiscono contemporaneamente il mercato trattato. Implementiamo il controllo sintetico con test placebo e diagnostica dell'adattamento del trend pre-intervento.
Vale la pena pagare il costo della piattaforma CausaLens, o è meglio costruire su PyWhy open source?
CausaLens fornisce una piattaforma no-code di Decision Intelligence con capacità di scoperta causale, stima e ottimizzazione, finanziata con oltre 50 milioni di dollari e con esperienza nel deployment aziendale. L'ecosistema PyWhy (DoWhy, EconML) è open source, sostenuto da Microsoft Research, con circa 24.000 stelle GitHub nell'ecosistema e ampia adozione da parte della community. La decisione tra piattaforma e open source dipende dall'expertise del team nell'inferenza causale e dalla tolleranza per l'opacità metodologica. Se si ha l'expertise statistica per validare le ipotesi, diagnosticare i fallimenti e interpretare le analisi di sensitività, PyWhy offre il controllo completo a costo zero di licenza. Se si desidera un'interfaccia gestita e si è a proprio agio nel fidarsi delle scelte metodologiche della piattaforma, CausaLens riduce il lavoro ingegneristico. Il rischio con qualsiasi piattaforma è che astrae la metodologia, e l'inferenza causale è esattamente il dominio in cui le scelte metodologiche sono portanti. Lavoriamo con entrambe: costruendo su PyWhy quando il cliente ha capacità ingegneristica, integrando CausaLens quando il cliente ha già investito nella piattaforma.
Qual è il rischio di implementare stime dell'effetto del trattamento da dati osservazionali senza analisi di sensitività?
Il rischio è di prendere una decisione aziendale sicura basata su una stima che potrebbe essere completamente spiegata da un confounder non misurato. Ogni stima causale osservazionale assume che siano stati misurati tutti i confounder rilevanti. Quell'ipotesi non è verificabile. L'analisi di sensitività quantifica quanto ci si possa sbagliare: gli E-values dicono la forza minima del confounding (rischio relativo) che una variabile non misurata dovrebbe avere con il trattamento e l'esito per spiegare la stima. I limiti di Rosenbaum danno il massimo bias nascosto compatibile con il fatto che l'intervallo di confidenza escluda ancora lo zero. Senza queste analisi, una stima CATE di +15% di conversione incrementale potrebbe essere reale, o potrebbe essere un artefatto di una singola variabile non misurata. Includiamo l'analisi di sensitività in ogni deliverable causale, non come appendice ma come metrica primaria di credibilità.
Costruisci la tua IA con fiducia.
Collabora con un team che vanta una profonda esperienza nella creazione della prossima generazione di IA aziendale. Lascia che ti aiutiamo a progettare, sviluppare e implementare una strategia di IA di cui ti puoi fidare.
Veriprajna società di consulenza Deep Tech è specializzata nella creazione di sistemi di IA safety-critical per i settori sanitario, finanziario e regolamentato. Le nostre architetture sono validate rispetto a protocolli consolidati con una documentazione di conformità completa.