IA na análise de causa raiz: o que ela acerta e onde inventa causa

IA na análise de causa raiz entrega, em vinte segundos, um texto que parece uma análise: causa provável, causas contribuintes, recomendação de ação. Está bem escrito, usa o vocabulário certo e nada ali foi verificado contra o seu processo.

A separação que importa não é entre resposta boa e resposta ruim, porque as duas chegam iguais na tela. É entre plausibilidade e evidência. Plausível é o que poderia ser verdade em processos daquele tipo. Evidente é o que é verdade neste processo, mostrado por um dado deste processo.

Este artigo trata da disciplina da análise de causa raiz, não de uma ferramenta específica. O que o modelo faz bem: ampliar a lista de hipóteses, reescrever um problema mal formulado, agrupar causas e projetar qual dado coletar. O que ele faz mal: ele produz causa plausível porque não tem acesso ao processo, e raramente avisa disso.

Também percorre o risco da causa inventada com aparência técnica e a regra de usar o modelo como gerador e nunca como juiz. Depois vêm o prompt que funciona contra o que não funciona, a verificação obrigatória de cada hipótese e o único caso em que o ganho é de ordem de grandeza, que é ler registro em texto livre em volume.

O exemplo com prompt e resposta comentada foi montado para este artigo, no formato dos kits de metodologia da Voitto. A linha de envase, os percentuais de refugo e as duas hipóteses devolvidas são ilustrativos: mostram a mecânica da leitura crítica e o tipo de erro a procurar, não um caso de empresa real.

Vinte segundos para um texto que parece uma análise

Você cola a descrição do problema no chat e pede a causa raiz. Em vinte segundos volta um texto organizado, com causa provável, causas contribuintes e recomendação de ação. Está bem escrito e cita fatores que fazem sentido para quem conhece o processo.

Nada daquilo foi verificado. E esse é o ponto de partida honesto para falar de IA na análise de causa raiz: parte do que a máquina devolve tem valor real, parte tem só aparência de valor, e as duas chegam na mesma fonte, com a mesma fluência.

A tentação é óbvia. Uma discussão que levaria três reuniões chega pronta antes do café. Recusar em bloco desperdiça um ganho legítimo. Aceitar em bloco coloca causa inventada dentro do projeto, o que é pior do que não ter feito análise de causa raiz nenhuma.

O que a análise de causa raiz exige e o modelo não tem

Análise de causa raiz é um procedimento de eliminação. Você levanta candidatos, confronta cada candidato com evidência colhida no processo e descarta os que o dado não sustenta. O que sobra depois do confronto é causa. O resto continua sendo hipótese, mesmo quando soa convincente.

Um modelo de linguagem não tem acesso ao processo. Não vê a máquina, não abre o histórico de parada e não mede nada. Ele trabalha sobre o texto que você colou e sobre padrões aprendidos de muitos textos parecidos com o seu.

Isso não o torna inútil. Torna-o um participante limitado à primeira metade do procedimento de análise de causa raiz: gerar candidatos ele faz, e faz rápido. Eliminar candidatos depende de quatro coisas que ele não tem.

• Acesso ao dado bruto. A não ser que você cole o dado, ele não tem série histórica, medição nem registro.
• Presença no local. Nenhum modelo foi ao posto ver o operador trabalhar por quarenta minutos.
• Memória do que já foi tentado. A ação que falhou no ano passado não está em lugar que ele consiga ler.
• Capacidade de testar. Ele pode propor o teste, nunca executar o teste.

Plausibilidade não é evidência

Essa distinção sustenta toda a análise de causa raiz. Plausível é o que poderia ser verdade dado o que se sabe em geral sobre processos daquele tipo. Evidente é o que é verdade neste processo, mostrado por um dado deste processo, colhido em data conhecida.

Modelo de linguagem é uma máquina de plausibilidade. Foi treinado para produzir a continuação mais provável de um texto, não a mais verdadeira. Quando você pergunta a causa de refugo em injeção plástica, ele devolve as causas que mais aparecem em textos sobre refugo em injeção plástica.

Boa parte das vezes isso acerta, porque causa comum é comum. E é aí que mora o risco: o acerto por frequência não se distingue, na leitura, do acerto por análise. As duas frases têm a mesma cara na tela.

O que ele faz bem: lembrar a causa que a sala esqueceu

A equipe que conhece o processo tem um ponto cego previsível: ela levanta as causas que já viu acontecer. Um modelo treinado em texto de muitos setores levanta também as que aquela equipe nunca viu, inclusive várias que não se aplicam.

Numa sessão de diagrama de Ishikawa ou de 5 porquês, a lista humana costuma estacionar em oito ou dez causas e a discussão passa a girar. Pedir mais vinte à máquina e descartar quinze é trabalho barato, e entre as cinco que sobram às vezes aparece uma que ninguém tinha dito em voz alta.

O valor aqui não é precisão, é cobertura. Levantar hipótese é a única etapa da análise de causa raiz em que errar sai barato, desde que o erro morra na etapa seguinte. Vinte hipóteses ruins não custam nada; uma hipótese ruim promovida a causa custa o projeto inteiro.

Reescrever um problema mal formulado

Boa parte das análises de causa raiz trava antes de começar, porque o problema foi escrito como opinião ou como solução disfarçada. "A produtividade caiu" não é problema analisável. "Falta de treinamento" já é resposta, apresentada no lugar da pergunta.

Nessa tarefa o modelo é bom e é seguro, porque o trabalho é linguístico e não factual. Dê a frase original e peça uma versão que diga o que acontece, onde, desde quando e quanto, sem causa embutida e sem adjetivo.

A reescrita continua precisando passar pela equipe, que é quem sabe se os números estão certos. Mas a estrutura volta pronta, e problema bem escrito é metade do caminho da análise de causa raiz.

Organizar causas por categoria

Depois do levantamento, alguém precisa agrupar as causas levantadas. É trabalho demorado, chato e sem julgamento técnico relevante: distribuir trinta anotações soltas em seis categorias. O modelo faz isso em segundos e faz razoavelmente bem, porque é tarefa de classificação de texto.

O cuidado é não deixar que ele preencha lacuna. Pedido para montar uma espinha de peixe, o modelo tende a produzir simetria: quatro causas em cada um dos seis Ms, porque o formato pede ramos cheios. Esse comportamento está tratado em diagrama de Ishikawa com IA e vale a leitura antes de gerar o primeiro.

A regra prática é curta: peça categorização do que você deu, não completude do desenho. Se uma categoria ficar vazia, ela fica vazia, e isso é informação sobre onde a equipe ainda não olhou.

Sugerir qual dado coletar

Essa é a pergunta mais subaproveitada de todas. Em vez de perguntar qual é a causa, pergunte qual dado seria necessário para distinguir entre as cinco hipóteses que você já tem. A resposta costuma ser concreta e verificável.

O modelo rende bem aí porque desenhar teste é raciocínio de forma, não de fato. Ele não precisa saber o valor da medição, precisa apenas saber qual valor separaria uma hipótese da outra.

1. Liste as hipóteses vivas, numeradas, com uma frase cada.
2. Peça, para cada uma, a medição que a confirmaria e a medição que a derrubaria.
3. Peça o corte de estratificação que faria a diferença aparecer: turno, máquina, operador, lote, horário.
4. Peça o tamanho mínimo de amostra e o período que tornaria a comparação honesta.

A saída vira o plano de coleta da análise de causa raiz, e o plano vira folha de verificação no posto. Repare que em nenhum momento foi preciso confiar no que a máquina supõe sobre o seu processo.

A causa inventada com aparência técnica

O risco específico não é o erro grosseiro. Modelo que dissesse bobagem seria fácil de pegar na primeira leitura. O risco é a causa que usa o vocabulário correto, descreve um mecanismo físico coerente e apresenta um número com casa decimal que nunca foi medido.

O exemplo típico é uma frase assim: "a folga do mancal excede 0,08 mm, o que produz vibração acima da faixa tolerada". Ninguém mediu folga alguma. O valor apareceu porque números com duas casas decimais aparecem nesse tipo de frase.

O dano é que essa frase atravessa a reunião sem resistência. Ela soa como quem esteve na máquina. Quando vira ação, a análise de causa raiz manda trocar um mancal que estava bom, o problema continua e a causa verdadeira agora carrega um descarte indevido no histórico.

• Número específico que você não forneceu. Tolerância, percentual, tempo de ciclo, torque, temperatura.
• Referência a norma, faixa ou especificação sem que o documento tenha sido dado ao modelo.
• Afirmação sobre o estado atual do equipamento em vez de afirmação sobre o que poderia estar acontecendo.

Por que o modelo quase nunca diz que não sabe

A resposta honesta para a maioria das perguntas de análise de causa raiz é simples: não dá para saber sem olhar o dado do processo. O modelo raramente responde isso, e a razão é de construção, não de má vontade.

Ele foi treinado para completar texto e ajustado para ser útil. Diante de uma pergunta sobre causa, a continuação estatisticamente provável é uma causa. Uma recusa se parece pouco com as respostas que ele aprendeu a imitar, então quase nunca é a saída escolhida.

Há um segundo motivo, mais incômodo. O modelo não distingue internamente o que veio do seu texto do que ele está construindo agora. Ausência de dado não gera sinal de alerta: a frase sai com a mesma fluência nos dois casos, e fluência é a pista que o leitor usa.

A consequência prática é que a calibragem precisa vir de fora. Não espere que a máquina marque o próprio limite. Quem marca é você, e o marcador é o dado.

Gerador de hipóteses, nunca juiz

Todo o uso responsável de IA na análise de causa raiz cabe em uma regra: o modelo entra antes do dado e sai antes da conclusão. Participa do levantamento e é retirado da sala na hora do veredito.

Como gerador, ele amplia a lista de candidatos e ajuda a organizar. Como juiz, precisaria decidir qual candidato é verdadeiro, e para isso faltaria exatamente o acesso que ele não tem. Pedir veredito é pedir que ele feche com plausibilidade um buraco que só evidência fecha.

A mesma fronteira vale dentro do método DMAIC. Na fase Analisar o modelo ajuda a listar e a organizar, mas quem prova a relação é o teste feito com dado, assunto tratado em IA na fase Analisar.

O prompt que funciona

Na análise de causa raiz, a diferença entre um prompt útil e um inútil não está na engenharia da frase nem em fórmulas de persona. Está em quanto processo real entrou no texto antes da pergunta.

1. Descreva o processo em três ou quatro linhas concretas: equipamento, etapa, volume, quem opera.
2. Dê o dado observado com número e período, não a impressão geral.
3. Diga o que já foi verificado e descartado, para não receber de volta o que já morreu.
4. Peça hipóteses, em número definido, e diga explicitamente para não concluir qual é a causa.
5. Peça, junto de cada hipótese, qual evidência do seu processo a confirmaria e qual a derrubaria.

O quinto item é o que mais muda o resultado. Quando a evidência é pedida junto da hipótese, o modelo fica obrigado a produzir afirmações falsificáveis, e afirmação falsificável é mais fácil de avaliar do que texto bem escrito.

Se existir um FMEA do processo, cole os modos de falha no prompt. Você troca invenção por recombinação do que a sua própria equipe já mapeou, o que é bem mais seguro.

O prompt que não funciona

"Quais são as causas raiz de refugo em processo de usinagem?" devolve uma lista de manual. Não há nada de errado com a lista, e não há nada nela sobre a sua máquina, o seu turno ou as suas três últimas semanas.

• Pergunta genérica sem dado. Produz o conteúdo médio da internet sobre o tema, que você já conhecia.
• Pergunta que pede conclusão de saída. "Qual a causa disso?" convida o modelo a inventar o que falta.
• Contexto de duas linhas com pedido de análise completa. A desproporção entre entrada e saída é preenchida por padrão.
• Pedido de números, prazos ou ganhos estimados. Tudo que vier será verossímil e nenhum valor terá origem.

O teste que resolve na hora: se o seu prompt pudesse ter sido escrito por alguém que nunca entrou nessa fábrica, a resposta vai valer o mesmo que a opinião de alguém que nunca entrou nessa fábrica.

Um exemplo: o prompt, a resposta e o que fazer com ela

A análise de causa raiz abaixo é de uma linha de envase de 200 ml, tampa aplicada por recravadeira de quatro cabeçotes, refugo por vazamento subindo de 0,8% para 2,3% em três semanas. O prompt enviado foi este.

"Linha de envase de frasco de 200 ml, tampa aplicada por recravadeira de quatro cabeçotes, cerca de 12 mil frascos por turno. O refugo por vazamento na inspeção final subiu de 0,8% para 2,3% entre a semana 12 e a semana 15. Já verifiquei que o fornecedor e o desenho da tampa são os mesmos e que a preventiva foi feita na semana 11. Ainda não tenho estratificação por cabeçote. Liste 10 hipóteses de causa e, para cada uma, diga qual dado do meu processo a confirmaria e qual a derrubaria. Não conclua qual é a causa."

Voltaram dez hipóteses. Duas delas bastam para mostrar a diferença entre o que serve e o que precisa ser barrado na porta.

A primeira hipótese é boa justamente porque é pobre em conteúdo. Ela não sabe nada, propõe um corte e devolve a decisão para o dado. Se o refugo aparecer concentrado em um cabeçote, a hipótese avança; se estiver distribuído nos quatro, ela morre naquela tarde.

A segunda é perigosa porque é acionável. Chega com número, faixa e ação, e nenhum dos três tem origem. O torque pode até ser o problema; o ponto é que a frase foi apresentada como constatação sem uma única medição por trás.

Se aquele "1,2 N.m" for copiado para o relatório A3, ele deixa de ser texto de chat e passa a ser dado oficial da análise de causa raiz. Três semanas depois ninguém lembra que o número nasceu de uma frase gerada, e ele será citado como medição.

A verificação obrigatória, hipótese por hipótese

Nenhuma hipótese vinda de modelo entra no projeto sem passar por três perguntas. São perguntas rápidas, e a maior parte das hipóteses cai já na primeira.

1. De onde veio esta afirmação? Se não está no dado que forneci nem no texto que escrevi, veio do modelo e é hipótese, não informação.
2. Qual medição do meu processo confirma ou derruba isso? Se não existe medição possível, a hipótese não é testável e sai da lista.
3. Quem no processo pode verificar isso em campo? Precisa ser um nome, com prazo, não uma função genérica.

O controle que funciona na prática é uma coluna. Na planilha de hipóteses da análise de causa raiz, mantenha uma coluna de origem com três valores possíveis: dado, equipe e modelo. Nada marcado como modelo pode aparecer em slide de status enquanto continuar marcado assim.

Hipótese de modelo que passa no teste perde a marca e vira hipótese verificada, com a medição anexada. Hipótese que não passa é descartada com registro do motivo, porque a mesma sugestão vai reaparecer na próxima geração de texto.

Quando a hipótese é sobre algo ter mudado no tempo, o teste natural é olhar a série antes e depois numa carta de controle. Mudança real deixa marca na série; mudança imaginada não deixa.

Onde a IA acelera de verdade: quando há texto demais para ler

Existe um caso em que o ganho não é marginal, é de ordem de grandeza. Quando a evidência do problema está espalhada em milhares de registros em texto livre, ninguém lê tudo. A análise de causa raiz acaba sendo feita sobre as cinquenta linhas que alguém teve tempo de abrir.

Aí o modelo é a ferramenta certa, porque a tarefa mudou de natureza. Não se pede que ele deduza nada: pede-se que ele leia e classifique o que já está escrito. É leitura em volume sobre dado que é seu, e a diferença em relação a tudo que veio antes é que a informação existe antes da pergunta.

A saída é uma contagem por categoria, que é exatamente a entrada de um diagrama de Pareto. E agora a contagem cobre a base inteira, não a amostra de conveniência que coube na tarde de quinta.

Reclamação de cliente e ordem de serviço em volume

Dois acervos rendem mais que os outros numa análise de causa raiz, por motivos parecidos. Nos dois, o texto foi escrito por gente diferente, sem vocabulário padronizado, e o mesmo problema aparece com dez nomes distintos.

• Reclamação de cliente. Descrição livre, linguagem do cliente e não da engenharia, e a categoria do sistema quase sempre errada porque foi escolhida no atendimento.
• Ordem de serviço de manutenção. O campo de descrição costuma ser a única memória do que o técnico realmente encontrou na máquina, e ninguém consolida esse campo.
• Registro de desvio e de não conformidade. Volume alto, texto curto, classificação original feita sob pressa.

O protocolo é sempre o mesmo. As categorias são definidas por você e pela equipe antes, nunca pelo modelo. O pedido é que cada registro seja classificado em exatamente uma categoria, com a opção "não classificável" disponível e sem punição por usá-la.

Depois vem a conferência por amostra, que não é opcional. Sorteie cinquenta registros já classificados e leia um por um. Para orientar onde olhar primeiro, 85% de acerto resolve. Para virar número de relatório, não resolve, e a correção manual da amostra precisa virar correção da regra.

Esse trabalho às vezes dispensa a coleta prospectiva: o histórico já tinha o dado, faltava quem lesse oito mil linhas.

O limite do que ela enxerga

Vale escrever o que fica de fora da análise de causa raiz assistida, porque a lista é maior do que parece quando se está satisfeito com a resposta que chegou.

• O que não está escrito em lugar nenhum. A maior parte do que explica um problema crônico nunca foi registrada.
• O conhecimento tácito de quem opera. O ajuste que o operador faz há dois anos e não consta em procedimento.
• A exceção que virou rotina. O desvio que todo mundo pratica e ninguém chama de desvio.
• O histórico de tentativas. As três ações que já foram testadas e falharam, e por quê.
• A restrição organizacional. O motivo real pelo qual a solução óbvia nunca foi implantada.

O último item é o que mais atrapalha. Muitos problemas persistentes têm causa conhecida e não resolvida por razão orçamentária, contratual ou política. O modelo devolverá com convicção a solução que a empresa já descartou três vezes.

Por isso o passo de ir ao local não tem substituto na análise de causa raiz. Ver o processo rodar, cronometrar, conversar com quem opera e olhar a peça continua sendo a origem de todo o resto. Nenhuma quantidade de texto colado no chat reproduz quarenta minutos em pé no posto.

O protocolo, dentro de um projeto de melhoria

Em ordem de execução, o que aplicar quando o projeto é real e a análise de causa raiz vai virar ação com custo.

1. Escreva o problema com número e período. Use o modelo para reescrever a formulação, não para explicar o problema.
2. Levante hipóteses com a equipe primeiro, no quadro, sem máquina. A lista humana é a que carrega conhecimento do processo.
3. Só então peça mais hipóteses ao modelo, com o contexto real colado e proibição explícita de concluir.
4. Marque a origem de cada hipótese na planilha: dado, equipe ou modelo.
5. Peça ao modelo o teste de cada hipótese, e execute os testes com dado seu.
6. Elimine por evidência. Toda hipótese ainda marcada como modelo sai da lista ou vira verificada.
7. Escreva a conclusão você. A frase que diz qual é a causa é a única do documento que não pode ter sido gerada.

O protocolo custa pouco e devolve o ganho verdadeiro. A máquina acelera levantamento, organização e leitura em volume, que ocupam boa parte do tempo do ciclo PDCA de qualquer projeto.

O que ela não acelera é a eliminação, que é onde a análise de causa raiz acontece de fato. Quem trata as duas metades como a mesma coisa vai fechar projeto mais rápido e resolver menos problema, e o indicador conta essa história alguns meses depois.

A leitura pragmática é essa: IA na análise de causa raiz não muda o método, muda a velocidade da primeira metade dele. É um ganho real e é menor do que parece no primeiro uso, o que também vale para o resto do que se promete sobre IA na melhoria contínua.