Consigo desenvolver um LIMS com IA?

Se você coordena um laboratório e já pediu a uma IA “me faça uma tela de cadastro de amostra”, conhece a sensação: em quinze minutos aparece algo que funciona. Campos, botões, uma tabela, um PDF. Funciona de verdade. E vem a pergunta inevitável — se em quinze minutos eu chego até aqui, por que eu pagaria por um sistema?

A pergunta é legítima e eu não vou respondê-la com medo. Trabalho com Sistemas de Gerenciamento de Informações de Laboratórios (LIMS) há mais de vinte anos, estou construindo agora a próxima geração da nossa plataforma justamente em cima de IA agêntica, e a última coisa que eu faria é argumentar que IA não serve para desenvolver software de laboratório. Serve, e muito.

A resposta honesta é: sim, você consegue construir. O que a IA ainda não te entrega é a capacidade de sustentar. E em laboratório, sustentar não é detalhe operacional — é o produto. Um LIMS não é medido pelo que faz no dia em que tudo dá certo. É medido pelo que consegue provar no dia em que algo dá errado, dois anos depois, na frente de um auditor, com o analista que fez a análise já desligado da empresa.

O que a IA realmente resolve hoje — e é muito mais do que se admite

Começo pelas concessões, porque elas são grandes e quem finge que não são está sendo desonesto.

A IA colapsou o custo de produzir código. Tarefas que consumiam semanas de um desenvolvedor experiente saem em uma tarde: uma tela com validação de campo, um parser que lê a saída de um cromatógrafo e devolve linhas estruturadas, um relatório em PDF com o cabeçalho do laboratório, uma consulta SQL cruzando amostras por período e cliente.

Mais que isso: ela derrubou a barreira de entrada. Um supervisor de qualidade que nunca programou automatiza hoje o que antes exigia abrir chamado na TI e esperar três meses na fila. Isso é uma mudança real de poder dentro do laboratório, e é boa. Eu incentivo.

E tem um efeito menos óbvio, talvez o mais valioso: a IA é excelente ferramenta de descoberta de requisito. Construir um protótipo em dois dias força você a explicitar decisões que estavam implícitas na cabeça de três pessoas do time. Quantos dígitos significativos esse resultado tem? O que acontece quando a amostra chega sem lacre? Quem pode reprovar um lote? Nenhum documento de processo revela isso tão rápido quanto um protótipo obrigando você a escolher.

Então o argumento não é “a IA não dá conta”. É que essas conquistas todas moram na parte mais barata do problema.

Onde o protótipo encontra o laboratório real

Existe uma assimetria cruel no software de laboratório: a parte que aparece na tela é 20% do trabalho, e a parte que ninguém vê é a que decide se o sistema sobrevive. O protótipo que a IA entrega em uma tarde é o topo do iceberg. Abaixo dele estão oito problemas que não são de código — são de regime.

1. O registro precisa ser defensável, não apenas correto

Uma planilha ou um HTML solto guarda o valor final. Um LIMS guarda a história do valor.

A ISO/IEC 17025:2017 é explícita: registros técnicos precisam permitir a reconstrução da atividade, e qualquer emenda tem que ser rastreável — valor anterior preservado, quem alterou, quando e por quê (7.5). A seção 7.11 exige que o sistema de gestão da informação seja validado quanto à funcionalidade antes do uso e após qualquer mudança. Em farmacêutico e alimentos, isso ainda encontra o 21 CFR Part 11 e o padrão ALCOA.

Traduzindo para uma segunda-feira de manhã: quando o auditor aponta um resultado no laudo e pergunta “esse número foi alterado depois da primeira digitação?”, a resposta não pode ser “acho que não”. Tem que ser uma tela, em dez segundos, mostrando que foi digitado 12,4 às 9h14 pela analista X, corrigido para 12,7 às 11h02 pelo supervisor Y com a justificativa “erro de transcrição, conferido contra o registro bruto do equipamento” — e que o valor original nunca deixou de existir.

Isso não é funcionalidade. É decisão de arquitetura tomada antes da primeira tela: o sistema não armazena estados, armazena eventos. É a diferença entre uma foto e um filme — e você não converte foto em filme depois. Reescreve.

2. Validação: quem valida o software que a IA escreveu?

Aqui está o ponto que quase todo mundo ignora e que costuma matar o projeto meses depois de ele parecer pronto.

Software usado em atividade acreditada precisa de evidência documental de que faz o que diz fazer. Na prática de indústrias que seguem o GAMP 5, software configurável de mercado cai na Categoria 4; software feito sob medida cai na Categoria 5 — o nível de maior esforço de validação que existe, com especificação funcional, matriz de rastreabilidade de requisitos e evidência de teste executado para cada requisito.

Ao decidir construir o próprio LIMS, você não escolheu apenas escrever código: se colocou voluntariamente no nível mais caro do espectro de validação. E esse esforço não diminui por a IA ter escrito o código — ele aumenta, porque não existe histórico de uso do produto em outros laboratórios, nem fornecedor auditável, nem documentação de ciclo de vida para referenciar.

Não é impossível. É que o custo real do “eu faço com IA” não é o custo de fazer, é o custo de provar. E provar é justamente o que a IA não faz por você, porque evidência de validação não é artefato de software: é artefato de processo.

3. Cada prompt novo é um deploy sem controle de mudança

Esse é o problema mais silencioso, e o que eu vejo com mais frequência.

Você validou sua telinha em março. Em abril, alguém pede um campo novo: volta na IA, pede o ajuste, cola o código, funciona. Em maio muda a regra de arredondamento de um ensaio — mesmo caminho. Em junho um cliente novo exige outro formato de certificado — mesmo caminho.

Em setembro, ninguém no laboratório responde três perguntas básicas: qual versão está rodando, o que mudou desde a validação, e quem aprovou cada mudança. A trilha do dado talvez exista. A trilha do sistema não — e ela é exigida com o mesmo rigor, porque um sistema que muda sem controle invalida a validação anterior.

Plataforma tem versionamento, changelog, ambiente de homologação separado do de produção e um fornecedor que assume dizer “a versão 8.4 mudou este comportamento”. Construção artesanal tende a ter um único ambiente — produção — e um histórico que mora no chat de quem fez.

4. O erro que não aparece: cálculo, unidade, arredondamento e regra de aprovação

Software de laboratório erra de um jeito específico e perigoso: erra em silêncio, com aparência de acerto.

Um resultado não é um número. É valor, unidade, método, versão do método, limite de quantificação, incerteza associada, casas decimais definidas pela norma do ensaio, arredondamento na regra correta e comparação contra a especificação vigente na data da análise. Erre qualquer um desses e a tela continua bonita, o PDF continua saindo, o cliente continua recebendo o laudo — e o resultado está errado.

O padrão clássico: um valor de 0,0499 mg/L arredondado para 0,05 numa especificação de “máximo 0,05”, com o sistema aprovando o lote quando a regra do método manda comparar antes de arredondar. Erro de uma linha. Consequência de recall.

A IA gera esse código exatamente como você pediu. E o problema é que você não sabe pedir o que não sabe que existe. Esse conhecimento — as duas mil regrinhas de domínio que só aparecem em produção, com cliente reclamando — não está no prompt. Está na cicatriz.

5. Concorrência: o problema que só aparece quando há trinta pessoas

Protótipo é testado por uma pessoa por vez. Laboratório não funciona assim.

Dois analistas abrem a mesma amostra em duas abas. Um lança o pH, o outro a condutividade, os dois salvam. Sem controle de transação e de concorrência, o segundo save sobrescreve o primeiro e o pH simplesmente desaparece — sem erro, sem aviso, sem log. O supervisor aprova o laudo e três dias depois alguém pergunta onde foi parar o pH.

Não é hipótese: é o comportamento padrão de praticamente qualquer código gerado sem que se peça explicitamente controle de concorrência — lê, altera em memória, grava por cima. Resolve-se com transação, isolamento adequado, controle otimista de versão de registro e índices pensados para o padrão de acesso real. A IA implementa isso muito bem — desde que alguém saiba que precisa ser pedido, e saiba testar sob acesso simultâneo.

6. O dado precisa viver mais que o projeto

Registro de laboratório tem retenção medida em anos, às vezes uma década. Isso muda a natureza do problema.

Backup não é a parte difícil. A parte difícil é restore testado — backup não verificado é uma crença, não um controle. Depois vem migração de esquema: quando você precisar adicionar um campo obrigatório em 2029, o que acontece com os 400 mil registros de 2026 que não têm esse campo? E reprodutibilidade: o certificado emitido em 2027 tem que continuar reproduzível em 2032, com a especificação, a assinatura e o layout daquela época — não com os de hoje.

Nada disso aparece no protótipo. Tudo isso aparece no ano três.

7. Segregação de funções não é uma tela de login

Controle de acesso em laboratório não é “usuário e senha”. É o desenho de quem pode fazer o quê e, principalmente, de quem não pode.

Quem lança o resultado não pode ser quem aprova. Quem aprova não altera resultado aprovado sem gerar revisão rastreável. Quem administra o sistema não deveria conseguir editar registro técnico direto na base. Quem emite o certificado precisa de assinatura eletrônica atribuível a uma pessoa — não a um login compartilhado do setor.

Isso é modelagem de permissão em cima do modelo de domínio, não uma camada colada depois. E quando há dado pessoal envolvido, entra também a LGPD, com base legal, minimização e retenção — dimensão que já detalhamos em LGPD e proteção de dados no laboratório.

8. A dependência de uma pessoa

Este é o item que mais me preocupa nas conversas com laboratórios que trilharam esse caminho.

O sistema construído com IA quase sempre é obra de uma pessoa entusiasmada — o analista que gosta de tecnologia, o supervisor curioso, o filho do dono que estuda engenharia. Funciona, melhora a vida do time, e cria um ponto único de falha humano que ninguém contabilizou.

Quando essa pessoa sai, entra de férias na semana da auditoria ou muda de área, ninguém mais entende o sistema. Não há documentação de arquitetura, não há segunda pessoa que saiba onde as regras estão escritas, e o histórico de decisões está num chat privado. O laboratório descobre que terceirizou sua operação crítica para um indivíduo, não para um fornecedor com contrato e responsabilidade. É o oposto de robustez organizacional — e é achado de auditoria em qualquer sistema de gestão sério.

O custo real dos “vários HTMLs soltos”: entropia

Existe uma versão específica desse caminho que merece nome próprio, porque é a mais comum: em vez de um sistema, o laboratório acaba com uma constelação de artefatos. Uma tela de cadastro aqui, uma planilha de cálculo lá, um script de relatório, um formulário de recebimento, um dashboard, um segundo formulário que alguém fez porque não sabia do primeiro.

Cada peça funciona. O conjunto não é um sistema — é entropia.

O sintoma clássico: o mesmo dado passa a existir em três lugares com três valores diferentes e ninguém sabe qual é o verdadeiro, porque nunca foi tomada uma decisão sobre qual é a fonte da verdade. Não há transação atravessando as peças, então “amostra recebida” pode estar marcada num artefato e não no outro. Não há trilha consolidada, então provar o histórico de um dado exige juntar evidência de quatro lugares com relógios diferentes. E não há integridade referencial: apaga-se um cliente na tela A e ficam 300 amostras órfãs apontando para o nada.

Esse custo tem a mesma natureza do que já discutimos em quanto custa não migrar de um LIMS antigo ou planilha: diluído, invisível, nunca aparece como linha de fatura. Com uma agravante — a sensação de que o problema está resolvido, o que impede a decisão de resolvê-lo de verdade.

Onde construir com IA faz total sentido — e onde não

Aqui está o critério que eu realmente uso, e ele não é “compre em vez de construir”. É uma pergunta única:

Esse artefato guarda registro, ou apenas manipula registro?

Se o artefato pode ir para o lixo amanhã sem que o laboratório perca registro legal, rastreabilidade ou capacidade de responder a um auditor — construa com IA, hoje, sem culpa. Nessa categoria de ferramenta de conveniência, a IA é imbatível em custo e velocidade. Cabem nela, com folga:

• Parsers e conversores de instrumento. Ler o TXT esquisito do espectrofotômetro e devolver CSV estruturado: saída auditável contra o arquivo original, script descartável, ganho imediato.
• Dashboards de leitura. Prazo de entrega, carga por analista, evolução de indicador. Consome dado de uma fonte confiável e não é fonte de nada.
• Conferência e reconciliação. Script que compara duas planilhas e aponta divergência, ou valida se todo laudo do mês tem certificado de calibração vigente por trás.
• Automação administrativa e cálculos auxiliares. Organizar arquivo, montar e-mail de envio de laudo, planilha de incerteza, estudo de capacidade sobre dado já consolidado.
• Protótipo de requisito. Construir a tela que você quer para mostrar ao fornecedor o comportamento exato que o laboratório precisa. Vale ouro numa implantação.

E o que não cabe: qualquer coisa que se torne o lugar onde o resultado mora, onde a aprovação acontece, onde o certificado nasce, onde a trilha vive. Isso é sistema de registro, e sistema de registro exige regime — versionamento, validação, controle de mudança, retenção, segregação de funções, responsabilidade contratual. Não porque a IA seja incapaz de escrever o código, mas porque o código é a menor parte do que isso exige.

O que vinte anos de LIMS ensinam que a IA não tem como saber

Quando me perguntam o que a Actiz tem que um bom prompt não tem, minha resposta não é “código melhor”. É o modelo de domínio — e ele é invisível na tela. Alguns exemplos de decisões de modelagem que só se aprendem operando:

Amostra é uma árvore, não um registro. Existe lote, amostra, alíquota, ensaio, replicata e reanálise. Cada nível tem status próprio, e o status do pai não é a soma dos filhos — um lote pode estar reprovado com todos os ensaios individualmente conformes, se a regra do produto disser isso.

Método tem versão, e resultado pertence a uma versão. Quando o laboratório revisa o procedimento de um ensaio, os resultados antigos não passam a pertencer ao método novo: continuam ligados à versão vigente na data de execução, inclusive para reemissão de certificado anos depois.

Especificação é temporal e herdada. A mesma análise tem limite diferente por cliente, produto e revisão de contrato. Um resultado de 2026 tem que ser julgado pela especificação de 2026, mesmo que ela mude em 2027 — sistema que guarda só a especificação atual reescreve o passado sem querer.

Equipamento tem estado, e esse estado é retroativo. Se em auditoria você descobre que uma balança ficou com calibração vencida entre 12/03 e 27/03, o sistema precisa listar em segundos todos os ensaios feitos nela naquele intervalo. Isso é modelagem de vigência, não relatório.

Certificado emitido é imutável. Correção não é edição: gera revisão, com o documento anterior preservado e o motivo registrado. Sistema que permite “editar o laudo” não tem esse conceito — e a diferença aparece quando o cliente chega com a versão antiga na mão.

Descarte de resultado não apaga nada. Repetição, outlier, contaminação: tudo isso é evento registrado com justificativa, não linha deletada.

Nenhum desses seis itens é difícil de programar. Todos são difíceis de saber. Não estão em documentação, não estão na norma nesse nível de detalhe, e não vão aparecer no seu protótipo — vão aparecer no ano dois, um por um, cada um exigindo uma reescrita que atravessa o modelo de dados inteiro. É por isso que empresas de LIMS levam anos, não porque escrever tela seja difícil.

Foi esse acúmulo que estruturamos como método de implantação: nossa metodologia existe porque a maior parte do risco de um projeto de LIMS não está no software, está na tradução do processo do laboratório para dentro dele.

IA agêntica muda o jogo — e por isso a plataforma importa mais, não menos

Chego no ponto que mais me interessa hoje, porque é o que estou construindo.

A geração atual de IA não apenas gera texto ou código: ela age — chama ferramentas, executa passos, decide o próximo. É aqui que o laboratório tem o maior ganho potencial dos próximos anos. Um agente que recebe o e-mail do cliente e abre a ordem de serviço; que percebe um ensaio com prazo em risco e replaneja a fila; que confere se todos os requisitos de emissão do certificado estão atendidos antes de submeter para aprovação; que responde “quantas amostras de água reprovaram por coliformes no trimestre” sem ninguém montar relatório.

Mas repare no que um agente precisa para fazer qualquer uma dessas coisas com segurança:

Uma superfície de ação com contrato. Ferramentas explícitas — “criar ordem de serviço”, “lançar resultado”, “submeter para aprovação” — com parâmetros e regras validados pelo domínio, não por clique simulado em tela. Um conjunto de HTMLs soltos não tem onde um agente atuar: ele só pode fingir ser humano operando telas, o que é frágil e não auditável.

Permissão herdada de uma pessoa. O agente age como alguém, com as permissões daquele alguém — nunca com um superusuário de serviço que pode tudo. Se o analista não pode aprovar, o agente agindo por ele também não pode.

A mesma trilha de auditoria. Toda ação de agente registrada com a marca de que foi um agente, qual instrução recebeu, qual modelo executou e qual humano responde por ela. Auditoria de IA em ambiente regulado vai ser exigência, e quem não tiver isso vai reconstruir tudo.

Determinismo fora do modelo. Este é o mais importante, e onde muita gente vai errar nos próximos anos: cálculo de resultado, comparação com especificação, regra de aprovação e arredondamento não podem ser executados pelo modelo de linguagem. O agente orquestra; o domínio decide. Se um LLM está calculando conformidade, o sistema não é validável — e não deveria estar em produção.

Reversibilidade e ponto de parada humano. Ação de agente sobre registro legal exige aprovação explícita ou reversão com trilha. Autonomia sem freio não é sofisticação, é risco não controlado.

A IA agêntica não dispensa a plataforma — ela eleva o requisito de plataforma, porque precisa de domínio bem modelado, permissões sérias, API com contrato e trilha imutável para poder agir. Um LIMS nativo de IA não é um LIMS com chat colado na lateral: é um LIMS cujo domínio inteiro foi desenhado para ser operado por humanos e por agentes com o mesmo rigor de rastreabilidade. Essa é a aposta do que estamos construindo, e ela só é possível porque existe vinte anos de modelo de domínio embaixo.

Um teste honesto: dez perguntas antes de escrever a primeira linha

Se depois de tudo isso você ainda quer construir — e há casos em que faz sentido — responda estas dez perguntas por escrito, com o gerente da qualidade na sala.

1. Se um auditor pedir agora o histórico completo de alterações de um resultado específico, quem produz isso e em quanto tempo?
2. Onde está a evidência documental de validação da versão que está em produção hoje?
3. Quem aprova uma mudança no sistema, e onde isso fica registrado?
4. Existe ambiente de teste separado do de produção?
5. Quando foi a última vez que um backup foi restaurado para verificação?
6. Duas pessoas editando a mesma amostra ao mesmo tempo — o que acontece? Já foi testado?
7. Quem pode alterar um resultado depois de aprovado, e o sistema impede tecnicamente ou só por combinado?
8. Se a pessoa que construiu isso sair amanhã, quem assume? Existe documentação de arquitetura?
9. Em cinco anos, esse dado ainda vai ser legível e reproduzível com a especificação vigente na época?
10. Quanto tempo por mês a equipe já gasta mantendo, corrigindo e explicando esse sistema — e onde esse tempo está contabilizado?

Se você responde as dez com tranquilidade, não construiu um protótipo: construiu um sistema, e provavelmente vai virar fornecedor de LIMS. Se travou em três ou mais, o que existe hoje é ferramenta de conveniência sendo usada como sistema de registro — a configuração de risco mais comum que eu encontro em laboratório. Os sinais de que chegou a hora de trocar de sistema valem para sistema próprio também, não só para legado de fornecedor.

A decisão não é “construir ou comprar”. É “registro ou conveniência”.

Enquadrar isso como build versus buy é o erro que faz o laboratório decidir mal — dos dois lados.

Quem decide “não construo nada” perde ganhos reais e baratos que a IA entrega em dias: parsers, dashboards, conferências, protótipos de requisito. Quem decide “construo tudo” descobre no ano dois que assinou um contrato de manutenção de software por prazo indeterminado, sem equipe, sem processo de validação e sem ninguém para chamar quando quebra na sexta à noite.

A decisão sensata separa duas camadas com clareza:

• Camada de registro — onde o resultado mora, a aprovação acontece, o certificado nasce e a trilha vive. Isso é plataforma, com fornecedor, versionamento, validação e responsabilidade contratual. Não porque a IA não conseguiria escrever, mas porque escrever é 20% do problema.
• Camada de conveniência — tudo que se conecta ao registro para facilitar a vida e pode ser descartado sem perda. Aqui, construa com IA, agressivamente, e ganhe tempo.

O melhor cenário — o que eu defendo — é que as duas camadas conversem: uma plataforma que expõe seu domínio por API e por ferramentas com contrato, e um laboratório com gente capacitada em IA construindo em cima disso. Aí você tem o rigor do sistema de registro com a velocidade da IA, em vez de escolher entre os dois.

Vinte anos de LIMS não me ensinaram que software é difícil de escrever. Me ensinaram que registro de laboratório é difícil de merecer confiança. A IA resolveu a primeira parte de forma espetacular. A segunda continua sendo sobre modelo de domínio, disciplina de processo e alguém que responda pelo resultado.

Se você está nessa encruzilhada agora, decidindo entre estruturar o que já foi construído ou partir para uma plataforma, agende uma conversa técnica com a gente. Não é uma demonstração de telas: é uma discussão sobre qual das duas camadas o seu problema realmente é.