Como classificar correções manuais em IA

Correções de usuários em IA não devem ser tratadas como defeito automático nem como opinião descartável. Elas são evidências graduadas. A decisão útil é separar correções cosméticas, correções de contexto e correções que revelam falha de produto.

Neste artigo, há sinal de falha quando a saída da inteligência artificial viola uma expectativa explícita, gera retrabalho relevante, altera uma decisão operacional ou produz um resultado incompatível com o objetivo da funcionalidade.

O critério para tratar uma correção manual como evidência de falha

Imagine uma funcionalidade com IA que sugere uma resposta para um atendimento, resume uma conversa interna ou propõe a próxima ação em um fluxo operacional. O usuário lê, ajusta e segue em frente. O produto registra que houve edição.

A pergunta começa aí: essa edição foi apenas gosto pessoal ou o sistema errou de um jeito que precisa mudar o produto?

Uma correção manual deve entrar como evidência de falha quando a resposta original descumpre algo que a funcionalidade já deveria respeitar. Isso pode ser uma regra de negócio, uma informação disponível no fluxo, uma restrição operacional, um critério de sucesso definido ou uma promessa feita pela própria interface.

O tamanho da edição não resolve a dúvida. Uma troca de palavra pode impedir uma promessa indevida. Uma reescrita longa pode ser apenas preferência de tom. Por isso, o time precisa observar o desvio que a correção revela, não a quantidade de texto alterado.

Um critério inicial ajuda:

Há falha potencial quando a correção muda uma informação factual, uma recomendação, uma ação, uma autorização ou uma promessa.
Há falha potencial quando a saída original contraria o objetivo declarado da funcionalidade.
Há falha potencial quando o usuário precisa corrigir algo que o sistema já tinha contexto suficiente para acertar.
Há preferência provável quando a correção muda voz, ordem, concisão ou estilo sem alterar a decisão nem o sentido operacional.

Esse enquadramento evita dois extremos ruins. O primeiro é transformar toda edição em incidente e paralisar o aprendizado. O segundo é tratar toda edição como ruído e deixar o produto repetir o erro com aparência de normalidade.

Sem essa triagem, a taxa de correções mistura preferência, contexto ausente e risco real. O DORA recomenda que testes sejam feitos ao longo do desenvolvimento, combinando automação e atividades manuais, como exploração e usabilidade, em vez de tratar qualidade como uma etapa posterior (DORA). Correções de usuários podem alimentar esse ciclo, desde que sejam classificadas com critério.

Classifique a correção pelo dano que ela evitou, não pelo tamanho da edição

Uma boa triagem começa por uma pergunta simples: que dano a correção evitou?

Se a resposta for “deixou mais simpático”, o caso provavelmente pertence a usabilidade, personalização ou preferência. Se a resposta for “impediu uma orientação errada”, “corrigiu uma informação”, “evitou uma ação indevida” ou “mudou a próxima etapa do processo”, o caso merece tratamento mais sério.

Uma escala prática pode separar três níveis de impacto.

Baixo impacto: a correção altera estilo, tom, ordem, formato ou vocabulário sem mudar a orientação final. O usuário preferiu uma frase mais direta, uma saudação menos formal ou um parágrafo mais curto. Isso pode informar opções de personalização, mas não deveria virar defeito automaticamente.

Médio impacto: a correção adiciona contexto que o sistema não tinha, mas talvez devesse ter pedido. O problema pode estar no desenho do fluxo, não no modelo. Se a interface não solicita uma informação necessária, a IA opera no escuro e o usuário vira fornecedor tardio de contexto.

Alto impacto: a correção muda fato, cálculo, recomendação, ação, obrigação, autorização, restrição ou próxima etapa. Aqui existe risco de falha de produto, mesmo que a edição pareça pequena.

Essa distinção protege a métrica. Uma taxa bruta de correções pode subir porque os usuários estão personalizando mais, porque a interface está pedindo pouco contexto ou porque a IA está errando decisões relevantes. Esses cenários exigem respostas diferentes.

A liderança não deve perguntar apenas “quantas correções houve?”. Deve perguntar “quais correções mudariam nossa decisão de liberar, limitar, reverter ou redesenhar esta funcionalidade?”.

Separe preferência do usuário, falta de contexto e erro do sistema

Produto, engenharia e qualidade costumam misturar três causas que parecem iguais no registro bruto: preferência, contexto ausente e erro do sistema.

Preferência aparece quando o usuário corrige para deixar do seu jeito. Ele muda o grau de formalidade, reorganiza frases ou aproxima a resposta do seu repertório. A saída original não estava necessariamente errada. Ela apenas não era a versão preferida por aquela pessoa, naquele momento.

Falta de contexto aparece quando o usuário adiciona informação que a IA não recebeu. A pergunta aqui é desconfortável: o produto deveria ter solicitado essa informação antes de gerar a resposta? Se sim, a correção aponta para desenho de fluxo. Talvez falte um campo, uma confirmação, uma escolha explícita ou uma integração já disponível no próprio produto.

Erro do sistema aparece quando havia contexto suficiente e, mesmo assim, a IA prometeu, inferiu, classificou, sugeriu ou executou algo errado. Nesse caso, a investigação pode envolver prompt, recuperação de informação, regra de negócio, avaliação, modelo, permissões ou interface. Não dá para escolher a solução antes de classificar a causa.

Três perguntas resolvem boa parte da triagem inicial:

O usuário corrigiu para adaptar voz, formato ou preferência individual?
O usuário corrigiu porque faltava informação que a entrada ou a interface não capturou?
O usuário corrigiu porque o sistema errou mesmo com contexto suficiente?

Essa separação também reduz a tentação de culpar o usuário. Se uma pessoa corrige sempre o mesmo tipo de ausência, talvez o produto esteja pedindo pouco. Se diferentes pessoas removem sempre o mesmo tipo de promessa, talvez o sistema esteja extrapolando. Se as correções variam apenas em tom, talvez o caminho seja configuração, não investigação de falha.

Esse raciocínio conversa com a necessidade de conectar IA a decisão de produto, não apenas a demonstrações de capacidade. Em uma estratégia mais ampla de adoção, como discutido em como criar uma estratégia de inteligência artificial conectada ao negócio, a pergunta relevante não é se a IA gera uma resposta plausível. É se ela sustenta o trabalho certo, com risco aceitável e critérios verificáveis.

Use um registro mínimo para transformar correções em aprendizado

Registrar correções não significa criar um cemitério de eventos. O registro só vale se ajudar alguém a decidir.

Um registro mínimo deve preservar o suficiente para reconstruir o caso sem exigir uma investigação inteira a cada edição. Campos úteis incluem:

entrada original do usuário ou do sistema;
saída original da IA;
correção feita pelo usuário;
intenção provável do usuário ao corrigir;
etapa do fluxo em que a correção ocorreu;
impacto estimado da correção;
recorrência em casos parecidos;
decisão tomada após revisão;
responsável pela próxima ação.

A intenção não é transformar cada usuário em avaliador formal. A intenção é impedir que o time olhe apenas para o texto final e perca a diferença entre o que a IA propôs e o que foi aceito.

Esse ponto é especialmente sensível em funcionalidades que executam ações ou orientam próximos passos. A Anthropic distingue a trajetória de execução de um agente do resultado efetivo no ambiente: uma mensagem dizendo que a tarefa terminou não basta para comprovar o resultado (Anthropic). Mesmo quando o produto não é um agente autônomo, a lição é útil: o registro precisa capturar resultado e critério, não apenas aparência de conclusão.

O mesmo vale para correções manuais. Saber que “houve edição” é pouco. Saber que a edição removeu uma promessa, corrigiu um fato ou adicionou uma condição que o fluxo não pedia muda a conversa.

Exemplo fictício: assistente que sugere respostas de atendimento

Considere um exemplo fictício de uma empresa que usa um assistente para sugerir respostas de atendimento. O sistema lê a solicitação do cliente e propõe uma resposta para o atendente revisar antes de enviar.

No primeiro caso, a IA escreve uma resposta correta, mas muito formal. O atendente troca “Prezado cliente” por uma saudação mais simples e encurta o encerramento. A decisão operacional não muda. A informação não muda. A promessa não muda. Essa correção indica preferência de voz ou ajuste de usabilidade. Pode alimentar opções de tom, mas não deveria ser tratada como falha de produto.

No segundo caso, a IA sugere uma resposta genérica. O atendente adiciona uma condição da política comercial que não estava visível na tela usada pelo sistema. A correção muda a utilidade da resposta, mas a causa ainda não está clara. Talvez o modelo não tenha acessado a regra. Talvez a regra não estivesse disponível. Talvez a interface não tenha pedido o tipo de cliente, o canal ou a condição necessária. O caso deve entrar como falta de contexto ou regra ausente até que a causa seja investigada.

No terceiro caso, a IA inclui uma promessa que a empresa não pode cumprir. O atendente remove a frase antes de enviar. A edição é pequena, mas o dano evitado é alto. Mesmo que tenha ocorrido uma única vez, a correção deve ser classificada como falha potencial, porque a saída original criou uma expectativa incompatível com o objetivo da funcionalidade e com o que a empresa podia cumprir.

O exemplo não prova resultado. Ele mostra como a mesma métrica, “usuário editou a resposta”, pode representar três fenômenos distintos. Medir apenas o volume de correções misturaria preferência, contexto ausente e falha de produto em uma média pouco acionável.

Quando uma correção deve virar teste, regra ou mudança de produto

Depois da triagem, vem o encaminhamento. Nem toda correção precisa virar teste. Nem toda correção grave permite uma regra imediata. O melhor próximo passo depende da natureza do desvio.

A correção deve virar teste quando o erro é reproduzível e existe critério de sucesso. Por exemplo: diante de uma entrada específica, a resposta não pode conter determinada promessa, deve incluir uma condição objetiva ou precisa classificar corretamente uma situação conhecida. Nesse caso, o time consegue criar um caso de avaliação com entrada, resultado esperado e verificador.

A correção deve virar regra quando revela uma restrição objetiva que precisa ser sempre respeitada. Regras desse tipo não deveriam depender apenas de preferência do modelo ou do redator do prompt. Se uma promessa nunca pode ser feita, se uma ação exige autorização ou se uma condição precisa aparecer em todo cenário aplicável, a restrição deve ser explicitada no produto.

A correção deve virar mudança de interface quando o usuário acrescenta contexto que o fluxo deveria solicitar antes da geração. Nesses casos, melhorar o prompt pode mascarar o problema. O sistema continuará tentando adivinhar o que precisava perguntar.

A correção deve virar investigação quando o impacto é alto, mas a causa ainda não está clara. Investigar não é adiar indefinidamente. É preservar a pergunta certa antes de mexer no modelo, no prompt, na regra, na base de conhecimento ou na experiência.

O Google SRE discute lançamentos graduais como forma de avaliar uma mudança em uma parcela do tráfego antes de ampliar a exposição, além de distinguir disponibilizar código de ativar funcionalidades por configuração (Google SRE). A lógica é útil para produtos com IA: quando uma mudança nasce de correções manuais graves, a decisão de ampliar exposição deve considerar controle por configuração e critérios observáveis.

Essa decisão também se conecta ao planejamento de adoção. Um roadmap de IA precisa reservar espaço para avaliação, revisão e ajustes de produto. Sem isso, correções manuais viram apenas manutenção reativa.

Filtro de decisão para correções manuais

Use as perguntas abaixo como filtro de decisão. Elas não substituem avaliação técnica, mas ajudam a impedir que o time trate todos os casos com o mesmo peso.

A correção altera uma informação factual, uma recomendação, uma ação ou uma promessa feita ao usuário? Se sim, trate como candidata a falha de produto e revise com prioridade maior do que correções de tom.
A saída original violou um critério de sucesso já definido para a funcionalidade? Se sim, registre como falha contra critério existente e avalie inclusão em teste ou avaliação recorrente.
O usuário precisou adicionar contexto que a interface não pediu? Se sim, investigue o desenho do fluxo antes de culpar modelo, prompt ou usuário.
A mesma correção aparece em situações parecidas? Se sim, classifique como padrão recorrente e priorize análise de causa.
A correção evitou risco operacional, reputacional, de segurança ou de decisão indevida? Se sim, escale como falha potencial mesmo que tenha ocorrido uma única vez.
A correção é apenas ajuste de voz, formato ou preferência individual? Se sim, mantenha como sinal de personalização ou usabilidade, sem tratá-la automaticamente como defeito.
Existe forma objetiva de verificar a saída correta? Se sim, transforme o caso em avaliação com entrada, critério de sucesso e verificador. Se não, encaminhe para revisão qualitativa com amostras comparáveis.

O ponto mais forte do checklist é forçar uma pergunta antes da solução. A correção pede teste, regra, mudança de interface, investigação ou apenas personalização?

Como revisar correções sem punir o usuário nem maquiar a métrica

Correções manuais são parte normal de muitos produtos com IA. O problema começa quando a organização usa a métrica para procurar culpados ou para defender uma narrativa pronta.

Se a taxa de correção cai, isso não prova qualidade: usuários podem ter desistido de corrigir, aceitado respostas medianas ou migrado para tarefas mais simples. Se a taxa sobe, isso também não prova fracasso: os cenários podem estar mais complexos ou a personalização pode ter aumentado.

A METR, ao discutir limites de medição de produtividade em fevereiro de 2026, aponta dificuldades como seleção de participantes e tarefas e a medição de tempo com agentes concorrentes, tratando novos dados como sinal pouco confiável do efeito atual da IA sobre produtividade (METR). A fonte não fala sobre correções manuais como métrica de qualidade, mas reforça uma cautela aplicável: indicadores isolados podem enganar quando o trabalho observado muda junto com a ferramenta.

Por isso, a revisão deve combinar leitura humana, critérios de sucesso, verificadores quando possível e análise de recorrência. Avaliação humana não substitui testes. Testes não capturam toda preferência. Métrica agregada não explica causa. Cada instrumento enxerga uma parte.

A pergunta útil não é apenas se o usuário corrigiu. É se a correção revelou preferência, contexto ausente, falha potencial ou necessidade de investigação.

Classifique correções manuais em quatro destinos: preferência, contexto ausente, falha potencial ou investigação. A partir daí, decida se o próximo passo é personalizar, redesenhar a interface, criar teste, explicitar regra, limitar exposição ou revisar a funcionalidade.

Acompanhar correções de usuários em IA exige separar quais edições mudam o risco do produto e quais apenas mostram como pessoas trabalham com a ferramenta.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

Para continuar esta leitura

Como preparar um plano de reversão de funcionalidades de IA

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.