Decisioning probabilistico per il settore farmaceutico — Monte Carlo, Bayesian e Arrhenius in QA, trasporto e negoziazione

1. Sintesi esecutiva

Le decisioni operative in ambito farmaceutico — rilasciare un lotto dopo un'escursione di temperatura, valutare la copertura di una gara, formulare una controproposta a una richiesta di prezzo di un fornitore — vengono abitualmente impostate come se avessero un'unica risposta corretta. Non è così. La realtà sottostante è sempre probabilistica: una distribuzione della perdita di shelf-life dato il profilo tempo-temperatura, una distribuzione della probabilità di aggiudicazione data la storia della tratta, una distribuzione dell'accettazione del fornitore data la BATNA.

Questo documento sostiene la sostituzione del paradigma deterministico del supporto decisionale con uno probabilistico che porta in primo piano le distribuzioni e gli intervalli di confidenza come output di prima classe. Esaminiamo tre fondamenti matematici — la simulazione Monte Carlo, l'inferenza Bayesian e la cinetica di Arrhenius — e dimostriamo ciascuno con un esempio operativo pratico in ambito farmaceutico.

2. Il problema — le stime puntuali in un mondo probabilistico

Consideriamo uno scenario tipico. Una spedizione in catena del freddo di un principio attivo farmaceutico (API) subisce un'escursione di 6 ore al di sopra di 8°C, con un picco a 14°C. Il team QA deve decidere: rilasciare il lotto o respingerlo. Gli strumenti classici di supporto decisionale — tipicamente Excel con una consultazione dei dati di stabilità, oppure un flusso di lavoro QMS a regole fisse — restituiscono un'unica risposta: "rilascia" o "respingi", eventualmente con un singolo numero stimato di perdita di shelf-life (ad es., "11 giorni").

Questa impostazione è comoda dal punto di vista operativo ma errata da quello epistemologico. La perdita effettiva di shelf-life non è un numero singolo bensì una distribuzione plasmata da:

• Incertezza sull'energia di attivazione (E_a) — tipicamente nota con un'approssimazione di ±15-20% dagli studi di stabilità, ma raramente comunicata come distribuzione.
• Errore di calibrazione del sensore — i data logger moderni sono accurati a ±0,5°C a temperatura ambiente ma derivano durante l'utilizzo.
• Disomogeneità spaziale — il sensore è un punto nel pallet; il prodotto reale ha sperimentato un intervallo di temperature.
• Parametri di Arrhenius specifici dell'API — talvolta estrapolati da composti chimicamente simili anziché misurati direttamente.

Quando, sei mesi dopo, al team QA viene chiesto — da un auditor o dal fornitore di un lotto reso — "perché lo avete rilasciato?", la motivazione documentata deve rispondere a tutti questi aspetti. Dire "il modello Excel indicava una perdita di shelf-life di 11 giorni, al di sotto della soglia di 30 giorni" non è una risposta difendibile. Lo è invece dire "la distribuzione calibrata collocava la perdita di shelf-life a 11 giorni ± 4 giorni (IC 95%), con il 3% di probabilità di superare i 30 giorni, valore che la nostra policy di rischio classifica come accettabile per questa classe di lotto".

Lo stesso schema si ripete in tutte le decisioni operative farmaceutiche. Il costo dell'uso delle stime puntuali non è sempre visibile: una gara aggiudicata a un vettore con un rischio di coda silenziosamente elevato; una controproposta che il fornitore respinge perché la BATNA era irrealistica; un lotto al limite rilasciato perché lo strumento decisionale riportava "OK" senza mostrare la distribuzione.

3. Tre fondamenti matematici

Un motore decisionale probabilistico per le operazioni farmaceutiche si basa su tre fondamenti, ciascuno adatto a una diversa classe di domande.

Simulazione Monte Carlo

Usata quando la domanda è "qual è la distribuzione degli esiti dati molti input incerti". Si campionano ripetutamente le distribuzioni degli input, si calcola l'esito ogni volta, si accumula la distribuzione empirica degli output. Computazionalmente poco costosa sull'hardware moderno; adatta al punteggio di copertura delle gare, alla previsione del rischio sulle tratte, agli stress-test di capacità.

Inferenza Bayesian

Usata quando esiste una stima a priori che dovrebbe essere aggiornata man mano che arrivano nuove evidenze. L'applicazione farmaceutica classica è l'elasticità di prezzo dei fornitori: la prior si basa su benchmark di categoria (Fastmarkets, ICIS, LME), la verosimiglianza deriva dalle risposte effettive del fornitore alle offerte passate, la posterior è la distribuzione di elasticità che dovremmo usare per pianificare il round successivo.

Cinetica di Arrhenius

La legge empirica della velocità di degradazione chimica in funzione della temperatura, usata per tradurre i profili tempo-temperatura in stime di perdita di shelf-life. L'equazione di Arrhenius è deterministica nella forma ma probabilistica nell'applicazione — i parametri (A, E_a) sono essi stessi stime con intervalli di confidenza derivanti dagli studi di stabilità.

4. Esempio pratico 1: la cinetica di Arrhenius nella modellazione della shelf-life in QA

L'equazione di Arrhenius descrive la costante di velocità k di una reazione chimica (in questo caso, la degradazione di un API) in funzione della temperatura:

Per un evento di escursione di temperatura, la domanda operativa è: dato il profilo tempo-temperatura effettivo dal log del sensore, qual è la perdita effettiva di shelf-life rispetto a un ipotetico stoccaggio isotermo nella condizione di etichetta?

Il motore probabilistico calcola:

1. Esposizione cumulativa — si integra k(T) sul profilo effettivo per ottenere il tempo di esposizione isotermo equivalente alla temperatura di riferimento.
2. Distribuzione della perdita di shelf-life — si traduce l'esposizione in giorni di shelf-life consumati, propagando attraverso il calcolo l'incertezza su E_a, A e la calibrazione del sensore. Monte Carlo con 10.000 campioni tipicamente converge in pochi secondi.
3. Probabilità di soglia — data la soglia di rifiuto del cliente (ad es., 30 giorni), si calcola la probabilità che la perdita di shelf-life la superi.

L'output non è "shelf-life ridotta di 11 giorni" ma "la perdita di shelf-life è 11 ± 4 giorni (IC 95%), con il 2,7% di probabilità di superare la soglia di rifiuto di 30 giorni". Il livello di policy decisionale mappa quindi questo risultato su una raccomandazione — rilascia, trattieni per revisione del QP, o respingi — a seconda della classe del lotto e della tolleranza al rischio del cliente.

Il beneficio è più evidente sei mesi dopo, quando un auditor chiede "perché questo lotto è stato rilasciato data l'escursione". Il pacchetto decisionale riproducibile contiene il profilo di input, i parametri di Arrhenius calibrati, la distribuzione risultante, la verifica della soglia e la versione della policy. La decisione è riproducibile bit per bit.

5. Esempio pratico 2: l'inferenza Bayesian nell'elasticità di prezzo dei fornitori

La negoziazione con i fornitori è il contesto classico per l'inferenza Bayesian: abbiamo una stima a priori dell'elasticità di prezzo del fornitore (da benchmark di categoria), osserviamo la sua risposta a una data offerta, aggiorniamo.

L'aggiornamento Bayesian per l'elasticità (chiamiamola e) è:

Dopo 3-5 round con un fornitore, la posterior tipicamente converge a una distribuzione stretta che ci consente di formulare la controproposta successiva con una probabilità di accettazione attesa calibrata. Il Decision Hub raccomanda quindi quattro price chip — Requested, Target, Ceiling, Walk-away — con le rispettive probabilità di accettazione.

Il negoziatore decide quale inviare. Il Decision Hub non afferma che un singolo numero sia "il migliore" — mostra la curva di compromesso tra il risparmio atteso e il rischio che il fornitore abbandoni il tavolo, e consente al negoziatore di esercitare il proprio giudizio con il contesto completo.

6. Esempio pratico 3: Monte Carlo per il punteggio di copertura delle gare

Domanda: dato il piano di produzione per il prossimo trimestre e le tratte di gara attive, qual è la probabilità di coprire il 95% della domanda di trasporto senza esposizione al freight spot?

Monte Carlo gestisce questo aspetto in modo naturale. Si campiona da:

• Stocasticità del piano di produzione — probabilità di slittamento per SKU per settimana, calibrata storicamente.
• Accettazione del vettore per tratta — tasso storico di accettazione delle aggiudicazioni per ciascun vettore di gara attivo.
• Volatilità della domanda per classe di temperatura — la catena del freddo e l'ambiente hanno profili di variabilità differenti.
• Distribuzione dell'inflazione delle tariffe spot — per vettore e per mese, dagli spread storici tra tariffe spot e a contratto.

Si eseguono 10.000 simulazioni. L'output è una distribuzione sull'esito congiunto "tasso di copertura × costo totale dell'esposizione spot". Il motore identifica quindi le tratte che contribuiscono maggiormente al rischio di coda (il 5% peggiore degli esiti) e raccomanda una mini-gara per quelle tratte prima che le fatture vengano riconciliate.

Sul piano operativo, questo trasforma il "penso che siamo per lo più coperti" del pianificatore in "abbiamo l'87% di probabilità di coprire il 95%+ della domanda, con il rischio di coda concentrato in tre tratte; eseguire una mini-gara per quelle tratte porta la probabilità congiunta al 96%".

7. Verificabilità — le versioni del modello in ogni decisione

La questione della verificabilità è ciò che distingue il decisioning probabilistico dalla curiosità probabilistica. Ogni pacchetto decisionale prodotto da un motore probabilistico correttamente progettato deve includere:

• La versione del motore (semver) — affinché si possa rieseguire l'esatta implementazione matematica.
• La versione del set di parametri (per tenant) — i vostri specifici parametri di Arrhenius, la vostra specifica storia dei vettori, le vostre specifiche prior di elasticità dei fornitori.
• La versione del set di regole (le vostre SOP) — i gate rigidi eseguiti prima del livello probabilistico.
• La versione del livello di policy — la vostra specifica configurazione di tolleranza al rischio.
• L'hash della lineage dei dati di input — quali dati grezzi hanno alimentato questa decisione.
• L'hash SHA-256 dell'intero output PDF + JSON — per la rilevabilità delle manomissioni.

Quando un auditor chiede "perché il modello ha raccomandato X due anni fa?" — il team riesegue l'esatta versione del motore con gli stessi identici input e ottiene lo stesso identico output. La riproducibilità bit per bit è il requisito operativo, non un optional.

8. Cosa NON è il decisioning probabilistico

• Non è un large-language-model. Gli LLM possono avere un ruolo nell'analizzare le note testuali libere sulle escursioni traducendole in campi strutturati, ma non entrano nel ciclo di raccomandazione decisionale. Le distribuzioni di probabilità derivano da modelli matematici espliciti, non dal campionamento di token nella generazione di testo.
• Non è una scatola nera. Ogni distribuzione può essere ispezionata, ogni regola è codice leggibile dall'uomo, ogni raccomandazione è tracciabile fino ai suoi input. Se il motore raccomanda X e l'operatore non è d'accordo, il ragionamento del motore è interamente revisionabile.
• Non è un sostituto del giudizio di QA / QP / approvvigionamento. Il decisioning probabilistico raccomanda; gli esseri umani approvano. L'approvazione è parte del pacchetto decisionale.
• Non è magia. La qualità dell'output è limitata dalla qualità dell'input. Il ruolo del motore include segnalare quando gli input sono insufficienti per un'inferenza affidabile — e rifiutarsi di raccomandare anziché confabulare.

9. Conclusioni

1. Le decisioni operative farmaceutiche sono probabilistiche per natura; gli strumenti deterministici impongono loro un'impostazione che perde informazione.
2. Tre fondamenti coprono la maggior parte delle classi di decisioni operative: Monte Carlo (previsione), Bayesian (aggiornamento sequenziale), Arrhenius (cinetica chimica).
3. L'architettura corretta dispone a livelli regole rigide (SOP / GxP) → modelli probabilistici → policy decisionale (tolleranza al rischio), con timbri di versione espliciti a ciascun livello.
4. La verificabilità richiede la riproducibilità bit per bit, non il semplice logging — versione del motore, versione dei parametri, versione delle regole, versione della policy, hash dell'input e hash dell'output in ogni pacchetto decisionale.
5. Probabilistico NON significa opaco. Ogni distribuzione è ispezionabile, ogni raccomandazione è revisionabile, nessun LLM è nel ciclo decisionale.