Per una startup il primo cliente ha un valore evidente: dimostra che qualcuno è disposto a pagare. Per EPSS non è sufficiente.
Il primo incarico deve verificare contemporaneamente il metodo, il processo di delivery, l’accesso ai dati, la collaborazione con i clinici, la struttura dei deliverable, il prezzo, i tempi, il monitoraggio, il riuso della libreria e la possibilità di ottenere una seconda commessa. È molto da chiedere a un contratto solo, ed è il motivo per cui la prima struttura va scelta come lighthouse partner e non come semplice acquirente.
Il contratto economicamente più grande non è quasi mai il partner strategicamente migliore.
Le cinque domande a cui il primo caso deve rispondere
Il problema è realmente percepito? La struttura riconosce che le metriche del modello non bastano a governarne l’uso, oppure sta comprando rassicurazione?
Il deliverable è utile? Direzione sanitaria, risk management e responsabili clinici capiscono il Perimetro di Validità e lo usano per decidere qualcosa.
Le evidenze sono accessibili? Documentazione, dati, configurazioni e workflow possono essere esaminati concretamente e non solo descritti.
Il processo è sostenibile? Ore, costi e competenze richieste sono compatibili con il prezzo praticato.
Il rapporto può continuare? Esiste una prospettiva di monitoraggio, di secondo sistema o di nuovo reparto.
Il lighthouse partner deve produrre apprendimento, non soltanto fatturato.
I requisiti essenziali
Un sistema identificato. La struttura deve utilizzare o essere in procinto di adottare un sistema determinato, di cui siano noti prodotto, versione, reparto, uso, output, popolazione, decisione supportata e stato di adozione. Un interesse generico per l’intelligenza artificiale non è un caso d’uso.
Uno sponsor interno. Serve una persona con interesse concreto e capacità di coordinamento, in direzione sanitaria, risk management, innovazione, dipartimento clinico, qualità o sistemi informativi. L’entusiasmo di un singolo professionista è prezioso ma insufficiente se non produce accesso, documenti e decisioni.
Accesso al workflow. EPSS valuta l’uso reale o previsto del sistema, quindi deve poter osservare quando compare l’output, chi lo vede, come viene interpretato, quando può essere ignorato, quali decisioni ne seguono, come viene registrato e quali responsabilità intervengono. Senza questo accesso il fascicolo resta documentale, e un perimetro costruito su evidenze prospettiche va dichiarato come tale in copertina.
Evidenze disponibili. Documentazione tecnica, protocolli, dati aggregati o pseudonimizzati, log, versioni, soglie, materiali di formazione, incidenti, near miss, procedure di escalation. L’assenza di alcuni dati non è un ostacolo: diventa un risultato dell’assessment, perché ogni condizione non accertata viene elencata insieme al dato che la renderebbe accertabile. L’assenza quasi totale di evidenze è un’altra cosa e rende il progetto ingestibile.
Disponibilità a pagare. Un pilota gratuito non valida il mercato. Il primo incarico può essere scontato, ma deve restare pagato, e lo sconto va compensato con accesso ai dati, feedback strutturato e facoltà di produrre un case study anonimizzato. Il lavoro non retribuito può arrivare al massimo a un workshop esplorativo breve e non deve sostituire l’assessment.
Questi requisiti coincidono con i criteri che qualificano un’opportunità commerciale come attiva: problema riconosciuto, budget, sistema identificato e sponsor interno. Non sono un ideale, sono la soglia sotto la quale una conversazione non è ancora una trattativa.
Una scorecard per la selezione
I pesi che seguono sono indicativi e vanno tarati sull’esperienza delle prime trattative. Il loro scopo non è produrre un numero, ma impedire che il fascino di un nome grande sostituisca la valutazione dell’accesso.
| Criterio | Peso |
|---|---|
| Sistema AI già in uso o in adozione imminente | 15 |
| Sponsor interno autorevole | 15 |
| Accesso al workflow | 15 |
| Disponibilità delle evidenze | 15 |
| Possibilità di incasso iniziale | 10 |
| Collaborazione del team clinico | 10 |
| Interesse per il monitoraggio | 8 |
| Possibilità di seconda commessa | 7 |
| Case study anonimizzato autorizzabile | 5 |
| Totale | 100 |
Una struttura con ottantacinque punti e un contratto più piccolo è preferibile a una struttura con cinquantacinque punti e un budget maggiore. Un partner clinico realmente disponibile, dati utilizzabili e un sistema già in esercizio valgono più di una scelta teoricamente perfetta.
La coalizione interna
Il progetto non dovrebbe dipendere da un solo interlocutore. Servono, con ruoli distinti: uno sponsor istituzionale che autorizza e sostiene l’iniziativa; un clinical lead che definisce il workflow e interpreta le conseguenze cliniche; un referente AI o IT per sistema, integrazione, dati e configurazione; il risk management, che collega l’assessment al governo del rischio; un data owner per accesso, qualità, estrazione e minimizzazione; privacy e legale per le condizioni di trattamento e di circolazione dei documenti; procurement o amministrazione per contratto, fatturazione e pagamento.
Se uno di questi ruoli manca, il progetto rallenta anche in presenza di un forte interesse clinico. Nella maggior parte dei casi il ruolo mancante è il data owner, e il sintomo si manifesta al momento della prima richiesta dati.
I segnali di allarme
Una struttura può essere prestigiosa e insieme inadatta. I segnali che consigliano di non procedere: nessun sistema specifico identificato; interesse puramente esplorativo; assenza di sponsor; impossibilità di accedere al workflow; indisponibilità totale dei dati; richiesta di lavoro gratuito; aspettativa di ricevere una certificazione; richiesta implicita di un esito predeterminato; produttore che finanzia direttamente o indirettamente il fascicolo; impossibilità di versare l’anticipo; tempi amministrativi incompatibili con la cassa disponibile; perimetro che cambia a ogni riunione; richiesta simultanea di assessment e rimedio; rifiuto di definire i lettori autorizzati.
Gli ultimi tre meritano attenzione perché arrivano travestiti da collaborazione. Un perimetro mobile non è flessibilità, è delivery non pagata. La richiesta di occuparsi anche del rimedio è la fine dell’indipendenza sulla quale il servizio si regge. E il rifiuto di nominare i lettori autorizzati significa che il documento circolerà senza controllo.
Un primo cliente sbagliato consuma più capitale e più reputazione di quanti ne generi.
L’anticipo alla firma come test del partner
L’incasso iniziale non serve soltanto a proteggere la cassa. È anche un test della capacità operativa della controparte.
Una struttura in grado di definire l’oggetto, firmare il contratto, autorizzare l’accesso, versare l’anticipo e nominare i referenti ha dimostrato, prima ancora che il lavoro cominci, di poterlo portare a termine. Una lunga manifestazione di interesse priva di passaggi amministrativi non è traction.
Vale anche il contrario, ed è utile saperlo prima: con le controparti pubbliche i pagamenti successivi all’anticipo possono richiedere diversi mesi. È un fatto da mettere nel piano di cassa, non un motivo per escludere il pubblico.
Una commessa che non consente anticipo alla firma, accesso alle evidenze e un perimetro definito non è compatibile con la struttura finanziaria di una startup alla prima delivery, salvo che il relativo fabbisogno sia coperto da una fonte dedicata.
Che cosa definire prima della firma
Il contratto dovrebbe chiarire almeno: sistema e versione, uso valutato, popolazione, reparto, durata, milestone, condizioni di pagamento, dati richiesti, responsabilità della struttura, accesso al workflow, revisione clinica, lettori autorizzati, riservatezza, proprietà dei deliverable, diritti sulla libreria, utilizzo di risultati aggregati, case study anonimizzato, monitoraggio, change request e condizioni di sospensione.
Un punto va aggiunto e non è negoziabile: nessun contratto va firmato prima che sia in vigore la copertura di responsabilità civile professionale. È una condizione preliminare, non una formalità da sistemare durante la delivery.
La chiarezza contrattuale serve soprattutto a impedire che il progetto si allarghi mentre viene eseguito.
Il perimetro minimo del primo progetto
Il primo fascicolo non deve tentare di valutare l’intero ospedale, tutti gli usi del sistema, tutte le popolazioni, ogni rischio possibile o l’intera conformità normativa.
Il perimetro va tenuto deliberatamente stretto: un sistema, una versione, un reparto, una popolazione, una decisione, un periodo, un numero limitato di condizioni prioritarie.
Un caso circoscritto è più facile da completare, da sottoporre a revisione e da trasformare in referenza. È anche l’unico che può essere consegnato nei tempi promessi.
Un piano dei primi novanta giorni
Giorni 1 a 15. Conferma del caso d’uso, nomina dei referenti, finalizzazione della richiesta dati, avvio dell’analisi documentale, mappa preliminare del workflow.
Giorni 16 a 45. Raccolta delle evidenze, interviste e osservazione in reparto, formalizzazione dei criteri, verifica dei dati, identificazione delle condizioni che restano indeterminate.
Giorni 46 a 70. Esecuzione dei controlli, review a quattro occhi con competenza clinica e competenza tecnica, bozza del Perimetro, Evidence Matrix, confronto con la struttura.
Giorni 71 a 90. Recepimento delle osservazioni, versione finale del fascicolo, Executive Risk Profile, Control & Monitoring Plan, decisione sul secondo incarico, definizione del case study.
Il progetto deve chiudersi con un risultato e con una decisione sul passo successivo. Un progetto che finisce senza nessuna delle due cose è costato quanto un progetto riuscito.
Il valore del case study
Il primo caso deve contribuire alla credibilità del metodo. La struttura dovrebbe autorizzare almeno una fra citazione del nome come partner, descrizione anonimizzata, testimonianza, presentazione congiunta, sintesi metodologica, pubblicazione accademica, workshop, dati aggregati sul processo, dichiarazione di accettazione del fascicolo.
Il case study non deve rivelare informazioni sensibili né conclusioni non autorizzate. Deve dimostrare due cose soltanto: che il metodo è stato applicato in un contesto reale e che il risultato è stato giudicato utilizzabile da chi lo ha commissionato.
Come misurare il successo
La consegna non è il criterio. Contano il fascicolo accettato, il pagamento delle milestone, lo scostamento fra ore preventivate ed effettive, la percentuale di evidenze effettivamente ottenute, il numero di criteri applicati e di criteri riutilizzabili altrove, le condizioni rese accertabili, la revisione clinica completata, il monitoraggio attivato, il case study autorizzato, la seconda commessa discussa o firmata.
Il primo partner è davvero lighthouse quando riduce il rischio del cliente successivo, non quando produce il primo ricavo.
Conclusione
EPSS non deve cercare il primo ospedale disposto ad ascoltare. Deve trovare la struttura che permette di dimostrare insieme il valore del problema, la solidità del metodo, l’utilità del fascicolo, l’accessibilità delle evidenze, la sostenibilità economica e la possibilità di una relazione continuativa.
È il luogo in cui una prova di concetto diventa un prodotto acquistato, utilizzato e replicabile. Per questo la scelta va fatta in modo selettivo.
Meglio un primo cliente più piccolo ma operativo, collaborativo e disponibile a una seconda fase, che una grande struttura prestigiosa incapace di fornire accesso, dati e decisioni.
EPSS è sviluppato da LOGICA, dedicata all’assurance indipendente dei sistemi di intelligenza artificiale nei contesti decisionali ad alto impatto.
Lascia un commento