Perché EPSS non deve diventare una piattaforma troppo presto

Per una startup che opera nell’intelligenza artificiale, presentarsi come piattaforma software sembra quasi obbligatorio. Una piattaforma promette scalabilità, margini elevati, ricavi ricorrenti e una crescita meno dipendente dal lavoro umano. È naturale immaginare EPSS come un ambiente digitale nel quale caricare documentazione, dati e configurazioni per ottenere automaticamente un Perimetro di Validità.

È un obiettivo legittimo. Trasformarlo troppo presto nel centro della strategia sarebbe però un errore di sequenza.

EPSS, Evidence-based Perimeter for Safe Systems, è prima di tutto un framework di assurance. Il suo valore non dipende dall’automazione di una sequenza di controlli già interamente nota, ma dalla capacità di stabilire quali controlli siano necessari per uno specifico uso di un sistema di intelligenza artificiale.

Vale la pena essere espliciti sullo stato attuale. I criteri della libreria sono scritti in una forma che ne consentirebbe la valutazione automatica una volta che i parametri fossero disponibili come dato strutturato. Quella esecuzione, però, non è realizzata: oggi la valutazione è manuale. Costruirla è un obiettivo del piano, non una capacità già in essere, e presentarla diversamente sarebbe la prima incrinatura nella credibilità di un servizio che vende proprio la distinzione fra ciò che è accertato e ciò che non lo è.

Il rischio della piattaforma costruita prima del mercato

Una piattaforma progettata troppo presto incorpora ipotesi non ancora validate.

Quali dati saranno realmente disponibili presso gli ospedali, e in quale formato? Quali documenti saranno accessibili? Quali criteri ricorreranno con maggiore frequenza? Quali passaggi richiederanno giudizio clinico? Quali controlli potranno essere eseguiti automaticamente? Quali output risulteranno utilizzabili da direzioni sanitarie e risk manager? Quanto sarà standardizzabile il processo fra strutture diverse?

Senza esperienza sul campo, il software finisce per automatizzare la rappresentazione teorica dell’assessment invece del processo reale. Il risultato è una piattaforma coerente al proprio interno e inadatta alle condizioni operative dei clienti.

Il primo prodotto è il processo

Nella fase iniziale il prodotto di EPSS non è il software. È un processo disciplinato e verificabile:

1. definizione degli usi e del perimetro, con intended use dichiarato e usi effettivamente osservati;
2. identificazione della popolazione, del reparto e del contesto;
3. raccolta delle evidenze, incluse procedure interne, log, incidenti e near miss;
4. osservazione del workflow, con punti di ingresso, supervisione, override e passaggi di responsabilità;
5. formalizzazione dei criteri, attingendo alla libreria dove la classe d’uso esiste già ed estendendola dove non esiste;
6. verifica, con esito registrato anche quando il criterio non risulta soddisfatto;
7. produzione del Perimetro e del fascicolo;
8. monitoraggio, con riesecuzione periodica dei controlli.

Questa sequenza va resa coerente, ripetibile e controllabile prima di essere tradotta in codice. La productizzazione iniziale non consiste nel sostituire il team con un’applicazione: consiste nel ridurre la variabilità non necessaria del lavoro umano.

Che cosa standardizzare subito

EPSS può diventare progressivamente più prodotto senza essere ancora una piattaforma commerciale. Alcuni elementi vanno standardizzati fin dall’inizio.

Repository sicuro e versionato per documenti, evidenze e log, con tracciabilità delle versioni del sistema valutato e delle modifiche locali.

Template standard per scoping, data request, osservazione del workflow, hazard register e piano di monitoraggio. Lo scoping deve descrivere sempre gli stessi elementi: chi utilizza l’output, quale output viene prodotto, quale decisione supporta, su quale popolazione e in quale contesto. La data request va costruita in funzione delle condizioni da verificare, non come elenco generico di informazioni.

Evidence Matrix in formato unico, per collegare ogni conclusione a documenti, test, log, osservazioni e limiti.

Registro dei criteri, in cui ciascun criterio ha identificativo, versione, classe d’uso, parametri richiesti, regola di valutazione, evidenze necessarie, esiti possibili, data di revisione, autore e revisore.

Ambiente analitico separato dai sistemi clinici, con minimizzazione dei dati personali e preferenza per dati pseudonimizzati o aggregati. È un requisito da impostare prima della prima commessa, non da introdurre quando i dati sono già arrivati.

Registro dei rapporti pregressi per sistema valutato, ai fini della regola di non contaminazione.

Review a quattro occhi, con ogni conclusione rilevante verificata da una competenza tecnica e da una competenza clinica o di dominio.

Deliverable con struttura coerente fra commesse: Perimetro di Validità, Clinical Assurance Dossier, Executive Risk Profile, Control & Monitoring Plan.

Messi insieme, questi elementi costituiscono già un sistema operativo interno, senza una riga di codice destinata al cliente.

Che cosa non automatizzare troppo presto

Alcune attività dipendono da giudizi contestuali e non vanno compresse prematuramente in checklist rigide: la formulazione dell’inferenza specifica, la delimitazione della popolazione rilevante, l’interpretazione critica delle evidenze, l’analisi della validità di contenuto, la valutazione delle conseguenze operative, la distinzione fra uso dichiarato e uso effettivo, l’interpretazione del comportamento del professionista, la qualificazione delle condizioni non accertate, l’identificazione dei conflitti fra fonti.

L’automazione può assistere questi passaggi. Non deve nasconderne la componente di giudizio.

Un sistema che restituisce automaticamente “soddisfatto” ricrea esattamente il problema che EPSS esiste per risolvere: un output rassicurante che non rende visibili le assunzioni su cui poggia. Un punteggio calcolato su dati incompleti resta un numero, e viene letto come garanzia; una condizione non accertata deve restare visibile come tale, insieme al dato che la renderebbe accertabile.

Una roadmap in quattro fasi

Fase 1, servizio strutturato. Il lavoro è manuale, ma passa da template, registri, procedure e criteri versionati. L’obiettivo è imparare quali elementi ricorrono davvero.

Fase 2, sistema operativo interno. Un ambiente riservato al team per gestire criteri, evidenze, versioni, incarichi, review, scadenze, monitoraggio e audit trail. Il cliente continua a ricevere un fascicolo, non una piattaforma.

Fase 3, esecuzione assistita. Alcuni controlli diventano semiautomatici: verifica della versione, confronto fra soglia validata e soglia configurata, completezza documentale, controllo dei campi richiesti, produzione della Evidence Matrix, generazione dei report, confronto fra baseline e stato corrente. Il giudizio resta in capo al team.

Fase 4, portale cliente. Solo dopo la stabilizzazione del processo la struttura riceve un ambiente in cui caricare evidenze, consultare il Perimetro, verificare le condizioni, registrare aggiornamenti, gestire scadenze e monitoraggio, visualizzare versioni e variazioni. A questo punto la piattaforma digitalizza un processo validato, non un’ipotesi.

I gate prima della piattaforma

La decisione di investire in un prodotto software rivolto ai clienti va subordinata a fatti osservati, non a un’esigenza percepita dal team.

Alcune condizioni ragionevoli: almeno tre assessment completi su casi reali; almeno due strutture differenti; almeno un secondo incarico presso lo stesso cliente; una quota misurabile di criteri riutilizzati; un contratto di monitoraggio attivo; una tassonomia delle classi d’uso sufficientemente stabile; dati strutturati effettivamente disponibili per alcuni controlli; riduzione dimostrata delle ore di delivery; disponibilità dichiarata a pagare per l’accesso al portale; verifica giuridica e assicurativa dell’ambiente software.

A queste va aggiunto l’indicatore che decide la questione: il rapporto fra ricavi e FTE dedicati alla delivery. Se cresce, il riuso della libreria sta funzionando e la piattaforma ha un processo da automatizzare. Se resta piatto, non c’è nulla da automatizzare. E se cresce mentre la profondità dell’analisi si riduce, il miglioramento è apparente e la piattaforma consoliderebbe una compressione della qualità.

Va detto che queste soglie collocano la piattaforma oltre il primo anno di attività. È il punto: la componente piattaforma è un’opzione successiva alla dimostrazione che la libreria riduce effettivamente il lavoro per commessa.

Build, buy o integrare

Non tutto va sviluppato internamente. Per gestione documentale, controllo delle versioni, workflow approvativi, ticketing, firma elettronica, business intelligence, gestione degli accessi, audit log e sicurezza esistono strumenti maturi e già verificati sul piano della conformità.

Lo sviluppo proprietario dovrebbe concentrarsi su ciò che rende EPSS distinto: struttura della libreria, rappresentazione parametrica dei criteri, valutazione a tre stati, collegamento fra uso, condizione ed evidenza, gestione del Perimetro, riesecuzione dei controlli, confronto fra versioni.

La regola è acquistare le funzioni generiche e sviluppare soltanto ciò che nessun altro può fornire.

Il rischio di diventare una software house

Uno sviluppo anticipato non cambia solo il prodotto: cambia il modo in cui la società misura se stessa. Il team comincia a guardare numero di funzionalità, velocità di rilascio, utenti registrati, qualità dell’interfaccia, integrazioni disponibili. Sono indicatori utili, ma soltanto dopo che il valore principale è stato dimostrato.

Nella fase iniziale gli indicatori che contano restano altri: fascicoli accettati dal cliente, clienti paganti, criteri formalizzati ed entrati in libreria, quota di riuso, tempo di delivery, condizioni effettivamente verificate, monitoraggi attivati, rinnovi, seconda commessa presso lo stesso cliente.

La tecnologia deve migliorare questi indicatori, non sostituirli.

La piattaforma come conseguenza della libreria

Il momento corretto per costruire una piattaforma arriva quando è la libreria a generare struttura. A quel punto sarà noto quali criteri ricorrono, quali dati sono normalmente disponibili, quali controlli sono automatizzabili, quali eccezioni richiedono giudizio, quali output vengono effettivamente usati dal cliente, quali eventi attivano il monitoraggio e quali modifiche impongono una rivalutazione.

La piattaforma diventerà allora il modo più efficiente di eseguire e mantenere il metodo. Prima di quel momento sarebbe un contenitore costruito senza conoscere la forma del contenuto.

Conclusione

EPSS non deve scegliere fra servizio e software. Deve scegliere la sequenza.

La prima fase richiede competenza, osservazione e formalizzazione. La seconda richiede standardizzazione interna. La terza introduce automazione assistita. Soltanto la quarta può trasformare EPSS in una piattaforma usata direttamente dai clienti.

Prima imparare, poi standardizzare, quindi automatizzare e infine piattaformizzare. In questa sequenza la tecnologia non riduce il rigore dell’assessment: rende più efficiente un metodo già dimostrato.

EPSS è sviluppato da LOGICA, dedicata all’assurance indipendente dei sistemi di intelligenza artificiale nei contesti decisionali ad alto impatto.