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

La escena real que decide el resultado de la inspección

Si alguna vez has hospedado una inspección, sabes que
no gana quien tiene más documentos, sino quien sabe demostrar control.

Las preguntas que separan a los sitios maduros de los frágiles suelen llegar dentro de la primera hora:

• «Muéstreme las tendencias de desviaciones y el CAPA aging de los últimos 12 meses».
• «¿Cuál es su proceso de escalado?»
• «¿Quién es el owner del PQS y cómo se revisa en la Management Review?»
• «Muéstreme un ejemplo de batch disposition con criticidades y cómo se tomó la decisión».

📌 En auditoría, el problema más frecuente que observo es este:
el sitio está document-ready (todo existe), pero no inspection-ready (nadie sabe explicar de forma coherente por qué el sistema funciona y dónde se evidencian las señales de control).

Lo que sigue es un playbook práctico para QA Managers, construido sobre los puntos que los inspectores realmente prueban en campo.

1) Inspection Readiness no es un evento: es un sistema

Si la inspección te obliga a “correr”, tu programa de inspection readiness no está integrado en el trabajo diario.

Señales de que estás preparado:

• Las self-inspections (EU GMP Capítulo 9) generan CAPAs sólidas, cerradas con effectiveness check
• El PQR/APR no es un ejercicio de “rellenar”, sino que produce decisiones (cambios, formación, inversiones)
• Los departamentos saben explicar por qué una SOP dice lo que dice (no solo “porque lo pide QA”)
• Existen evidence packages ya preparados para las áreas de alto riesgo

✅ Para recordar:
El inspector no busca perfección. Busca gobernanza:
cómo identificas los riesgos, cómo los controlas y cómo aprendes cuando algo falla.

2) Timeline operativa: qué preparar y cuándo

Una timeline reduce el estrés y, sobre todo, evita “huecos” que se convierten en findings.

Tabla — Timeline de Inspection Readiness (lista para copiar en un plan)

3) Estructura de hosting: Front Room / Back Room / Request Log

Roles que reducen errores (y observaciones innecesarias)

• Lead host (QA): gestiona agenda, tono, prioridades y escalado
• Scribe (note-taker): transcribe preguntas y respuestas literalmente, numerando solicitudes
• Runner: recupera documentos (con control de versión)
• SME (Subject Matter Expert): responde solo dentro de su ámbito
• Document controller: verifica versionado, completitud, anexos y redacción mínima

📌 La brecha más común en auditoría es el “documento entregado con prisas”:
páginas faltantes, anexos desactualizados, logbooks con correcciones no explicadas o, peor aún, registros que abren una desviación “latente”.

El Request Log que “salva” la inspección

Un request log bien gestionado evita:

• solicitudes perdidas
• entregas duplicadas
• respuestas incoherentes entre departamentos

Contenido mínimo del log:
ID de solicitud, hora, inspector, descripción, owner, ETA de entrega, entregado sí/no, notas de seguimiento.

4) Gemba walk: cómo evitar los “findings de pasillo”

Muchos findings no nacen de revisar documentos, sino de recorridos en planta.

Dónde el inspector “huele” debilidad del sistema:

• etiquetado de estatus inconsistente (cuarentena/liberado/rechazado)
• line clearance hecha “de memoria”
• logbooks con huecos o registros idénticos (red flag)
• segregación física/lógica insuficiente (materiales, residuos, devoluciones)
• gowning y comportamientos no estandarizados (incluso fuera de áreas estériles)

✅ Para recordar:
Producción piensa en operatividad.
El inspector piensa en repetibilidad.
QA debe hacer coincidir ambas.

5) Las 7 reglas de oro para entregar documentos sin dañarte

1. Nunca entregar originales: solo copias controladas (o PDFs “view-only”).
2. Control de versión: misma revisión en sala y en planta.
3. Control de completitud: anexos, referencias, apéndices.
4. Nada de información extra no solicitada: menos superficies de ataque.
5. Trazabilidad: quién extrajo el documento, cuándo y desde qué sistema (EDMS/eQMS/LIMS/MES).
6. Coherencia narrativa: si muestras un trend, debe haber decisiones asociadas (CAPA, change, training).
7. Cero improvisaciones: si no sabes, “lo verificamos y volvemos” (con ETA en el request log).

6) Closing meeting y respuesta: cómo escribir una CAPA letter creíble

Una respuesta débil no es solo “mala”: es peligrosa, porque crea expectativas verificables.

Estructura que funciona (y resiste un re-audit):

• Acknowledge: reconocer la observación (sin defensa instintiva)
• Immediate containment: acciones inmediatas para recuperar control
• Root cause: sistémica, no “error humano”
• CAPA: acciones, responsables, plazos y entregables
• Effectiveness check: cuándo y cómo se demostrará la eficacia
• Risk assessment: impacto en lotes/paciente y posible escalado

📌 Insight contrarian (mito a desmontar): «Basta con responder rápido».

Responder rápido con CAPAs genéricas (“re-training”) genera recurrencias.
Mejor responder con pocas acciones, pero medibles (p. ej., actualización de SOP + evaluación de competencias + verificación en campo + auditoría focalizada).

Checklist “30 segundos”

• Request log listo y asignado
• Evidence package: PQR/APR, tendencias de desviaciones, CAPA aging, change log
• Roles: host / scribe / runner / SME / document control
• Rutas en planta: status label, segregación, logbooks, line clearance
• Plan de respuesta: borrador de CAPA letter / 483 response

FAQ

¿Quién debe hablar con el inspector durante una inspección GMP?
Idealmente una voz guía (QA host) y SMEs solo cuando sea necesario. Demasiados interlocutores aumentan incoherencias.

¿Cuánto material conviene mostrar?
Solo lo solicitado y lo necesario para contextualizar. El over-sharing incrementa los findings.

¿Qué hace que una CAPA sea “débil” a ojos del inspector?
CAPA no medible, sin effectiveness check o con root cause “humana” no soportada.

Si quieres convertir este playbook en un toolkit operativo (checklists de hosting, templates de request log, estructura de respuesta CAPA), la guía completa sobre el rol del QA Manager es la referencia interna más útil.