GAMP 5 Categoría 4 para motores de decisión probabilísticos — por qué "configurable" es la clasificación correcta

1. Resumen ejecutivo

GAMP 5 — Good Automated Manufacturing Practice versión 5, publicada por ISPE — es el estándar de facto del sector para la validación de sistemas informáticos (CSV) en entornos farmacéuticos regulados. Su marco de categorías (1 a 5) determina la profundidad y la amplitud de la actividad de validación. Los motores de decisión probabilísticos para operaciones farmacéuticas son una nueva clase de software que encaja con dificultad en las categorías existentes: no son ni simples herramientas parametrizadas (Cat 3) ni desarrollos totalmente a medida (Cat 5).

Este documento defiende que la Categoría 4 — software configurable — es la clasificación correcta para motores como GRIP de Synlogica, donde la capa de reglas deterministas (SOP, controles GxP) y los parámetros del modelo probabilístico (coeficientes de Arrhenius, distribuciones a priori bayesianas, distribuciones de Monte Carlo) son configurables por cada cliente, pero el motor subyacente — la matemática probabilística, el grafo de ejecución de reglas, el formato del paquete de decisión — se cualifica una sola vez por el proveedor y se utiliza sin cambios por cada cliente.

La clasificación importa porque delimita el esfuerzo de validación. Una clasificación Cat 5 (a medida) exigiría que el cliente validara las funcionalidades internas del motor frente a sus requisitos específicos (normalmente entre 200 y 400 jornadas-persona de esfuerzo). Una clasificación Cat 4 correcta acota la validación del lado del cliente a la capa de configuración (normalmente entre 40 y 80 jornadas-persona) y acepta la cualificación que el proveedor hace del propio motor.

2. Categorías de GAMP 5 — un repaso de 90 segundos

La Segunda Edición de GAMP 5 (2022) describe cinco categorías de sistemas informatizados, cada una con un enfoque de validación recomendado:

(La Categoría 2 se eliminó en la Segunda Edición; se mantiene la numeración 1, 3, 4, 5 como referencia retrospectiva.) El marco se basa en el riesgo: el esfuerzo de validación debe ajustarse al impacto GxP, la complejidad y la novedad del sistema.

La Categoría 4 merece especial atención porque es la más importante a nivel operativo: cubre los sistemas que los equipos farmacéuticos utilizan realmente en su día a día (ERP, LIMS, MES) y, cada vez más, los sistemas de decisión que se asientan sobre ellos.

3. El reto de la clasificación para motores probabilísticos

Los motores de decisión probabilísticos complican la conversación habitual de Cat 3 frente a Cat 4 frente a Cat 5 de tres maneras:

3.1 El motor es el mismo; los parámetros no lo son

Cada cliente de Synlogica Terminus utiliza la misma versión del motor GRIP — el muestreador de Monte Carlo, la lógica de actualización bayesiana, el integrador de Arrhenius son idénticos bit a bit entre los distintos clientes. Lo que difiere es la configuración: parámetros de Arrhenius por cliente para la cartera de API, distribuciones a priori bayesianas por cliente para la elasticidad del proveedor, distribuciones de entrada de Monte Carlo por cliente para el riesgo de ruta. Este es el patrón de Cat 4 de manual.

3.2 Las salidas probabilísticas no son idénticas bit a bit entre ejecuciones (por diseño)

Una simulación de Monte Carlo inicializada con un estado inicial aleatorio produce salidas estadísticamente equivalentes, pero no idénticas bit a bit entre ejecuciones. Los inspectores formados en software determinista a veces señalan esto como falta de reproducibilidad, lo que sería un problema de Part 11. La respuesta correcta: el motor inicializa la simulación de forma determinista por cada decisión (usando, p. ej., SHA-256 del linaje de los datos de entrada), de modo que cualquier decisión puede reproducirse bit a bit aunque dos ejecuciones no relacionadas difieran entre sí.

3.3 La capa de la política de decisión es configuración de tolerancia al riesgo, no código a medida

"Recomendar liberación si la probabilidad de superar el umbral es inferior al 5% Y el lote no es estéril Y la clase de producto es clase B" parece lógica a medida, pero es la configuración de un DSL genérico de políticas. Mientras el propio DSL esté cualificado y la configuración se valide como cualquier configuración de Cat 4, esto no es Cat 5.

El riesgo de una clasificación incorrecta es simétrico: subclasificar (p. ej., Cat 3) y que el inspector pida evidencia de validación que falta; sobreclasificar (Cat 5) y que el equipo dedique años-persona a validar lo que el proveedor ya ha cualificado.

4. Por qué la Categoría 4 (configurable) es la opción adecuada

La adecuación a la Categoría 4 se apoya en tres observaciones:

4.1 El producto existe con independencia de cualquier cliente concreto

GRIP es desarrollado y cualificado por Synlogica como producto. Cada cliente recibe el mismo binario del motor, las mismas implementaciones de algoritmos, el mismo formato de paquete de decisión. Esta es la prueba definitoria de la Categoría 4 frente a la Categoría 5: un sistema Cat 5 se construye para un único cliente; un producto Cat 4 se construye una sola vez y lo usan muchos.

4.2 La superficie de configuración es estructurada, no arbitraria

Los clientes configuran GRIP a través de una superficie definida: conjuntos de reglas (declarados en un DSL estructurado), parámetros del modelo (entradas tipadas con reglas de validación), configuraciones de política (seleccionadas de un conjunto documentado de plantillas de política con parámetros de tolerancia al riesgo), puntos de integración de datos (mapeados a través de una capa de conectores). No escriben código dentro de GRIP. No modifican las funcionalidades internas del motor.

4.3 Existen paquetes de cualificación del proveedor y son auditables

El proveedor (Synlogica) mantiene documentación de cualificación de GAMP 5 Categoría 4 para GRIP — cualificación de diseño, registros de revisión de código, informes de pruebas unitarias y de integración, protocolos de cualificación, notas de versión por cada release. Estos se ponen a disposición de los clientes bajo el acuerdo de tratamiento de datos como parte del trust pack. El esfuerzo de validación del cliente se construye sobre esta evidencia en lugar de duplicarla.

La combinación — software de clase producto, superficie de configuración estructurada, evidencia de cualificación del proveedor — es exactamente el patrón para el que se definió la Categoría 4.

5. Qué cambia frente a la Categoría 5 (a medida)

Las diferencias prácticas entre los niveles de esfuerzo de Cat 4 y Cat 5 son sustanciales:

El enfoque de Cat 4 no es "menos riguroso"; es "rigor repartido entre proveedor y cliente". El rigor del cliente se concentra en la validación de la configuración (que el proveedor no puede hacer por él), y el rigor del proveedor se concentra en la cualificación del motor (que sería un derroche duplicar por cada cliente).

6. Entregables de validación que un cliente debería esperar

Del proveedor (como parte del trust pack):

• Dosier de auditoría del proveedor — incluido el estado de ISO 9001 / ISO 27001, documentación del ciclo de vida de desarrollo, registros de revisión de código y control de cambios.
• Protocolo e informe de cualificación de GRIP — cualificación de diseño, cobertura de pruebas unitarias, cobertura de pruebas de integración, cualificación del rendimiento.
• Notas de versión por cada release — qué cambió en el motor, qué cambió en el DSL de reglas, qué cambió en el DSL de políticas, qué cambió en el formato del paquete de decisión. Versionado mediante semver.
• Matriz de trazabilidad — requisito → diseño → código → prueba, mantenida en cada release.
• Evaluación de riesgo de las salidas probabilísticas — que cubre el mecanismo de determinismo por inicialización (seeding) y las garantías de convergencia de las actualizaciones de Monte Carlo / Bayesian.

Del cliente (elaborados con el apoyo del proveedor):

• Especificación de requisitos de usuario (URS) — acotada al uso previsto: qué decisiones de negocio se tomarán con Terminus.
• Evaluación de riesgo funcional — impacto GxP por clase de decisión, controles por nivel de impacto.
• Especificación de configuración — las reglas, parámetros y políticas específicas del cliente, con su justificación.
• Scripts de IQ / OQ — centrados en la capa de configuración y en la integración con los sistemas existentes (eQMS, ERP, TMS).
• PQ (cualificación del rendimiento) — escenarios de extremo a extremo que confirman que el sistema configurado da soporte a las decisiones de negocio previstas.
• Informe resumen de validación — que cierra el ciclo de vida de la validación y autoriza el uso en producción.

7. Validar la lógica probabilística — los retos específicos

7.1 "Misma entrada, misma salida" — la prueba de reproducibilidad

Los sistemas probabilísticos pueden validarse para lograr reproducibilidad bit a bit inicializando el muestreador aleatorio de forma determinista. La prueba: un paquete de decisión reproducido frente a la misma versión del motor con las mismas entradas debe producir la misma salida. GRIP lo consigue mediante una inicialización (seeding) derivada de SHA-256. La evidencia de validación es un protocolo de reproducibilidad que reproduce N decisiones de producción y confirma salidas idénticas.

7.2 "¿Qué ocurre cuando las entradas se degradan?" — la prueba de robustez

Los motores probabilísticos necesitan pruebas explícitas de qué ocurre cuando los datos de entrada faltan, son ruidosos o están fuera de los rangos esperados. El comportamiento esperado es la negativa controlada a recomendar en lugar de una recomendación basada en entradas asumidas. Los scripts de OQ de GAMP 5 para sistemas probabilísticos deberían incluir pruebas negativas que cubran la indisponibilidad de datos, la anomalía de sensores y la deriva de parámetros.

7.3 "¿Cómo sabemos que el modelo es correcto?" — la prueba de calibración

Se distingue de la validación en el sentido regulatorio. La calibración trata de si las predicciones del modelo coinciden con la realidad (p. ej., si los envíos clasificados como un 95% probables de llegar a tiempo llegan realmente a tiempo el 95% de las veces). Esto es una cuestión continua de monitorización del rendimiento, separada de la validación. La pregunta de la validación es "¿el sistema implementa correctamente el modelo previsto?"; la pregunta de la calibración es "¿es preciso el propio modelo previsto para nuestras operaciones?".

7.4 "¿Qué cambia cuando se actualiza la versión del motor?" — la prueba de impacto

Cuando el proveedor publica una nueva versión del motor, el equipo de validación del cliente necesita una evaluación de impacto: ¿cambió el comportamiento algorítmico?, ¿cambió la semántica del DSL de reglas?, ¿cambió el formato del paquete de decisión? El versionado de GRIP sigue semver: las versiones de parche son equivalentes bit a bit para entradas válidas, las versiones menores amplían sin romper, y las versiones mayores pueden cambiar la semántica y desencadenar la revalidación por parte del cliente de las configuraciones afectadas.

8. Controles continuos y gestión del cambio

Los sistemas Cat 4 requieren disciplina de validación continua:

• Control de cambios — cada cambio de configuración (nueva regla, parámetro modificado, política actualizada) pasa por el control de cambios con evaluación de riesgo, plan de pruebas, aprobación y verificación posterior al cambio.
• Revisión periódica — normalmente anual; confirma que la configuración sigue siendo apta para su propósito, que la lista de usuarios está actualizada y que las integraciones siguen siendo válidas.
• Gestión de incidencias — toda anomalía en un paquete de decisión se registra, se investiga y se determina su causa raíz. Las anomalías que se rastrean hasta la configuración son del lado del cliente; las que se rastrean hasta el motor son del lado del proveedor y desencadenan una escalada de soporte.
• Notificación de cambios del proveedor — el proveedor notifica cada release. El equipo de validación del cliente evalúa el impacto y decide el alcance de la revalidación.
• Monitorización continua del rendimiento — las métricas de calibración (predicho frente a real) se reportan periódicamente; una deriva significativa desencadena un reajuste de la configuración.

El mayor error en la validación continua de Cat 4 es tratarla como un evento puntual. El sistema se cualifica en la puesta en marcha; los controles continuos lo mantienen cualificado a lo largo de los cambios. La madurez de la validación se mide por la disciplina de esos controles continuos, no por la profundidad de la cualificación inicial.

9. Conclusiones

1. GAMP 5 Categoría 4 (configurable) es la clasificación correcta para motores de decisión probabilísticos como GRIP, donde el motor lo cualifica el proveedor y los clientes configuran reglas, parámetros y políticas.
2. La sobreclasificación a Cat 5 (a medida) añade entre 3 y 5 veces más esfuerzo de validación sin aportar valor de cumplimiento para software de clase producto con superficies de configuración estructuradas.
3. La documentación de cualificación del lado del proveedor (auditoría del proveedor, protocolo de cualificación, notas de versión, trazabilidad) debe estar disponible bajo el acuerdo de tratamiento de datos y ser considerada como evidencia fiable por los validadores del lado del cliente.
4. La lógica probabilística requiere patrones de validación específicos: determinismo por inicialización (seeding) para la reproducibilidad, pruebas negativas para la degradación de entradas, releases del motor con control de versiones y semántica de semver documentada.
5. La calibración (precisión del modelo en producción) es independiente de la validación (implementación correcta); ambas importan, pero requieren controles distintos.
6. Los controles continuos — control de cambios, revisión periódica, gestión de incidencias, notificación de cambios del proveedor — son donde se mide la madurez de Cat 4.