Validación del WMS en GDP: Data Integrity y Audit Trail para la Responsible Person
Validación del WMS en GDP: Data Integrity y Audit Trail — lo que realmente pide el inspector
Si durante una inspección te preguntan: “¿Quién modificó la fecha de caducidad de este lote y por qué?”, no están poniendo a prueba al operario de almacén. Están poniendo a prueba tu sistema.
Y ahí está el punto: hoy, en GDP, la compliance ya no se juega solo en cámaras frigoríficas y albaranes. Se juega en los registros electrónicos, los audit trails y la gobernanza IT.
En 30 segundos
Un WMS no es “GDP-compliant” porque funcione. Es GDP-compliant cuando puede demostrar qué ocurrió, quién lo hizo y cuándo.
La CSV (Computer System Validation) en logística casi siempre falla por las mismas razones: URS débiles, testing superficial, accesos demasiado amplios y un audit trail que existe pero nunca se revisa.
El mito peligroso es: “Imprimimos un PDF y ya estamos cubiertos.”
Spoiler: no.
El vocabulario que aparece en los findings (LSI “lenguaje de inspector”)
En el entorno digital de GDP, prepárate para oír, y para demostrar: CSV, URS, matriz de trazabilidad, IQ/OQ/PQ, GAMP 5, EU Annex 11, 21 CFR Part 11, ALCOA+, audit trail review, RBAC (role-based access control), segregation of duties, change impact assessment, backup/restore test, disaster recovery.
Qué datos del WMS son realmente “GDP-critical”
En una auditoría, la pregunta implícita siempre es:
“Si este dato fuera erróneo o estuviera manipulado, ¿podría perder trazabilidad o liberar producto no apto?”
Tabla: datos críticos y controles esperados
| Dato / objeto en WMS/ERP | Riesgo GDP si es erróneo | Control “audit-proof” esperado |
|---|---|---|
| Lote / batch | recall incompleto, trazabilidad rota | audit trail activo, informes one-step-back/forward, controles de entrada |
| Fecha de caducidad | FEFO distorsionado, envío de producto caducado | bloqueo lógico, audit trail sobre cambios, workflow de aprobación |
| Estado del stock (cuarentena/liberado/bloqueado) | liberación indebida | cuarentena electrónica, autorizaciones segregadas, event log |
| Cantidades movidas | descuadre de inventario, robos internos no detectados | reconciliaciones, exception reports, controles sobre adjustments |
| Timestamps de operación | reconstrucción de eventos no fiable | sincronización horaria (NTP), governance de zonas horarias, controles de clock drift |
| Interfaces (portal de pedidos, serialización, TMS) | pérdida o alteración de datos | interface validation, controles de completitud, gestión de errores |
Desde la perspectiva de fabricación, el WMS suele verse como algo “fuera del perímetro GMP”. En una auditoría GDP, sin embargo, se convierte en un sistema de calidad: si no está gobernado, la Responsible Person se queda sin evidencia objetiva.
CSV en GDP: cómo hacerla sin una “validación de papel maché”
En auditoría, el problema más frecuente que veo es este: compañías con un bonito “Validation Report”, pero sin lógica de riesgo, sin trazabilidad entre requisitos y pruebas, y con tests que no cubren los verdaderos failure modes.
Un enfoque práctico que resiste en inspección
1) GxP scoping y risk assessment
Identifica las funciones con impacto GxP, por ejemplo:
- bloqueo por caducidad
- cuarentena
- trazabilidad
- integración de serialización
Clasifica el sistema con lógica tipo GAMP 5: ¿configurado, personalizado, SaaS?
2) URS robustas — no “el sistema debe funcionar”
Ejemplo de una URS útil:
“El sistema debe impedir el envío de lotes con fecha de caducidad anterior a la fecha de envío y debe registrar el evento en el audit trail.”
3) Matriz de trazabilidad
Cada URS debe terminar en uno o más test cases. Si ese vínculo no existe, es un gap de auditoría.
4) Testing IQ/OQ/PQ — incluyendo casos “sucios”
- IQ: instalación / entorno
- OQ: funciones y controles, como roles, bloqueos, audit trail, timestamps
- PQ: procesos reales, por ejemplo recepción → almacenamiento → picking → expedición → retrabajo
5) Data migration y master data governance
Si importas master data, datos de producto o fechas de caducidad, necesitas evidencia de que no “ensuciaste” los datos.
Aquí es donde suelen aparecer incidentes como:
unidad de medida interpretada mal, box vs pack → envíos incorrectos.
6) Go-live con quality gate
IT no debe decidir sola. El go-live debe tener un quality gate, con evidencia mínima formalmente cerrada.
Para recordar
Un WMS no está validado porque el vendor diga que lo está.
Está validado cuando tú puedes demostrar que la configuración y el uso del sistema dentro de tu proceso GDP están bajo control.
Audit trail: activarlo no basta — hay que revisarlo
Contrarian insight, mito común:
“Activamos el audit trail y, si hace falta, ya lo miraremos.”
Es una práctica obsoleta porque:
- convierte el audit trail en una herramienta reactiva, no en un mecanismo de control
- deja abierta la puerta al data integrity drift, es decir, errores repetidos o comportamientos oportunistas
Qué significa “audit trail review” en la práctica
Primero, define los campos críticos:
- fecha de caducidad
- lote
- estado
- ajustes de cantidad
- override de bloqueos
Después, define una frecuencia de revisión basada en riesgo:
- mensual sobre muestras
- trimestral sobre tendencias
- ad hoc ante eventos específicos
Busca patrones típicos:
- cambios repetidos en fechas de caducidad
- borrados u overrides anómalos
- actividad “fuera de horario” sin justificación
- uso excesivo de perfiles admin
En una auditoría, la pregunta clave es:
“¿Puede mostrarme evidencia de que el audit trail se revisa antes de que un problema se convierta en un recall?”
Accesos, roles y segregación: incluso las buenas compañías fallan aquí
El problema más habitual que veo en auditoría es una cuenta compartida en terminales o handhelds, como “ALMACEN1”, o perfiles demasiado potentes “por comodidad”.
Contramedidas que realmente funcionan
- RBAC: roles mínimos necesarios
picking ≠ master data ≠ release/quarantine - Proceso Joiner–Mover–Leaver: para crear, modificar y desactivar accesos
- User access review periódica: al menos anual, mejor cada seis meses para roles críticos
- MFA cuando sea posible, especialmente en accesos remotos y roles admin
- Segregation of duties: quien crea o modifica master data no debería aprobar excepciones
Patches y upgrades: cuando IT “mejora” y GDP empeora
Actualizar un sistema es normal. Hacerlo sin control es un riesgo GDP.
Checklist práctica
- cada patch o upgrade pasa por un change impact assessment
- existe un entorno TEST separado
- realizas regression testing sobre procesos GDP-critical
- el resultado y la liberación quedan documentados
- para SaaS: vendor qualification más evidencia de release notes y evaluación de impacto
Desde la perspectiva IT, un cambio de software suele parecer “rutina”.
Desde la perspectiva GDP, puede ser el origen de:
- bloqueos de caducidad que dejan de funcionar
- audit trail degradado
- informes de trazabilidad que dejan de ser reproducibles
Recuadro de conclusiones clave
- CSV en GDP = proceso + evidencia, no un PDF en una carpeta compartida
- Audit trail = activo + protegido + revisado
- Los 3 grandes killers en auditoría: accesos, falta de revisión y cambios IT no gobernados
- Si pierdes data integrity, también pierdes la capacidad de ejecutar un recall eficaz
FAQ
¿Se necesita 21 CFR Part 11 en una empresa de la UE?
No siempre como obligación legal directa. Sin embargo, los conceptos subyacentes, como audit trail, firmas electrónicas y controles de acceso, suelen esperarse como best practice cuando se gestionan registros electrónicos relevantes para GxP.
¿Qué sistemas debo validar para GDP?
Todos los sistemas que impactan la trazabilidad, el estado del stock, las fechas de caducidad, la temperatura, la serialización y el reporting de recall. Típicamente:
- WMS / ERP
- sistemas de monitorización de temperatura
- módulos de serialización
- interfaces de pedidos
¿Con qué frecuencia debe hacerse la audit trail review?
El mejor enfoque es risk-based: mensual sobre muestras para campos críticos, y con mayor frecuencia si tienes muchas excepciones.