Case Agence: Automação para Priorização de Manutenção Hospitalar
Em uma unidade hospitalar de São Paulo, quatro gestores perdiam duas horas e meia por semana decidindo, ordem por ordem, o que era urgente e o que podia esperar na manutenção do hospital. A Agence foi chamada para provar que a automação de manutenção hospitalar com IA conseguia fazer essa triagem inicial sem tirar a palavra final das mãos deles.
O gargalo: 14 horas por semana para priorizar ordens de manutenção manualmente
A unidade atendida integra uma grande rede hospitalar de São Paulo, com um parque de ativos que vai de equipamentos críticos de UTI a itens de infraestrutura predial, como ar-condicionado e iluminação. Todo esse parque é gerido de forma centralizada pelo Manusis4, o CMMS que a rede usa para registrar as ordens de manutenção preventiva, corretiva e preditiva ao longo da semana. Foi o próprio hospital que procurou a Agence, no final do primeiro semestre de 2025, com uma queixa direta: o processo semanal de priorização de ordens de manutenção estava consumindo tempo demais da equipe de gestão.
A rotina seguia um roteiro fixo. Toda segunda de manhã, o analista de planejamento entrava no Manusis4, exportava os dados e consolidava tudo manualmente em uma planilha de Excel. Na segunda à tarde, quatro gestores se reuniam por duas horas e meia para analisar cada ordem, uma a uma, e decidir o que entrava na fila de execução daquela semana. Encerrada a reunião, o analista retornava ao Manusis4 para atualizar manualmente o status de cada ordem aprovada, liberando o sequenciamento do serviço. As ordens reprovadas permaneciam na planilha e voltavam à pauta nas semanas seguintes.
Esse é o tipo de gargalo que normalmente justifica um projeto de automação de processos: profissionais qualificados presos a uma tarefa repetitiva, sem tempo para frentes mais estratégicas da operação hospitalar.
14h
horas-homem consumidas por semana só na etapa de priorização, antes de qualquer execução de serviço
2h30
duração da reunião semanal em que os gestores analisavam ordem por ordem
4
gestores envolvidos na análise de cada ordem de manutenção
Diagnóstico: custo de tempo, variabilidade entre gestores e risco de erro na planilha
O diagnóstico do hospital revelou que o problema não era só a duração da reunião. A preparação consumia cerca de 4 horas semanais do analista de planejamento, e a reunião ocupava os 4 gestores por 2 horas e meia, somando 10 horas-homem. No total, 14 horas de trabalho qualificado eram gastas antes que qualquer ordem de manutenção fosse de fato executada. Nas entrevistas, um segundo padrão apareceu: nos extremos da priorização, entre o que era claramente crítico e o que era claramente de baixa prioridade, os gestores convergiam. A divergência se concentrava nas categorias intermediárias, e a causa era mais humana do que técnica: um gestor com mais convivência em determinado setor do hospital tendia a atribuir criticidade maior a uma ordem do que um colega sem aquela vivência, mesmo diante da mesma informação.
Custo de tempo
4 horas semanais do analista de planejamento mais 10 horas dos quatro gestores em reunião somam 14 horas-homem por semana, gasto antes de qualquer serviço ser executado.
Variabilidade entre gestores
Nos extremos da priorização havia consenso. A divergência se concentrava nas categorias intermediárias, por assimetria de vivência entre gestores e setores do hospital.
Risco de erro manual
Extração e consolidação inteiramente manuais no Excel geravam reuniões prejudicadas por dados equivocados na planilha, segundo relato da própria equipe.
A solução em duas camadas: extração automática e classificação por IA
A resposta definida com o hospital foi dividir a solução em duas camadas. A primeira é sistêmica: automatiza a extração e a consolidação dos dados que hoje saem do Manusis4, um caso concreto de automação de CMMS, sem depender do analista abrindo o sistema toda segunda-feira. A segunda é cognitiva: analisa semanticamente cada ordem de manutenção e propõe uma classificação de prioridade, reproduzindo os critérios que os próprios gestores usam.
Esse desenho segue os princípios de human in the loop em IA aplicados a qualquer processo crítico, em que a decisão final nunca pode ficar só com o modelo.
A metodologia seguiu dois trilhos. Com a equipe do hospital, a Agence aplicou as fases de empatia e definição do Design Thinking, com sessões de shadowing e entrevistas gravadas com analistas e gestores. Com a equipe técnica, as fases de ideação, prototipação e testes rodaram em sprints quinzenais sob Scrum, com o melhor resultado de cada ciclo levado a uma reunião de validação com o hospital a cada três dias.
Decisões de engenharia: por que automação web, LLM local e Playwright venceram as alternativas
Cada decisão técnica respondeu a uma necessidade específica, e em quase todas elas a alternativa mais óbvia foi descartada por um motivo concreto. O Manusis4 é um SaaS sem acesso ao código-fonte e sua documentação não prevê API de exportação, o que tornava a integração via API inviável. A saída foi automação web não invasiva, simulando a navegação de um usuário real dentro da própria plataforma.
| Necessidade | Alternativa descartada | Decisão |
|---|---|---|
| Extração e consolidação dos dados | Integração via API, inviável por ser SaaS sem código-fonte e sem endpoint de exportação | Automação web não invasiva, simulando a navegação de um usuário |
| Pré-classificação das ordens | Árvore de decisão e machine learning, exigiam volume de dados indisponível | Modelo de linguagem com engenharia de prompt para IA |
| Interoperabilidade com o Power BI | Refazer os dashboards, com risco de incompatibilidade com planilhas históricas | Preservação integral do formato da planilha mestre já usada pelo hospital |
| Soberania dos dados sensíveis | API de LLM de terceiros, com risco de alimentar treinamento de modelos externos | LLM local para dados sensíveis, hospedado na infraestrutura do próprio hospital |
| Resiliência sistêmica | Requisições diretas sem tratamento de falha, vulneráveis à instabilidade do Manusis4 | Playwright, com espera automática nativa e lógica de retry |
O volume de ordens históricas priorizadas também não sustentava um modelo estatístico convencional: o gabarito disponível somava apenas 500 ordens, dado insuficiente para treinar uma árvore de decisão ou um modelo de machine learning tradicional. Foi esse limite, não o tamanho do parque de equipamentos do hospital, que levou à escolha de um modelo de linguagem com engenharia de prompt para IA. O resultado é uma stack inteiramente aberta, com Python, Playwright, Pandas e Qwen2.5-14B, sem custo de licença e totalmente auditável, o que facilita tanto a manutenção quanto a revisão técnica por terceiros.
Engenharia de prompt: como a concordância com os gestores saiu de 38% para 72%
O hospital forneceu um gabarito de 500 ordens de manutenção já priorizadas pelos gestores. A cada mudança relevante no prompt, a equipe técnica rodava o fluxo completo e comparava o resultado ao gabarito com scripts próprios, que geravam automaticamente o percentual de concordância e a matriz de confusão. O fluxo chegou a ser executado de uma a duas vezes por dia, mapeando avanços, regressões e padrões de falha a cada iteração.
38%
concordância na V1, persona genérica sem contexto institucional
55%
concordância na V2, com contexto do hospital e few-shot
72%
concordância na V3, com escores numéricos de risco
V1: linha de base
Persona de Engenheiro Clínico Sênior, ancorada em normas reais, mas deliberadamente sem informação da instituição. O modelo acertava as demandas críticas, mas superestimava a prioridade das ordens de baixa criticidade.
V2: contextualização
Contexto do hospital, matriz de criticidade institucional e exemplos reais com justificativa caso a caso. O calibre geral melhorou, mas ordens da mesma categoria ainda eram indistinguíveis entre si.
V3: escores numéricos
Inclusão de dois valores inteiros na resposta, risco ao paciente e impacto operacional. Foi o que deu à IA a granularidade que faltava dentro de cada categoria de prioridade.
O salto de uma versão para outra não veio de um modelo maior ou mais caro: veio de prompt mais específico. É a mesma lição que aparece em outros projetos de inteligência artificial aplicada a processos de negócio, em que a engenharia de prompt costuma valer mais do que a escolha do modelo em si.
Dois escores numéricos bastaram porque são exatamente as variáveis que alimentam o score de risco em manutenção desenhado com o hospital: risco ao paciente e impacto operacional. Adicionar um terceiro critério exigiria recalibrar toda a matriz de pesos, sem garantia de que o gabarito de 500 ordens sustentasse essa granularidade extra.
O score de risco e as quatro camadas contra alucinação da IA
A resposta da V3 se apoia em uma fórmula simples: score de risco em manutenção = (risco ao paciente × 0,6) + (impacto operacional × 0,4). A equipe testou quatro combinações de peso diferentes, e essa foi a que mais coincidiu com a priorização histórica dos gestores. A variável de risco ao paciente captura tudo que ameaça a segurança do paciente e as exigências regulatórias; a de impacto operacional captura infraestrutura e gestão.
- ✓Autossuficiência do prompt: todos os insumos necessários para a classificação já estão dentro do próprio prompt, sem busca externa em tempo real.
- ✓Contextualização específica da instituição: quanto mais claras as regras do hospital dentro do prompt, menor a margem para a IA inventar critério próprio.
- ✓Restrição de formato: a resposta sai em JSON, com chaves e tipos fixos, o que permite detectar automaticamente qualquer saída fora do padrão e disparar um retry.
- ✓Human in the loop: a validação final continua com os gestores, a camada de proteção mais importante de todas.
Essa disciplina de validação segue o mesmo raciocínio que orienta qualquer projeto de implementação de IA nas empresas: testar contra um problema real antes de confiar na solução em escala.
Na prática, é a camada 3 que age primeiro quando alguma resposta foge do esperado. Se o modelo devolve um JSON com campo faltante ou de tipo errado, o sistema descarta a resposta e dispara automaticamente uma nova tentativa da mesma requisição, antes que qualquer classificação malformada chegue perto da planilha dos gestores.
Protocolo de validação: testando a IA sem viés de confirmação
Antes de qualquer redução de esforço ser prometida, a solução precisava provar que classificava bem sem contaminar a decisão dos gestores. O desenho do piloto foi pensado exatamente para isso.
- 1Duas semanas em paraleloA automação rodou ao lado do processo antigo completo, processando 198 ordens de manutenção, sem substituir nenhuma etapa manual ainda.
- 2Sigilo até o fim da reuniãoAs priorizações geradas pela IA ficaram guardadas até o encerramento de cada reunião do comitê, evitando que os gestores decidissem influenciados pela sugestão do modelo.
- 3Comparação só depoisSomente após a reunião as classificações da IA eram comparadas às decisões humanas. Esse desenho evitou o viés de confirmação, o ponto central deste protocolo de validação de IA em processos críticos.
- 4Métricas do pilotoAcurácia da classificação, sensibilidade nas ordens críticas e tempo médio de cada etapa da automação foram os três indicadores acompanhados nessas duas semanas.
- 5Redução de esforço medida depoisSó depois da solução em produção, com a planilha pré-classificada como ponto de partida, o ganho de tempo dos gestores entrou na conta.
Resultados em produção: menos horas de gestão, mesma decisão final humana
Com a solução em produção, o ciclo completo passou a rodar em 55 minutos: 20 minutos de extração, majoritariamente o tempo de download das planilhas no Manusis4, 33 minutos no fluxo de priorização por IA e 2 minutos de transformação, já com a consolidação dos dados e a geração da planilha final no formato legado que os dashboards do Power BI já usavam. O resultado consolida um modelo de IA para gestão hospitalar que preserva a decisão dos gestores e reduz apenas o trabalho repetitivo em torno dela.
98%
taxa de sucesso em 50 ciclos consecutivos de extração
72%
concordância final com os gestores no teste em produção
18/18
ordens críticas do período acertadas, sem rebaixamento na camada de emergência
40%
redução aproximada em tempo de reuniões de gestão semanais
| Indicador | Antes | Depois |
|---|---|---|
| Preparação de dados | 4 horas semanais | Menos de 1 minuto, o tempo de abrir o e-mail com a planilha pronta |
| Reunião de priorização | 4 gestores por 2h30 | Cerca de 40% mais curta |
| Natureza da reunião | Classificação item a item | Validação de exceções |
| Custo de infraestrutura de IA | Não existia | Cerca de US$ 20 por mês, com instâncias spot |
A reunião deixou de ser sobre classificar cada ordem uma a uma e passou a ser sobre validar as poucas exceções que realmente exigem decisão humana.
Perguntas frequentes sobre automação de manutenção hospitalar com IA
Como funciona a priorização automática de ordens de manutenção com inteligência artificial?
Um robô de automação web extrai as ordens do Manusis4 todo início de semana. Cada ordem é enviada a um modelo de linguagem, que classifica a prioridade e calcula um score de risco com base no impacto ao paciente e na operação. O resultado chega aos gestores como uma pré-priorização, já organizada na planilha que eles sempre usaram.
A IA substitui a decisão dos gestores na priorização de manutenção hospitalar?
Não. A IA entrega uma sugestão de prioridade para cada ordem, mas a validação final continua com os quatro gestores do comitê. Essa foi uma premissa definida antes da primeira linha de código, porque o processo envolve risco direto ao paciente.
É seguro usar inteligência artificial com dados hospitalares sensíveis?
O projeto usou um LLM local para dados sensíveis, hospedado na infraestrutura do próprio hospital, para que nenhuma informação de paciente ou de ativo crítico saísse da instituição rumo a uma API de terceiros que pudesse usá-la para treinar outros modelos.
Quanto custa manter uma solução de IA local para automação de manutenção?
No case, o custo de infraestrutura de IA ficou em torno de US$ 20 por mês. Rodar o servidor com GPU o mês inteiro custaria cerca de US$ 400, mas como a rotina só precisa executar uma vez por semana, instâncias spot sobem e derrubam o ambiente automaticamente conforme o uso.
Como evitar que a IA alucine ao classificar prioridades em processos críticos?
Com quatro camadas: um prompt autossuficiente, que já contém toda a informação necessária; contexto específico da instituição; resposta em formato fixo, que permite detectar e repetir automaticamente qualquer saída fora do padrão; e validação humana final, a camada que nenhuma das outras substitui.
Priorize manutenção crítica com o rigor que sua operação exige
O resultado desse case não veio de uma promessa genérica de IA: veio de um gabarito real para medir concordância, de engenharia de prompt iterada até o número sustentar a decisão e de um protocolo de validação sem viés de confirmação. Se você lida com um processo manual e crítico na sua operação, vale a pena avaliar com um especialista onde há espaço para esse mesmo tipo de pré-priorização, sem abrir mão da decisão final humana.
