O agente da Tulip monta apps de fábrica após o engenheiro aprovar o plano. Em plantas GxP, isso é o produto
O AI Authoring da Tulip planeja apps de manufatura a partir de SOPs, rascunha mudanças após aprovação do engenheiro e traz agentes de revisão e apps em código para GxP. Nada disso está em GA ainda.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.

Numa planta que fabrica medicamentos ou dispositivos médicos, o app que o operador usa para registrar uma etapa do lote faz parte de um sistema validado. Mudar um campo, uma checagem ou a ordem de duas etapas é uma mudança controlada, com motivo, revisão e registro. Um agente de IA que edita esses apps só é útil se cabe nessa disciplina.
A Tulip, cuja plataforma de operações roda apps no chão de fábrica de muitas indústrias, anunciou o AI Authoring em 9 de outubro, na conferência Operations Calling, em Boston. As escolhas de desenho dizem muito sobre como agentes precisam ser na manufatura regulada.
Quatro peças, nenhuma em disponibilidade geral
O anúncio tem quatro partes, cada uma num estágio diferente:
- Projects propõe um plano para um fluxo de valor, uma linha ou um processo a partir do material que o time já tem: SOPs, layouts, documentos de processo, apps existentes, bibliotecas e boas práticas. Está entrando em testes com clientes.
- O Authoring Agent, um painel de chat no editor de apps, rascunha apps novos e mudanças nos existentes a partir de um SOP enviado ou de uma descrição do processo, sobre o modelo de dados que o time já usa. Também entrando em testes com clientes.
- Composable AI Agents dão aos revisores uma primeira passada em testes, documentação e avaliação. Beta aberto.
- Code-Based Apps permitem que engenheiros construam apps na própria IDE com agentes de código e os rodem na Tulip, como versões congeladas e totalmente auditadas que a Tulip diz serem “projetadas para ambientes GxP”. Preview, com parceiros de design.
Essa dispersão importa para o planejamento. Nada disso deve entrar num ambiente validado como se estivesse pronto.
O plano é o primeiro registro controlado
A frase mais importante do anúncio é sobre o que o agente não faz: “Nada muda até que o engenheiro aprove.” O Authoring Agent faz perguntas de esclarecimento, propõe um plano de construção e só depois da aprovação rascunha as mudanças, que o engenheiro revisa uma a uma, com a opção de assumir no editor e a palavra final sobre o que é publicado.
Em termos regulatórios, o plano aprovado tem valor por si só. Ele diz o que vai mudar, por quê e com base em qual SOP, antes de qualquer mudança existir. Esse é o formato de uma solicitação de mudança e, se a plataforma o guardar, o plano vira evidência em vez de histórico de chat. A pergunta a fazer à Tulip é exatamente essa: o plano, os rascunhos do agente e as edições do engenheiro ficam retidos como um registro revisável, ligado à versão publicada?
É o padrão que descrevemos em agentes como autores de mudanças em produção: o controle para o que o agente produz já existe, e na manufatura ele tem nome, controle de mudanças. Um agente que produz um plano antes de produzir uma mudança se encaixa nele naturalmente.
Agentes de revisão ajudam; não assinam
Os Composable AI Agents são posicionados como uma primeira passada para revisores em testes, documentação e avaliação. É um uso razoável, com um limite que vale manter explícito. Num processo validado, a revisão que conta é feita e assinada por uma pessoa qualificada; um agente pode prepará-la, apontar lacunas e rascunhar documentação, mas não pode ser a evidência de que o app está apto para uso. Como dissemos, na IA regulada a prova vem de fora do modelo.
Apps em código trazem perguntas de cadeia de suprimentos de software
Os Code-Based Apps abrem a Tulip para código escrito com agentes externos, na IDE do próprio engenheiro. As versões congeladas e auditadas atendem parte da exigência regulatória. O resto é a pergunta conhecida de software: qual agente escreveu qual código, ao que ele tinha acesso e como esse código foi testado antes de chegar ao chão de fábrica. Essas perguntas pertencem ao plano de validação, não a depois dele.
A Tulip não descreve um processo de validação em detalhe, e nenhum dos quatro componentes está em disponibilidade geral, então os fabricantes regulados têm tempo para fazer as perguntas certas. A direção do desenho está certa: plano primeiro, aprovação antes da mudança, revisão humana na publicação. O trabalho de validação continua sendo seu.