Cómo una CRO califica a un proveedor de IA dentro de su propio sistema de calidad

La RFP del patrocinador ya lo pregunta. Su SGC todavía no tiene respuesta.

En algún momento de los dos últimos ciclos, una pregunta migró de la diapositiva de innovación a la sección de calificación de la RFP del patrocinador. Con pequeñas variaciones, dice así:

Describa los sistemas de inteligencia artificial o aprendizaje automático empleados en la prestación de estos servicios. Describa cómo se validan esos sistemas. Describa cómo se controlan sus salidas dentro de su sistema de gestión de la calidad. Identifique quién responde por la salida.

No es una pregunta sobre innovación. Es una pregunta de calificación de proveedores, y aterriza en la unidad de calidad, no en el área comercial. Hoy la mayoría de las CRO responde de una de dos maneras, y ambas pierden la licitación.

Las dos respuestas que pierden

La primera es la negación. «No utilizamos sistemas de IA en la prestación de estos servicios.» Hace dieciocho meses eso era defendible. Hoy el patrocinador lee esa frase como falsa o como poco competitiva, porque sabe qué están proponiendo los demás licitantes y cómo es un flujo moderno de redacción médica o de factibilidad.

La segunda es el certificado de seguridad. La CRO reenvía el informe SOC 2 o el certificado ISO 27001 del proveedor. Es un error de categoría, y el responsable de calidad del patrocinador lo detecta de inmediato. SOC 2 dice que el proveedor no perderá sus datos. No dice nada sobre si puede confiarse en la salida dentro de una presentación regulatoria. Seguridad de la información y validación de sistemas computarizados son disciplinas distintas que responden preguntas distintas, y la RFP formuló la segunda.

Por qué la unidad de calidad está genuinamente atascada

Conviene decirlo con claridad, porque la dificultad es real y no responde a falta de diligencia de nadie.

La validación de sistemas computarizados, tal como se practica bajo GAMP 5 y como la esperan los inspectores, descansa sobre una premisa antigua y del todo razonable: el sistema es determinista. Se define el requisito, se especifica el diseño, se prueban instalación, operación y desempeño, y se demuestra que la misma entrada produce la misma salida. La repetibilidad es la viga maestra. Cada artefacto del paquete de validación, cada matriz de trazabilidad, cada disparador de recalificación se apoya en ella.

Un modelo de lenguaje de gran tamaño no ofrece repetibilidad en ese sentido. La misma entrada puede producir salidas distintas. Los ajustes de temperatura y la fijación de semilla reducen la varianza, pero no convierten el sistema en determinista, y una unidad de calidad que redacta un protocolo de PQ afirmando lo contrario ha redactado un documento que no podrá defender en inspección.

Se le pide entonces a la función de calidad de la CRO que valide algo cuyo comportamiento fundamental rompe el marco mismo sobre el que se construyó la validación. No es un problema de papeleo. Es estructural, y decirle a un director de calidad que «simplemente amplíe el POE existente» no es una respuesta.

Qué está pidiendo realmente el patrocinador

Relea la pregunta y observe qué no pregunta. No pregunta si el modelo es preciso. No pide una puntuación de referencia. Pregunta cómo se controla la salida y quién responde por ella.

Esa es una pregunta sobre evidencia, no sobre el modelo.

El marco regulatorio que el patrocinador tiene en mente es aquel en el que ya vive. Bajo 21 CFR Part 11 y el Anexo 11 europeo, los registros que sustentan una decisión regulada exigen pistas de auditoría atribuibles, contemporáneas y duraderas. Bajo ALCOA+, los datos que la sustentan deben ser atribuibles, legibles, contemporáneos, originales y exactos. Bajo ICH E6(R3), el patrocinador sigue siendo responsable de los sistemas empleados en la conducción del estudio con independencia de quién los opere. Ninguno de esos marcos pregunta si el modelo es inteligente. Todos preguntan si usted puede demostrar el camino recorrido después, ante alguien hostil, años más tarde.

Este es el giro que destraba todo el problema:

Usted no valida el modelo. Valida la evidencia que el modelo produce.

Un sistema probabilístico que emite una afirmación no verificable es invalidable, y ninguna cantidad de documentación lo arregla. Un sistema probabilístico cuya salida es contrastada por un mecanismo separado e independiente antes de que un humano la vea es otro objeto. Lo que entra en su sistema de calidad no es la opinión del modelo. Es un artefacto contrastado con procedencia trazable, y los artefactos contrastados son algo que su SGC ya sabe manejar.

La verificación como capa separada

Este es el principio de arquitectura detrás del Three-Gate Verification System de NexTrial, y conviene describirlo de forma estructural y no como argumento de producto, porque la estructura es lo que la unidad de calidad de una CRO necesita evaluar.

Gate 1, jurisdicción. El conjunto de requisitos regulatorios aplicable se resuelve antes de cualquier generación. Lo que exige la FDA no es lo que exige ANVISA ni lo que exige CDSCO, y un sistema que trata la jurisdicción como filtro posterior ya produjo el artefacto equivocado. Gate 1 está diseñado para que la jurisdicción sea una restricción de entrada y no una comprobación aguas abajo.

Gate 2, prueba estructural. El artefacto generado se contrasta con la estructura de requisitos de la jurisdicción mediante un mecanismo independiente del modelo que lo produjo. El sentido de esa independencia es la evidencia no correlacionada: un modelo que contrasta su propia salida comparte los modos de falla de aquello que contrasta, y por eso las puntuaciones de autoconsistencia y los índices de confianza no son evidencia. Esta capa de prueba estructural está entregada y se encuentra en primera validación con un patrocinador. Un patrocinador es una n pequeña, y aquí se declara como n pequeña a propósito.

Gate 3, supervisión humana. El veredicto va a un humano calificado, que decide. No es una recomendación que el humano refrenda ni una automatización que el humano vigila. La decisión sigue siendo un acto humano, con la evidencia adjunta.

Una capa de verificación formal construida en Lean 4 está en desarrollo. No está en producción, y aquí no se le asocia ninguna cifra de desempeño, porque una cifra asociada a un sistema no entregado es una cifra fabricada.

Por qué esta estructura importa específicamente a una CRO: produce un artefacto que usted pone delante del auditor del patrocinador sin tener que defender el modelo. El objeto defendible es la prueba, no la predicción.

La capa jurisdiccional y por qué varía por región

Para una CRO que opera entre fronteras, tres cosas son ciertas a la vez, y cada una genera una versión distinta de la misma pregunta.

En Brasil, un patrocinador internacional bajo ANVISA enfrenta una estructura de requisitos genuinamente distinta de la estadounidense, y la CRO que lleva la ejecución local es quien debe demostrar conformidad. Codificar esa estructura, en lugar de traducir una lista de verificación estadounidense, marca la diferencia entre una presentación que pasa y una que regresa con exigencias.

En India, las obligaciones de cumplimiento de protocolo ante CDSCO para patrocinadores extranjeros conviven con un modelo de prestación que a menudo es de servicio funcional y no de servicio completo, lo que cambia quién carga con la obligación de calidad y cómo la calificación del proveedor llega hasta el patrocinador.

En Europa, la pregunta abierta es si un determinado sistema de apoyo a ensayos clínicos cae en la categoría de alto riesgo bajo el Reglamento Europeo de IA, y qué obligaciones se activan en ese caso. Esa cuestión no está resuelta para esta clase de herramienta, y cualquier proveedor que le diga lo contrario a una CRO tendrá que desdecirse después. La postura correcta es construir la documentación técnica y el registro que una clasificación de alto riesgo exigiría, y poder mostrarlos con independencia del desenlace.

Ocho preguntas para cualquier proveedor de IA

La unidad de calidad de una CRO puede enviar estas preguntas a cualquier proveedor de la categoría, incluidos nosotros. Están ordenadas para que las primeras cuatro descalifiquen rápido.

1. Cuando su sistema produce una salida, ¿qué mecanismo independiente la contrasta antes de que un humano la vea? Si la respuesta es un índice de confianza generado por el mismo modelo, no hay contraste independiente.
2. ¿Ese mecanismo de contraste está correlacionado con el modelo generador? Datos de entrenamiento, arquitectura o contexto de prompt compartidos significan puntos ciegos compartidos.
3. ¿Qué artefacto entrega su sistema a nuestro sistema de calidad, y cuál es su registro de procedencia? Usted califica el artefacto, no el software.
4. Muéstreme la pista de auditoría de una sola decisión, de principio a fin. Lo que no se pueda reconstruir a demanda no sobrevivirá a una inspección.
5. ¿Qué estructura de requisitos jurisdiccionales se aplicó, y dónde se mantiene esa codificación? Jurisdicción tratada como capa de traducción es jurisdicción mal tratada.
6. ¿Qué está entregado en su plataforma y qué está en desarrollo? Pida la respuesta con esas palabras. El tiempo verbal de la respuesta revela qué está comprando.
7. ¿Dónde se sitúa la decisión humana en su flujo, y puede omitirse? Si puede omitirse bajo presión de plazos, se omitirá.
8. ¿Qué almacena su sistema y qué no almacena nunca? Para una CRO que custodia datos del patrocinador por contrato, el límite importa más que la capacidad.

Un proveedor que responde las ocho en lenguaje llano es un proveedor que su unidad de calidad puede calificar. Un proveedor que responde con puntuaciones de referencia no entendió la pregunta.

El punto comercial

La CRO capaz de entregar al patrocinador un paquete de validación gana la licitación. No la CRO con más IA ni la que tiene menos. Gana aquella cuya unidad de calidad responde la sección de calificación sin titubear, porque esa respuesta convierte una declaración de innovación en un servicio contratable.

Esa es la demanda real. No es una compra de tecnología. Es una compra de evidencia.

Evidencia, no sustitución. El humano decide.

Preguntas frecuentes

¿Puede validarse un sistema de IA bajo GAMP 5?
El marco de validación presupone comportamiento determinista, y un modelo de lenguaje de gran tamaño no lo ofrece. El enfoque viable es validar la evidencia que el sistema produce en lugar del modelo en sí, exigiendo un mecanismo de verificación independiente entre la salida generada y la decisión humana.

¿SOC 2 o ISO 27001 responden a la pregunta de calificación de IA de un patrocinador?
No. Esas certificaciones abordan la seguridad de la información. La pregunta de calificación del patrocinador aborda si puede confiarse en la salida dentro de una decisión regulada, lo cual es una cuestión de validación de sistemas computarizados y no de seguridad.

¿Quién responde por una salida de IA en un ensayo clínico bajo ICH E6(R3)?
La responsabilidad por los sistemas empleados en la conducción del estudio permanece en el patrocinador con independencia de quién los opere, y por eso la evidencia de calificación de proveedores de la CRO repercute en la preparación para inspección del propio patrocinador.

¿Qué es la evidencia no correlacionada?
Verificación producida por un mecanismo que no comparte la arquitectura, los datos de entrenamiento ni el contexto del modelo generador. Los contrastes correlacionados reproducen el error original, y por eso el índice de confianza de un modelo no acredita su corrección.

¿Qué debe preguntar primero una CRO a un proveedor de IA?
Qué mecanismo independiente contrasta la salida antes de que un humano la vea. Si no existe, las demás preguntas dejan de importar.