Toda propuesta de registro electrónico de lote (eBR) enumera las mismas capacidades: firma electrónica conforme a 21 CFR Part 11, control de secuencia de pasos, registro de auditoría completo y bloqueo de valores fuera de especificación. La lista es prácticamente idéntica de un proveedor a otro, y con razón: es lo mínimo exigible a cualquier sistema para manufactura farmacéutica. Justamente por eso no distingue a nadie.
La pregunta que casi nunca aparece en un proceso de calificación de proveedor GxP es otra, y es la que decide si el sistema resistirá una inspección: ¿cómo se comprobó ese control?
La mayoría de las demostraciones comerciales muestran el sistema haciendo exactamente lo que está previsto que haga. Un operario captura un valor, el sistema lo acepta o lo rechaza según el rango configurado, la pantalla avanza al paso siguiente. Se ve bien. Y no dice nada sobre lo que ocurre cuando alguien, por intención o por error de operación, intenta que el sistema haga algo distinto de lo previsto.
Esa segunda prueba es la que rara vez se muestra. En este artículo la documentamos.
Qué es la verificación adversarial de controles GxP
La verificación adversarial de controles GxP parte de una premisa incómoda: un control que solo se ha probado en su uso correcto no se ha probado.
Cada control crítico se somete a dos pruebas. La primera, convencional: se usa el sistema tal como se espera que se use, y se confirma que el control actúa. La segunda, adversarial: se intenta evadir ese control de forma deliberada, por las vías que un usuario malintencionado, un error de configuración o un fallo de infraestructura explotarían en producción.
Las vías de ataque que aplicamos sobre los controles de un eBR son tres:
- Invocación directa al servidor, omitiendo por completo la interfaz de usuario. Si un control solo vive en la pantalla, esta prueba lo revela de inmediato.
- Manipulación del contenido de la petición, alterando datos que el sistema podría estar asumiendo como confiables por venir del cliente.
- Interrupción deliberada de servicios dependientes, para observar si el sistema falla de forma segura o si deja pasar el dato cuando el componente que lo validaba deja de responder.
Este ejercicio no sustituye la calificación operacional formal ni el proceso completo de validación de sistemas computarizados. Lo que hace es alimentar esa validación con evidencia más sólida que una especificación funcional y una demostración en condiciones ideales.
Tres casos ilustran el método.
Caso 1. Saltar un paso que la interfaz no muestra
El intento. Forzar la ejecución del paso siguiente de un lote sin haber completado el anterior, enviando una petición directa al servidor, sin pasar por ningún botón ni pantalla del sistema.
El resultado. Rechazo. No porque un botón estuviera oculto o deshabilitado en la interfaz, sino porque la tarea correspondiente al paso siguiente todavía no existe dentro del motor de proceso. El sistema no tiene nada que ejecutar, aun cuando se le solicite directamente. Existe además una segunda capa de verificación independiente que también falla de forma cerrada si el paso previo no está completo.
Por qué importa. Hay una diferencia de fondo entre un control de interfaz y un control de estado, y se vuelve visible exactamente en esta prueba:
- Un control de interfaz impide que el usuario vea la opción de avanzar. Cualquiera con conocimiento técnico básico puede sortearlo llamando al servidor por fuera de la pantalla.
- Un control de estado hace que la acción sea imposible en el motor mismo, independientemente de cómo se intente invocarla.
Para un inspector, la diferencia entre ambos es la diferencia entre un candado en la puerta y una puerta que todavía no existe.
Caso 2. Aprobar la propia captura
El intento. Un usuario registrado como autor de una versión intenta, mediante manipulación directa de la petición al servidor, quedar registrado también como aprobador de esa misma versión.
El resultado. Rechazo, verificado antes de aceptar la firma. El servidor conserva la autoría del registro y el servicio de firma electrónica comprueba esa autoría antes de admitir cualquier firma de aprobación. No se trata de qué botones aparecen en pantalla para ese usuario: es una verificación que ocurre del lado del servidor, sobre datos que el cliente no controla. Incluso el escenario en que el servicio de firma deja de responder a mitad de la operación quedó cubierto: el sistema revierte la operación en curso en lugar de dejarla a medias.
La parte que conviene contar completa. Este control no fue un acierto desde el primer diseño. Su primera versión, detectada y corregida en desarrollo, antes de cualquier despliegue en un entorno validado, falló exactamente esta prueba: bajo determinadas condiciones, permitía que el mismo usuario quedara registrado como autor y como aprobador. Se documentó el fallo, se corrigió el mecanismo y se volvió a atacar de la misma forma hasta que resistió.
Por qué importa. Un sistema que nunca fue sometido a esta prueba no tiene manera de demostrar que resistiría. Un sistema con un fallo documentado, corregido y reverificado tiene algo más valioso que un historial limpio: evidencia de que el proceso de desarrollo detecta brechas y las cierra, que es precisamente lo que un régimen de control de cambios debe poder demostrar. La ausencia de fallos en el registro no garantiza nada. El historial de fallos encontrados y cerrados sí.
Caso 3. Cuando el componente que valida deja de responder
El intento. Apagar deliberadamente el servicio responsable de evaluar si un valor capturado cae dentro del rango permitido, mientras un operario está a mitad de una captura en piso.
El resultado. El sistema bloquea el guardado del dato. No permite que el valor entre al registro sin validación solo porque el validador dejó de estar disponible.
Por qué importa. Esta es la diferencia entre un sistema que falla cerrado y uno que falla abierto, y es de los puntos que un auditor reconoce de inmediato porque conecta directamente con los principios de integridad de datos ALCOA+.
Un sistema que permite avanzar sin validación cuando un componente cae no está fallando de forma segura: está abriendo una ventana en la que datos sin control de calidad entran al registro regulatorio, sin que nadie lo note hasta la revisión del historial de lote. La disciplina de fallar cerrado debe estar presente en cada componente del que dependa un control crítico, no solo en el componente principal.
Lo que este método no resuelve
Conviene ser preciso sobre los límites del ejercicio, porque un proveedor que presenta su metodología como infalible está describiendo marketing, no ingeniería.
La verificación adversarial confirma que un control resiste los ataques que efectivamente se le aplicaron. No demuestra que resista todos los ataques posibles. No sustituye los protocolos IQ/OQ/PQ, ni el plan maestro de validación, ni la evaluación formal de integridad de datos que un sistema de este tipo requiere antes de entrar a producción.
Tampoco todos los controles de un sistema exigen el mismo nivel de segregación. Algunas decisiones de diseño son deliberadas y no deben leerse como huecos: que dos roles determinados no puedan recaer en la misma persona en un punto del flujo no implica que ninguna combinación de roles pueda compartirse en otro punto donde el requisito regulatorio aplicable no lo exige.
La pregunta correcta no es si todo está segregado, sino si lo que exige segregación efectivamente la tiene, y si esa decisión quedó documentada como tal en la especificación.
La pregunta que debería estar en toda calificación de proveedor
La pregunta habitual en un proceso de calificación de proveedor es alguna variante de “¿su sistema cumple con 21 CFR Part 11?”. Casi cualquier proveedor puede responder que sí, y esa facilidad es exactamente lo que la vuelve inútil como criterio de decisión.
Una pregunta que sí exige evidencia:
¿Puede mostrarme el registro de un intento deliberado de evadir este control, y el resultado de esa prueba?
Cómo interpretar la respuesta:
- Si llega en forma de especificación funcional o de una demostración del sistema en uso normal, la verificación adversarial probablemente no ocurrió.
- Si llega acompañada únicamente de éxitos, conviene preguntar cuántos intentos se ejecutaron y de qué tipo.
- Si incluye al menos un intento que reveló una brecha, junto con la corrección aplicada y la reverificación posterior, hay evidencia de un proceso de desarrollo que toma en serio la posibilidad de fallar.
Esa pregunta separa a un proveedor que diseñó controles de uno que los puso a prueba. Es, en la práctica, uno de los pocos criterios de calificación de proveedor GxP que un comité técnico puede evaluar sin depender de la palabra del proveedor.
Cómo se conecta con el Anexo 11 revisado
El borrador de revisión del Anexo 11 de EudraLex, publicado el 7 de julio de 2025 junto con el Capítulo 4 y el nuevo Anexo 22, refuerza tres exigencias que esta metodología atiende directamente: la evaluación formal de capacidad del proveedor, la demostración documentada de control de cambios sobre sistemas validados y la incorporación de la ciberseguridad al perímetro de cumplimiento GMP.
Un proveedor que solo puede mostrar que su sistema funciona no satisface ninguna de las tres con solvencia. Un proveedor que puede mostrar cómo lo puso a prueba, qué encontró y cómo lo cerró, satisface las tres con el mismo cuerpo de evidencia.
Desarrollamos el análisis completo de los cambios del borrador en Anexo 11 y Anexo 22: qué cambia para un eBR. La lista de verificación por punto está disponible para equipos de Calidad y Validaciones dentro del dossier de calificación de proveedor.
Resumen en video
Revisión rápida de los tres vectores de ataque y cómo cada uno revela la fortaleza de los controles en un eBR.
Conversemos sobre su escenario
Si su equipo de Validaciones tiene en mente un escenario de ataque contra su propio registro electrónico de lote, uno que nunca se ejecutó en producción porque el riesgo no lo permitía, conversemos sobre cómo se plantearía esa prueba en un entorno controlado.
No es necesario que el sistema sea nuestro para que la conversación tenga valor.
Conocer la línea farmacéutica de Valdrent
Valdrent diseña e implementa sistemas de registro electrónico de lote conforme a 21 CFR Part 11, EudraLex Anexo 11 y RTCA 11.03.42:07, con despliegue dentro de la infraestructura del cliente.