IA no FMEA: priorizar modos de falha com apoio de modelo

Perguntar o que a IA no FMEA resolve costuma levar a duas respostas erradas em direções opostas. Uma diz que o modelo escreve o FMEA inteiro e a equipe só valida. A outra diz que não serve para nada porque não conhece o processo.

As duas ignoram a mesma coisa: o FMEA tem colunas de natureza muito diferente. Umas exigem repertório e redação. Outras exigem conhecimento verificável do que acontece naquela máquina, naquele turno, com aquele dispositivo de controle. A IA é boa nas primeiras e ruim nas segundas, e a fronteira entre elas é nítida.

Este artigo percorre essa fronteira com um critério: onde o erro do modelo aparece e onde ele passa despercebido. Modo de falha absurdo alguém corta na reunião. Nota de Ocorrência inventada entra na planilha com a mesma cara de todas as outras e contamina a priorização por anos.

O caminho passa pelo que a IA faz bem, pelo que ela faz mal, pelo uso em processo novo sem histórico, pela auditoria de planilha preenchida, pelo prompt que funciona e por um protocolo com uma regra que não admite exceção. No meio, um exemplo completo com prompt, saída do modelo, revisão da equipe e os NPR recalculados.

O exemplo da estação de aperto foi montado para este artigo, no formato dos kits da Voitto. Os números são ilustrativos e não descrevem uma empresa real: servem para mostrar como a revisão de notas altera a ordenação. Todos os NPR foram recalculados em Python a partir das notas e conferem com as tabelas.

Onde o FMEA consome tempo de verdade

Quem já conduziu um FMEA sabe que o gargalo não é a aritmética. Multiplicar Ocorrência por Gravidade por Detecção leva menos de um segundo por linha em qualquer planilha. O tempo vai embora antes disso, na parte que ninguém consegue automatizar com fórmula.

Em um FMEA de processo com 40 linhas, o esforço se concentra em duas tarefas. Levantar os modos de falha de cada etapa toma horas, porque depende de alguém lembrar de um evento raro. Escrever o efeito de forma legível toma mais horas, porque cada participante descreve o mesmo problema com palavras diferentes, e alguém precisa uniformizar tudo depois.

É exatamente nesse recorte, e não no cálculo do NPR, que faz sentido testar apoio de modelo de linguagem. Um FMEA preenchido mostra bem a diferença entre as colunas que exigem memória e redação e as que exigem julgamento com base em histórico.

O que a IA faz bem: lembrar do modo de falha que ninguém citou

Descreva a etapa em três ou quatro frases, peça uma lista de modos de falha e o modelo devolve entre dez e vinte itens em segundos. O valor não está nos óbvios, que a equipe já ia citar. Está nos dois ou três que ninguém lembrou porque nunca aconteceram naquela planta, mas acontecem no setor. Falha de sensor de presença que fica travado em estado alto, peça montada de cabeça para baixo quando a geometria permite, contaminação cruzada em troca de lote.

Isso funciona porque o levantamento de modos de falha é, na origem, um exercício de recuperação de memória coletiva. Um diagrama de Ishikawa faz a mesma coisa com uma estrutura de seis categorias para forçar a equipe a olhar para onde não estava olhando. O modelo cumpre esse papel de provocação com um repertório maior.

A regra de uso é tratar a lista como pauta, não como conteúdo. Cada item entra na reunião com uma pergunta objetiva: isso pode ocorrer nesta máquina, com este ferramental? O não também vale, porque descarta com registro em vez de descartar por esquecimento.

Redigir efeito e causa e padronizar a linguagem

O segundo uso é de redação. Um FMEA mal escrito não é um FMEA com análise errada; é um FMEA que ninguém consegue reler seis meses depois. Efeito descrito como "problema na montagem" não permite atribuir Gravidade, porque não diz para quem o problema aparece.

O modelo é bom em converter frase solta em estrutura fixa. Dado o padrão "efeito no cliente final, efeito na próxima operação, efeito na própria estação", ele reescreve as 40 linhas no mesmo formato em uma passada, sem cansar na linha 30 como cansa um ser humano. Na coluna de causa, instruído com a regra de que causa é aquilo em que se pode agir, ele sinaliza as linhas preenchidas com efeito disfarçado.

Isso não substitui a investigação. Encontrar a causa real continua sendo trabalho de cinco porquês com quem opera a máquina. O que o modelo entrega é a forma, não o conteúdo: uma causa mal investigada continua mal investigada, só que agora bem escrita, o que é um risco em si.

Há um ganho parecido na uniformidade entre linhas. Em FMEA grande, a mesma falha aparece descrita de três jeitos em etapas diferentes, e isso impede agrupar para priorizar e impede que a busca por texto encontre o que já foi analisado. Pedir que o modelo agrupe as descrições em famílias e proponha um termo único por família produz uma lista de sinônimos que a equipe aprova em minutos.

O que a IA faz mal: atribuir as notas de O, G e D

Aqui a conversa muda de tom. Pedir a um modelo que preencha as colunas de Ocorrência, Gravidade e Detecção produz números com aparência de análise e origem desconhecida.

A nota de Ocorrência é frequência. Na escala de dez pontos mais usada, nota 4 significa algo como uma falha a cada 2.000 peças, e esse número existe em algum lugar: registro de refugo, apontamento de parada, reclamação de garantia. O modelo não tem acesso a nenhum deles. O que ele tem é uma noção de quão comum aquele tipo de falha é em textos sobre o assunto.

A exceção parcial é a Gravidade. Ela descreve a consequência do efeito para quem recebe a peça, e isso independe bastante da planta: perda de função de segurança é 9 ou 10 em qualquer lugar. É a única das três colunas em que a sugestão do modelo costuma sobreviver à revisão, como o exemplo vai mostrar. Essa assimetria é o ponto central de qualquer discussão sobre IA na gestão da qualidade.

Por que aceitar nota sugerida por modelo é o erro mais grave

Entre todos os usos ruins de IA em FMEA, aceitar a nota sugerida é o que causa mais dano, e por uma razão estrutural: o erro não aparece.

Se o modelo inventa um modo de falha absurdo, alguém na reunião percebe e corta. Se ele escreve um efeito confuso, o revisor reescreve. Mas se ele atribui Ocorrência 4 a uma falha que na planta ocorre uma vez por semana, o número entra na planilha com a mesma cara de todos os outros. Não há sinal de alerta. O NPR sai calculado, a ordenação sai bonita, a reunião termina no horário.

Some-se a isso o efeito de ancoragem. Recebendo a planilha com notas prontas, a equipe revisa a partir daquele número em vez de formar juízo próprio. A discussão vira "4 está bom ou seria 5?" quando deveria ser "quantas vezes isso aconteceu nos últimos doze meses?". A segunda tem resposta verificável; a primeira é opinião sobre um chute. O dano só aparece meses depois, difuso, quando a contenção já foi para a linha errada.

Detecção: a nota mais dependente de contexto local

Detecção mede a capacidade do controle atual de pegar a falha antes que ela siga adiante. Nota baixa exige dispositivo que trave a peça ou a estação. Nota alta significa que a falha só será percebida pelo cliente. Entre os dois extremos há uma escala que depende de fatos muito locais.

• Existe poka-yoke naquela estação, ou o controle é inspeção visual do operador?
• A inspeção é de 100% ou por amostragem, e com que frequência?
• O dispositivo de detecção é verificado, e com que periodicidade? Poka-yoke não testado tem eficácia desconhecida.
• A falha é detectável na própria estação, na seguinte ou só no teste final de linha?
• O sistema trava a peça ou apenas registra o desvio em relatório que alguém lê no dia seguinte?

Nenhuma dessas informações está na descrição do processo que você escreveu no prompt. O modelo preenche a lacuna com o caso típico, que é o caso médio de nenhuma planta. É por isso que a coluna de controles atuais precisa estar cruzada com o plano de controle vigente antes de qualquer nota de Detecção ser escrita.

Ocorrência sem histórico: o problema por trás da nota

Ocorrência é a nota que mais revela a maturidade do sistema de dados da planta, e o procedimento honesto é declarar a base. Uma linha de FMEA madura tem a Ocorrência sustentada por uma frase do tipo "11 ocorrências em 12 meses, sobre 84 mil peças produzidas". Quem revisar depois consegue conferir. Quando não existe registro, a equipe estima, e o correto é marcar essa linha como estimativa, não disfarçá-la de dado.

Uma carta de controle da característica associada, quando existe, dá uma âncora melhor que qualquer estimativa de reunião, porque converte a frequência em taxa observada. O mesmo vale para o apontamento de parada de máquina em processos com manutenção estruturada.

Esse é o ponto em que a IA pode ajudar sem opinar sobre a nota: dado um extrato de apontamentos, ela consolida contagens por tipo de falha e devolve a taxa. A conta é conferível e a fonte é da planta. O que ela não pode fazer é converter ausência de dado em número.

FMEA de processo novo, sem histórico algum

O caso mais tentador para usar IA é o processo que ainda não existe. Máquina nova, produto novo, linha em fase de projeto. Não há refugo para contar porque não há produção.

A tentação é transferir o julgamento para o modelo, já que "ninguém sabe mesmo". O raciocínio erra em um ponto: ninguém sabe a taxa real, mas várias pessoas sabem mais do que um modelo genérico. O fornecedor tem dados de máquinas iguais em outros clientes, a engenharia tem o FMEA de um processo análogo e a manutenção conhece aquela família de acionamento.

A prática defensável é usar o FMEA análogo como base de Ocorrência, ajustado pela diferença entre os processos, e registrar essa origem na linha. Em processo novo, a Detecção costuma ser a nota mais alta, porque os dispositivos ainda não foram instalados e validados.

Onde a IA ajuda de verdade aqui é na completude da lista de modos de falha, que é justamente o ponto fraco de um processo sem histórico de campo. Em equipamento novo, cruzar essa lista com os modos de falha previstos nos pilares do TPM costuma revelar itens que o olhar de processo não captura.

A revisão pela equipe multidisciplinar continua obrigatória

FMEA nunca foi um documento técnico produzido por um especialista. É um acordo entre funções que enxergam o processo de ângulos diferentes: qualidade, produção, manutenção, engenharia e, quando pertinente, o fornecedor.

Quando o modelo preenche e a equipe apenas valida, essa troca não acontece. A reunião encurta de quatro horas para uma, o que parece ganho, e o que se perde é o mecanismo que fazia o FMEA funcionar. O documento sobrevive; o conhecimento compartilhado não.

A mesma lógica vale para a análise que vem depois. Uma análise de causa raiz feita por um modelo a partir de descrição textual produz hipóteses plausíveis e não testadas, que é o oposto do que a técnica pede.

O exemplo: o prompt e a saída do modelo

Uma estação de aperto automatizado ilustra bem a mecânica. Quatro parafusos fixam o suporte do compressor ao bloco, com parafusadeira pneumática e transdutor de torque. O prompt enviado foi este, reproduzido na íntegra.

"Você é engenheiro de processo. Liste os modos de falha da seguinte etapa de FMEA de processo. Etapa: aperto de quatro parafusos M8 do suporte do compressor ao bloco, com parafusadeira pneumática e transdutor de torque, torque especificado de 24 N.m mais ou menos 2 N.m, ciclo de 18 segundos, um operador. Para cada modo, escreva o efeito e a causa provável, e sugira notas de Ocorrência, Gravidade e Detecção na escala de 1 a 10 com o NPR."

O modelo devolveu cinco modos de falha bem construídos, com efeitos claros e causas plausíveis. A tabela abaixo traz as notas que ele sugeriu, com o NPR que ele próprio calculou.

A revisão da equipe e o NPR recalculado

A equipe reuniu produção, manutenção e qualidade, com o registro de refugo dos últimos 12 meses e o plano de controle da estação na mesa. Os cinco modos de falha foram aceitos sem alteração, e os textos de efeito e causa receberam ajustes pequenos. As notas foram outra história.

As justificativas vieram de fatos locais. A calibração é semanal e registrada, com uma única não conformidade em três anos, o que derruba a Ocorrência do torque baixo para 2. A rosca espanada subiu para 6 porque o registro mostra 11 ocorrências em 12 meses. O torque acima caiu para 1 porque o programa é travado por senha e não houve registro.

O movimento decisivo foi na Detecção do parafuso trocado. Existem dois comprimentos parecidos no mesmo carrinho de abastecimento, o transdutor fecha o torque igual nos dois e não há dispositivo que diferencie comprimento. A falha segue para o cliente. A nota foi de 5 para 7, e a Ocorrência de 2 para 4, com três registros de troca em 18 meses.

Repare que as cinco notas de Gravidade ficaram intactas. Das 15 notas sugeridas, 9 mudaram, e as 6 que sobreviveram são as 5 de Gravidade mais uma de Detecção. A assimetria não é coincidência.

Conferindo a aritmética e o que a ordem revelou

As duas ordenações foram recalculadas em Python, a partir das notas, para eliminar erro de conta e comparar as listas lado a lado.

modelo = [("Torque abaixo",4,8,3), ("Falta parafuso",3,9,2), ("Espanada",5,5,4), ("Torque acima",3,7,4), ("Trocado",2,8,5)] e equipe = [("Torque abaixo",2,8,2), ("Falta parafuso",2,9,2), ("Espanada",6,5,3), ("Torque acima",1,7,6), ("Trocado",4,8,7)], com npr = sorted([(n, o*g*d) for n,o,g,d in t], key=lambda x: -x[1]).

A soma dos NPR quase não se moveu: 414 na versão do modelo e 424 na versão da equipe, diferença de 2,4%. Um indicador agregado diria que a revisão foi irrelevante. Só uma das cinco posições se manteve, a terceira.

O item que a equipe pôs em primeiro lugar, com 224, estava em quarto na saída do modelo, com 80, diferença de 2,8 vezes. Aceita como veio, a planilha mandaria a contenção para a rosca espanada, o problema mais visível, e o parafuso de comprimento errado, o único capaz de chegar ao cliente sem barreira, ficaria sem ação.

Essa é a demonstração concreta do argumento: o modelo acertou o conteúdo e errou o peso, e é o peso que decide para onde vai o dinheiro.

IA para achar inconsistência de preenchimento

Existe um uso de IA em FMEA que é quase todo ganho e quase nenhum risco, e ele é o menos praticado: usar o modelo como auditor do que a equipe já preencheu. A pergunta que ele responde bem é de coerência interna, não de mérito, e incoerências se acumulam sem que ninguém releia a planilha inteira.

• Duas linhas com modo de falha equivalente e notas de Gravidade diferentes, sem que o efeito justifique a diferença.
• Gravidade 9 ou 10 sem nenhuma ação recomendada associada, o que contraria a regra de severidade alta.
• Detecção baixa declarada sem nenhum controle correspondente na coluna de controles atuais.
• Causa que repete o modo de falha com outras palavras, em vez de apontar mecanismo.
• Ação recomendada sem responsável ou sem prazo.
• Duas linhas com controle atual idêntico e notas de Detecção distantes.

Cada apontamento desses é verificável em segundos por quem conhece o processo, e o custo de um falso positivo é baixo. É o oposto da nota sugerida, cujo erro é invisível. Rodar essa auditoria sobre um FMEA já preenchido antes da reunião de fechamento costuma render de cinco a dez ajustes reais.

Ler FMEA antigo para atualizar

FMEA é documento vivo e quase nunca é tratado como tal. A revisão deveria disparar com mudança de processo ou falha não prevista, e é adiada porque reler 60 linhas escritas por outra equipe é penoso.

O modelo reduz esse atrito. Ele resume o FMEA existente por etapa, aponta quais linhas mencionam equipamento ou dispositivo que não existe mais e sinaliza onde o texto está vago demais para ser reavaliado. Isso transforma uma releitura de três horas em uma pauta de 20 itens.

O passo seguinte é o que dá retorno: cruzar o FMEA antigo com o que de fato aconteceu desde a última revisão. Refugo registrado, reclamação de cliente, parada de máquina. Modo de falha que ocorreu e não estava previsto é lacuna de análise. Modo previsto com Ocorrência alta e nenhum evento em dois anos é nota superestimada.

Esse cruzamento é trabalho de leitura e comparação, que é onde o modelo rende. A conclusão, de novo, é da equipe. E quando um modo de falha novo aparece, o gatilho de reação precisa virar um plano de reação escrito antes de o FMEA ser fechado.

O FMEA gerado inteiro por modelo e por que ele passa

Vale nomear o cenário que mais preocupa. Alguém com prazo curto descreve o processo, pede o FMEA completo, cola o resultado no formulário padrão da empresa e envia. O documento fica bom.

E fica bom mesmo, no sentido superficial: redação uniforme, modos de falha coerentes com a etapa, notas plausíveis e distribuição de NPR sem concentração suspeita. Um auditor que cheque estrutura não encontra nada.

O que denuncia um FMEA assim é o tipo de coisa que só a planta produz. Ausência de menção a máquina específica, a turno, a fornecedor, a evento datado. Detecção coerente demais com o controle descrito, sem a irregularidade que a realidade sempre tem. Nenhuma linha com nota estranha que exija explicação, quando todo FMEA real tem duas ou três.

O custo desse documento não é a auditoria reprovada. É que ele ocupa o lugar do FMEA verdadeiro por anos. A próxima revisão parte dele, as decisões de controle derivam dele e ninguém mais volta ao processo real para conferir. O erro se consolida por herança.

O prompt que funciona na prática

A diferença entre uma saída útil e uma saída genérica está quase toda na especificidade do que entra. Prompt de uma linha devolve conteúdo de manual.

1. Descreva a etapa com números: equipamento, parâmetro de processo, tolerância, tempo de ciclo, quantidade de operadores, material. Sem isso, a resposta serve para qualquer fábrica do mundo.
2. Peça modos de falha, efeito em três níveis e causa provável como mecanismo acionável.
3. Proíba explicitamente as notas: "não sugira valores de Ocorrência, Gravidade ou Detecção, e não calcule NPR". Isso elimina a ancoragem na origem.
4. Peça, no lugar das notas, as perguntas que a equipe precisa responder para atribuir cada nota, e a fonte de dado onde a resposta estaria.
5. Defina o formato de saída em tabela com as colunas do seu formulário, para colar sem reformatar.

O quarto item é o que mais surpreende quem testa. Em vez de um número inventado, o modelo devolve algo como "verificar a contagem de apertos rejeitados no CLP nos últimos 12 meses". Isso é pauta de investigação, e é aí que o apoio de modelo se aproxima do que se espera de IA na melhoria contínua: acelerar o trabalho de levantamento sem terceirizar o julgamento.

O protocolo de uso, em seis regras

Reduzido ao essencial, o uso defensável de IA em FMEA cabe em poucas regras, e uma delas não admite exceção.

1. A nota é sempre da equipe. Sem exceção, em qualquer coluna, em qualquer circunstância.
2. Toda nota de Ocorrência declara sua base: registro consultado ou estimativa assumida.
3. Detecção só é atribuída com o plano de controle da estação aberto.
4. Saída de modelo entra como rascunho identificado, nunca como planilha pronta.
5. A lista de modos de falha gerada é revisada item a item, com o descarte registrado.
6. Nenhum FMEA é fechado sem a reunião multidisciplinar, mesmo que ela dure uma hora.

O que muda e o que não muda no FMEA

A conclusão prática é menos dramática do que os dois extremos do debate sugerem. O modelo não torna o FMEA obsoleto e também não é acessório dispensável. Ele ataca a parte do trabalho que sempre foi custosa e pouco nobre: lembrar, redigir, padronizar, comparar e auditar texto.

O que não muda é o núcleo. FMEA é um mecanismo de priorização de recurso escasso, e isso depende de notas que codificam conhecimento local verificável. A estação de aperto mostrou com números: soma de NPR igual, ordem diferente, contenção no alvo errado.

Dentro de um ciclo DMAIC, o FMEA é ferramenta da fase de análise e alimenta diretamente a fase de controle. Uma priorização errada na análise contamina tudo o que vem depois, incluindo o plano de controle que sobrevive ao projeto.

Por isso a regra única vale mais que o protocolo inteiro: no FMEA, a nota é da equipe. A IA escreve, sugere, compara e audita. Quem decide o peso do risco é quem responde por ele.