El retrofit de un sistema de monitorización ambiental es un proyecto más difícil que una instalación nueva, y casi siempre se aborda como si lo fuera menos. Las diferencias son sustanciales: se trabaja en una planta en producción, con restricciones de acceso y de parada; existe un histórico de datos que preservar y mantener comparable; existen procedimientos, hábitos y expectativas consolidados; y hay decisiones tomadas años antes por personas que a menudo ya no están disponibles para explicarlas.
La regla operativa es simple: antes de decidir qué cambiar hay que establecer con precisión qué no consigue hacer el sistema actual, y por qué. Un retrofit iniciado sin gap assessment estructurado produce casi siempre un sistema nuevo con los mismos problemas que el anterior, porque los problemas estaban en la estrategia de monitorización, en la configuración o en la gestión — no en la tecnología.
Por qué nace un proyecto de retrofit
Los orígenes típicos son cinco y conducen a intervenciones distintas. Conviene separarlos explícitamente, porque confundirlos es la primera causa de un alcance erróneo:
- Obsolescencia técnica: fin del soporte de software, repuestos no disponibles, sistemas operativos ya no actualizables. Una restricción externa con fecha límite.
- Brechas de integridad de datos: ausencia de audit trail adecuado, cuentas compartidas, imposibilidad de revisar los registros sin el proveedor. Atañe a cómo está construido y configurado el sistema.
- Brechas de cobertura: puntos de monitorización ya no coherentes con el risk assessment, áreas modificadas, nuevas líneas. Atañe a la estrategia, no al sistema.
- Hallazgo de inspección o resultado de auditoría: con plazo y alcance definidos por la observación, a abordar con una respuesta dirigida y verificable.
- Evolución del proceso: nuevas necesidades operativas, integraciones, aumento del número de puntos. Un proyecto de extensión, no necesariamente de sustitución.
Los orígenes pueden coexistir, pero deben reconocerse por separado: la respuesta a una brecha de estrategia no es un sistema nuevo, y la respuesta a una obsolescencia de software no es una revisión del mapa de puntos.
El marco regulatorio
| Nivel | Qué establece respecto a una intervención sobre un sistema existente |
|---|---|
| Requisito regulatorio (EudraLex Volume 4, Annex 15) | Exige que las modificaciones se gestionen mediante control de cambios, con evaluación de impacto sobre el estado cualificado y definición del alcance de recualificación sobre base de riesgo. |
| Requisito regulatorio (Annex 11, revisión de enero de 2011) | Se aplica al componente informatizado modificado o sustituido, incluidas la migración de datos y su legibilidad en el tiempo. |
| Requisito regulatorio (EudraLex Volume 4, Annex 1) | Exige que el programa de monitorización siga siendo coherente con la evaluación del riesgo y con la estrategia de control de la contaminación: toda modificación de la cobertura debe remitirse a esa base. |
| Requisito regulatorio (conservación de datos) | Los datos históricos siguen sujetos a las obligaciones de conservación aplicables incluso tras la baja del sistema que los generó. |
| Buena práctica de ingeniería | Planificación de los trabajos en área clasificada, gestión de la convivencia entre sistemas, minimización de paradas y aperturas de la envolvente. |
| Recomendación operativa GuideGxP | Realizar el gap assessment antes de definir el alcance y clasificar cada brecha por naturaleza — estrategia, configuración, tecnología, gestión —, porque solo las brechas de tecnología se resuelven comprando. |
Cómo realizar el gap assessment
El gap assessment compara el sistema existente con los requisitos que debería satisfacer hoy, no con aquellos con los que se compró. La secuencia:
1. Reconstruir los requisitos actuales
Antes de mirar el sistema hay que definir qué hace falta hoy: intended use actualizado, decisiones GMP que se apoyan en los datos, áreas y puntos que el risk assessment actual justifica, requisitos de integridad de datos aplicables, necesidades de integración. En muchos casos esta es la parte más útil de todo el ejercicio, porque la URS original — si existe — refleja un contexto que entretanto ha cambiado.
2. Levantar el estado real del sistema
No el estado documentado: el real. Puntos efectivamente instalados y su correspondencia con el mapa aprobado; configuración actual frente a la baseline; versiones de software en uso y estado del soporte; cuentas activas y permisos asignados; funcionamiento del audit trail; estado de calibración de los equipos; documentación as-built disponible y actualizada; contratos de servicio vigentes. La diferencia entre lo documentado y lo levantado es ya, en sí misma, un resultado.
3. Clasificar cada brecha por naturaleza
| Naturaleza de la brecha | Ejemplo | Tipo de solución |
|---|---|---|
| Estrategia | Puntos no coherentes con el risk assessment actual | Revisión de la estrategia de muestreo; puede no requerir ninguna intervención en el sistema |
| Configuración | Cuentas compartidas, permisos no segregados, límites modificables por operadores | Reconfiguración, re-verificación y actualización procedimental |
| Gestión | Audit trail nunca revisado, calibraciones vencidas, backup nunca restaurado | Procedimientos y plan de gestión en operación |
| Tecnología | Audit trail ausente por construcción, exportación imposible, soporte finalizado | Sustitución o actualización del componente |
| Documentación | As-built no disponible, cualificación incompleta | Reconstrucción documental y verificación en campo |
La clasificación es el núcleo del método: solo las brechas de tecnología se resuelven comprando. Un proyecto que responde a brechas de gestión con una compra produce un sistema nuevo gestionado igual y, por tanto, con los mismos hallazgos.
4. Evaluar criticidad y prioridad
Cada brecha se evalúa por impacto sobre la calidad del producto y sobre la defendibilidad de los datos, y por urgencia. El resultado es una escala de prioridades que distingue lo que hay que resolver de inmediato, lo que entra en el proyecto y lo que puede aceptarse con una motivación documentada.
Herramienta de decisión: remediación, retrofit o sustitución
| Criterio | Orienta a remediación dirigida | Orienta a retrofit parcial | Orienta a sustitución |
|---|---|---|---|
| Naturaleza predominante de las brechas | Gestión y configuración | Tecnología en parte del sistema | Tecnología en la plataforma central |
| Estado del soporte del proveedor | Activo | Activo con limitaciones | Finalizado o fin anunciado |
| Posibilidad de cumplir los requisitos de integridad de datos | Sí, con reconfiguración | Parcialmente | No, por límites constructivos |
| Coherencia de la cobertura con el risk assessment | Recuperable | Recuperable con adiciones | Requiere rediseño |
| Disponibilidad de documentación | Adecuada | Reconstruible | No reconstruible |
| Horizonte productivo del área | Cualquiera | Medio | Largo |
| Impacto sobre la producción | Mínimo | Gestionable por fases | Relevante, a planificar |
La valoración económica debe hacerse sobre todo el ciclo de vida, no solo sobre la inversión inicial: una remediación barata que deja el sistema fuera de soporte solo desplaza el problema unos meses. El tema se desarrolla en el artículo sobre el coste total de propiedad de un EMS.
Gestionar la intervención en una planta en producción
- Continuidad de la monitorización: para cada fase debe definirse cómo se garantiza la monitorización requerida mientras se trabaja. Las soluciones temporales se cualifican para el uso previsto, no se improvisan.
- Convivencia entre sistemas: si el antiguo y el nuevo coexisten, debe establecerse cuál es la fuente autorizada para cada punto y cada periodo, con fechas precisas y documentadas.
- Trabajos en área clasificada: cada apertura de la envolvente, cada nuevo paso, cada entrada de personal externo exige evaluación del impacto sobre la contaminación, planificación y, cuando proceda, recualificación del área afectada.
- Datos históricos: la estrategia se decide al inicio — migración, archivo en formato independiente, mantenimiento en solo lectura del sistema antiguo — con plan de verificación de completitud y exactitud y atención a la legibilidad durante todo el periodo de conservación.
- Comparabilidad de tendencias: un cambio de sistema o de método interrumpe la continuidad de las series; si la comparación es necesaria, debe planificarse un periodo de solapamiento.
- Formación: el personal opera un sistema nuevo con procedimientos actualizados; la formación se completa antes del paso a uso, no después.
- Change control: toda la intervención es una modificación, con evaluación de impacto y alcance de cualificación definidos de antemano.
Escenario práctico
En una planta que llamaremos Site Delta — realista pero ficticia — una auditoría interna detecta que el audit trail del sistema de monitorización no es revisable sin la intervención del proveedor. La reacción inmediata del equipo de proyecto es iniciar la sustitución de todo el sistema.
El gap assessment da un cuadro distinto. Se detectan cinco brechas: el audit trail no revisable de forma autónoma es un límite constructivo del software (tecnología); las cuentas compartidas en dos áreas son un problema de configuración; la ausencia de un plan de revisión de datos es un problema de gestión; dos puntos de monitorización ya no corresponden al risk assessment actualizado tras un cambio de layout (estrategia); la documentación as-built está incompleta en una rama de la instalación (documentación).
Solo la primera exige intervenir en la plataforma. Las otras cuatro se resuelven con reconfiguración, procedimientos, revisión del mapa de puntos y reconstrucción documental, en plazos y con costes muy inferiores. La decisión final de Site Delta es un retrofit parcial: actualización del componente software manteniendo la infraestructura de campo, acompañada de un plan de remediación para las brechas no tecnológicas.
La cuestión del escenario no es que la sustitución sea siempre desproporcionada — a veces es la única vía posible. Es que la decisión, para ser defendible, debe apoyarse en una clasificación explícita de las brechas, y que esa clasificación cuesta unas semanas frente a un proyecto que cuesta muchas.
Errores frecuentes y señales de alarma
- Definir el alcance antes del gap assessment. Lleva a comprar la solución a un problema que no era ese.
- Comparar el sistema con la URS original en lugar de con los requisitos actuales. El contexto ha cambiado: la referencia debe ser el hoy.
- Levantar el estado documentado en lugar del real. La diferencia entre ambos suele ser la brecha más significativa.
- Responder a brechas de gestión con una compra. El sistema nuevo hereda la misma gestión y, por tanto, los mismos hallazgos.
- No definir la estrategia de datos históricos al inicio. Decidirlo en la baja reduce drásticamente las opciones disponibles.
- Subestimar la convivencia entre sistemas. Sin una definición fechada de la fuente autorizada, las investigaciones posteriores se vuelven ambiguas.
- Descuidar el impacto de las obras sobre el área clasificada. Aperturas y pasos no planificados generan reprocesos y recualificaciones imprevistas.
- Aplazar la formación hasta después del paso a uso. Es la vía más directa para generar errores operativos en las primeras semanas.
- No cerrar formalmente las brechas aceptadas. Una brecha que se decide no resolver se documenta con motivación y aprobación, no simplemente se deja fuera del alcance.
Cómo documentar
- Informe de gap assessment: requisitos actuales, estado levantado, lista de brechas con naturaleza, criticidad y prioridad.
- Documento de decisión: opciones evaluadas (remediación, retrofit, sustitución), criterios, motivación de la elección y de las exclusiones.
- Change control de la intervención, con evaluación de impacto y alcance de cualificación definido.
- Plan de continuidad de la monitorización durante las obras, con soluciones temporales y su cualificación.
- Plan de datos históricos: estrategia, verificaciones de completitud y exactitud, legibilidad en el tiempo.
- Definición fechada de la fuente autorizada para cada punto durante la convivencia.
- Plan de remediación para las brechas no tecnológicas, con responsabilidades y plazos.
- Registro de las brechas aceptadas con motivación y aprobación.
Puntos clave
- El gap assessment precede a la definición del alcance, no al revés.
- La comparación se hace con los requisitos actuales, no con los originales.
- Solo las brechas de tecnología se resuelven comprando; las demás exigen configuración, procedimientos o estrategia.
- La estrategia de datos históricos se decide al inicio del proyecto.
- Durante la convivencia hace falta una definición fechada de qué sistema prevalece.
- Las brechas que se decide no resolver se documentan y aprueban, no se ignoran.
Preguntas frecuentes
¿Por dónde empieza un proyecto de retrofit?
Por la reconstrucción de los requisitos actuales y el levantamiento del estado real del sistema, no por la petición de ofertas. El alcance se define tras la clasificación de las brechas.
¿Cuándo conviene sustituir en lugar de actualizar?
Cuando las brechas predominantes son tecnológicas en la plataforma central, cuando el soporte ha finalizado o su fin está anunciado, cuando los requisitos de integridad de datos no pueden satisfacerse por límites constructivos, o cuando la documentación no es reconstruible. La valoración se hace sobre todo el ciclo de vida.
¿Qué ocurre con los datos del sistema antiguo?
Siguen sujetos a las obligaciones de conservación aplicables. Las opciones — migración, archivo en formato independiente, mantenimiento en solo lectura — se evalúan con un plan documentado que incluya verificaciones de completitud y exactitud y la legibilidad durante todo el periodo requerido.
¿Hace falta una recualificación completa tras un retrofit?
No necesariamente. El alcance se determina con evaluación de impacto en el change control, con enfoque basado en el riesgo: algunos cambios exigen solo la verificación de las funciones afectadas, otros una recualificación más amplia. Los criterios se tratan en el artículo sobre FAT, SAT, IQ, OQ y PQ del sistema.
¿Cómo se garantiza la monitorización durante las obras?
Con un plan de continuidad definido por fases que establezca para cada una cómo se asegura la monitorización requerida. Las eventuales soluciones temporales se cualifican para el uso previsto y se documentan como tales.
¿El retrofit obliga a rehacer el risk assessment?
Debe al menos reexaminarse: si el layout, el proceso o las áreas han cambiado desde la redacción original, el mapa de puntos debe remitirse a la evaluación actualizada. El método se describe en el artículo sobre la estrategia de muestreo basada en el riesgo.
Referencias regulatorias y técnicas
- EudraLex Volume 4 — EU Guidelines for Good Manufacturing Practice (Comisión Europea): Annex 1 (aplicable desde el 25 de agosto de 2024), Annex 11 (revisión de enero de 2011), Annex 15 (en vigor desde el 1 de octubre de 2015).
- ICH Quality Guidelines — ICH Q9(R1) Quality Risk Management.
- ISO 14644-1 — Cleanrooms and associated controlled environments: clasificación de la limpieza del aire por concentración de partículas.
- PIC/S — Guides and Guidance Documents.
Continúa el recorrido del proyecto
Este artículo forma parte del recorrido Environmental Monitoring Systems de GuideGxP, que sigue el ciclo de vida de un proyecto EMS desde la definición de requisitos hasta la gestión en operación.
- Antes: la estrategia de muestreo y la URS del sistema.
- Relacionados: gestión en operación, selección del proveedor y presupuesto y TCO.
- Fundamentos regulatorios GuideGxP: integridad de datos, ALCOA+ y audit readiness.
¿Quieres recibir análisis como este directamente por email? Suscríbete a The Pragmatic GMP, la newsletter de GuideGxP para quienes trabajan cada día con GMP, cualificación y data integrity.
