--- title: "La nube avanza, ¿tu control de los datos también?" description: "Qué están observando los reguladores sobre integridad de datos, terceros y sistemas cloud, y qué deberías poder explicar en una inspección." url: https://qbdgroup.com/es/blog/nube-integridad-datos-gxp-annex-11 type: "Artículo del blog" language: es published: 2026-10-22 author: "Katheryn Vanessa Oyola" category: "Software Solutions & Services" publisher: "QbD Group" citation: "QbD Group, \"La nube avanza, ¿tu control de los datos también?\", https://qbdgroup.com/es/blog/nube-integridad-datos-gxp-annex-11" --- # La nube avanza, ¿tu control de los datos también? > Qué están observando los reguladores sobre integridad de datos, terceros y sistemas cloud, y qué deberías poder explicar en una inspección. ## Introducción Hace algunos años, cuando hablábamos de un sistema crítico, era fácil imaginar dónde estaba: un servidor dentro de la empresa, administrado por el equipo interno y bajo controles que, al menos en teoría, estaban cerca. Hoy el escenario es diferente. Cada vez más procesos de calidad, laboratorio, manufactura, documentación o capacitación dependen de soluciones en la nube. La empresa usa el sistema todos los días, pero parte de la infraestructura, las actualizaciones, los respaldos e incluso ciertos accesos privilegiados están en manos de un proveedor. Y ahí aparece una pregunta sencilla, pero importante: **Si nuestros datos están cada vez más fuera de nuestra infraestructura, ¿seguimos teniendo realmente el control sobre ellos?** Esta preocupación no es solo tecnológica. FDA, PIC/S, MHRA y la evolución propuesta del EU GMP Annex 11 vienen mostrando una atención creciente sobre temas como la dependencia de terceros, el movimiento de los datos, los accesos privilegiados, los metadatos, la recuperación de la información y la capacidad de una compañía para demostrar que sus registros siguen siendo confiables durante todo su ciclo de vida. No existe hoy una única regulación internacional denominada "Cloud GMP". Pero, cuando se leen estas publicaciones en conjunto, el mensaje empieza a ser bastante claro: > La tecnología puede estar en manos de un tercero. La responsabilidad sobre los datos sigue siendo de la compañía regulada. ## La nube ya forma parte del entorno regulado El primer cambio de mentalidad es dejar de pensar que el cloud está "por fuera" del sistema regulado. La guía de FDA **Data Integrity and Compliance With Drug CGMP: Questions and Answers** mantiene una expectativa básica: los datos utilizados en actividades CGMP deben ser confiables y exactos, y las empresas deben gestionar sus riesgos de integridad teniendo en cuenta los procesos, las tecnologías y los modelos de negocio que utilizan. PIC/S es todavía más directo. En **PI 041-1 – Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments**, incluye dentro de la gobernanza de datos el almacenamiento, procesamiento, transferencia y recuperación de registros, incluyendo expresamente entornos descentralizados y cloud. Por eso, la conversación ya no debería quedarse en: **¿podemos usar un sistema en la nube?** La pregunta realmente importante es: **¿podemos demostrar que seguimos teniendo control sobre los datos que ese sistema gestiona?** ## El regulador también está mirando hacia adelante **El EU GMP Annex 11 vigente sigue siendo la versión de 2011.** Pero el entorno tecnológico actual tiene poco que ver con el de hace quince años. Por eso resulta tan interesante la propuesta de revisión de Annex 11: reconoce expresamente el aumento del uso de servicios cloud, la aparición de nuevas tecnologías y el papel cada vez mayor de los sistemas computarizados en los procesos GMP. El borrador no es todavía un requisito vigente y debe tratarse como tal. Pero sí sirve para algo muy valioso: entender **qué preocupaciones está intentando resolver el regulador para los próximos años.** Y varias tienen que ver directamente con una realidad cada vez más común: **las empresas utilizan más tecnología, pero controlan directamente menos infraestructura.** ## Cuando dejamos de ver lo que ocurre detrás del sistema Pensemos en una situación bastante habitual. La empresa utiliza un SaaS para gestionar información crítica. Los usuarios entran, trabajan, revisan registros y generan reportes. Todo parece estar bajo control. Pero detrás de esa pantalla, el proveedor puede estar administrando: - Infraestructura. - Bases de datos. - Actualizaciones. - Copias de seguridad. - Recuperación. - Monitoreo. - Seguridad. - Accesos administrativos. - Y, en algunos casos, otros proveedores tecnológicos. Entonces aparece una pregunta incómoda, pero necesaria: **¿qué tanto conocemos realmente de lo que ocurre con nuestros datos detrás de la plataforma?** PIC/S establece que la gestión de integridad de datos debe considerar la infraestructura IT, la seguridad, los proveedores y los mecanismos utilizados para almacenar, procesar, transferir y recuperar registros. La propuesta de revisión de Annex 11 refuerza la misma idea: apoyarse en un proveedor externo no elimina la responsabilidad de la compañía frente a aquellas actividades que puedan afectar la calidad, la seguridad del paciente o la integridad de los datos. Dicho de forma simple: > Puedes delegar una actividad. No puedes delegar la responsabilidad de saber si se está haciendo bien. ## El proveedor no puede convertirse en una caja negra Cuando seleccionamos un proveedor tecnológico es normal revisar contratos, certificaciones, niveles de servicio o políticas de seguridad. Todo eso aporta. Pero, para un sistema crítico, puede no ser suficiente. El Concept Paper on the Revision of Annex 11 ya planteaba que, cuando sistemas críticos son operados o gestionados por terceros, incluyendo servicios cloud, la expectativa debería ir más allá de tener simplemente un acuerdo formal. La compañía regulada debería poder acceder a la documentación necesaria para demostrar control durante una inspección. Esto cambia el tipo de preguntas que hacemos. No basta con preguntar: **¿hacen backup?** También deberíamos saber: **¿qué respaldan?, ¿cada cuánto?, ¿qué pasa si necesitamos recuperar la información?, ¿cómo sabemos que la recuperación funciona?** No basta con saber: **el proveedor administra las actualizaciones.** También importa: **¿cómo nos informa?, ¿qué impacto pueden tener?, ¿qué evidencia recibimos?** La frase "eso lo maneja el proveedor" deja de ser tranquilizadora cuando nadie puede explicar **cómo sabe la empresa que ese control realmente funciona.** ## ¿Quién puede hacer más de lo que vemos? Otro punto que empieza a ser especialmente relevante en sistemas cloud son los **accesos privilegiados.** Normalmente nos preocupamos por que cada usuario tenga su propia cuenta, que no comparta contraseñas y que solo tenga acceso a lo que necesita. Pero hay personas que pueden hacer mucho más. Un administrador puede tener capacidad para: - Crear o modificar usuarios. - Cambiar permisos. - Modificar configuraciones. - Administrar bases de datos. - Restaurar información. - Ejecutar funciones que un usuario normal no puede realizar. PIC/S señala que los privilegios administrativos asociados con aplicaciones GMP/GDP críticas deberían estar estrictamente controlados y, cuando sea posible, segregados de las actividades normales de los usuarios. En cloud surge una pregunta adicional: **¿quién tiene esos privilegios fuera de nuestra empresa?** Podría tratarse de soporte técnico, administradores del SaaS, proveedores de infraestructura o incluso personal de compañías subcontratadas. Por eso, cuando hablamos de accesos, ya no basta con revisar únicamente a nuestros propios empleados. También necesitamos entender **quién puede intervenir realmente el sistema y cómo se controlan esas intervenciones.** ## Saber dónde está el dato ya no es suficiente Antes era relativamente fácil decir: "Los datos están en este servidor". Hoy un dato puede hacer un recorrido mucho más largo. Puede nacer en una aplicación, viajar por una interfaz, pasar por otra plataforma, terminar en un dashboard y luego utilizarse para generar un reporte. Así que la pregunta **¿dónde están nuestros datos?** puede quedarse corta. La pregunta más útil es: **¿por dónde circulan nuestros datos?** PIC/S reconoce las interfaces y transferencias como puntos en los que puede existir riesgo de pérdida, modificación o transcripción incorrecta de información. En un entorno cloud, entender el **data flow** puede ser tan importante como saber dónde está alojada la información. Porque el riesgo no siempre está en el lugar donde termina el dato. Muchas veces está **en el camino.** ## Lo que vemos en pantalla no siempre es todo el dato Supongamos que una plataforma muestra: **Resultado: 98,7 %** A simple vista, ese parece ser el dato. Pero detrás puede existir mucha más información: - Quién generó el resultado. - Cuándo. - Qué versión del registro estamos viendo. - Si existió un valor anterior. - Si hubo una modificación. - Quién la realizó. - Qué quedó registrado en el audit trail. - Qué parámetros estaban activos. Todo ese contexto puede formar parte de la **metadata**. FDA reconoce que los metadatos ayudan a entender el significado y el contexto de un dato y que debe conservarse aquella información necesaria para reconstruir adecuadamente una actividad CGMP. PIC/S también considera que la metadata puede formar parte integral del registro original cuando es necesaria para interpretar correctamente la información. Esto nos lleva a una pregunta especialmente importante en sistemas cloud: **Si mañana necesitamos extraer nuestros registros del sistema, ¿recibiremos realmente el registro completo o solo una representación de él?** Un PDF puede mostrar el resultado final. Pero puede no contener toda la historia. Y eso puede convertirse en un problema cuando necesitamos investigar una desviación, reconstruir una actividad o responder durante una inspección. ## Tener una copia no sirve de mucho si no puedes recuperarla Otro ejemplo común: "El proveedor realiza backup todos los días". Suena bien. Pero todavía faltan algunas preguntas: - ¿De qué hace backup? - ¿Incluye metadata? - ¿Incluye audit trail? - ¿Incluye las configuraciones necesarias para interpretar correctamente la información? - ¿Se ha probado alguna vez la restauración? PIC/S espera que los sistemas cuenten con mecanismos adecuados de backup y restauración y que la capacidad de recuperación sea comprobada. Por eso conviene diferenciar dos cosas: > Backup significa que existe una copia. Recuperabilidad significa que puedes demostrar que esa copia sigue siendo útil. Para información GxP, la segunda es la que realmente importa. ## Ciberseguridad e integridad de datos ya no pueden vivir separadas Durante años muchas compañías han dividido claramente estos temas. Calidad habla de integridad de datos. IT habla de ciberseguridad. Pero en la práctica cada vez es más difícil separarlos. Un ataque puede afectar: - Disponibilidad. - Autenticidad. - Completitud. - Trazabilidad. - Confiabilidad. La propuesta revisada de Annex 11 presta mucha más atención a amenazas de seguridad, vulnerabilidades, conexiones remotas y protección de sistemas GMP. Y tiene sentido. Si un ransomware impide acceder a información crítica, si una cuenta comprometida modifica registros o si una vulnerabilidad permite intervenir una base de datos, ya no estamos hablando únicamente de un problema de IT. También estamos hablando de **integridad de datos**. Por eso, probablemente veremos cada vez más una conversación conjunta entre **Calidad, IT, propietarios de procesos y proveedores tecnológicos**. ## ¿Qué pasa si mañana dejamos de trabajar con el proveedor? Hay un riesgo que muchas veces se descubre demasiado tarde. La compañía utiliza un SaaS durante años y un día decide cambiarlo. O el proveedor deja de prestar el servicio. O vende la plataforma. O simplemente se termina el contrato. La pregunta entonces es: **¿qué pasa con nuestros registros?** La obligación de conservarlos no desaparece porque termine la relación comercial. La propuesta revisada de Annex 11 introduce expresamente el concepto de **exit strategy**, precisamente para asegurar que la compañía pueda mantener control sobre sus datos cuando finaliza la relación con el proveedor. PIC/S, por su parte, señala que la información archivada debe seguir siendo accesible, legible y recuperable durante el período requerido, incluso cuando cambian las tecnologías utilizadas. Por eso hay una recomendación que parece sencilla, pero puede evitar muchos problemas: **La estrategia de salida debería discutirse antes de contratar el sistema, no cuando ya estamos tratando de abandonarlo.** ## Entonces, ¿qué parece estar mirando el regulador? Cuando se leen en conjunto FDA, PIC/S, MHRA y las propuestas europeas, empieza a aparecer una dirección bastante coherente. No existe una regulación global específica llamada "Cloud GMP". Pero sí vemos preguntas que se repiten detrás de muchas de estas expectativas: | Lo que está cambiando | Lo que deberíamos preguntarnos | |---|---| | Más procesos dependen de terceros | ¿Cómo supervisamos lo que ya no hacemos directamente? | | Más datos están fuera de nuestra infraestructura | ¿Sabemos dónde están y por dónde circulan? | | Crece el uso de SaaS | ¿Qué controla el proveedor y qué seguimos teniendo que controlar nosotros? | | Los registros electrónicos son más complejos | ¿Estamos conservando dato, metadata y contexto? | | Hay más accesos remotos y administrativos | ¿Quién puede intervenir realmente el sistema? | | Aumenta la exposición digital | ¿Cómo podría un incidente de seguridad afectar nuestros datos? | | Dependemos más de proveedores | ¿Podemos recuperar nuestros registros si mañana cambia o desaparece el servicio? | ## Si mañana llega un inspector, ¿qué deberíamos poder explicar? No significa que FDA, MHRA, PIC/S o los inspectores bajo el marco EU GMP vayan a llegar con esta lista exacta de preguntas. Pero sí parece razonable esperar que una compañía que utiliza sistemas cloud pueda explicar, sin improvisar: - Qué información GxP maneja el sistema. - Dónde nace. - Dónde se almacena. - Cómo se mueve. - Qué metadata necesita. - Quién puede acceder. - Quién tiene privilegios administrativos. - Qué actividades realiza el proveedor. - Cómo se supervisa ese proveedor. - Cómo se conocen los cambios y los incidentes relevantes. - Cómo se recuperan los datos. - Cómo se mantienen accesibles durante el período de retención. - Y qué ocurriría si mañana terminara el servicio. No se trata de que el dueño del proceso se convierta en especialista en infraestructura cloud. Se trata de que pueda demostrar que **conoce suficientemente el entorno del que dependen sus procesos y sus decisiones GxP**. ## Conclusión: la nube avanza. Nuestro control también debería hacerlo Los reguladores no parecen estar intentando frenar el uso de cloud. Al contrario: sus publicaciones reconocen que los servicios externos, la automatización y los nuevos modelos tecnológicos ya forman parte de la industria. Lo que no cambia es el principio de fondo. FDA sigue esperando datos confiables y exactos. PIC/S incluye expresamente el cloud dentro de la gobernanza de integridad de datos. Y la evolución propuesta del Annex 11 muestra un entorno en el que proveedores, seguridad, datos y tecnología están cada vez más conectados. Por eso, quizás la conversación ya no debería empezar preguntando **¿qué más podemos llevar a la nube?,** sino con una pregunta mucho más importante: **a medida que la nube avanza, ¿nuestro conocimiento y nuestro control sobre los datos avanzan con ella?** Porque en un entorno regulado, avanzar hacia la nube no debería significar perder visibilidad ni control, sino fortalecer la capacidad de demostrar que los datos siguen siendo confiables, íntegros y disponibles durante todo su ciclo de vida. En QbD Group ayudamos a compañías farmacéuticas y biotecnológicas a mantener el control de sus datos GxP en entornos cloud: desde la evaluación y supervisión de proveedores SaaS hasta la validación de sistemas computarizados, la integridad de datos y la definición de estrategias de salida. **¿Quieres saber si podrías explicar hoy, sin improvisar, cómo controlas tus datos en la nube? [Habla con nuestros expertos](/es/servicios/software-solutions-services/integridad-de-datos).** --- Source: https://qbdgroup.com/es/blog/nube-integridad-datos-gxp-annex-11 — © QbD Group. Quote freely with attribution and a link back.