Flujos de trabajo normativos que funcionan a largo plazo

Un registro de desviación que requiere seis clics para pasar de producción a la aprobación QA puede igualmente fallar una auditoría si no hay forma de saber quién cambió la clasificación de riesgo, cuándo lo hizo o por qué se modificó también la ruta de aprobación. Esa es la definición práctica de cómo construir flujos de trabajo normativos: no se trata de que el mapa de procesos sea ordenado, sino de que cada decisión regulada dentro del flujo sea atribuible, explicable y reconstruible como evidencia.

En el ámbito farmacéutico y de las ciencias de la vida, eso suele significar diseñar el sistema siguiendo las mejores prácticas GxP y la norma 21 CFR Parte 11 desde la primera decisión del flujo de trabajo, y también resistirse a la tentación comprensible de añadir el cumplimiento normativo a posteriori a un flujo de trabajo de casos de Salesforce Service Cloud, una app de calidad personalizada o un asistente de IA como Claude. Los controles de enlace tardío fomentan la introducción de datos en dos sitios, las soluciones provisionales y las lagunas en el rastro de pruebas. Los controles integrados en el flujo de trabajo fomentan que lo correcto sea la opción predeterminada.

Empieza por las decisiones reguladas, no por la plataforma

Los flujos de trabajo que cumplen con las normas empiezan por la decisión regulada. En un flujo de trabajo de desviaciones GxP, eso puede ser la evaluación inicial del impacto, si se debe abrir una CAPA, la decisión de resolución por parte de Control de Calidad o si se han completado las comprobaciones de eficacia. Cada decisión tiene un responsable distinto, requisitos de documentación, normas de aprobación y requisitos de conservación.

Esta forma de plantearlo es mejor que empezar por qué formulario hay que solicitar. Un formulario es una interfaz. El flujo de trabajo es la serie de cambios de estado, permisos, marcas de tiempo, archivos adjuntos como prueba, personas encargadas de aprobar y excepciones que sustentan el formulario. Tienes que documentar qué provoca cada cambio de estado, quién está autorizado a provocarlo y qué impide que el registro pase al siguiente estado antes de tiempo.

Por ejemplo, el registro inicial de una desviación lo puede crear un operario de producción, pero solo un revisor cualificado de control de calidad puede cambiar el estado del registro de «evaluación» a «resolución». Si la clasificación de impacto es alta, puede que se requiera un segundo responsable de calidad y que no se permita cerrar la CAPA hasta que se registre una comprobación de eficacia. Estas son las reglas que no deberían aparecer en un documento de formación ni depender del criterio individual o de un correo electrónico, sino que deberían ser una lógica de flujo de trabajo que se pueda aplicar.

Aquí es donde el responsable del proceso, el responsable de calidad y el equipo de aplicaciones empresariales tienen que trabajar todos a partir del mismo documento. El responsable del proceso conoce la realidad sobre el terreno del proceso. El equipo de calidad sabe qué controles GxP se aplican. El equipo de TI sabe si la configuración de Salesforce es suficiente o si el comportamiento de la interfaz supone un riesgo o requiere software a medida.

Cómo vincular los controles a los momentos del flujo de trabajo

Las matrices de cumplimiento suelen desvincularse de la plataforma que se supone que deben regular. En cambio, resulta más práctico asignar cada control a un momento concreto del flujo de trabajo y, para cada momento, entender qué pruebas se necesitan, qué funciones están permitidas, cómo las garantiza el sistema y cuál es el resultado para la auditoría.

Podrían ser cosas como la creación del registro, un cambio en la clasificación, la asignación, la finalización de una investigación, la aprobación, la reapertura y el cierre dentro de un flujo de trabajo de calidad validado. En cuanto al 21 CFR Parte 11, las preguntas son prácticas y directas: ¿Se puede atribuir el registro a un usuario concreto? ¿Está la firma electrónica vinculada a la acción que autoriza? ¿Se guarda el valor anterior cuando cambia un campo con restricciones? ¿Puede el auditor ver todo el historial sin que un administrador tenga que copiarlo y pegarlo?

Una marca de tiempo no es un registro de auditoría. Un registro de auditoría te indica el usuario, la fecha y la hora, los valores antiguos y nuevos, y el motivo del cambio si este es significativo. Debe poder ser consultado por los revisores autorizados en la aplicación y conservarse durante el tiempo que la organización establezca para ese tipo de registro. El campo de clasificación podría modificar la matriz de aprobación, así que merece especial atención.

Todo esto también se aplica fuera del ámbito de las ciencias de la vida. En el sector de los seguros, si usas Financial Services Cloud, el flujo de trabajo de aprobación de la suscripción tiene que poder explicar por qué se aprobó una excepción y quién tenía la autoridad delegada para hacerlo. En el mantenimiento, reparación y revisión (MRO) de la aviación, un flujo de trabajo conforme a la Parte 145 de la EASA debe registrar la decisión de puesta en servicio, las pruebas de mantenimiento y la autorización del personal certificador. La normativa cambia, pero el principio de diseño sigue siendo el mismo: vincular cada control al momento exacto del flujo de trabajo en el que una decisión operativa se convierte en un registro regulado.

Diseño de flujos normativos: empieza por los controles, no por el proceso

Una vez que conozca las decisiones reguladas, diseñe el flujo de trabajo partiendo de la evidencia. ¿Qué necesita demostrar un auditor, un revisor de control de calidad o un responsable de control interno dentro de seis meses? A continuación, diseñe el modelo de datos, los permisos, las validaciones y la experiencia de usuario que permitan generar dicha evidencia durante las operaciones normales.

En Salesforce Service Cloud, esto podría consistir en utilizar tipos de registro para el tipo de desviación, listas de selección controladas para la clasificación del impacto, conjuntos de permisos para habilitar el control de calidad, procesos de aprobación para la resolución y seguimiento del historial de los campos definidos como de alto riesgo. Algunas organizaciones consiguen el comportamiento deseado con la configuración predeterminada y un flujo (Flow) regulado. Otras pueden necesitar una aplicación personalizada o una integración controlada, si su flujo de trabajo incluye sistemas de laboratorio, sistemas de ejecución de fabricación, registros de lotes o almacenamiento externo de documentos.

La configuración estándar es la mejor opción cuando permite que el proceso funcione sin que los operadores tengan que llevar registros paralelos. No lo es cuando un control crítico depende de una automatización poco fiable, del comportamiento no rastreable del middleware o de campos que los usuarios pueden saltarse mediante una integración. El desarrollo a medida debe estar justificado por un requisito específico de control o de proceso, no por el uso general de tecnología personalizada.

Cuando diseñas «al revés», se ponen de manifiesto los modelos de responsabilidad deficientes. Si necesitas que un revisor de calidad apruebe una investigación, pero las reglas de asignación envían todos los expedientes a una cola genérica, no es solo una cuestión de apariencia. Afecta a la rendición de cuentas, al tiempo de ciclo y a la capacidad de demostrar la separación de funciones. Dispón de métricas que demuestren si el flujo de trabajo se comporta tal y como se ha diseñado, como el tiempo medio desde la recepción hasta la evaluación inicial, el porcentaje de registros reabiertos tras su cierre, las comprobaciones de eficacia de las CAPA pendientes y el número de anulaciones manuales de la ruta de aprobación.

Tratar las excepciones como rutas de flujo de trabajo de primera clase

En un proceso ideal el trabajo regulado no falla, pero dista mucho de la realidad. Puede pasar que el responsable de producción necesite corregir una evaluación de impacto después de la revisión de calidad. Un aprobador requerido puede estar ausente. Una integración puede fallar al crear el registro de origen antes de transferir un adjunto. Un flujo de trabajo normativo necesita contemplar estos escenarios como parte del diseño, no como excepciones secundarias.

Eso no significa dar acceso de edición para arreglarlo todo. Significa tener integradas en el flujo de trabajo funciones controladas de reapertura, lógica de delegación, colas de corrección y temporizadores de escalado. Si un aprobador es externo, el sistema debería registrar la delegación y la acción pendiente original debería mantenerse. Si falla una interfaz, el registro debería pasar a un estado de excepción con la propiedad, la lógica de reintento y las pruebas de conciliación para volver a incorporarlo al flujo de trabajo, en lugar de desaparecer en un registro técnico.

El diseño de UX/UI es importante porque, cuando los usuarios están bajo presión, eligen el camino más corto que hay. Una pantalla de desviación en la que hay que pasar por cinco pestañas para llegar a las pruebas necesarias desanima a completar el envío del registro. Una pantalla que se adapte al contexto, que muestre los campos obligatorios según el tipo de desviación, que sepa quién es el siguiente responsable y que explique por qué se bloquea un registro, reduce los errores de formación y de introducción de datos. El objetivo no es tener una pantalla más bonita. Se trata de que haya menos registros incompletos, menos ciclos de repetición evitables y una mayor adopción del proceso controlado.

Aplicar la IA cuando el modelo de control está claro

La IA puede mejorar los flujos de trabajo que cumplen con la normativa, pero no debería tomar decisiones sin revisión en un proceso de gran impacto. En un flujo de trabajo de incidencias de calidad, un asistente de IA como Claude podría resumir una investigación, identificar temas recurrentes en las desviaciones cerradas o buscar procedimientos controlados relevantes. Un usuario cualificado debería revisar y aprobar el registro resultante, y el contexto de origen, las indicaciones, el resultado y la acción del usuario deberían quedar registrados en el sistema cuando esos elementos influyan en una decisión regulada.

La Ley de IA de la UE establece una serie de controles distintos que se aplican, sobre todo en lo que se refiere a la gestión de riesgos, la documentación, la supervisión humana y el registro de datos para los casos de uso de alto riesgo. Aunque un caso de uso no entre en la categoría de alto riesgo, las organizaciones deberían poder responder a preguntas básicas sobre qué datos se introdujeron en el modelo, qué se le permitía hacer al modelo, quién podía anularlo y cómo se supervisa el rendimiento del modelo para detectar desviaciones o recomendaciones peligrosas.

La IA es ideal para casos de uso como la clasificación, la recuperación, la síntesis y la detección de anomalías. No sirve para aprobar de forma autónoma una decisión que afecte a un lote ni para cambiar la clasificación de un registro controlado sin que antes haya una acción humana responsable. Esa distinción es de carácter operativo, no filosófico.

Un flujo de trabajo se gana la confianza cuando el operador puede seguirlo rápidamente, el equipo de calidad puede respaldarlo y el equipo de TI puede modificarlo sin introducir riesgos incontrolados. Incorpora el rastro de pruebas en el proceso, prueba las rutas de excepción con la misma rigurosidad con la que pruebas la ruta normal y haz que cada decisión automatizada sea visible para las personas responsables de ella.