Checklist de preparación para una auditoría INVIMA en sistemas computarizados

Una auditoría de INVIMA ya no se limita a revisar planillas de producción en papel: cada vez con más frecuencia, los inspectores formados en Buenas Prácticas de Manufactura y alineados con estándares PIC/S preguntan por la validación de los sistemas computarizados que soportan calidad y manufactura. Si el equipo de sistemas no está preparado para esa conversación, un hallazgo menor de forma se convierte fácilmente en un hallazgo crítico.

Qué revisa INVIMA en sistemas computarizados

Un inspector no evalúa el software en sí no es un auditor de código, sino la evidencia de que el sistema fue validado para su uso previsto y de que se mantiene bajo control durante toda su vida útil. En la práctica, eso se traduce en preguntas muy concretas sobre:

• Inventario y clasificación de sistemas GxP: qué sistemas computarizados soportan procesos regulados y con qué nivel de criticidad.
• Estado de validación: evidencia documental de que cada sistema crítico fue validado antes de entrar en uso productivo.
• Control de accesos: que los permisos de usuario correspondan a roles reales, sin privilegios excesivos ni cuentas genéricas.
• Audit trail: que el registro de auditoría esté activo, sea inalterable y se revise periódicamente no solo que exista.
• Control de cambios: que toda modificación al sistema (parche, actualización, configuración) pase por una evaluación de impacto sobre el estado validado.
• Respaldo y continuidad: que los backups existan y, más importante, que se haya probado restaurarlos.

Los documentos que te van a pedir primero

En la mayoría de visitas, el inspector pide estos documentos en los primeros minutos de la revisión de sistemas computarizados. Tenerlos listos y actualizados marca la diferencia entre una conversación fluida y una defensiva:

• Plan maestro de validación (VMP) vigente, que incluya los sistemas computarizados del alcance regulado.
• Inventario de sistemas GxP con su clasificación de criticidad o impacto.
• Protocolos y reportes de validación (IQ/OQ/PQ, o su equivalente basado en riesgo) de cada sistema crítico.
• Matriz de usuarios y niveles de acceso, con evidencia de revisión periódica.
• SOP de control de cambios, con evidencia de change requests ejecutados y su evaluación de impacto.
• Evidencia de revisión del audit trail: quién la hace, con qué frecuencia y qué se documenta.
• Plan de respaldo y evidencia de una restauración probada, no solo del job programado.

Los hallazgos más comunes

Después de acompañar auditorías en el sector salud y farmacéutico, los hallazgos relacionados con sistemas computarizados tienden a repetirse:

• Validación «de papel»: protocolos firmados, pero sin evidencia real de que la ejecución corresponda al ambiente productivo actual.
• Audit trail activado pero nunca revisado: la funcionalidad existe, pero nadie puede mostrar una revisión periódica documentada.
• Usuarios genéricos o compartidos (por ejemplo, «admin» o «calidad1») que rompen la trazabilidad de quién hizo qué.
• Cambios de configuración sin evaluación de impacto sobre el estado validado parches o actualizaciones aplicados «porque tocaba», sin análisis previo.
• Backups que nunca se probaron a restaurar, descubiertos como inservibles justo cuando se necesitan.

Para un inspector, un sistema del que no se puede demostrar documentalmente que fue validado y se mantiene bajo control es, en la práctica, un sistema no validado sin importar qué tan bien funcione en el día a día.

Checklist de preparación: 90-60-30 días

No hace falta empezar a preparar la visita la semana anterior. Repartir el trabajo en tres momentos reduce el riesgo de llegar con huecos de documentación:

Cuándo	Qué revisar
90 días antes	Actualizar el inventario de sistemas GxP y su clasificación de riesgo.
90 días antes	Confirmar que el VMP siga vigente y refleje los sistemas actuales en uso.
60 días antes	Verificar que protocolos y reportes de validación estén firmados, archivados y sin huecos.
60 días antes	Auditar la matriz de accesos contra los roles reales: nadie con más permisos de los que necesita.
30 días antes	Revisar la evidencia de revisión periódica del audit trail de cada sistema crítico.
30 días antes	Probar una restauración real de backup, no solo confirmar que el job corrió.
Semana de la visita	Armar un dossier por sistema, con índice de documentos, listo para entregar.

Errores que agravan un hallazgo durante la visita

• No tener un responsable designado para hablar de sistemas computarizados que calidad y TI se miren entre sí esperando que el otro responda.
• Responder «eso lo maneja TI» sin poder mostrar evidencia conjunta de calidad y sistemas trabajando coordinados.
• Entregar copias impresas desactualizadas en lugar de la versión controlada vigente del documento.
• Minimizar un hallazgo menor en lugar de reconocerlo y comprometerse con un plan de acción con fecha concreta.

Cómo organizar la evidencia para que fluya

La diferencia entre una visita tensa y una fluida casi nunca es el nivel de cumplimiento real, sino qué tan rápido se puede mostrar. Tres prácticas ayudan:

1. Un dossier digital por sistema crítico, con índice de documentos y enlaces directos, no una carpeta compartida sin orden.
2. Un «system owner» designado por sistema, que conozca su historial de validación y cambios sin tener que buscarlo en vivo.
3. Un simulacro interno (mock audit) semanas antes, donde alguien que no participó en la preparación haga las preguntas típicas del inspector.