Hay un patrón que se repite en casi todas las inspecciones FDA bajo 21 CFR Part 11: el inspector dedica los primeros treinta minutos a revisar exactamente las mismas cinco cosas. No son aleatorias. Son los puntos donde, según el archivo público de warning letters de los últimos cinco años, se concentran más del 80% de las observaciones.
Si conoces esos cinco puntos y los tienes resueltos, una inspección Part 11 deja de ser un evento traumático y se convierte en un trámite documentado. Si no los conoces o los tienes a medias, los cinco puntos van a aparecer en tu Form 483 antes del almuerzo.
Este artículo va dirigido a Directores de Calidad, Responsables de Sistemas y CIOs de plantas farmacéuticas, biotech y CROs que operan software bajo alcance de FDA. Cubre qué pide realmente la norma, qué mira el auditor en la práctica, cuáles son los hallazgos típicos, y qué tiene que estar listo en tu sistema antes de que llegue el inspector.
Qué cubre Part 11 y qué no
El primer error frecuente es pensar que Part 11 aplica a "todo el software de la planta". No es así. Part 11 aplica específicamente a registros electrónicos y firmas electrónicas usados para satisfacer requisitos GxP. La distinción es importante.
Un sistema queda bajo alcance de Part 11 si cumple alguna de estas condiciones:
- Crea, modifica, almacena, archiva, recupera o transmite registros que sustituyen a documentos en papel exigidos por una "predicate rule" de la FDA (típicamente 21 CFR Parts 210/211 para fármacos, Part 820 para dispositivos médicos, Part 58 para GLP).
- Captura firmas electrónicas que reemplazan firmas manuscritas en esos registros.
- Transmite registros regulados a la FDA en formato electrónico.
Un sistema queda fuera de alcance Part 11 si:
- Es solo de soporte interno sin impacto GxP (gestión de RRHH, contabilidad general, comunicaciones internas).
- Genera registros que la planta mantiene voluntariamente en papel firmado a mano.
- Es un sistema de cálculo desechable que no almacena el resultado como registro oficial.
Lo importante: es la planta quien decide y documenta qué sistemas están en alcance. Esa decisión tiene que estar justificada en el inventario de sistemas computarizados y revisada con la frecuencia que defina el sistema de calidad. Un sistema mal categorizado como "fuera de alcance" cuando un inspector entiende que sí está dentro genera una observación de las que más cuesta resolver.
Closed system vs open system: una distinción técnica clave
Part 11 distingue entre dos tipos de sistemas, y los requisitos cambian:
Closed system (§11.10). Acceso controlado por las personas responsables de los registros. Es el caso típico de software interno con autenticación corporativa, donde solo personal autenticado de la propia planta accede. La mayoría de sistemas farmacéuticos son closed.
Open system (§11.30). Acceso por partes externas no responsables del contenido de los registros. Por ejemplo, un portal donde proveedores externos suben certificados. Un open system necesita controles adicionales, especialmente cifrado robusto durante la transmisión y firma electrónica avanzada para garantizar autenticidad e integridad.
La distinción importa porque un auditor va a preguntar primero qué tipo de sistema es cada uno y va a verificar que los controles aplicados se corresponden con esa categoría.
Los cinco puntos que el auditor revisa primero
A continuación, los cinco hallazgos más frecuentes en inspecciones Part 11, en el orden en que un auditor experimentado los aborda. Conocerlos es la mitad de la preparación.
Punto 1 — Validación documentada del sistema
Qué dice la norma: §11.10(a) exige validación de sistemas para asegurar que funcionan de forma consistente y precisa según su propósito.
Qué mira el auditor: la documentación de validación. Plan de validación. Protocolos IQ/OQ/PQ con resultados firmados. Reportes de validación aprobados por Calidad. Plan de revalidación tras cambios significativos.
Hallazgo típico: sistemas en producción sin validación formal documentada, o con una validación inicial que nunca se actualizó tras una migración a nueva versión, cambio de servidor o modificación de scope. La FDA es muy clara: validación no es un evento de implantación, es un estado que se mantiene.
Nota sobre CSA: la FDA publicó en septiembre de 2025 la guidance "Computer Software Assurance for Production and Quality System Software", que permite enfoques proporcionales al riesgo en lugar de validación exhaustiva tradicional. Esto cambia cómo demuestras cumplimiento, no qué tienes que cumplir. Los controles de Part 11 (audit trail, autenticación, e-signatures) siguen siendo obligatorios para todos los sistemas en alcance.
Punto 2 — Audit trail completo y revisable
Qué dice la norma: §11.10(e) exige audit trails computer-generated, time-stamped, automáticos, que registren acciones de creación, modificación y eliminación de registros electrónicos. Las entradas no pueden ser modificables ni eliminables por ningún usuario, incluido el administrador.
Qué mira el auditor: una demostración en pantalla. Te van a pedir que abras un registro cualquiera, modifiques algo, y muestres el audit trail completo del cambio. Van a verificar:
- Que se registra el usuario, no solo el rol o la cuenta compartida.
- Que el timestamp es de servidor sincronizado, no de cliente local.
- Que se guarda el valor anterior y el valor nuevo, no solo el hecho de que hubo cambio.
- Que existe campo de justificación cuando aplica.
- Que el audit trail no se puede desactivar desde la interfaz, ni siquiera con permisos de admin.
- Que existe evidencia documentada de revisión periódica del audit trail por parte de Calidad.
Hallazgo típico: audit trails que existen técnicamente pero nunca han sido revisados por el equipo de Calidad. La norma no exige solo que el audit trail exista; exige que se revise con frecuencia documentada. Sin evidencia de revisión, los datos pierden su valor como prueba de control. Es probablemente el hallazgo más frecuente de Part 11 en inspecciones recientes.
Punto 3 — Cuentas de usuario únicas y atribuibles
Qué dice la norma: §11.10(d) y §11.300 exigen control de acceso por identificadores únicos y verificación de identidad antes de cualquier operación bajo Part 11.
Qué mira el auditor: la lista de usuarios del sistema. Los logs de inicio de sesión. La política de contraseñas configurada. El procedimiento de gestión del ciclo de vida de cuentas (alta, baja, modificación de permisos).
Hallazgo típico: cuentas compartidas. "Operador1", "TurnoNoche", "Lab", o usuarios genéricos con varios técnicos detrás. Cuando un auditor encuentra una cuenta compartida en un sistema GxP, el resto del audit trail del sistema queda en duda automáticamente: si no se sabe quién hizo qué, las firmas electrónicas no son atribuibles, y el sistema completo pierde valor probatorio. Es un hallazgo crítico que suele escalar rápidamente a Form 483.
Otro hallazgo relacionado: cuentas de usuario que siguen activas semanas o meses después de que la persona haya dejado la planta. Sin procedimiento de baja documentado, los accesos quedan abiertos.
Punto 4 — Firmas electrónicas con todos los elementos exigidos
Qué dice la norma: §11.50 exige que las firmas electrónicas en un registro contengan el nombre impreso del firmante, la fecha y hora de la firma, y el significado de la firma (por ejemplo: revisado, aprobado, autorizado).
Qué mira el auditor: un registro firmado electrónicamente. Va a verificar visualmente que los tres elementos están presentes y son legibles. Después va a pedir que demuestres que la firma está vinculada de forma permanente al registro y no se puede separar, copiar o transferir.
Hallazgo típico: firmas electrónicas que muestran solo el nombre y la fecha pero no el significado. O sistemas donde el "significado" es genérico ("firmado") y no específico al evento ("aprobado para liberación de lote", "revisado por QC", "autorizado por Director Técnico").
Adicionalmente, §11.100(c) exige una certificación única por escrito a la FDA de que las firmas electrónicas de la organización son legalmente equivalentes a las manuscritas. Es un trámite que se hace una vez y se mantiene en archivo. Si el auditor pide ver esa certificación y no la tienes, es un hallazgo administrativo que puedes resolver, pero da mala imagen.
Punto 5 — Control de cambios con impacto Part 11
Qué dice la norma: §11.10(k) exige controles para asegurar que solo personal autorizado puede modificar registros maestros. Esto se conecta con el requisito general de control de cambios bajo GMP.
Qué mira el auditor: los últimos cambios al software (parches, actualizaciones, cambios de configuración) y cómo se documentaron. Va a revisar si para cada cambio:
- Se evaluó el impacto sobre los controles Part 11.
- Se actualizó la validación si era necesario.
- Se firmó la aprobación del cambio por roles con autoridad documentada.
- Se ejecutaron pruebas de regresión sobre las funciones críticas.
Hallazgo típico: change control que salta el assessment de impacto Part 11. Una actualización del proveedor de software se aplica como "rutina" sin evaluar si toca audit trail, autenticación o e-signatures. Después de la actualización, un control crítico ha cambiado sin que la planta lo sepa. Cuando el inspector lo detecta, el rastro de no-trazabilidad puede comprometer cualquier registro generado desde esa actualización.
Lo que el auditor te pedirá demostrar en pantalla
Más allá de la documentación, hay una parte del auditoría que es práctica. El auditor va a pedirte que abras el sistema y le demuestres en vivo algunas operaciones. Conviene haberlas ensayado:
- Acceder al sistema con tu usuario y tu contraseña, mostrando que el sistema bloquea tras N intentos fallidos.
- Mostrar la lista de usuarios activos y la fecha de último acceso de cada uno.
- Localizar un registro específico y mostrar su audit trail completo desde creación hasta el momento actual.
- Hacer una modificación menor a un registro, firmarla electrónicamente, y demostrar que la firma queda vinculada.
- Exportar el audit trail en formato firmado e íntegro (PDF/A con firma digital, CSV firmado, o XML) que pueda llevarse el auditor para análisis posterior.
- Demostrar que un usuario sin permisos no puede acceder a un módulo crítico.
- Mostrar el último ciclo de revisión periódica del audit trail con la firma de Calidad.
Si tu equipo nunca ha hecho estas demostraciones de forma controlada, la primera vez que se hacen es delante del inspector, y eso suele acabar mal.
La responsabilidad cuando el sistema es de un proveedor
Una pregunta frecuente: si el software es de un vendor externo (SaaS, on-premise empaquetado, plataforma cloud), ¿la responsabilidad de Part 11 es del proveedor o de la planta?
La respuesta de la FDA es clara: la responsabilidad es siempre de la planta. El proveedor puede haber construido un sistema técnicamente capaz de cumplir Part 11, pero es la planta la que debe validar el sistema en su entorno, configurar los controles correctamente, mantener los procedimientos asociados, y responder ante el auditor. "El vendor lo certifica" no es una respuesta aceptable en una inspección.
Lo que sí es razonable y necesario:
- Solicitar al proveedor su documentación de validación de producto (V-Model, casos de prueba, declaraciones de cumplimiento).
- Verificar el contrato de calidad con el proveedor y los SLAs sobre disponibilidad, soporte y gestión de cambios.
- Auditar al proveedor periódicamente, especialmente si es un vendor crítico cloud.
- Mantener un plan de continuidad si el vendor cesa actividad o el contrato termina.
Las cinco preguntas que un Director de Calidad debe poder responder hoy
Antes de la próxima inspección, deberías ser capaz de responder, sin dudar, estas cinco preguntas para cada sistema bajo alcance Part 11:
- ¿Cuándo fue la última validación documentada del sistema, y qué cambios desde entonces se han evaluado contra impacto Part 11?
- ¿Cuándo fue la última revisión del audit trail por Calidad, y dónde está la evidencia firmada?
- ¿Existen cuentas compartidas en el sistema, y si las hay, cuál es la justificación documentada?
- ¿Las e-signatures muestran nombre, fecha y significado en todos los puntos donde se aplican? ¿Tenemos la certificación 11.100(c) en archivo?
- ¿El último cambio al sistema pasó por evaluación de impacto Part 11, y dónde está el documento firmado?
Si alguna de las cinco respuestas no es inmediata, ahí está la primera prioridad de remediación.
Lo que hacemos en Smart Clean Solutions
En Smart Clean Solutions desarrollamos plataformas de gestión y trazabilidad para entornos farmacéuticos donde Part 11 no es una capa añadida, sino una característica estructural del sistema desde el primer día. Audit trail nativo no desactivable, autenticación por usuario único, e-signatures con los tres elementos exigidos, control de cambios con assessment Part 11 integrado en el workflow. Trabajamos contigo en la validación del sistema en tu entorno y te entregamos la documentación que el auditor va a pedirte.
Si tu planta está preparándose para una inspección Part 11 o ya ha tenido alguna observación previa que quieres cerrar definitivamente, hablemos. Te respondemos en menos de 24 horas con una primera valoración técnica del estado de tu sistema y los puntos que conviene priorizar.
Referencias normativas y fuentes:
- 21 CFR Part 11 — Electronic Records; Electronic Signatures. Code of Federal Regulations. Texto vigente en eCFR.
- FDA Guidance for Industry — Part 11 Scope and Application (versión vigente). fda.gov.
- FDA Guidance — Computer Software Assurance for Production and Quality System Software (septiembre 2025).
- EU GMP Annex 11 — Computerised Systems. European Commission. (Equivalente europeo, alineado con Part 11.)
- GAMP 5 — A Risk-Based Approach to Compliant GxP Computerized Systems. ISPE.
- ALCOA+ / ALCOA++ — Principios de integridad de datos aplicables a registros Part 11.
- FDA Warning Letters Database — Archivo público de acciones de cumplimiento.
