Guía en español: qué exige el borrador del Anexo 22 a la IA en GMPVer la guía

Primero el proceso real. Después, el código

La mayoría de los sistemas que fallan una auditoría no fallan por el código. Fallan porque nadie escribió con claridad qué tenía que hacer el sistema ni por qué.

  • El mismo equipo de principio a fin
  • Una entrega firmada en cada fase
  • El riesgo decide el esfuerzo de prueba

Desarrollo y validación, en paralelo

El software y su documentación de validación avanzan a la vez. Cada fase termina con una entrega firmada, y un requisito que no se puede probar se reescribe antes de seguir.

  • En curso
  • Devuelto
  • Aprobado
  • Entrega firmada

Arriba, el software; abajo, su documentación de validación.

  1. 0. EvaluaciónEvaluación¿Compensa?Si no compensa, aquí termina
  2. 1. EstrategiaDesarrollo del software: Proceso realmapeado donde ocurre el trabajoDocumentación de validación: Plan de validaciónalcance y responsabilidades
  3. 2. Requisitos de usuarioDesarrollo del software: Requisitoscon quien usará el sistemaDocumentación de validación: URSrevisadas por calidadNo se puede probar: se reescribe
  4. 3. Diseño y construcciónDesarrollo del software: Entregas cortasy revisablesDocumentación de validación: ET y DQdiseño cualificado
  5. 4. Enfoque basado en riesgosDocumentación de validación: Análisis de riesgospaciente, producto e integridad de datosdecide el esfuerzo de prueba
  6. 5. Verificación continuaDesarrollo del software: Pruebas automatizadasdesde el primer díaDocumentación de validación: Evidenciade las pruebas y del modelo, si hay IA
  7. 6. CualificaciónDesarrollo del software: Instalaciónen su entornoDocumentación de validación: IQ, OQ y PQprotocolo, ejecución, desviaciones, informe
  8. 7. LiberaciónLiberacióndocumentación cerrada y firmada
  9. 8. Estado validadoEstado validadosoporte y control de cambioscada cambio indica qué evidencia rehacer

Una evaluación previa y ocho fases, del proceso real al estado validado

Qué ocurre y qué se entrega en cada fase.

  1. Evaluación

    Antes de empezar, revisamos el proceso con usted: dónde se pierde el tiempo, cuánto control le corresponde y si la IA aporta.Si no compensa, aquí termina. Si la evaluación muestra que el proceso no gana nada con software a medida, que una herramienta estándar lo resuelve o que el cumplimiento se complica sin beneficio, se lo decimos y no seguimos adelante.

    Entrega: Una respuesta clara: si el proyecto compensa o no.

  2. Estrategia

    Vamos a donde ocurre el trabajo y mapeamos el proceso real, no el del procedimiento. Con ese mapa fijamos la estrategia de validación: alcance, responsabilidades y los procedimientos propios del cliente que aplican.

    Entrega: Plan de validación.

  3. Requisitos de usuario

    Escritos con quien va a usar el sistema y revisados por calidad. Si un requisito no se puede probar, no es un requisito y lo reescribimos.

    Entrega: Especificaciones de requisitos de usuario ().

  4. Diseño y construcción

    Entregas cortas y revisables. Usted ve el sistema funcionando mucho antes de que esté terminado, que es cuando todavía es barato cambiarlo.

    Entrega: Especificación técnica y cualificación de diseño ().

  5. Enfoque basado en riesgos

    Evaluamos dónde un fallo del sistema llegaría al paciente, al producto o a la integridad de datos. Ese análisis decide el esfuerzo de prueba del resto del proyecto, que se concentra donde el riesgo lo justifica. Si hay IA, tiene en cuenta además la incertidumbre del modelo, su influencia en la decisión y lo difícil que es detectar sus fallos.

    Entrega: Análisis de riesgos.

  6. Verificación continua

    Pruebas automatizadas desde el primer día, con el esfuerzo manual reservado a lo que el riesgo justifica. Es el enfoque de garantía de software computarizado, y reduce el papel sin reducir la evidencia. Si el sistema incorpora un modelo, se evalúa además con casos reales contra un criterio de aceptación fijado de antemano.

    Entrega: Evidencia de las pruebas y, si hay IA, documentación del modelo.

  7. Cualificación

    Cualificación de instalación, operacional y de proceso (IQ, OQ y PQ) en su entorno, sobre un diseño ya cualificado en la DQ.

    Entrega: , y , cada una con su protocolo, ejecución, desviaciones e informe (la se entrega en la fase 3).

  8. Liberación

    Con la documentación cerrada y firmada, el sistema entra en producción con su informe de validación, no con la promesa de escribirlo.

    Entrega: Matriz de trazabilidad, análisis de riesgos residual e informe final de validación.

  9. Estado validado

    Soporte, evolución y control de cambios. Cada modificación posterior indica qué evidencia hay que rehacer, y esa decisión queda documentada. Si lo prefiere, también alojamos y mantenemos la infraestructura sobre Azure o AWS.

    Entrega: Plan de mantenimiento del estado validado y, si hay IA, plan de seguimiento del modelo.

Todo empieza por la primera fase

Evaluamos con usted el proceso y el riesgo antes de escribir una línea de código.