En septiembre de 2025 (y de nuevo en febrero de 2026), la FDA ultimó su guía sobre el control de calidad del software informático (CSA), reforzando un enfoque basado en el riesgo para la validación del software utilizado en los sistemas de producción y calidad. Para las organizaciones que aún se basan en las prácticas tradicionales de validación de sistemas informáticos (CSV), la guía aporta una mayor claridad normativa en torno a la aplicación del control de calidad basado en el riesgo a los entornos de software modernos.
Muchos de los principios en los que se basa la CSA no son nuevos. Lo que está cambiando es la forma en que las organizaciones aplican esos principios a medida que la tecnología, las plataformas de software y las exigencias normativas siguen evolucionando.
Este artículo es el primero de una serie de cuatro partes que analiza la evolución de la garantía de calidad del software en el sector de las ciencias de la vida. Analizaremos los factores normativos que impulsan la CSA, los retos habituales en su implementación, la preparación de las organizaciones y el papel que pueden desempeñar las tecnologías emergentes, como la inteligencia artificial, en la garantía de calidad del software moderna.
Tanto si estás evaluando el CSA por primera vez como si estás perfeccionando un programa de validación ya existente, esta serie está diseñada para ofrecerte información práctica sobre cómo desarrollar un enfoque sostenible y basado en el riesgo para el control de calidad del software.
Por qué se está replanteando el uso del formato CSV tradicional
La validación de sistemas informáticos (CSV) ha sido el modelo operativo por defecto para las empresas del sector de las ciencias de la vida que utilizan software GxP. Todos los sistemas, desde un simple libro de registro electrónico hasta un sistema de ejecución de la fabricación a gran escala, solían someterse al mismo ciclo de vida rígido.
Ese ciclo de vida exigía una gran cantidad de documentación, casos de prueba detallados para cada función —independientemente del riesgo— y montones de pruebas documentales en papel firmadas. La validación se convirtió en uno de los procesos más costosos, que más tiempo consumían y más reacios al cambio dentro de muchas organizaciones.
La intención que subyace al formato CSV siempre ha sido acertada. Garantizar que el software funcione según lo previsto es esencial para la seguridad de los pacientes, la calidad del producto y el cumplimiento normativo.
Con el paso del tiempo, muchas organizaciones se dieron cuenta de que el esfuerzo dedicado a la validación ya no era proporcional al riesgo del sistema. En el marco del CSV clásico, una hoja de cálculo interna de seguimiento de bajo riesgo solía conllevar casi la misma carga documental que un sistema que controlaba directamente una fase crítica de la fabricación. Los equipos dedicaban la mayor parte de su tiempo a generar documentación para *demostrar* que se habían realizado las pruebas, en lugar de *llevar a cabo* realmente las pruebas que importaban.
La iniciativa «Case for Quality» de la FDA, liderada por el CDRH desde 2011, identificó muchos de estos mismos retos: exceso de documentación, pruebas duplicadas por parte de los proveedores y una cultura de validación que disuadía a las empresas de adoptar tecnologías más nuevas, seguras y eficientes, simplemente porque su validación parecía costosa sobre el papel.
El marco normativo en el que se basa la CSA
El CSA no sustituye a los requisitos de validación. Proporciona un marco basado en el riesgo para cumplir dichos requisitos.
Conviene comprender el marco normativo en el que se inscribe:
21 CFR, parte 820
La Parte 820 del Título 21 del Código de Regulaciones Federales (CFR) establece el Reglamento sobre el Sistema de Calidad (QSR) de la FDA para los fabricantes de productos sanitarios. A partir del 2 de febrero de 2026,el reglamento modificadose ajustará en mayor medida a la norma ISO 13485:2016, al incorporar dicha norma internacional por referencia para la mayoría de los requisitos.
Principios generales de la validación de software (GPSV)
Publicados en enero de 2002, los«Principios generales de validación de software»(GPSV)de la FDAofrecen una orientación básica sobre los principios de validación de software. Se centraban principalmente en el software integrado en los dispositivos y ofrecían una cobertura limitada del software interno, ajeno al producto (sistemas de calidad, herramientas de producción, gestión de documentos, etc.), del que dependen hoy en día muchas organizaciones.
Guía de la FDA sobre el control de calidad del software informático
Publicada inicialmente como borrador de directrices en septiembre de 2022 y finalizada el 24 de septiembre de 2025 (actualizada de nuevo en febrero de 2026),la guía de la FDA sobre el CSAsustituye directamente a la sección 6 de la GPSV. Ofrece a los fabricantes un marco formal, basado en el riesgo, para garantizar la calidad del software utilizado en los sistemas de producción y de gestión de la calidad.
21 CFR, Parte 11
Los requisitos que regulan los registros electrónicos y las firmas electrónicas siguen plenamente vigentes. La CSA no relaja las obligaciones de la Parte 11. Por el contrario, ayuda a los equipos a centrar los controles de la Parte 11 en los registros que realmente constituyen pruebas reglamentarias, en lugar de registrar todo de forma indiscriminada.
ISPE GAMP 5, segunda edición
GAMP 5 (2.ª edición)es el marco de trabajo basado en el riesgo que la ISPE lleva aplicando desde hace tiempo para la validación de sistemas informatizados. Se ajusta estrechamente a la filosofía de la CSA y se utiliza ampliamente como metodología de aplicación práctica, junto con las directrices de la FDA.
Cabe destacar que las directrices de la FDA sobre el CSA abordan explícitamente realidades tecnológicas modernas que las directrices anteriores nunca contemplaron: la computación en la nube (SaaS, PaaS, IaaS), las actualizaciones automáticas de los proveedores e incluso el uso de herramientas de inteligencia artificial en los sistemas de producción o de calidad. Estos aspectos por sí solos indican que se trata de un marco diseñado para el futuro del sector, y no solo para su pasado.
¿Qué cambia con la CSA?
El cambio fundamental es el siguiente: en lugar de aplicar pruebas uniformes y exhaustivas a todos los sistemas, independientemente del riesgo, la CSA pide a los equipos que sigan un proceso proporcionado de cuatro pasos:
- Define el uso previsto:¿Para qué sirve realmente este software en este contexto concreto?
- Evaluar el riesgo de fallo:¿Cuál sería el impacto real si esta función concreta fallara? Los procesos de alto riesgo (con impacto directo en la calidad del producto o en la seguridad del paciente) se someten a un escrutinio riguroso. Las funciones de bajo riesgo son objeto de actividades de verificación proporcionales a su impacto potencial.
- Planificar las actividades de verificación: Seleccionar el método adecuado en función del nivel de riesgo, lo que puede incluir pruebas con guion, pruebas sin guion o exploratorias, pruebas ad hoc o el uso de la documentación del proveedor y la evidencia generada por el sistema.
- Documentar la fiabilidad, no solo la actividad: los registros deben reflejar los fundamentos del enfoque de verificación, no solo la prueba de que se ha completado una lista de comprobación.
Se trata de una mentalidad realmente diferente a la de «validar todo de la misma manera, de forma exhaustiva, por si acaso». Exige a los equipos que reflexionen de forma crítica sobre el riesgo, en lugar de recurrir por defecto a la máxima documentación como red de seguridad, y esa es precisamente la razón por la que la transición al CSA supone tanto un cambio cultural y organizativo como un cambio de procedimientos.
Por qué es importante ahora
Hay varios factores que están impulsando esta transición.
- Con la entrada en vigor de las directrices definitivas de septiembre de 2025 (y la actualización de febrero de 2026), el CSA ya no es un concepto preliminar en fase de «esperar y ver qué pasa». Se trata de la expectativa expresada por la FDA sobre cómo debe garantizarse el software de los sistemas de producción y calidad de cara al futuro.
- La tecnología ha superado a los modelos de validación tradicionales. Las plataformas alojadas en la nube, las actualizaciones continuas de los proveedores y las herramientas basadas en inteligencia artificial no encajan perfectamente en los marcos de validación diseñados para software local, estático y que se actualiza con poca frecuencia.
- La presión sobre los recursos no va a desaparecer. A las empresas del sector de las ciencias de la vida se les exige que hagan más con equipos de calidad y de TI más reducidos. Un marco de trabajo que reduzca la documentación de escaso valor y, al mismo tiempo, aumente el rigor allí donde realmente importa es una respuesta directa a esa presión.
De cara al futuro
Comprender los principios en los que se basa el CSA es solo el primer paso. Lo más difícil es su implantación en la organización: lograr que las personas confíen en una nueva forma de abordar el riesgo, desarrollar las competencias internas necesarias para aplicarlo correctamente y modernizar los sistemas y procesos heredados, diseñados en torno a la antigua mentalidad del CSV, todo ello sin comprometer el cumplimiento normativo ni la seguridad de los pacientes.
En la segunda parte, abordaremos el reto que hace fracasar más transiciones al CSA que cualquier otra carencia técnica: la resistencia cultural, y cómo lograr una aceptación genuina por parte de la organización de una mentalidad basada en el riesgo.
Cómo puede ayudarte RCM Life Sciences
RCM Life Sciencesayuda a las organizaciones a pasar del modelo tradicional de CSV a un modelo de CSA más eficiente y basado en el riesgo, sin perder el control sobre el cumplimiento normativo, la calidad ni la integridad de los datos. Nuestro equipo cuenta con experiencia práctica en los ámbitos de la calidad, la normativa, la validación de sistemas informáticos, los sistemas de gestión de calidad electrónicos (eQMS), la gestión de proyectos y las iniciativas de transformación digital, lo que permite ayudar a los clientes a evaluar sus prácticas actuales de validación, rediseñar los procedimientos operativos estándar (SOP) y las plantillas, definir estrategias de garantía basadas en el riesgo, formar a equipos multifuncionales y facilitar una implementación preparada para las inspecciones.
Tanto si estás evaluando el CSA por primera vez como si estás perfeccionando un programa de validación ya existente, RCM puede ayudarte a evaluar el impacto en el cumplimiento normativo de los sistemas basados en la nube y en la inteligencia artificial, y a desarrollar una hoja de ruta práctica para el control de calidad del software basado en el riesgo.Ponte en contacto con nuestro equipo para obtener más información.
Próximo artículo de la serie:Cómo llevar a cabo con éxito la transición de CSV a CSA: Preparación de la organización (próximamente)