El agente de Tulip crea apps de planta tras la aprobación del ingeniero. En GxP, esa aprobación es el producto

En una planta que fabrica medicamentos o dispositivos médicos, la app que un operador usa para registrar un paso de lote forma parte de un sistema validado. Cambiar un campo, una comprobación o el orden de dos pasos es un cambio controlado, con un motivo, una revisión y un registro. Un agente de IA que edita ese tipo de apps solo es útil si encaja en esa disciplina.

Tulip, cuya plataforma de operaciones de primera línea ejecuta apps en muchas plantas de fabricación, anunció AI Authoring el 9 de octubre en su conferencia Operations Calling, en Boston. Las decisiones de diseño dicen mucho sobre cómo deben ser los agentes en la fabricación regulada.

Cuatro piezas, ninguna con disponibilidad general (GA)

El anuncio tiene cuatro partes, cada una en una fase distinta:

• Projects propone un plan para un flujo de valor, una línea o un proceso a partir del material existente de un equipo: SOP, planos, documentos de proceso, apps existentes, librerías y buenas prácticas. Entra en pruebas con clientes.
• Authoring Agent, un panel de chat en el editor de apps, redacta apps nuevas y modifica las existentes a partir de un SOP cargado o una descripción de proceso, sobre el modelo de datos existente del equipo. También entra en pruebas con clientes.
• Composable AI Agents dan a los revisores una primera pasada sobre pruebas, documentación y evaluación. Beta abierta.
• Code-Based Apps permiten a los ingenieros crear apps en sus propios IDE con agentes de codificación de IA y ejecutarlas en Tulip, como versiones congeladas y totalmente auditadas que, según Tulip, están “diseñadas para entornos GxP”. Preview, con socios de diseño.

Esa dispersión importa para la planificación. Nada de esto debería entrar en un entorno validado como si estuviera terminado.

El plan es el primer registro controlado

La frase más importante del anuncio es sobre lo que el agente no hace: “Nada cambia hasta que el ingeniero lo aprueba.” El Authoring Agent hace preguntas de aclaración, propone un plan de construcción y solo después de la aprobación redacta los cambios, que el ingeniero revisa uno a uno, con la opción de tomar el control en el editor y la última palabra sobre lo que se publica.

En términos regulados, el plan aprobado tiene valor por sí mismo. Indica qué cambiará, por qué y sobre la base de qué SOP, antes de que exista ningún cambio. Esa es la forma de una solicitud de cambio y, si la plataforma lo conserva, el plan se convierte en evidencia en lugar de historial de chat. La pregunta que hay que hacerle a Tulip es precisamente esa: ¿se conservan el plan, los borradores del agente y las ediciones del ingeniero como un registro revisable vinculado a la versión publicada?

Este es el patrón que describimos en agentes como autores de cambios en producción: el control para la salida de los agentes ya existe y, en la fabricación, tiene un nombre: control de cambios. Un agente que produce un plan antes de producir un cambio encaja en él de forma natural.

Los agentes de revisión asisten; no firman

Composable AI Agents se plantean como una primera pasada para los revisores sobre pruebas, documentación y evaluación. Es un uso razonable, con un límite que conviene mantener explícito. En un proceso validado, la revisión que cuenta la realiza y firma una persona cualificada; un agente puede prepararla, señalar carencias y redactar documentación, pero no puede ser la evidencia de que la app es apta para su uso. Como lo expresamos en IA regulada, la prueba viene de fuera del modelo.

Las apps basadas en código traen preguntas de cadena de suministro de software

Code-Based Apps abren Tulip a código escrito con agentes de codificación externos en los IDE de los propios ingenieros. Las versiones congeladas y auditadas cubren parte del requisito regulado. El resto es la conocida pregunta del software: qué agente escribió qué código, a qué se le permitió acceder y cómo se probó ese código antes de llegar a la planta. Esas preguntas pertenecen al plan de validación, no a después.

Tulip no describe un proceso de validación en detalle y ninguno de los cuatro componentes tiene disponibilidad general (GA), así que los fabricantes regulados tienen tiempo para hacer las preguntas correctas. La dirección de diseño es correcta: primero el plan, aprobación antes del cambio y revisión humana en la publicación. El trabajo de validación sigue siendo suyo.