Automatización, SCADA e integridad de datos en sistemas de agua farmacéutica

A las tres y cuarenta de la madrugada el retorno del loop de WFI registra una excursión de conductividad que dura pocos minutos y vuelve sola a la normalidad. Nadie la advierte: la alarma está configurada con prioridad baja y la pantalla se reinicia al cambio de turno. Dos semanas después, durante la investigación de un resultado microbiológico atípico, Calidad pide el dato bruto de aquella noche. El historian devuelve un valor promediado sobre el intervalo de registro: el pico ya no existe. La configuración de compresión la definió el integrador en la puesta en marcha, no figura en ninguna especificación de configuración y ningún audit trail conserva su rastro.

No es un problema de instrumentación: los transmisores estaban calibrados. Es un problema de sistema informatizado — qué se adquiere y con qué resolución, quién puede modificar su configuración, dónde el valor se convierte en un registro GMP y durante cuánto tiempo sigue siendo reconstruible. En los sistemas de agua farmacéutica esta parte llega casi siempre con el skid, configurada por un integrador y aceptada como «funcionando». El alcance de Annex 11 y Part 11 no se hereda del proveedor: lo define, lo justifica y lo documenta la planta.

Dónde nace el dato y dónde se convierte en registro

Un sistema de agua tiene cuatro niveles. Los instrumentos generan la señal: conductividad, temperatura, TOC, caudal, presión, ozono residual. El PLC ejecuta la lógica: regulación, enclavamientos, secuencias de sanitización, comparación con los límites. El HMI muestra y opera en campo. El SCADA supervisa alarmas, cuentas de usuario, recetas y tendencias; el historian conserva la serie histórica y la hace consultable.

El primer entregable de un proyecto de automatización GMP no es una especificación de software: es el mapa del flujo del dato. Para cada parámetro crítico debe quedar escrito dónde nace, dónde se procesa, dónde se hace duradero, qué copia es el registro de referencia y quién puede modificarla en cada nivel. Responde a las dos preguntas que cuentan en una inspección: cuál es el dato original y quién puede cambiarlo sin dejar rastro. Allí hay que resolver dos situaciones: si el registro duradero reside en el historian, la cadena que lo genera — intervalo de muestreo, filtros, compresión — determina qué podrá demostrar ese registro; y los analizadores de TOC con memoria, cuentas y audit trail propios son sistemas informatizados independientes, no componentes absorbidos implícitamente en el alcance del SCADA.

Qué datos son críticos y para qué decisión

La pregunta que desbloquea el alcance no es «¿el sistema está sujeto a la Part 11?», sino: ¿qué decisión GMP toma alguien mirando este dato? Si nadie decide nada, es un dato de proceso. Si alguien libera un uso, cierra una investigación o justifica un límite, es un registro GMP y arrastra consigo los controles.

El Annex 1 de EudraLex Volumen 4 hace que este mapa no sea negociable en tres puntos. El 6.15 exige que los sistemas de WFI incluyan monitorización continua, como TOC y conductividad: es exactamente el dato que el sistema informatizado debe adquirir y conservar íntegro. El 6.13 establece que los alert level deriven de los datos de la cualificación inicial y se revisen mediante recualificación, monitorización rutinaria e investigaciones: los límites son, por tanto, parámetros de configuración que cambian con el tiempo y deben cambiar bajo control. El 6.14 pide que las excursiones de alerta se documenten, revisen e investiguen distinguiendo el evento aislado de la tendencia adversa: distinción posible solo si la serie histórica está completa y es legible. Los aspectos metrológicos se tratan en el artículo sobre monitorización en línea de TOC y conductividad.

El marco regulatorio: qué está vigente

EudraLex Volumen 4, Annex 11 (Computerised Systems). La versión vigente es la de enero de 2011, operativa desde el 30 de junio de 2011: es el texto con el que se inspecciona hoy. Cubre por temas gestión del riesgo, personal, proveedores y prestadores de servicio, validación, datos, verificaciones de exactitud, conservación de datos, impresiones, audit trails, gestión de cambios y de configuración, evaluación periódica, seguridad, gestión de incidentes, firma electrónica, continuidad de negocio y archivo.

21 CFR Part 11 está en vigor (62 FR 13464 del 20 de marzo de 1997, modificado por 86 FR 68830 de 2021 y 88 FR 13018 de 2023). La guía de la FDA Part 11 – Scope and Application de septiembre de 2003 adopta una interpretación restringida y ejerce enforcement discretion en algunas áreas, pero afirma explícitamente que "part 11 remains in effect". La consecuencia operativa es clara: la aplicabilidad de la Part 11 a un sistema de agua concreto debe determinarse y documentarse — qué registros exige una predicate rule, cuáles se mantienen en forma electrónica, si se usan firmas electrónicas y dónde — y no asumirse ni excluirse por costumbre.

El Annex 15 (revisión 2015, operativo desde el 1 de octubre de 2015) rige la cualificación del sistema de agua, del que la parte informatizada es un componente y no un proyecto paralelo. ASTM E2500-25 aporta el enfoque science- and risk-based para derivar las verificaciones de los aspectos críticos; ICH Q9(R1) (Step 4 el 18 de enero de 2023) el método con el que se justifica el alcance de los controles. El Aide-Memoire PIC/S PI 009-4 «Inspection of Utilities», rev. 4 en vigor desde el 1 de enero de 2021, es el documento con el que los inspectores estructuran el examen de las utilities.

Ninguno de estos textos fija frecuencias de backup, duraciones de conservación de los logs ni periodicidades de evaluación: son parámetros que la planta deriva del riesgo y justifica.

El borrador de revisión del Annex 11: no es texto vigente

Conviene decirlo explícitamente, porque hoy es la principal fuente de confusión en los pliegos. Un borrador de revisión del Annex 11, junto con la revisión del Capítulo 4 y un nuevo Annex 22 dedicado a la inteligencia artificial, estuvo sometido a consulta pública del 7 de julio de 2025 al 7 de octubre de 2025. No ha sido adoptado y no existe fecha de aplicación publicada. Su contenido no se reproduce aquí: puede cambiar antes de la adopción y citarlo como requisito sería incorrecto. Regla operativa sin matices: el borrador no se cita en una URS como requisito, no justifica una desviación y no aparece en un expediente como base normativa. En inspección se aplica el texto de 2011.

Ignorarlo en la fase de compra sería, sin embargo, discutible por una razón puramente de ingeniería: un sistema de agua vive décadas, mientras que la infraestructura de software se compra una sola vez. Las capacidades que hacen robusto un sistema frente a cualquier evolución normativa — audit trail consultable y exportable en formato abierto, exportación de datos brutos sin el proveedor, cuentas nominales y roles segregados nativos, sincronización horaria centralizada, restore verificable, trazabilidad de las sesiones remotas, política declarada de soporte y parcheo — cuestan poco si se piden antes del pedido y resultan costosas como retrofit. Ahora bien, deben escribirse en las URS del sistema de agua por lo que son: requisitos del usuario motivados por el ciclo de vida, no requisitos normativos.

Los controles que se sostienen en inspección

Audit trail

El Annex 11 pide, sobre la base de una evaluación del riesgo, que el sistema genere un registro de los cambios y borrados relevantes para GMP, disponible en forma comprensible y revisado con regularidad. En un sistema de agua el contenido mínimo se deriva del mapa del flujo del dato: límites de alerta y de acción, parámetros de los ciclos de sanitización, forzados de enclavamientos, deshabilitación de una alarma o de un punto de medida, configuración de adquisición, coeficientes de calibración, reconocimiento de alarmas, accesos y restauraciones desde backup.

El error más frecuente es de alcance: el rastro existe en el SCADA, pero el parámetro es realmente modificable a nivel de PLC desde el software de programación, donde no deja huella. El audit trail debe cubrir el nivel en el que el parámetro es efectivamente modificable; si no es posible, el acceso a ese nivel debe bloquearse por diseño y el cambio encaminarse por el nivel trazado. El segundo error es de legibilidad: un rastro exportable solo en formato propietario, o interpretable solo por el técnico del proveedor, no funciona en el momento en que hace falta.

Sobre la revisión de los audit trail ningún texto vigente fija una frecuencia universal. Debe definirla y justificarla la planta en función de la criticidad del parámetro, combinando normalmente una revisión disparada por el evento — cada investigación de una excursión comprueba qué se modificó y quién lo hizo — con una revisión periódica planificada. El inspector no comprueba el número: comprueba el racional y la evidencia de la ejecución.

Gestión de accesos

Cuentas nominales, nunca compartidas: el HMI de planta con una cuenta genérica «operador» sigue siendo la observación más fácil de redactar y la más difícil de defender, porque hace imposible atribuir cualquier acción. La matriz de roles y permisos es un entregable cualificado, no un ajuste de fábrica: se define en las URS, se verifica en OQ probando que cada rol puede hacer lo que debe y no puede hacer el resto, y se mantiene bajo change control. La sostienen tres principios. Segregación: quien administra las cuentas no genera ni aprueba los datos críticos. Ciclo de vida de la cuenta: alta, modificación y baja ligadas a la incorporación, el cambio de puesto y la salida — las cuentas activas de personas que ya no están en la planta son el defecto más recurrente en auditoría interna. Cuentas del proveedor: deshabilitadas por defecto, habilitadas bajo solicitud aprobada y por la duración de la intervención, con sesión registrada.

Sincronización horaria

PLC, SCADA, historian, analizadores con memoria propia y LIMS deben referirse a una fuente horaria común. Sin ella, la correlación entre excursión, alarma, muestra, resultado de laboratorio y acción emprendida no es demostrable, y la investigación que exige el Annex 1 6.14 se detiene antes de empezar. Deben gestionarse explícitamente la zona horaria y el cambio a horario de verano — que genera registros duplicados o ausentes si no se prevé —, el formato de marca de tiempo a lo largo de toda la cadena y el permiso, restringido y trazado, para modificar el reloj. La verificación pertenece a la cualificación y se vuelve a comprobar en la evaluación periódica.

Alarmas

Un SCADA de sistema de agua gestiona con facilidad centenares de tags. El problema no es generar alarmas: es que sean manejables y que cada una lleve a una acción. La primera separación es entre alarmas de proceso y mantenimiento y alarmas de calidad, las ligadas a alert y action level de conductividad, TOC, temperatura, caudal y ozono residual; mezclarlas produce un flujo indistinto en el que el operador aprende a ignorarlo todo. La configuración es un entregable formal: tag, límite, prioridad, texto, destinatario, acción esperada y referencia al procedimiento. El sistema debe distinguir alerta de acción, archivar todo el ciclo de vida del evento — activación, toma a cargo, retorno a la normalidad, resultado — y permitir cambiar los límites bajo change control con evidencia en audit trail, porque el Annex 1 6.13 impone que esos niveles se revisen. La supresión temporal de una alarma debe ser una función controlada, trazada y con caducidad, no una práctica heredada de la obra.

Backup y restore

Deben salvarse el programa del PLC, la configuración del SCADA, la base de datos de usuarios, las series históricas, el audit trail, las recetas y los parámetros de ciclo. La pregunta que cuenta no es si se ejecutan los backups, sino si el restore se ha probado: una restauración nunca probada es continuidad declarada, no demostrada. La prueba pertenece a la cualificación y se repite en la evaluación periódica y tras cambios sustanciales.

La frecuencia de los backups, el número de generaciones conservadas y la duración de la conservación no están fijados por ningún requisito numérico universal: se establecen a partir de la criticidad de los datos, de la pérdida máxima aceptable para las decisiones que esos datos sostienen y de los requisitos de conservación aplicables a la planta, y se documentan en el racional del sistema. Se mantiene firme la distinción entre backup, destinado a la recuperación operativa, y archivo, destinado a la legibilidad del registro en el tiempo: en un sistema llamado a vivir tanto como el loop, la obsolescencia del formato y del software de lectura es un riesgo que evaluar al elegir la plataforma.

Interfaces hacia otros sistemas

Un sistema de agua rara vez queda aislado: intercambia datos con el LIMS (resultados químicos y microbiológicos fuera de línea), con MES o ERP, con el EMS o el BMS, con el CMMS y con las herramientas de reporte usadas en la product quality review. Para cada interfaz deben definirse el dato intercambiado, el sentido, el sistema de referencia para ese dato, los controles de corrección y seguridad de la transferencia, el comportamiento si el destinatario no está disponible y cómo se detecta una transferencia fallida. El Annex 11 exige precisamente que los sistemas que intercambian datos por vía electrónica incluyan controles integrados para la entrada y el procesamiento correctos y seguros de los datos.

Dos puntos prácticos. La transcripción manual de un valor desde el SCADA a un formulario en papel también es una interfaz, la menos fiable: debe gestionarse con verificación independiente y declararse como riesgo residual. Y cuando el mismo dato vive en varios sistemas hay que decidir qué copia es el registro; de lo contrario, en la investigación se acaba eligiendo a posteriori qué versión de la verdad usar, que es precisamente lo que la integridad del dato excluye. La misma lógica aplicada a un sistema de monitorización ambiental se desarrolla en el artículo sobre software EMS, Annex 11 y Part 11.

Acceso remoto, ciberseguridad y parcheo

La asistencia remota del proveedor es hoy el modo normal de soporte y, a la vez, el modo normal de perder el control de la configuración. Requisitos mínimos que fijar en contrato y en procedimiento: conexión no permanente e iniciada por la planta, autenticación nominal, aprobación documentada por intervención, registro de la sesión, revisión de los cambios al finalizar y change control para cualquier intervención que toque parámetros o software en estado validado.

En ciberseguridad la tensión es conocida: la lógica de seguridad pide aplicar los parches rápido, la de validación no modificar nada sin evaluación. La respuesta no es elegir un bando, es tener un proceso: categorías de parche definidas de antemano, criterios predefinidos de evaluación del impacto sobre las funciones GMP, verificaciones proporcionadas y una vía de emergencia documentada para las vulnerabilidades críticas. El sistema no actualizado también es un riesgo GMP: indisponibilidad, pérdida de datos históricos y alteración de registros son consecuencias de calidad. La segregación de la red de automatización respecto a la red ofimática y a internet es una medida de diseño. En las URS deben pedirse la duración declarada del soporte, la política de publicación de parches, la compatibilidad entre versiones y la disponibilidad de la documentación de configuración: un SCADA sobre un sistema operativo sin soporte se resuelve con un retrofit, no con un parche.

CSV basada en riesgo: cuánto validar y sobre qué base

El punto de partida es una determinación documentada: qué funciones son críticas para GMP, qué registros electrónicos exige una predicate rule, si se usan firmas electrónicas y dónde. Esta evaluación establece el alcance Part 11 y es coherente con el planteamiento de la guía de la FDA de 2003. Declarar «el sistema no es Part 11» sin evaluación no es una posición defendible; declarar «todo es Part 11» es costoso e igual de poco argumentado.

El alcance de la validación se gradúa según el riesgo con el método de ICH Q9(R1). El software de un sistema de agua es casi siempre software configurado sobre plataforma comercial: la estrategia eficaz consiste en evaluar al proveedor — el Annex 11 exige evaluación de proveedores y gestión de los prestadores de servicio —, aprovechar cuando la evaluación lo permita la documentación de desarrollo y prueba que ya ha producido, y concentrar la verificación propia en la configuración específica de la planta y en las funciones críticas.

Las pruebas no deben duplicarse respecto a la cualificación del sistema de agua: pertenecen al mismo plan, con el enfoque de ASTM E2500-25 para derivar cada verificación de un aspecto crítico identificado. En campo se comprueban típicamente la correspondencia entre el valor leído por el instrumento, el visualizado y el archivado hasta el historian; el comportamiento al superar los límites; los permisos efectivos por rol, probados también en negativo; la generación del audit trail; el restore; la sincronización horaria; el comportamiento ante falta de alimentación o de red. Cómo encajan estas pruebas en FAT, SAT, IQ, OQ y PQ se trata en el artículo sobre la cualificación del sistema de agua; las pruebas de los ciclos, que el sistema debe registrar íntegramente, en el de la cualificación de los ciclos de sanitización.

Revisión periódica del sistema informatizado

El Annex 11 exige que los sistemas informatizados se evalúen periódicamente para confirmar que siguen en estado validado y conformes. La frecuencia no está fijada por un número: se establece según la criticidad y el riesgo, se escribe en procedimiento y se justifica. Hacen útil la revisión, en lugar de convertirla en un trámite: los cambios realizados en el periodo y su estado de change control; desviaciones e incidentes; comportamiento de las alarmas, incluidas alarmas crónicas y supresiones todavía activas; resultado de las revisiones de audit trail; listado de cuentas contrastado con el personal realmente en plantilla; resultado de las pruebas de restore; estado del soporte de software y de la obsolescencia; retraso de calibración. No es un ejercicio separado: revisa las mismas tendencias que la revisión periódica del sistema de agua y debe planificarse junto con ella. Las demás fases del ciclo de vida están reunidas en el hub del clúster Pharmaceutical Water & WFI.

Ejemplo de aplicación: Planta Delta

Ejemplo didáctico, planta ficticia. Planta Delta compra un nuevo sistema de WFI y trata la automatización como un accesorio del suministro mecánico. En design review afloran cuatro puntos: el analizador de TOC tiene memoria, cuentas y audit trail propios, no integrados con el SCADA; los límites de alerta son modificables desde el software de programación del PLC sin evidencia en el SCADA; la configuración de adquisición del historian la definió el integrador y no figura en ninguna especificación; el backup cubre solo la base de datos histórica y las cuentas previstas son compartidas por turno.

Acciones acordadas antes del FAT: mapa del flujo del dato firmado por Ingeniería y QA; parámetros críticos listados con el nivel en el que residen y el requisito de audit trail en ese nivel; modificación de los límites bloqueada a nivel de PLC y encaminada por el SCADA con cuentas nominales; configuración del historian declarada parámetro cualificado y puesta bajo change control; prueba de restore completa incluida en OQ; analizador de TOC tratado como sistema autónomo. El coste se concentró antes del pedido, donde es una cláusula contractual: los mismos cambios después del SAT habrían sido modificaciones a precio de proveedor y retraso en el cronograma.

Matriz de decisión: arquitectura de gestión del dato

La columna de pesos está deliberadamente vacía: dependen de la criticidad de los productos, del parque de sistemas y de la madurez IT/OT de la planta, y deben asignarse y justificarse internamente antes de puntuar.

Checklist de design review y de auditoría interna

• Mapa del flujo del dato aprobado, con el registro de referencia para cada parámetro crítico.
• Evaluación documentada de la aplicabilidad de la Part 11 y de la criticidad GMP de las funciones.
• Audit trail activo en el nivel en que los parámetros son modificables y exportable sin el proveedor.
• Configuración del historian declarada, cualificada y bajo change control.
• Matriz de roles y permisos verificada en positivo y en negativo; ninguna cuenta compartida; baja ligada al proceso de personal.
• Fuente horaria común; gestión documentada de zona horaria y horario de verano.
• Lista de alarmas con prioridad y acción esperada; alerta distinguida de acción; ninguna supresión permanente.
• Prueba de restore ejecutada y documentada, no solo planificada.
• Acceso remoto del proveedor no permanente, aprobado por intervención y registrado.

Errores frecuentes y red flags

• «El sistema es Part 11 compliant», declarado por el proveedor. La conformidad es una propiedad de la implementación y del uso, no del producto.
• El borrador de revisión del Annex 11 citado como requisito. No está adoptado y no tiene fecha de aplicación: rige el texto de enero de 2011.
• Audit trail solo a nivel de SCADA con límites modificables en el PLC. No cubre el punto en el que el cambio ocurre de verdad.
• Cuentas compartidas en el HMI de planta. Hacen imposible atribuir una acción a una persona.
• Compresión o intervalo de registro ajustados en la puesta en marcha y nunca formalizados. El dato que necesita la investigación puede ya no existir.
• Backups regulares y restore nunca probado. Continuidad declarada, no demostrada.
• Conexión remota del proveedor permanentemente activa. El estado validado de la configuración no es defendible.
• Alarmas de calidad mezcladas con las de mantenimiento. Impiden la distinción entre evento aislado y tendencia adversa que exige el Annex 1 6.14.
• Relojes no sincronizados entre PLC, SCADA, analizadores y LIMS. La secuencia de los eventos pasa a ser indemostrable.
• Frecuencias de backup, de revisión o de evaluación periódica copiadas de otra planta. Deben derivarse del riesgo del propio sistema y justificarse.

Si este tipo de análisis te resulta útil en el trabajo diario, The Pragmatic GMP reúne análisis técnicos y actualizaciones regulatorias con el mismo enfoque.

Key takeaways

• El sistema de automatización es el lugar donde la monitorización continua exigida por el Annex 1 6.15 se convierte en registro: si el registro no es reconstruible, la monitorización no demuestra nada.
• El alcance se define a partir de la decisión GMP que sostiene cada dato, no de la etiqueta del proveedor.
• Del Annex 11 se aplica la versión de enero de 2011; el borrador en consulta hasta el 7 de octubre de 2025 no ha sido adoptado y no se cita como requisito.
• La aplicabilidad de la Part 11 se determina y se documenta: la guía de la FDA de 2003 restringe la interpretación pero confirma que la Part 11 sigue en vigor.
• Un audit trail en el nivel correcto, cuentas nominales, reloj común y restore probado valen más que cualquier declaración de conformidad del proveedor.
• Las frecuencias de backup, revisión y evaluación periódica no están fijadas por un número normativo: se derivan del riesgo y se justifican.

Referencias

• EudraLex Volumen 4, Annex 11 Computerised Systems — versión de enero de 2011, operativa desde el 30 de junio de 2011. Borrador de revisión (con el Capítulo 4 y un nuevo Annex 22) en consulta del 7 de julio al 7 de octubre de 2025, no adoptado. health.ec.europa.eu
• EudraLex Volumen 4, Annex 1 (C(2022) 5938 final), operativo desde el 25 de agosto de 2023 — puntos 6.13, 6.14, 6.15. Annex 15, revisión 2015, operativo desde el 1 de octubre de 2015.
• 21 CFR Part 11 — en vigor. ecfr.gov
• FDA, Part 11 – Scope and Application, septiembre de 2003 — interpretación restringida y enforcement discretion; "part 11 remains in effect".
• ICH Q9(R1) Quality Risk Management, Step 4 el 18 de enero de 2023. ich.org
• PIC/S PE 009-17 y Aide-Memoire PI 009-4 Inspection of Utilities, rev. 4, en vigor desde el 1 de enero de 2021. picscheme.org
• ASTM E2500-25; WHO TRS 1033, Annex 3 (2021). who.int