Descubre las ventajas y los riesgos de los sistemas cloud y SaaS en entornos BPx, cómo abordar su validación bajo un enfoque basado en riesgos y qué deberías poder demostrar durante una inspección.
Migrar un sistema BPx a la nube puede mejorar la disponibilidad, facilitar la escalabilidad y reducir la dependencia de infraestructura local.
Sin embargo, también plantea una cuestión fundamental:
¿Cómo mantener el estado validado cuando parte del control del sistema está en manos del proveedor?
En soluciones cloud y Software as a Service (SaaS), actividades como infraestructura, mantenimiento, seguridad y actualizaciones pueden ser gestionadas por terceros.
Pero trasladar un sistema a la nube no traslada automáticamente las responsabilidades de la organización usuaria.
En un entorno BPx, la organización debe poder demostrar que el sistema es adecuado para su uso previsto, que los riesgos asociados están controlados y que los datos mantienen su integridad durante todo su ciclo de vida.
Por eso, implementar un sistema cloud en un entorno BPx no es únicamente una decisión tecnológica:
También es una decisión de cumplimiento.
¿Qué ventajas ofrece un sistema en la nube?
Las soluciones cloud pueden aportar beneficios importantes frente a las infraestructuras tradicionales:
- Mayor disponibilidad y accesibilidad.
- Escalabilidad de recursos.
- Actualizaciones centralizadas.
- Reducción de infraestructura local.
- Posibilidad de estandarización entre diferentes sedes.
- Acceso a capacidades técnicas gestionadas por proveedores especializados.
Desde la perspectiva planteada en GAMP 5 Second Edition, el uso de soluciones SaaS y servicios cloud puede abordarse mediante actividades de aseguramiento y validación dimensionadas de acuerdo con el impacto GxP, la complejidad, la novedad tecnológica y el riesgo del sistema.
La diferencia fundamental frente a una infraestructura tradicional es que parte del control puede quedar en manos del proveedor.
Y es precisamente allí donde aparecen los principales riesgos que deben gestionarse.
¿Cuáles son los principales riesgos para el cumplimiento BPx?
Una de las principales diferencias entre un sistema instalado localmente y una solución cloud es la distribución del control.
En un modelo SaaS, el proveedor puede controlar la infraestructura, realizar mantenimiento, desplegar nuevas versiones e incluso modificar determinadas funcionalidades.
Mientras tanto, la organización utiliza ese mismo sistema para ejecutar procesos BPx.
Por eso, antes de implementar una solución cloud deberían estar claramente definidos aspectos como:
- Responsabilidades entre el proveedor y la organización usuaria.
- Gestión de cambios y actualizaciones.
- Propiedad, disponibilidad, recuperación y retención de los datos.
- Backups, restauración y continuidad del negocio.
- Gestión de usuarios, roles y privilegios.
- Audit Trail y registros electrónicos.
- Ciberseguridad y controles de acceso.
- Gestión de incidentes y desviaciones.
- Subcontratistas utilizados por el proveedor.
- Estrategia de salida y recuperación de los datos al finalizar el servicio.
La guía de integridad de datos de MHRA citada en el enfoque original destaca la necesidad de considerar aspectos como la propiedad, recuperación, retención y seguridad de los datos cuando se utilizan servicios cloud, además de definir las responsabilidades entre las partes.
La idea clave puede resumirse así:
La nube no elimina los controles. Cambia quién los ejecuta y cómo la organización obtiene evidencia de ellos.
Ventajas vs. riesgos: ¿qué cambia realmente en la nube?
| Ventajas potenciales | Riesgos que deben controlarse |
| Mayor disponibilidad | Dependencia del proveedor |
| Escalabilidad | Menor control directo sobre determinada infraestructura |
| Actualizaciones centralizadas | Cambios que pueden afectar el estado validado |
| Menor infraestructura local | Dependencia de controles ejecutados por terceros |
| Estandarización entre sedes | Gestión de accesos, datos y responsabilidades |
| Servicios técnicos especializados | Gestión de subcontratistas y continuidad del servicio |
El problema, por tanto, no es que la nube sea incompatible con los requisitos BPx.
El desafío consiste en comprender qué controla la organización, qué controla el proveedor y qué evidencia permite demostrar que el sistema permanece bajo control.
¿Quién es responsable de mantener el estado validado en un sistema SaaS?
Este punto suele generar confusión.
Contratar un proveedor SaaS no elimina la responsabilidad de la organización sobre el uso BPx del sistema.
El proveedor puede aportar documentación, pruebas, certificaciones, procedimientos, controles técnicos y evidencia relacionada con el desarrollo o mantenimiento de la solución.
Esta información puede aprovecharse dentro de una estrategia basada en riesgos.
Sin embargo, la organización debe determinar si la evidencia disponible es suficiente considerando:
- La configuración del sistema.
- Los procesos que soporta.
- Los riesgos asociados.
- Su uso previsto.
La guía de MHRA mencionada en el artículo original advierte sobre la necesidad de considerar la configuración y el uso previsto del sistema al evaluar la evidencia de validación proporcionada por terceros.
En otras palabras:
El proveedor puede gestionar la tecnología; la organización usuaria debe asegurar que el sistema sea adecuado para su uso previsto dentro del proceso BPx.
Esta distinción cobra especial importancia en modelos SaaS, donde el proveedor puede tener un alto grado de control tecnológico sin conocer necesariamente todos los procesos BPx específicos de cada organización.
¿Cómo abordar la validación de un sistema cloud bajo GAMP 5 y Anexo 11?
Un error frecuente es interpretar la validación como una batería estándar de documentos y pruebas que debe repetirse exactamente de la misma manera para todos los sistemas.
El enfoque basado en riesgos propone algo diferente:
La profundidad y extensión del aseguramiento deben estar determinadas por el riesgo.
Una estrategia de validación de sistemas en la nube puede contemplar, según el sistema, su uso previsto y su criticidad, los siguientes pasos:
1. Definir el uso previsto y los requisitos del usuario
Antes de determinar qué validar, es necesario entender para qué será utilizado el sistema.
¿Qué proceso soportará?
¿Qué datos BPx gestionará?
¿Qué decisiones dependen de él?
¿Qué funcionalidades son realmente críticas?
Estas respuestas permiten establecer el alcance de las actividades posteriores.
2. Realizar una evaluación de riesgos
No todas las funcionalidades presentan el mismo impacto sobre la calidad, la integridad de los datos o la seguridad del paciente.
La evaluación de riesgos permite concentrar los esfuerzos de validación donde realmente son necesarios.
3. Evaluar al proveedor y su evidencia
Debe determinarse qué actividades realiza el proveedor, qué controles mantiene, cómo desarrolla y mantiene el software y qué documentación o evidencia puede proporcionar.
El objetivo no debería ser duplicar innecesariamente su trabajo, sino determinar qué evidencia puede aprovecharse y dónde son necesarias verificaciones adicionales por parte de la organización.
4. Definir claramente las responsabilidades
Debe establecerse quién gestiona aspectos como:
- Infraestructura.
- Backups.
- Seguridad.
- Incidentes.
- Accesos.
- Cambios.
- Recuperación de datos.
- Disponibilidad de la información.
Las responsabilidades compartidas o delegadas no deberían quedar implícitas.
5. Ejecutar verificaciones y pruebas basadas en riesgo
El esfuerzo debería concentrarse especialmente en aquellos aspectos relevantes para el uso previsto, como:
- Procesos y funcionalidades críticas.
- Configuraciones.
- Interfaces.
- Migraciones de datos.
- Controles de acceso.
- Integridad de datos.
La evidencia del proveedor puede formar parte de esta estrategia cuando resulte aplicable, mientras que las verificaciones propias deberían concentrarse donde exista mayor riesgo.
6. Mantener el estado validado
Este punto es fundamental:
La validación no termina cuando el sistema entra en producción.
Cambios, nuevas versiones, incidentes y actualizaciones deben evaluarse durante todo el ciclo de vida del sistema.
¿Qué ocurre cuando el proveedor actualiza automáticamente el SaaS?
Este es uno de los puntos más importantes del modelo cloud.
Supongamos que un sistema validado funciona correctamente hoy y mañana el proveedor despliega una nueva versión.
La primera pregunta podría ser: “¿Debemos revalidar todo?”
Pero esa no necesariamente es la pregunta más útil.
La pregunta debería ser:
“¿Qué impacto tiene este cambio sobre nuestro uso previsto y nuestros procesos BPx?”
Una actualización puede modificar funcionalidades críticas, interfaces, configuraciones, cálculos, perfiles de usuario, reportes, Audit Trails o mecanismos de seguridad.
Por ello, debería existir un proceso que permita seguir una secuencia como esta:
ACTUALIZACIÓN DEL PROVEEDOR → EVALUACIÓN DE IMPACTO → RIESGO BPx → ACCIÓN NECESARIA → EVIDENCIA → CONFIRMACIÓN DEL ESTADO VALIDADO
Dependiendo del impacto identificado, podrían ser necesarias verificaciones específicas, pruebas adicionales u otras acciones documentadas.
El principio es importante: Actualizar no significa automáticamente revalidar todo.
Pero tampoco significa asumir que nada necesita evaluación.
¿Qué deberías poder demostrar sobre un sistema cloud durante una inspección BPx?
Más que disponer únicamente de una carpeta extensa denominada “Validación”, una organización debería poder demostrar que conoce y controla su sistema durante todo su ciclo de vida.
Entre los principales aspectos se encuentran:
Uso previsto y criticidad
Qué hace el sistema, qué procesos soporta y cuáles de sus funciones tienen impacto BPx.
Evaluación del proveedor
Cómo se determinó que el proveedor y los servicios utilizados eran adecuados para las necesidades de la organización.
Evidencia de validación
Por qué las verificaciones y pruebas ejecutadas proporcionan confianza suficiente sobre las funciones críticas del sistema.
Gestión de cambios
Cómo se conocen, evalúan, documentan y gestionan las actualizaciones y modificaciones realizadas por el proveedor.
Integridad de datos
Cómo se gestionan los accesos, modificaciones, Audit Trails, datos originales y metadatos.
La guía de MHRA citada en el artículo original señala, por ejemplo, consideraciones sobre el uso de accesos individuales en sistemas que generan, modifican o almacenan información GxP.
Mantenimiento del estado validado
Qué mecanismos permiten demostrar que el sistema continúa bajo control después de su puesta en producción y tras cambios o actualizaciones.
El enfoque descrito en el Anexo 11 considera la validación de las aplicaciones, la cualificación de la infraestructura IT y la gestión de riesgos durante el ciclo de vida.
La nube cambia la tecnología, no la responsabilidad BPx
Implementar un sistema cloud puede aportar disponibilidad, escalabilidad, estandarización y eficiencia.
Sin embargo, también cambia la distribución del control entre la organización y sus proveedores.
Por eso, la clave no está en validar más simplemente porque el sistema está en la nube, sino en aplicar un enfoque basado en riesgos que permita determinar: qué controlar, qué evidencia aprovechar del proveedor y qué verificar directamente.
Antes de implementar una solución cloud, una organización debería poder responder tres preguntas:
¿Qué funciones y datos son críticos para BPx?
¿Están claramente definidas las responsabilidades con el proveedor?
¿Podemos demostrar que el sistema permanece en estado validado después de cambios y actualizaciones?
En QbD Group Suramérica acompañamos a las organizaciones en la Validación de Sistemas Computarizados (VSC) bajo un enfoque de ciclo de vida y basado en riesgos, desde la evaluación del sistema y del proveedor hasta la definición de la estrategia de validación, la ejecución de pruebas y el mantenimiento del estado validado.
¿Estás implementando o migrando un sistema a la nube?
Conversemos antes de que la tecnología avance más rápido que tu estrategia de cumplimiento.
