Un agente de IA puede leer una nota de llamada, extraer los cuatro criterios mínimos de un informe de alta y redactar un informe individual de seguridad del caso (ICSR) en minutos. La cuestión de diseño es qué puede terminar el agente por sí solo. La gravedad, el carácter esperado, la codificación, el día en que empezó el plazo y la decisión de notificar tienen peso regulatorio, y un error en cualquiera de ellos puede pasar inadvertido hasta que un inspector compara los documentos fuente con la base de datos de seguridad. Este artículo recorre un caso sintético a través de una revisión gobernada: los documentos fuente, el caso que prepara el agente, las comprobaciones que se ejecutan antes de escribir nada, la decisión del revisor de seguridad y el registro que queda. Es un diseño práctico basado en nuestro blueprint publicado de farmacovigilancia. KLA no tiene ningún cliente farmacéutico, y nada de lo que aquí se expone describe un despliegue.
Las normas que el diseño debe respetar
Las normas de la UE sobre notificaciones individuales de casos están en el módulo VI de las GVP, revisión 2, que la EMA recoge como vigente desde el 22 de noviembre de 2017 en su página de las GVP. Cuatro puntos condicionan cualquier diseño con agentes.
Validez. La sección VI.B.2 exige cuatro criterios mínimos para que una notificación se considere un ICSR: un notificador identificable, un único paciente identificable, al menos un medicamento sospechoso y al menos una reacción adversa sospechosa. Una notificación a la que le falte alguno está incompleta; la organización debe hacer su seguimiento con la diligencia debida y registrarla igualmente para la evaluación de la seguridad.
Día cero. La sección VI.B.7 inicia el plazo cuando los criterios mínimos llegan a «any personnel of the marketing authorisation holder, including medical representatives and contractors» (traducción no oficial: cualquier miembro del personal del titular de la autorización de comercialización, incluidos los visitadores médicos y los contratistas). Los plazos se cuentan en días naturales, fines de semana y festivos incluidos. En virtud del artículo 107, apartado 3, y del artículo 107 bis, apartado 4, de la Directiva 2001/83/CE, los ICSR graves y válidos se envían a EudraVigilance en un plazo de 15 días y los no graves en un plazo de 90 días (sección VI.C.3).
Gravedad. La sección VI.A.1.6 adopta la definición de ICH E2A: muerte, riesgo vital, hospitalización o prolongación de la hospitalización, discapacidad o incapacidad persistente o significativa, o anomalía congénita, además de los acontecimientos médicamente importantes que se consideren graves. La sección VI.B.2 añade que la gravedad «should not be downgraded from serious to non-serious if the notified recipient disagrees with the seriousness reported by the primary source» (traducción no oficial: no debe rebajarse de grave a no grave si el destinatario notificado no está de acuerdo con la gravedad comunicada por la fuente primaria).
Responsabilidad sobre la IA. El documento de reflexión de la EMA sobre la IA en el ciclo de vida de los medicamentos (9 de septiembre de 2024) prevé que la IA apoye «adverse event report management and signal detection» (traducción no oficial: la gestión de las notificaciones de acontecimientos adversos y la detección de señales) de conformidad con las GVP, y afirma que «it remains the responsibility of the MAH to validate, monitor and document model performance and include AI/ML operations in the pharmacovigilance system» (traducción no oficial: sigue siendo responsabilidad del TAC validar, supervisar y documentar el rendimiento del modelo e incluir las operaciones de IA/ML en el sistema de farmacovigilancia). El grupo EMA–FDA sobre IA en farmacovigilancia (versión 2, 2 de marzo de 2026) incluye entre sus casos de uso el procesamiento de casos, el cribado de la literatura, la eliminación de duplicados y las comprobaciones de exhaustividad de los ICSR, y entre sus temas «large language models and agentic AI» (traducción no oficial: los grandes modelos de lenguaje y la IA agéntica). El CIOMS publicó el informe de su Grupo de Trabajo XIV sobre IA en farmacovigilancia el 4 de diciembre de 2025; léalo junto con las GVP para la terminología y los principios.
Dónde trazamos el límite y por qué
Redactamos estos límites por primera vez cuando diseñamos una demostración guiada de seguimiento de la literatura para una empresa farmacéutica europea en la primavera de 2026. El encargo de diseño situaba la supervisión humana en el centro: la persona cualificada responsable de farmacovigilancia (QPPV) y los médicos de seguridad conservan las decisiones reguladas, y el sistema hace explícita su supervisión en la política, la aplica en el enrutamiento y la deja visible en el registro.
Agrupamos el trabajo en cohortes según el riesgo. En las cohortes de bajo riesgo, el agente puede ejecutar búsquedas aprobadas, recuperar documentos, solicitar traducciones y crear el esqueleto de un caso. Para un caso candidato a válido puede redactar los hechos del caso y proponer a un revisor los términos MedDRA, la gravedad, la causalidad y el carácter esperado. En un caso grave, inesperado, con sospecha de duplicado o de codificación ambigua, un revisor médico ve todos los casos. La lista de prohibiciones absolutas se mantuvo corta:
- El agente no rebaja la gravedad evaluada por el notificador (módulo VI de las GVP, VI.B.2).
- El agente no fija la codificación MedDRA definitiva en las cohortes con prohibición absoluta.
- El agente no toma la decisión definitiva sobre el carácter esperado.
- El agente no fusiona definitivamente duplicados cuando difieren campos relevantes.
- El agente no realiza notificaciones ni comunicaciones con autoridades o socios. En el diseño, estas herramientas no forman parte del conjunto de herramientas del agente.
El caso sintético: documentos fuente
Todo en este caso es inventado: la empresa, el producto «Examplazole 20 mg», las personas y las horas. Las posiciones del plazo usan números de día para que la aritmética sea fácil de seguir.
| Documento | Recibido por | Cuándo | Contenido relevante |
|---|---|---|---|
| Nota de llamada de información médica | Línea de información médica (contratista de la empresa) | Día 0, viernes 18:40 | Un farmacéutico comunitario informa de que una mujer de 67 años «se quedó ingresada una noche» por sodio bajo nueve días después de empezar a tomar Examplazole 20 mg. Se registran el nombre, la cualificación y el país del notificador. |
| Correo reenviado al buzón de seguridad | Equipo de farmacovigilancia | Día 3, lunes 08:15 | La misma nota de llamada, reenviada después del fin de semana. |
| Informe de alta | Equipo de farmacovigilancia, remitido por el farmacéutico | Día 4 | Ingreso de una noche, sodio sérico de 124 mmol/l, Examplazole suspendido, sodio normal al alta. |
| Ficha técnica del producto (SmPC), versión 7 | Repositorio de fichas técnicas | Versión vigente el día 0 | La hiponatremia no figura. |
Qué prepara el agente
El agente lee los tres documentos del caso y la ficha técnica. Cada campo extraído conserva un puntero al documento y al pasaje del que procede, de modo que el revisor puede contrastar un valor con su fuente en un solo paso. En KLA, Document Intake adjunta a la ejecución del Process los documentos, los campos aprobados y su procedencia.
El borrador del caso del agente: los cuatro criterios mínimos presentes; gravedad propuesta como grave por el criterio de hospitalización, citando «se quedó ingresada una noche» y el ingreso que recoge el informe de alta; término de nivel más bajo de MedDRA propuesto, «Hiponatremia»; carácter esperado propuesto como inesperado frente a la SmPC versión 7; causalidad pendiente del revisor. Su primera propuesta de día cero fue el día 3, el momento en que el correo llegó al buzón de seguridad.
Las comprobaciones que se ejecutan antes de escribir nada
Cada escritura propuesta pasa por un punto de control de políticas antes de llegar a la base de datos de seguridad. El punto de control devuelve uno de cuatro resultados: allow, warn, require_approval o block. En este caso se activaron cuatro comprobaciones.
| Acción propuesta | Regla | Resultado | Qué ocurrió |
|---|---|---|---|
| Marcar el caso como válido | Los cuatro criterios mínimos presentes, cada uno con una referencia a la fuente | allow | Caso marcado como válido; las referencias a las fuentes se guardan con la decisión. |
| Fijar el día cero en el día 3 | El día cero es la primera recepción por cualquier miembro del personal, incluidos los contratistas (VI.B.7) | warn | El agente lo contrastó con el registro de llamadas y cambió el día cero al día 0. La fecha límite pasó del día 18 al día 15. |
| Cambiar la gravedad a no grave tras el informe de alta | No se rebaja la gravedad evaluada por el notificador (VI.B.2) | block | La gravedad sigue siendo grave. El agente anotó en la narrativa el sodio normal al alta. |
| Notificar el ICSR | La notificación de un caso grave requiere un revisor de seguridad designado | require_approval | Se abrió una Decision Request en Decision Desk para el revisor de seguridad de guardia, con la fecha límite visible. |
Decide el revisor de seguridad
El revisor de seguridad abre la Decision Request el día 4. La solicitud muestra el borrador del caso, el pasaje fuente de cada campo, los cuatro resultados de las políticas y el tiempo restante del plazo. El revisor confirma la gravedad por el criterio de hospitalización y confirma el carácter inesperado frente a la SmPC versión 7. Mantiene el término de nivel más bajo «Hiponatremia», evalúa la causalidad como posiblemente relacionada, modifica una frase de la narrativa y registra el motivo. Después aprueba la notificación.
Un rechazo tiene el mismo peso en el registro. Si el revisor hubiera considerado el caso no válido o la codificación incorrecta, la ejecución terminaría sin notificación y el registro conservaría el motivo del revisor. Un caso que requiere seguimiento vuelve a la cola de procesamiento de casos con las preguntas abiertas adjuntas.
La notificación y el registro que queda
Tras la aprobación, la ejecución se reanuda en el paso en pausa. La herramienta de notificación llama a la base de datos de seguridad de la empresa, que genera el mensaje E2B(R3) y lo envía a EudraVigilance. El agente nunca tiene esa herramienta. La base de datos de seguridad y su conexión con la pasarela siguen siendo sistemas validados de la empresa; la ejecución gobernada registra lo que se les pidió y lo que devolvieron.
| Campo | Valor registrado |
|---|---|
| Documentos fuente | Nota de llamada, correo reenviado, informe de alta, SmPC versión 7, cada uno con un hash de contenido |
| Campos extraídos | Notificador, paciente, producto, reacción, fechas, cada uno vinculado a su pasaje fuente |
| Propuestas del agente | Validez, gravedad, término MedDRA, carácter esperado, día cero (valor inicial y corregido) |
| Resultados de las políticas | Versión de la política, regla, resultado y motivo de cada una de las cuatro comprobaciones |
| Decisión humana | Identidad y función del revisor, hora, decisión, evaluación de la causalidad, modificación de la narrativa y motivo |
| Notificación | Llamada a la herramienta, hora de la solicitud, referencia del caso en la base de datos de seguridad y estado del acuse de recibo |
| Plazo | Día cero, fecha límite, día de la notificación |
| Integridad | Identificador del Lineage Record; la ejecución puede exportarse como Sealed Evidence Bundle |
Qué no cubre este diseño
No valida nada. La validación de sistemas informatizados, el seguimiento del rendimiento de los modelos y el sistema de calidad siguen siendo tarea del titular de la autorización de comercialización, como indica el documento de reflexión de la EMA. Una ejecución gobernada añade a ese trabajo un registro completo por caso.
No resuelve la clasificación con arreglo al Reglamento de IA. El procesamiento de casos de farmacovigilancia no figura entre los casos de uso del anexo III, por lo que, para la mayoría de los titulares de autorizaciones de comercialización, las normas vinculantes de este flujo de trabajo proceden de la legislación de farmacovigilancia. Compruebe la clasificación de su propio sistema.
No abarca la gestión de señales, los informes periódicos ni el diseño de búsquedas bibliográficas. Requieren sus propios límites, y el blueprint solo cubre la recepción y el procesamiento de casos.
Preguntas frecuentes
¿Puede un agente de IA notificar un ICSR a EudraVigilance por sí solo?
El titular de la autorización de comercialización sigue siendo responsable de cada notificación que presenta. En el diseño descrito, el agente no dispone de herramienta de notificación; un revisor de seguridad designado aprueba la notificación y la base de datos de seguridad de la empresa la envía.
¿Cuándo empieza el día cero de una notificación de acontecimiento adverso?
Módulo VI de las GVP, sección VI.B.7: cuando los criterios mínimos llegan al centro nacional o regional de farmacovigilancia de una autoridad competente o a cualquier miembro del personal del titular de la autorización de comercialización, incluidos los visitadores médicos y los contratistas. Los plazos se cuentan en días naturales.
¿Qué decisiones de farmacovigilancia deben quedar en manos de un revisor humano?
En nuestro diseño: cualquier rebaja de la gravedad evaluada por el notificador, la codificación MedDRA definitiva en casos graves, inesperados o ambiguos, el carácter esperado definitivo, las fusiones de duplicados cuando difieren campos relevantes, y toda notificación o comunicación con autoridades y socios.
¿Un plano de control en tiempo de ejecución convierte una herramienta de IA en validada conforme a GxP?
No. La validación del sistema y el seguimiento del rendimiento del modelo siguen siendo responsabilidad del titular de la autorización de comercialización. Un plano de control aplica el límite de revisión y registra cada decisión, lo que aporta al trabajo de validación e inspección su evidencia a nivel de caso.
¿Ha desplegado KLA este diseño en alguna empresa farmacéutica?
No. Es un diseño práctico basado en nuestro blueprint publicado de farmacovigilancia y en un caso sintético. KLA no tiene ningún cliente farmacéutico.
Conclusiones clave
En farmacovigilancia, el trabajo útil del agente es la preparación: leer las fuentes, extraer los criterios mínimos con su procedencia, redactar el caso y proponer las evaluaciones médicas. Las decisiones reguladas quedan en manos de un revisor designado, y el plazo se calcula desde la primera recepción por cualquier persona que trabaje para la empresa. Un diseño gobernado plasma esas reglas como política, detiene al agente en cada límite y conserva un registro por caso que un inspector puede seguir desde el documento fuente hasta la notificación. Lea el blueprint de farmacovigilancia para ver el conjunto completo de controles, consulte cómo demostrar qué leyó un agente antes de actuar y vea KLA para el sector farmacéutico.
Fuentes: EMA, Guideline on good pharmacovigilance practices Module VI Rev 2 (EMA/873138/2011 Rev 2); EMA, Reflection paper on the use of AI in the medicinal product lifecycle (EMA/CHMP/CVMP/83833/2023); EMA y FDA de EE. UU., Guiding principles for the cluster teleconferences on AI in pharmacovigilance (EMA/422032/2023, versión 2); Grupo de Trabajo XIV del CIOMS. El caso es sintético. KLA no está afiliada a la EMA, la FDA ni el CIOMS, ni cuenta con su respaldo o certificación.