CSV clásico vs. CSA: el nuevo enfoque de la FDA para validar software

Desde 2022 la FDA viene promoviendo Computer Software Assurance (CSA) como alternativa a la validación tradicional (CSV) para software de manufactura y de calidad. No es una norma nueva ni reemplaza el marco regulatorio: es un cambio de enfoque sobre cómo generar la evidencia de que un sistema funciona como debe, gastando el esfuerzo donde realmente reduce riesgo.

Qué es CSA y por qué aparece ahora

La guía borrador de la FDA Computer Software Assurance for Production and Quality System Software (2022) nació de un diagnóstico simple: muchas organizaciones dedicaban la mayor parte del esfuerzo de validación a documentar pruebas scripted de bajo riesgo (clics, capturas de pantalla, firmas), y muy poco tiempo real a probar lo que de verdad podía fallar. El resultado eran validaciones larguísimas que, paradójicamente, no siempre detectaban los problemas importantes.

CSA no elimina la validación: pide priorizarla según el riesgo del proceso que el software soporta, no según cuánto papeleo se pueda generar.

CSV clásico: qué exige

El modelo de Computer System Validation tradicional, apoyado en GAMP 5 y el modelo en V, suele traducirse en la práctica en:

• Protocolos IQ/OQ/PQ exhaustivos, con pasos scripted paso a paso.
• Evidencia documental de cada paso (capturas de pantalla, firmas, iniciales) sin importar el riesgo real del caso probado.
• Poca diferenciación entre una función crítica (por ejemplo, un cálculo de dosis) y una función de bajo impacto (por ejemplo, el color de un botón).

El cambio de enfoque de CSA

CSA propone clasificar cada función del sistema según su impacto en el proceso (alto, medio, bajo) y elegir el método de prueba proporcional a ese impacto:

• Alto impacto (afecta directamente la calidad del producto o la seguridad del paciente): pruebas scripted rigurosas, como hoy.
• Impacto medio/bajo: pruebas no scripted o exploratorias — el probador sigue un objetivo, no un guion palabra por palabra — con evidencia mínima suficiente (un registro de qué se probó y el resultado, no una captura por paso).
• Funcionalidad ya verificada por el proveedor (con evidencia confiable de su propio desarrollo): aprovechar esa evidencia en vez de repetir las mismas pruebas desde cero.

La pregunta que ordena todo CSA no es «¿qué tan completo es el protocolo?», sino «¿qué tanto reduce el riesgo esta prueba, y cuánta evidencia necesito realmente para confiar en el resultado?».

Principales diferencias

Aspecto	CSV clásico	CSA
Punto de partida	Cobertura documental completa	Riesgo para el paciente/proceso
Tipo de prueba	Mayormente scripted	Scripted solo donde el riesgo lo exige
Evidencia	Captura por cada paso	Mínima suficiente, proporcional al riesgo
Evidencia del proveedor	Rara vez se aprovecha	Se reutiliza si es confiable
Objetivo	Demostrar cumplimiento documental	Asegurar que el sistema es adecuado para su uso

Errores frecuentes al adoptar CSA

• Tratar CSA como «validar menos». No es reducir el esfuerzo en general, es redirigirlo hacia el riesgo real.
• No documentar el criterio de clasificación de riesgo. Si un inspector pregunta por qué una función se probó de forma exploratoria, debe existir un análisis de riesgo detrás, no solo la decisión de ahorrar tiempo.
• Aplicarlo sin ajustar los procedimientos internos. Si el SOP de validación sigue exigiendo protocolos scripted para todo, CSA no puede aplicarse aunque la guía lo permita.
• Ignorarlo por ser aún una guía borrador. Aunque no es de cumplimiento obligatorio, refleja hacia dónde va la expectativa de inspección de la FDA.

Cómo empezar sin perder cumplimiento

1. Actualizar la metodología de riesgo para que clasifique funciones por impacto en el proceso, no solo por categoría GAMP del sistema.
2. Revisar los SOP de validación para permitir explícitamente pruebas no scripted en funciones de riesgo medio/bajo.
3. Definir qué evidencia del proveedor es aceptable reutilizar, y con qué criterios de confiabilidad.
4. Pilotear en un sistema no crítico antes de aplicar CSA a gran escala.
5. Capacitar al equipo de calidad en el nuevo criterio: el objetivo cambia de «documentar todo» a «asegurar lo que importa».