Inspection Readiness GMP: il playbook operativo del QA Manager (AIFA/EMA/FDA)

La scena reale che decide l’esito dell’ispezione

Se hai mai ospitato un’ispezione, sai che non vince chi ha “più documenti”, ma chi sa dimostrare controllo.

La domanda che separa i siti maturi da quelli fragili arriva spesso entro la prima ora:

• “Mostratemi trend deviazioni e CAPA aging degli ultimi 12 mesi.”
• “Qual è il vostro processo di escalation?”
• “Chi è owner del PQS e come lo riesaminate in Management Review?”
• “Fatemi vedere un esempio di batch disposition con criticità e come avete deciso.”

📌 In fase di audit, il problema che riscontro più spesso è questo: il sito è “document-ready” (tutto esiste), ma non è “inspection-ready” (nessuno sa raccontare in modo coerente perché il sistema funziona e dove si vedono i segnali di controllo).

Quello che segue è un playbook pratico per QA Manager, costruito sui punti che gli ispettori testano davvero sul campo.

1) Inspection Readiness non è un evento: è un sistema

Se l’ispezione ti obbliga a “correre”, significa che il tuo inspection readiness program non è integrato nel lavoro quotidiano.

Segnali che sei pronto:

• le self-inspection (EU GMP Chapter 9) generano CAPA robuste e chiuse con effectiveness check
• il PQR/APR non è un esercizio “di compilazione”, ma produce decisioni (cambi, training, investimenti)
• i reparti sanno spiegare perché una SOP dice quella cosa (non solo “perché lo chiede QA”)
• hai pacchetti prova (“evidence package”) già pronti per le aree ad alto rischio

✅ Da ricordare

L’ispettore non cerca la perfezione. Cerca governo: come identifichi i rischi, come li controlli, come impari quando qualcosa va storto.

2) Timeline operativa: cosa preparare e quando

Una timeline riduce stress e, soprattutto, evita “buchi” che diventano finding.

Tabella — Timeline Inspection Readiness (pronta da copiare in un piano)

Quando	Obiettivo	Deliverable “audit-proof”	Errore tipico da evitare
T-90 / T-60	Identificare aree “high risk”	Risk assessment (ICH Q9), heatmap rischi, top 10 gap	Fare tutto uguale per tutti (non risk-based)
T-45	Stabilizzare evidenze	PQR/APR aggiornati, trend deviazioni, CAPA backlog, change log	PQR firmato ma non “usato”
T-30	Simulare ispezione	Mock inspection, lista domande, training “come rispondere”	Mock audit vetrina, senza follow-up
T-7	Preparare hosting	War room, ruoli, request log, set documenti	Ruoli confusi, “tutti parlano”
Giorni ispezione	Controllare flusso	Front room/back room, daily debrief, issue log	Consegnare documenti non verificati
T+15 (tipico)	Risposta	CAPA letter / 483 response con piano credibile	Promettere troppo o scadenze irrealistiche
Post	Eseguire	Evidence completion + effectiveness	Chiudere “sulla carta” senza prova

3) Struttura di hosting: Front room / Back room / Request Log

Ruoli che riducono errori (e osservazioni inutili)

• Lead host (QA): gestisce agenda, toni, priorità, escalation
• Scribe (note-taker): trascrive domande e risposte verbatim, numerando richieste
• Runner: reperisce documenti (con controllo versione)
• SME (Subject Matter Expert): risponde solo nel proprio perimetro
• Document controller: verifica versioning, completezza, allegati, redaction minima

📌 In audit, la falla più comune che vedo è il “documento consegnato di fretta”: pagina mancante, allegato non aggiornato, logbook con correzioni non spiegate, o peggio record che apre una deviazione “dormiente”.

Il Request Log “salva-ispezione”

Un request log ben fatto evita:

• richieste perse
• consegne duplicate
• risposte incoerenti tra reparti

Contenuti minimi del log:

• ID richiesta, ora, ispettore, descrizione, owner, ETA consegna, consegnato sì/no, note di follow-up.

4) Gemba walk: come evitare i “finding da corridoio”

Molti finding nascono non da un audit di documenti, ma da una passeggiata in reparto.

Ecco dove l’ispettore “fiuta” debolezza del sistema:

• status labeling incoerente (quarantena/rilasciato/scartato)
• line clearance fatta “a memoria”
• logbook con “buchi” o registrazioni tutte uguali (red flag)
• segregation fisica/logica insufficiente (materiali, scarti, resi)
• gowning e comportamenti non standardizzati (anche fuori sterile)

✅ Da ricordare

La produzione pensa “operatività”. L’ispettore pensa “ripetibilità”. QA deve far combaciare le due cose.

5) 7 regole d’oro per consegnare documenti senza farti male

1. Mai consegnare originali: solo copie controllate (o PDF “view-only”).
2. Controllo versione: stessa revisione in sala e in reparto.
3. Controllo completezza: allegati, riferimenti, appendici.
4. No “extra info” non richiesta: meno superfici di attacco.
5. Tracciabilità: chi ha estratto il documento, quando e da quale sistema (EDMS/eQMS/LIMS/MES).
6. Coerenza narrativa: se mostri un trend, devi avere decisioni collegate (CAPA, change, training).
7. Stop alle improvvisazioni: se non sai, “verifichiamo e torniamo” (con ETA nel request log).

6) Closing meeting e risposta: come scrivere una CAPA letter credibile

Una risposta debole non è “brutta”: è pericolosa, perché crea aspettative verificabili.

Struttura che funziona (e che regge un re-audit)

• Acknowledge: riconosci l’osservazione (senza difenderti d’istinto)
• Containment immediato: cosa hai fatto subito per mettere sotto controllo
• Root cause: sistemica, non “colpa dell’operatore”
• CAPA: azioni, owner, scadenze, deliverable
• Effectiveness check: quando e come dimostri che ha funzionato
• Risk assessment: impatto su batch/paziente, eventuale escalation

📌 Contrarian insight (mito da sfatare): “Basta rispondere velocemente.”

• Rispondere in fretta con CAPA generiche (“re-training”) crea recidive.
• Molto meglio rispondere con poche azioni, ma misurabili (es. aggiornamento SOP + assessment competenze + verifica in campo + audit mirato).

Checklist “30 secondi” 

• Request log pronto e assegnato
• Evidence package: PQR/APR, trend deviazioni, CAPA aging, change log
• Ruoli: host / scribe / runner / SME / doc control
• Percorsi reparto: status label, segregazione, logbook, line clearance
• Piano risposta: bozza template CAPA letter/483 response

FAQ 

• Chi deve parlare con l’ispettore durante un’ispezione GMP?
  Idealmente una voce guida (QA host) e SME solo quando serve. Troppi interlocutori aumentano incoerenze.
• Quanto materiale conviene mostrare?
  Solo quanto richiesto + quanto necessario a contestualizzare. “Over-sharing” aumenta i finding.
• Cosa rende una CAPA “debole” agli occhi dell’ispettore?
  CAPA non misurabile, senza effectiveness check, o con root cause “umana” non supportata.

Se vuoi trasformare questo playbook in un toolkit operativo (checklist hosting, template request log, traccia risposta CAPA), la guida completa sul ruolo del QA Manager è il riferimento interno più utile.