CSV vs CSA: durante veinte años, la validación de sistemas computarizados (CSV) ha sido sinónimo de protocolos interminables, capturas de pantalla y firmas en cada página. Con la guía final de la FDA Computer Software Assurance for Production and Quality Management System Software, publicada el 24 de septiembre de 2025 y actualizada el 3 de febrero de 2026, el Computer Software Assurance (CSA) se convierte en la referencia oficial: menos documentación defensiva, más pensamiento crítico y pruebas proporcionales al riesgo. En este artículo vemos qué cambia realmente respecto a la CSV tradicional, cómo aplicar el nuevo enfoque y qué significa para los profesionales GxP.
CSV vs CSA: por qué la FDA cambió de enfoque
La CSV "clásica" nace de la guía de la FDA General Principles of Software Validation (GPSV) de 2002, un documento pensado para una época en la que el software era en gran parte a medida e instalado on-premise. Con el tiempo, sin embargo, la aplicación de la GPSV degeneró en un exceso de burocracia: scripts de prueba firmados línea a línea, cientos de capturas de pantalla, evidencias en papel duplicadas. El resultado, observado por la propia FDA, es paradójico: las empresas invierten más energía en producir documentación que en asegurar la calidad real del software.
El CSA invierte la perspectiva. El objetivo no es demostrar que se ha probado todo de la misma manera, sino concentrar el esfuerzo de aseguramiento donde el riesgo para la calidad del producto y la seguridad del paciente es mayor, aplicando el principio del enfoque menos gravoso (least burdensome). La guía final sustituye formalmente la Sección 6 de la GPSV de 2002 (la dedicada al software de producción y del sistema de calidad), mientras que el resto de la GPSV sigue vigente.
Del borrador de 2022 a la guía final: las etapas
El recorrido del CSA ha sido largo y conviene reconstruirlo, porque muchas empresas se quedaron en el borrador:
- Septiembre de 2022: la FDA publica el borrador Computer Software Assurance for Production and Quality System Software.
- 24 de septiembre de 2025: CDRH y CBER publican la guía final, que incorpora los comentarios recibidos sobre el borrador.
- 3 de febrero de 2026: la FDA emite una versión actualizada con el título Computer Software Assurance for Production and Quality Management System Software, alineado con la terminología de la QMSR (21 CFR Parte 820 armonizada con ISO 13485, aplicable desde el 2 de febrero de 2026).
Respecto al borrador, la versión final añade una sección terminológica sobre IaaS, PaaS y SaaS, aclara que el marco puede aplicarse también a herramientas de inteligencia artificial usadas en producción o en el sistema de calidad, amplía las indicaciones sobre cuánto puede apoyarse uno en la documentación del proveedor e insiste en la preferencia por evidencias digitales frente al papel.
Cómo funciona el CSA: intended use, riesgo, aseguramiento
El método CSA se articula en cuatro pasos lógicos, a repetir para cada software (o funcionalidad individual) en alcance:
- Identificar el intended use: ¿el software (o la función) se usa directamente en producción o en el sistema de calidad, o solo los apoya?
- Análisis del riesgo de proceso: ¿puede un fallo del software generar un problema de calidad que comprometa previsiblemente la seguridad? Si es así, el riesgo de proceso es "alto"; en caso contrario, "no alto". La FDA usa esta clasificación binaria, pero admite escalas más granulares (moderado, bajo).
- Seleccionar las actividades de aseguramiento proporcionales al riesgo: pruebas scripted rigurosas para las funciones de alto riesgo, métodos no scripted para el resto.
- Registrar las evidencias: intended use, determinación del riesgo, qué se probó, quién lo hizo y con qué resultado.
Los cambios de paradigma regulatorio como este se entienden mejor una pieza a la semana: suscríbete a The Pragmatic GMP, la newsletter semanal gratuita de GuideGxP, para recibir análisis prácticos y audit-ready sobre CSA, Anexo 11 e integridad de datos.
CSV vs CSA: la comparación punto por punto
| Aspecto | CSV tradicional (GPSV 2002) | CSA (guía final 2025) |
|---|---|---|
| Punto de partida | Documentar la validación de todo el sistema | Intended use y riesgo para paciente/calidad |
| Pruebas | Principalmente scripted, uniformes | Scripted solo donde el riesgo es alto; no scripted en el resto |
| Evidencias | Capturas de pantalla, impresiones, firmas manuales | Registros digitales: logs del sistema, audit trail, resultados en la herramienta |
| Proveedores | Auditorías in situ y revalidación interna | Aprovechamiento basado en riesgo de la documentación del proveedor (ISO, SOC, SBOM) |
| Cloud e IA | No contemplados | IaaS/PaaS/SaaS y herramientas de IA explícitamente en alcance |
| Esfuerzo documental | Alto, independiente del riesgo | Proporcional al riesgo (least burdensome) |
Testing scripted y no scripted: cómo elegir
La novedad más concreta para quien valida es la legitimación del testing no scripted. Para las funciones de riesgo "no alto", la guía señala explícitamente métodos como el ad-hoc testing, el error-guessing y el exploratory testing: el tester ejercita el sistema con escenarios realistas y registra de forma sintética qué hizo y qué observó, sin scripts paso a paso preaprobados. Para las funciones de riesgo "alto" sigue recomendándose un testing más riguroso y trazable, típicamente scripted. Ningún método es obligatorio por ley: la elección debe motivarse con pensamiento crítico y documentarse en el análisis de riesgo.
Evidencias y documentación: qué espera la FDA
CSA no significa "sin documentos". Significa los documentos correctos. El expediente mínimo que un inspector espera encontrar incluye: el inventario de software mapeado a los intended use, la clasificación del riesgo de proceso de cada elemento, la descripción de las actividades de aseguramiento realizadas, quién las ejecutó y los resultados. La guía desaconseja explícitamente capturas de pantalla y duplicaciones en papel cuando el sistema ya genera logs y audit trails utilizables como evidencia. Atención a un punto a menudo malinterpretado: si los registros son electrónicos, el 21 CFR Parte 11 sigue aplicándose, y la FDA no ejerce discrecionalidad sobre la validación del software de producción y calidad.
¿Y para el farma? GAMP 5 y Anexo 11
Formalmente, el CSA es una guía para productos sanitarios (software de producción y del sistema de gestión de calidad bajo 21 CFR Parte 820). Pero sus principios ya son práctica habitual también en el farmacéutico: la segunda edición de GAMP 5 (ISPE, 2022) incorpora pensamiento crítico, testing ágil y aprovechamiento del proveedor en plena coherencia con el CSA, y la revisión en curso del Anexo 11 de las NCF de la UE empuja en la misma dirección basada en riesgo. Quien opera en ámbito GxP puede por tanto adoptar el planteamiento CSA en su metodología de validación, manteniendo como referencias vinculantes el Anexo 11 y la Parte 11 para los registros electrónicos.
Recomendación GuideGxP
No reescribas todos los PNT en una noche. El paso de CSV a CSA se hace por etapas y con evidencias sólidas: actualiza primero el procedimiento de evaluación de riesgos de los sistemas computarizados introduciendo la clasificación por intended use y riesgo de proceso; define en el PNT cuándo se admite el testing no scripted y cómo documentarlo; revisa la cualificación de proveedores para aprovechar de forma defendible certificaciones y paquetes de prueba del vendor; y asegúrate de que los audit trails y logs sean realmente recuperables, porque en el CSA son tu evidencia primaria. En auditoría, la pregunta no será "¿cuántos scripts ejecutaste?" sino "¿cómo decidiste dónde concentrar las pruebas?".
Para establecer una gobernanza de integridad de datos, una revisión del audit trail y controles de laboratorio QC defendibles en inspección, echa un vistazo a nuestra Data Integrity en ámbito GMP – Guía Operativa de gobernanza, audit trail review y laboratorios QC: el complemento ideal para llevar el CSA a tu PQS.
