Una receta cambia tras un ensayo de desarrollo, pero el informe conserva solo el nombre del ciclo. El siguiente proceso termina sin alarmas y el lote se vincula a un PDF sin versión. El equipo puede haber ejecutado correctamente su lógica, pero falta la relación entre parámetros aprobados, configuración real y material tratado. Esa relación debe poder verificarse mediante la automatización.
1. Definir la frontera del sistema informatizado
El sistema comprende más que el PLC. Incluir HMI, registrador independiente, historian, servidores, bases de datos, usuarios, sincronización, copias e interfaces con MES o Calidad. Identificar dónde nacen, se transforman y se conservan los datos. Un diagrama debe describir también interrupciones de comunicación y funcionamiento temporalmente autónomo, manteniendo los fallos dentro del alcance evaluado.
Distinguir control del proceso y gestión documental. Una receta aprobada en Calidad no demuestra que los mismos parámetros estén activos en el PLC. Un registro correcto en el controlador no prueba que la exportación conserve todos los eventos. Las interfaces forman parte del uso previsto. Allí pueden aparecer diferencias entre autorización organizativa y ejecución técnica.
[REGULATORY REQUIREMENT] EU GMP Annex 11 exige un enfoque de ciclo de vida basado en riesgo para sistemas informatizados utilizados en actividades GMP. El texto vigente listado por EudraLex en la fecha de comprobación es el de 2011. No presentar propuestas de revisión como requisitos ya aplicables. Diferenciar disposiciones vigentes y recomendaciones adicionales utilizadas por el proyecto.
2. Traducir el proceso a estados verificables
Describir estados y transiciones: preparado, carga identificada, acondicionamiento, exposición, secado o enfriamiento, finalización, anomalía y parada. Definir condiciones, tiempos máximos, eventos registrados y salidas para cada transición. El comportamiento debe entenderse sin leer código fuente. Esta descripción permite que Ingeniería, Producción y quienes verifican compartan la misma expectativa funcional.
La transición a exposición debe reflejar la estrategia validada. Si depende de varias medidas, aclarar tratamiento de valores ausentes o inválidos. Perder una señal no debe interpretarse accidentalmente como condición satisfecha. Aplicar el mismo principio al final de ciclo, autorización de descarga y transferencia hacia una zona más crítica.
[GEP] Utilizar una matriz causa-efecto para enclavamientos y alarmas críticas. Registrar evento, fase, acción, estado seguro y condiciones de recuperación. Apoya desarrollo, revisión y pruebas, reduciendo diferencias entre especificación, programa y procedimiento. Los cambios en cualquiera de esas capas deben trasladarse a las demás para conservar una descripción actualizada.
3. Gestionar recetas como configuraciones controladas
Cada receta necesita identidad, versión, estado y ámbito. Separar desarrollo, pruebas y producción, impidiendo uso involuntario de configuraciones no aprobadas. Definir parámetros fijos, seleccionables y modificables dentro de límites autorizados. La autorización para transferir una receta al entorno productivo también pertenece a esta gestión, además del permiso para editar valores.
La revisión debe comparar contenido anterior y nuevo, motivo, impacto y aprobaciones. El registro identifica la versión ejecutada y conserva los valores necesarios para reconstruir la secuencia. Guardar solo «ciclo componentes» no distingue configuraciones distintas con igual etiqueta. El vínculo de versión debe permitir recuperar permanentemente el contenido vigente en aquel momento.
Considerar cuándo se carga la receta en el controlador. Si se aprueba un cambio durante un ciclo, debe quedar claro qué versión lo gobierna. Verificar que actualizaciones o sincronizaciones no alteren silenciosamente parámetros activos. El inicio de vigencia de otra versión debe ser inequívoco tanto técnicamente como en las correspondientes evidencias.
4. Alinear accesos y responsabilidades
Definir funciones de operador, supervisor, mantenimiento, administrador y revisor. Asignar permisos necesarios y diferenciar ejecución de modificación. Evaluar separación de responsabilidades críticas según organización y controles compensatorios documentados. Una lista de roles no basta si los privilegios reales son mucho más amplios que las tareas descritas.
Las cuentas deben atribuir acciones a personas autorizadas. Credenciales compartidas reducen esa capacidad y exigen evaluar limitaciones concretas. El acceso del proveedor requiere finalidad, autorización, duración y registro conforme a procedimientos. El soporte técnico no debe crear inadvertidamente una capacidad permanente de modificar configuraciones críticas fuera de la revisión habitual.
Probar creación, cambio, desactivación y caducidad, además del acceso normal. Comprobar una sesión abierta cuando se revoca su rol y gestionar cuentas abandonadas. Incluir funciones administrativas: pueden cambiar controles sobre los que descansa la confianza en proceso y datos. La verificación debe reflejar esos efectos reales, no solo la apariencia del menú.
5. Hacer útil el audit trail
El audit trail debe explicar quién actuó, cuándo, sobre qué elemento y con qué resultado. Conservar valores anteriores y posteriores y motivos requeridos para cambios relevantes. Proteger y verificar configuración del seguimiento. Una tabla de eventos disponible no demuestra que se estén registrando todas las modificaciones decisivas para proceso o datos.
Las entradas tienen significados distintos. Cambiar una receta, desactivar una alarma, ajustar el reloj y fallar un acceso apoyan evaluaciones diferentes. Definir qué revisar por ciclo, periódicamente o de inmediato. Justificar frecuencia según riesgo y uso, asignando responsabilidad para investigar y cerrar hallazgos, de modo que la revisión produzca acciones trazables.
La exportación debe mantener orden, identidad y contexto. Verificar filtros, paginación e intervalos para evitar que una salida aparentemente completa omita eventos. Conservar acceso a originales: una captura de pantalla no sustituye de forma general el registro electrónico. La presentación debe servir al propósito de revisión y hacer visibles sus límites.
6. Conectar alarmas, aborto y reinicio
Un aborto interrumpe o lleva la secuencia a estado seguro según lógica definida. Reiniciar puede significar continuar, comenzar otra secuencia o impedir continuación. Establecer y validar estas reglas durante desarrollo. No deben depender de la preferencia del operador ante el fallo. Incluir también la decisión necesaria sobre la carga presente.
Definir eventos que impiden demostrar prestación aunque no causen daño mecánico. Pérdida de datos críticos, receta errónea o condición no comprobada pueden exigir algo más que un aviso. El mensaje final debe representar el estado y conservar la historia anterior. El informe necesita mostrar lo ocurrido realmente, incluidas excepciones relevantes.
Tras una pérdida eléctrica, reconocer el ciclo interrumpido y ofrecer información conservada. Probar distintos momentos de la secuencia. Reiniciar correctamente el PLC demuestra disponibilidad técnica, no conformidad de la carga durante el corte. Esta diferencia debe entenderse tanto en la interfaz como en el procedimiento operativo y la revisión posterior.
7. Definir registros originales y copias
Establecer qué datos necesita la decisión GMP y dónde residen. Incluir carga, versión, valores reales, eventos, metadatos y aprobaciones. Si el registro está distribuido, documentar vínculos y responsables de conservación. Evaluar integridad entre todos los sistemas participantes, no solo dentro de la aplicación a la que resulta más sencillo acceder.
Un PDF puede servir para revisar, pero debe demostrarse que conserva información necesaria para su uso. Datos dinámicos, audit trail o detalles no exportados pueden requerir sistema original o archivo adecuado. Justificar la elección, sin basarla únicamente en facilidad de impresión. Debe mantenerse capacidad de investigar posteriormente.
Verificar integridad y exactitud de transferencias a historian o MES. Considerar duplicados, retrasos, desorden y pérdida temporal de red. Las reglas de reconciliación deben mostrar problemas e impedir declarar completo un informe con datos ausentes. La retransmisión tampoco debe introducir silenciosamente registros adicionales o contradictorios.
8. Matriz de pruebas esenciales
| Función | Escenario | Evidencia esperada |
|---|---|---|
| Receta | Cambio aprobado antes y durante un ciclo | Versión inequívoca y controlada |
| Accesos | Intento crítico sin privilegio | Acción impedida y registro pertinente |
| Alarma | Pérdida de medida crítica en exposición | Respuesta y datos según especificación |
| Comunicación | Interrupción entre PLC y registro | Laguna detectada y recuperación reconciliada |
| Copia | Restauración autorizada | Datos legibles, completos y utilizables |
| Reloj | Cambio o pérdida de sincronización | Secuencia temporal reconstruible |
Son escenarios prácticos [GUIDEGXP RECOMMENDATION], no una lista normativa exhaustiva. Incorporar riesgos propios y criterios previos a ejecución. Una prueba satisfactoria demuestra comportamiento requerido, no solo ausencia de error. La documentación debe relacionar estado inicial, acción realizada y consecuencias observadas, permitiendo reconstruir por qué se aceptó el resultado.
9. Copias, restauración y continuidad
Las copias deben incluir datos y configuraciones necesarios. Identificar recetas, programas, parámetros, usuarios, certificados y componentes según arquitectura. Proteger copias y comprobar funcionamiento. Encontrar un archivo en destino no demuestra que pueda recuperarse el estado completo y correcto. La selección del contenido debe corresponder al escenario de recuperación previsto.
Las pruebas de restauración deben mostrar sistema utilizable y registros completos y legibles. Establecer condiciones que no afecten a producción. Documentar versión, entorno, datos de muestra, resultado y límites. Restaurar una parte puede aportar evidencia útil, pero no demuestra automáticamente recuperación de todas las funciones y conjuntos de datos.
La continuidad debe explicar qué hacer cuando el sistema no está disponible. Un procedimiento manual temporal solo sirve si está previsto y conserva controles necesarios. No crear registros retrospectivos sin evidencia para rellenar lagunas. Las decisiones deben distinguir pruebas contemporáneas disponibles de información que realmente se ha perdido.
10. Ejemplo: informe aparentemente completo
En un caso ilustrativo, el PDF muestra éxito del PLC mientras el historian perdió conexión durante una fase crítica. El controlador conserva algunos datos locales, pero la impresión no indica la laguna. El equipo suspende aceptación automática y evalúa los originales disponibles antes de decidir sobre el material.
La investigación diferencia prestación física e integridad del registro y determina si los datos locales permiten reconstrucción fiable. La corrección incorpora aviso de transferencias incompletas y reconciliación. Las nuevas pruebas incluyen pérdida, recuperación y prevención de duplicados. La solución debe abordar la causa, no limitarse a cambiar el diseño del informe.
Un informe no debe sugerir mayor integridad que los datos disponibles. Mostrar estado final y excepciones. Calidad decide con pruebas reales, no con la apariencia profesional del documento. Esto resulta especialmente importante cuando varios sistemas ofrecen fragmentos diferentes de información sobre un mismo ciclo y deben evaluarse conjuntamente.
11. Validación y proveedor
Evaluar competencia, desarrollo, versiones y soporte del proveedor. Sus documentos y pruebas pueden contribuir si son adecuados y revisados. Comprar un paquete denominado «validado» no transfiere responsabilidad del centro por uso GMP. El proyecto debe mostrar cómo las pruebas suministradas cubren el sistema y la utilización realmente previstos.
[GUIDANCE] GAMP 5, segunda edición de 2022, ofrece buenas prácticas para sistemas informatizados. No es ley ni certificación automática de software. Ajustar evidencia a riesgo, uso y conocimiento. Que una descripción comercial mencione GAMP no sustituye una verificación justificada de funciones críticas.
Relacionar URS, especificaciones, riesgos, ensayos y desviaciones. Definir autorización y mantenimiento del estado validado. Una lista de pruebas ejecutadas no basta si se desconoce cobertura o riesgos abiertos. Los asuntos pendientes necesitan evaluar su importancia para el uso y una decisión autorizada sobre sus consecuencias.
12. Cambios y revisión periódica
Actualizaciones, parches, hardware, migraciones e interfaces pueden afectar al control o a los datos. Evaluar impacto, pruebas, reversión y documentación. Justificar equivalencia mediante propiedades relevantes, no solo modelo comercial. Un cambio técnicamente pequeño puede importar si modifica tiempos, tratamiento de medidas o conservación de información.
La revisión considera incidentes, accesos, prestaciones, copias, modificaciones, documentación y soporte. Incluir dependencias externas y componentes sin asistencia. Planificar modernización antes de que una urgencia obligue a decidir sin pruebas suficientes. Asignar responsables y medidas a riesgos conocidos del ciclo de vida.
Son señales de alerta cuentas compartidas sin control, recetas sin versión, audit trail no revisable, copias nunca restauradas e informes con lagunas ocultas. Una automatización adecuada muestra relación entre configuración aprobada, acciones, proceso y datos. Debe seguir siendo comprensible y verificable durante toda la vida útil.
13. Entrega a Producción
Antes de autorizar, confirmar configuración instalada frente a probada y recetas aprobadas. Verificar procedimientos, formación, anomalías y administración. Las desviaciones abiertas requieren impacto documentado y decisión autorizada. Una lista de tareas pendientes no debe ocultar funciones críticas no demostradas entre actividades generales del proyecto.
Entregar una configuración base recuperable de software y ajustes, con versiones y pruebas. El centro debe saber obtener soporte y qué intervenciones requieren autorización previa. Establecer cómo detectar cambios inesperados tras acceso remoto o mantenimiento. La entrega combina documentación técnica y reglas claras para su utilización posterior.
Demostrar con usuarios selección de carga, inicio, lectura del registro, gestión de una excepción y recuperación del archivo. Esto confirma utilizabilidad conforme a procedimientos. No sustituye validación, pero puede revelar lagunas organizativas antes de producir. Incorporar los hallazgos a formación e instrucciones de trabajo.
Referencias y contenidos relacionados
Fuentes verificadas el 23 de septiembre de 2026: EU GMP Annex 11 vigente listado y Annex 15; ISPE GAMP 5, segunda edición 2022. Las matrices son originales y no reproducen procedimientos propietarios.
Continuar en Sterilization & Depyrogenation Systems, vigilancia de ciclos, cualificación y Automation & Digital Systems.
