Governance stateful delle crisi per l'IA nella salute comportamentale

Una crisi in un chatbot di salute mentale è una traiettoria. Un moderatore per-messaggio non può vederla.

Abbiamo costruito un middleware di sicurezza che avvolge un chatbot di salute comportamentale esistente e applica una policy di escalation stateful, tra i turni, di proprietà del team clinico. Intercetta la conversazione in escalation che un moderatore stateless strutturalmente non vede, e prova ogni decisione con una traccia di audit concatenata tramite hash e archiviabile. La sicurezza è un problema di architettura, non un problema di prompting.

0 vs 68

Risposte non sicure consegnate, protetto vs non protetto

Golden set etichettato di 40 conversazioni

2 turni

Rilevamento mediano più precoce rispetto a un moderatore stateless identico

Stesso classificatore e stesso gate; solo la statefulness

0 / 29

False escalation sui turni benigni

Golden set etichettato di 40 conversazioni

Una demo di un pattern di architettura di sicurezza su dati sintetici. Non è un dispositivo medico, non è un consiglio clinico, non è un'integrazione EHR.

Volume senza memoria

I chatbot di salute comportamentale vengono moderati un messaggio alla volta. Una crisi non arriva un messaggio alla volta.

La maggior parte della revisione di sicurezza su un chatbot di salute mentale valuta ogni risposta in isolamento. Ogni messaggio viene controllato, segnalato o lasciato passare, e dimenticato. Funziona per una singola riga esplicitamente pericolosa. È strutturalmente cieca a una conversazione che deriva, turno dopo turno, in cui nessun singolo messaggio è abbastanza allarmante da essere bloccato da solo.

I fallimenti documentati hanno quella forma. Il chatbot "Tessa" di NEDA ha fornito consigli su deficit calorico e plicometro prima di essere ritirato (NEDA, 2023). I clinici hanno segnalato psicosi rinforzata dal chatbot in pazienti che non hanno mai incontrato una persona che li contrastasse (dott. Keith Sakata, UCSF, 2025). OpenAI ha ritirato un aggiornamento di GPT-4o dopo che era diventato piaggioso (OpenAI, 2025). In ciascun caso il modello suonava di supporto in ogni singolo turno, mentre la traiettoria andava da qualche parte non sicura.

Un moderatore stateless non ha modo di vedere quella traiettoria, perché non ha memoria dei turni precedenti. Un modello di base migliore non risolve questo. Un chatbot perfetto non ha ancora idea della policy di escalation della tua piattaforma, non produce alcuna traccia di audit che tu possa archiviare e non ti dà alcun gate deterministico da certificare. Ecco perché qui trattiamo la sicurezza come un problema di architettura, ed ecco perché la demo confronta due stack che eseguono il modello identico.

Demo a schermo diviso: la stessa conversazione sintetica con un paziente passa attraverso un chatbot MindMate Support non protetto a sinistra e lo stesso chatbot dietro lo strato di sicurezza Veriprajna a destra, con una barra di pipeline che recita classificatore, traiettoria, verifier, gate, audit. — La demo riproduce una conversazione sintetica attraverso due stack. MindMate Support è un sostituto fittizio di un chatbot esistente. Solo dati sintetici, nessun PHI.

Il meccanismo: una pipeline stateful che gira a ogni turno

I modelli consultivi alimentano un gate deterministico. Il gate prende la decisione, e la decisione è codice che puoi leggere.

Ogni turno del paziente passa attraverso una pipeline fissa. Il messaggio viene privato del PII e sottoposto a hash, un classificatore C-SSRS ne valuta la severità sulla struttura Columbia e restituisce un livello, una confidenza e un ABSTAIN quando non può giustificare una severità. Un Trajectory Monitor stateful accumula quindi il rischio tra i turni. Questa è la capacità centrale, ed è l'unica cosa che un moderatore per-messaggio non ha: vede lo schema, non la singola riga, e produce un rischio effettivo e una banda (BENIGN, WATCH, CONCERN, HIGH, CRITICAL) con una ragione dichiarata come "disturbo alimentare persistente, pendenza in aumento."

Prima che qualsiasi risposta candidata raggiunga il paziente, un verifier panel multi-critico la ispeziona: un critico di piaggeria e tono, un matcher di pattern vietati e un verificatore di affermazioni cliniche. Un critico che segnala forza il gate almeno a un livello minimo configurato, per quanto gentile possa suonare la risposta.

La decisione stessa è un policy gate deterministico a 5 livelli, ed è Python, non un LLM: L1 CONTINUE, L2 RESTRICT, L3 SUBSTITUTE_SCRIPT, L4 HUMAN_HANDOFF, L5 CRISIS_PROTOCOL. Quando il gate blocca una risposta sostituisce uno script da una libreria in bundle di script scritti da clinici, per livello e famiglia, e registra l'id dello script. Non improvvisa mai il linguaggio di crisi. Ogni turno viene quindi scritto come una voce sha256 concatenata a quella precedente.

Lo stack protetto che mostra la barra di pipeline per-messaggio (classificatore, traiettoria, verifier, gate, audit) con le latenze per stadio, e i risultati inline del gate per i turni iniziali che recitano L1 CONTINUE e L2 RESTRICT, mentre il moderatore stateless sullo stesso turno legge BENIGN, non vede nulla, nessuna memoria. — La pipeline gira su ogni messaggio. La latenza aggiuntiva è sotto il millisecondo per turno (media 0.16 ms, p95 0.21 ms sul golden set).

Il team clinico possiede la policy, non l'engineering

Le soglie, i minimi imposti dal verifier e la libreria di 12 script sono configurati dal comitato di sicurezza clinica sotto la versione di policy 2026.04-clinical-v1. L'engineering applica esattamente quello, e non lo modifica. Lo storico di un paziente, recuperato tramite il flag FHIR stubbato, può abbassare una soglia così che lo strato scali prima per un paziente più vulnerabile. Quando la confidenza del classificatore è bassa, si astiene e instrada a una revisione umana anziché indovinare una severità.

Il modal della policy clinica che mostra i livelli minimi imposti dal verifier per critico e finding, le regole di incertezza e di confine (l'astensione a bassa confidenza forza un umano, un punteggio di jailbreak pari o superiore a 0.8 forza un minimo L3), e la libreria di 12 script approvati dal clinico con un messaggio sostitutivo L2 per disturbo alimentare rivelato. — Il modal della policy: minimi imposti dal verifier, regole di astensione e jailbreak, e la libreria di script approvati dal clinico con un messaggio sostitutivo rivelato.

Una conversazione, esaminata da un capo all'altro

Lo scenario in evidenza predefinito è la deriva verso il disturbo alimentare: sei turni, ciascuno individualmente una domanda ordinaria di benessere.

La conversazione si apre con domande innocue su mangiare in modo più sano e contare le calorie. Un moderatore per-messaggio non ha nulla da bloccare, e la baseline stateless nella demo resta verde, leggendo WATCH e "non vede nulla, nessuna memoria" turno dopo turno. Lo strato stateful, osservando la traiettoria, entra in CONCERN al turno 3. Blocca la risposta del chatbot e sostituisce uno script di grounding scritto da un clinico che indica la NEDA Helpline. Sono due turni prima del primo messaggio esplicitamente pericoloso.

Turno 3 dello stack protetto: il misuratore di rischio tra i turni legge 3.4 CONCERN, la risposta del chatbot è bloccata e non inviata, e viene sostituito uno script di grounding L3 approvato dal clinico con il numero della NEDA Helpline, mentre il moderatore stateless per-messaggio sullo stesso turno legge ancora WATCH e non vede nulla. — Turno 3: lo strato stateful raggiunge CONCERN e sostituisce uno script di grounding. Il moderatore stateless, stesso classificatore, non vede ancora nulla.

Nei turni finali i messaggi diventano esplicitamente pericolosi. Lo stack non protetto a sinistra consegna la risposta dannosa, mostrata barrata e etichettata come consegnata al paziente e non sicura. A destra, il verifier panel intercetta la risposta, coglie il tono piaggioso e lo schema vietato, e il gate scala a L4 HUMAN_HANDOFF, eseguendo il paging di un membro del care-team con il contesto completo. Descriviamo l'intercettazione, non il contenuto dannoso in sé.

Turni finali: a destra il verifier panel intercetta la risposta candidata, il misuratore di rischio legge 5.0 CRITICAL e il gate limita l'escalation a L4 HUMAN_HANDOFF perché non c'è un segnale acuto L5, viene sostituito uno script di handoff approvato dal clinico, e la risposta dannosa è bloccata e non inviata, mentre lo stack non protetto a sinistra mostra la stessa risposta barrata come consegnata e non sicura. — Il verifier intercetta la risposta candidata e il gate scala a L4 HUMAN_HANDOFF. Lo stack non protetto consegna la stessa risposta.

Il risultato della sessione rende concreto il delta, ed è attribuibile alla sola statefulness perché entrambi gli stack hanno usato lo stesso classificatore e lo stesso gate. L'unica differenza era la memoria tra i turni.

Il pannello del risultato di sessione: intercettato 2 turni prima del moderatore stateless identico (turno 3 contro turno 5), 0 risposte non sicure consegnate dove lo stack non protetto ne avrebbe inviate 2, catena di audit intatta attraverso 6 voci a prova di manomissione sotto la policy clinica 2026.04-clinical-v1. — Risultato di sessione per la conversazione di deriva verso il disturbo alimentare: 0 non sicure consegnate contro 2, intercettato 2 turni prima, catena di audit intatta.

Su tutto il golden set

L'harness di benchmark valuta un golden set etichettato di 40 conversazioni di 177 turni, generato deterministicamente da 8 conversazioni canoniche scritte a mano più parafrasi che preservano le etichette e varianti di controllo benigne. Su quel set lo stack protetto ha consegnato 0 risposte non sicure dove uno non protetto ne ha consegnate 68. Il rilevamento è avvenuto con una mediana di 2 turni prima rispetto al moderatore stateless identico, e su 2 conversazioni il moderatore stateless non ha mai scalato affatto. Ci sono state 0 false escalation su 29 turni benigni, l'accuratezza del livello C-SSRS è stata del 94.3% esatta e del 97.2% entro un livello, e lo strato si è astenuto verso un umano una volta. Questi numeri sono circoscritti a questo golden set sintetico, non una garanzia open-world.

Il tabellone live delle 40 conversazioni che elenca ogni scenario con il suo esito, per esempio deriva verso il disturbo alimentare intercettata 2 turni prima, psicosi a combustione lenta in cui il moderatore stateless l'ha mancata, e veri negativi benigni senza escalation. — Il benchmark sulle 40 conversazioni, calcolato live dalla demo. Gli scenari a combustione lenta sono quelli in cui il moderatore stateless non scala mai affatto.

La ricevuta archiviabile

Ogni conversazione genera un Safety Incident Report. Ogni turno è una voce sha256 concatenata a quella precedente, così modificare qualsiasi campo rompe ogni hash successivo e la manomissione è evidente. Il report mostra il livello del classificatore, il rischio tra i turni, i finding del verifier, la decisione del gate e la ragione, l'id dello script sostituito e la catena di hash, con la catena verificata intatta. È costruito per essere archiviato: evidenza di monitoraggio postmarket FDA, difesa in contenzioso, sottoscrizione assicurativa.

Il Safety Incident Report concatenato tramite hash per la conversazione di deriva verso il disturbo alimentare, una tabella di 6 turni che mostra l'hash del messaggio privato del PII, il livello del classificatore, la banda di rischio tra i turni, i finding del verifier, la decisione del gate con la ragione, l'id dello script sostituito e la catena di hash sha256, con evidenza di manomissione contrassegnata come catena intatta. — Il Safety Incident Report: un record per conversazione, concatenato tramite hash, a prova di manomissione, che un reviewer può leggere riga per riga.

Un moderatore stateless contro lo strato di sicurezza

Stesso lavoro, una differenza strutturale: memoria tra i turni e una policy di cui qualcuno può essere proprietario.

Capacità	Moderatore stateless per-messaggio	Clinical AI Safety Layer
Valuta un singolo messaggio	Sì	Sì
Vede la traiettoria tra i turni	No, non ha memoria	Sì, un accumulatore di rischio stateful
Ispeziona la risposta candidata prima della consegna	No	Sì, un verifier panel multi-critico
Chi possiede la policy di escalation	Implicita nel modello o nel prompt	Il team clinico, un gate a 5 livelli
Che cosa prende la decisione	Un modello o un prompt	Codice deterministico esterno all'LLM
Linguaggio di crisi quando blocca	Generato dal modello, improvvisato	Libreria di script approvati dal clinico
Audit costruito per essere archiviato	Nessuno	Safety Incident Report concatenato tramite hash

Cosa questa demo non fa

Non è un dispositivo medico e non è FDA-cleared, HIPAA-certified, né un consiglio clinico. Il framing FDA PCCP e SaMD è una direzione di produzione differita, non un'affermazione sulla demo.
Ogni conversazione, ogni paziente e il chatbot "MindMate Support" è sintetico. Non ci sono dati di pazienti reali e nessun PHI.
L'adapter FHIR è uno stub con un flag paziente sintetico. Non c'è alcuna connessione Epic o Cerner nella demo.
Il classificatore è un classificatore lessicale deterministico, intenzionalmente semplice. Lo swap di produzione è un modello fine-tuned in-VPC dietro la stessa interfaccia. La similarità semantica nella demo è Jaccard a token, non sentence embeddings.
Tutti i numeri di prova sono circoscritti a un golden set etichettato di 40 conversazioni di dati sintetici, mai una garanzia open-world. Non ci sono clienti, deployment o endorsement di clinici da citare, e non ne inventiamo alcuno.

Domande che fanno gli acquirenti

Questo sostituisce il nostro chatbot o il nostro modello clinico?

No. È middleware che avvolge il chatbot esistente e non cambia mai il modello. Aggiunge un accumulatore di rischio stateful tra i turni, un verifier panel multi-critico e un gate di escalation deterministico intorno al modello, e sostituisce uno script scritto da un clinico quando blocca una risposta. Il punto è la governance stateful e una ricevuta archiviabile, non un modello diverso.

In che cosa è diverso dalla moderazione dei contenuti che già eseguiamo su ciascun messaggio?

Un moderatore per-messaggio valuta ogni risposta in isolamento e non ha memoria, quindi manca una crisi che si costruisce tra i turni. Su un golden set etichettato di 40 conversazioni lo strato stateful ha scalato con una mediana di 2 turni prima rispetto a un moderatore stateless identico che usava lo stesso classificatore e lo stesso gate. Su due di quelle conversazioni il moderatore stateless non ha mai scalato affatto.

La decisione di escalation è presa da un LLM?

No. Il classificatore e il verifier panel sono consultivi, ma la decisione di escalation a 5 livelli e l'audit sono Python deterministico esterno a qualsiasi LLM. Un reviewer può leggere il gate; non può sottoporre a controinterrogatorio un prompt. Gli agenti consigliano, il codice decide.

Possiamo dimostrare a un regolatore o a un tribunale cosa ha fatto il sistema e perché?

Ogni turno è una voce sha256 concatenata a quella precedente, così modificare qualsiasi campo rompe ogni hash successivo e la manomissione è evidente. Il risultato è un Safety Incident Report archiviabile in JSON e HTML, inquadrato per il monitoraggio postmarket FDA, la difesa in contenzioso e la sottoscrizione assicurativa. Nella demo il report mostra la catena intatta.

Un modello di base migliore non renderebbe questo superfluo?

Un chatbot perfetto non ha ancora idea della policy di escalation della tua piattaforma, non produce alcuna traccia di audit, non ti dà alcun gate deterministico da certificare e non offre alcuna difesa quando viene jailbroken. Il valore durevole è la governance stateful più la ricevuta archiviabile, non un tasso di errore del modello più basso. Ecco perché la demo confronta contro un classificatore e un gate identici e attribuisce il miglioramento alla sola statefulness.

È un dispositivo medico validato, e i dati sono reali?

No. Questa è una demo di un pattern di architettura di sicurezza, non un dispositivo medico, e non è FDA-cleared né HIPAA-certified. Ogni conversazione è sintetica, l'adapter FHIR è uno stub, e il classificatore è un classificatore lessicale deterministico che sta al posto di un modello di produzione in-VPC. Tutti i numeri di prova sono circoscritti a un golden set etichettato di 40 conversazioni di dati sintetici.

Ricerca tecnica

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

Soluzione completa

Esplora la soluzione Clinical AI Safety for Mental Health Platforms →

Se il tuo chatbot ha un problema di architettura, ci piacerebbe confrontarci

Governance stateful, una policy di proprietà del team clinico e un audit che puoi archiviare.

Se il tuo team sta cercando di capire come rendere un chatbot di salute comportamentale difendibile per una revisione enterprise, di payer o normativa, ci piacerebbe davvero sentire come ci state pensando. Il problema è di settore e anche le risposte lo saranno.

Cosa costruiamo

✓ Monitoraggio del rischio stateful, tra i turni
✓ Un gate di escalation deterministico di proprietà del team clinico
✓ Sostituzione di script approvati dal clinico
✓ Safety Incident Report concatenati tramite hash e archiviabili

Come lavoriamo

✓ Middleware che avvolge il tuo chatbot esistente
✓ Modelli consultivi, decisioni prese da codice che puoi leggere
✓ Swap di produzione verso un classificatore fine-tuned in-VPC
✓ Governance che tiene anche quando il modello di base migliora

Contatta via WhatsApp Scrivi al nostro team via email