Da necessidade à evidência

Pergunta central: qual evidência justificaria acrescentar IA a uma decisão que hoje já é tomada por pessoas, regras e sistemas?

Uma equipe recebe o pedido: “coloquem IA para priorizar as ordens de serviço”. É tentador abrir um catálogo de modelos, enviar descrições de chamados a uma API e mostrar uma demonstração. Isso prova apenas que um modelo produz texto ou uma classificação. Não prova que o sistema ajuda o usuário, reduz risco, supera o processo atual, usa dados legítimos ou continuará funcionando quando a operação mudar.

Este capítulo ensina a percorrer o caminho inverso: começar pela necessidade, identificar a decisão, construir uma alternativa simples sem IA, definir a prova antes de ver o resultado e só então decidir se um modelo merece existir. O caso condutor é um sistema de manutenção integrado ao ERP, mas o método vale para fraude, suporte, inspeção, recomendação, previsão e assistentes.

Ao final, você conseguirá

• transformar “queremos IA” em uma tarefa verificável;
• separar usuário, decisão, recomendação e efeito no mundo;
• criar um baseline não-IA, isto é, a referência simples que a solução candidata precisa superar;
• formular hipótese de valor, métrica principal e guardrails, as métricas-limite que não podem piorar;
• descrever conjunto de dados, exemplo, atributo de entrada e rótulo;
• escolher uma amostra e uma divisão de treino, validação e teste coerentes com o uso real;
• reconhecer vazamento de dados, baixa representatividade, rótulo ruim e risco de privacidade;
• encerrar corretamente com “não usar IA” quando uma regra ou melhoria de processo resolve o problema.

1. O modelo mental: a IA não é o produto

No sistema de manutenção, a finalidade não é “prever prioridade”. A finalidade pode ser reduzir o tempo até a inspeção de uma ordem realmente crítica sem inundar o supervisor com falsos alarmes. A previsão é apenas um possível mecanismo dentro desse processo.

O modelo não deve ser confundido com três papéis humanos e técnicos:

Elemento	No exemplo	Pergunta de controle
usuário	supervisor que organiza a fila	quem recebe ajuda?
decisão	escolher qual ordem revisar primeiro	qual escolha muda?
recomendação	“revisar OS-104 antes da OS-099”	o que o componente pode propor?
autorização	API verifica perfil, unidade e estado da OS	quem pode efetivar a mudança?
resultado	tempo até inspeção, falha evitada, horas gastas	como saberemos se ajudou?

Uma classificação não deve alterar estoque, interromper equipamento ou aprovar uma ordem por conta própria. Autorização continua sendo responsabilidade determinística da aplicação e de suas políticas.

O contrato da decisão em uma frase

Use este molde:

Para [usuário], ao decidir [ação], usando somente [informações disponíveis naquele instante], o sistema pode [saída permitida], mas não pode [efeito proibido], para melhorar [resultado observável] sem violar [limites].

Exemplo:

Para o supervisor, ao ordenar a inspeção das OS abertas, usando os campos existentes no momento da abertura, o sistema pode sugerir uma faixa de prioridade e explicar os sinais usados, mas não pode encerrar, aprovar ou parar equipamento; buscamos reduzir em 20% o tempo mediano até a inspeção de OS críticas sem aumentar em mais de 10% as inspeções desnecessárias.

Esse enunciado expõe entradas, saída, usuário, valor e risco. “Criar um classificador de OS” não expõe nenhum deles.

2. Antes da IA: observe o processo que já existe

O Rules of Machine Learning, do Google, recomenda não ter medo de lançar ou manter um produto sem aprendizado de máquina e medir primeiro o sistema atual. Isso é engenharia, não resistência à inovação.

Faça uma caminhada pelo processo real:

1. acompanhe quem abre a OS e quem a recebe;
2. anote campos disponíveis na abertura, não os que aparecem depois;
3. observe atalhos fora do sistema: telefone, planilha, rádio e mensagens;
4. identifique a decisão e o tempo disponível para tomá-la;
5. registre erros atuais, sua frequência e consequência;
6. descubra quem pode contestar e corrigir a prioridade;
7. meça o fluxo atual antes de propor uma mudança.

Cinco problemas que parecem pedir IA, mas talvez não peçam

Sintoma	Causa possível	Primeiro experimento sem IA
descrições incompletas	formulário ruim	campos obrigatórios e exemplos contextuais
OS críticas ficam escondidas	fila sem filtros	ordenação por criticidade e parada
técnico não encontra procedimento	busca fraca	índice textual, sinônimos e filtros
categoria inconsistente	taxonomia ambígua	reduzir categorias e orientar cadastro
supervisor demora a revisar	notificação inadequada	alerta por regra e painel de pendências

Se o formulário melhorado resolve o problema, um modelo adicionaria custo, latência, dependência, necessidade de monitoramento e novos modos de falha sem criar valor proporcional.

3. Baseline: a solução que impede autoengano

Baseline é o ponto de comparação. Pode ser o processo humano atual, uma regra, uma busca, uma média histórica, uma ordenação ou um modelo estatístico simples. Ele precisa ser executável, medido no mesmo conjunto e submetido às mesmas restrições da solução candidata.

Para triagem de OS:

def prioridade_baseline(criticidade: int, equipamento_parado: bool, temperatura_c: float) -> str:
    """Regra auditável usando somente dados disponíveis na abertura da OS."""
    if equipamento_parado or criticidade >= 5 or temperatura_c >= 95:
        return "imediata"
    if criticidade >= 3:
        return "alta"
    return "normal"

O código é pequeno de propósito. Outra pessoa consegue explicar cada resultado, testar limites e alterá-lo sem retreinar nada.

Quatro baselines úteis

1. Processo atual: a fila manual como ela funciona hoje.
2. Regra de negócio: criticidade, equipamento parado e limite físico.
3. Previsão ingênua: repetir último valor, usar média ou classe majoritária.
4. Modelo simples: regressão logística ou árvore curta, quando a comparação exige aprendizado estatístico.

O candidato não precisa vencer apenas F1 ou acurácia. Precisa justificar o custo total do sistema: desenvolvimento, inferência, latência, supervisão, segurança, privacidade, incidentes, dependência de fornecedor e manutenção dos dados. O guia oficial do Google para experimentos de ML recomenda registrar o baseline e alterar uma coisa por experimento para preservar a explicação causal do resultado.

Quando o baseline vence

Suponha que a regra encontre 94 de 100 OS críticas e gere 12 inspeções desnecessárias. Um modelo encontra 95, mas gera 30 inspeções desnecessárias, custa por chamada e não explica estabilidade. Dizer “não adotar” é a decisão tecnicamente madura.

baseline atende ao objetivo e aos limites?
        ├── sim → existe ganho líquido material do candidato?
        │          ├── não → manter baseline
        │          └── sim → piloto controlado
        └── não → problema está em regra, processo, dados ou capacidade?
                   ├── processo/dados → corrigir antes do modelo
                   └── padrão complexo e avaliável → testar candidato

4. Hipótese de valor: uma previsão sobre o sistema, não sobre o modelo

Uma hipótese boa pode falhar. Ela declara mudança, população, comparação, medida, prazo e limites:

Se mostrarmos ao supervisor uma sugestão de prioridade para OS abertas da unidade Norte, então o tempo mediano até a inspeção de OS críticas cairá pelo menos 20% em quatro semanas, comparado à regra versionada, sem aumentar mais de 10% as inspeções sem ação e sem executar alterações automaticamente.

Uma hipótese ruim é “o modelo terá 90% de acurácia”. Ela não informa se 90% cria valor, qual erro importa, quem usa ou o que não pode piorar.

Métrica, alvo e guardrail

• Métrica: medida observada, como tempo até inspeção.
• Alvo: mudança mínima considerada útil, como redução de 20%.
• Guardrail: limite que protege outro aspecto, como falsos alarmes, latência, custo ou disparidade entre unidades.

Tipo	Exemplo	Por que existe
valor	tempo mediano até inspeção crítica	mede o resultado desejado
qualidade	recall de OS críticas	mede quantas críticas foram encontradas
carga humana	inspeções sem ação por semana	impede transferir custo ao supervisor
segurança	zero execução sem autorização	limita o efeito técnico
equidade operacional	recall por unidade e tipo de ativo	revela degradação escondida na média
desempenho	p95 de latência abaixo de 800 ms	protege experiência e operação
custo	custo total por OS corretamente priorizada	compara sistemas, não chamadas isoladas

A matriz de confusão em linguagem operacional

Para “OS crítica”:

Realidade	Sistema alerta	Sistema não alerta
crítica	verdadeiro positivo: inspeção útil	falso negativo: risco perdido
não crítica	falso positivo: trabalho extra	verdadeiro negativo: fluxo normal

Precisão pergunta: entre os alertas, quantos eram críticos? Recall pergunta: entre as OS críticas, quantas foram alertadas? Se perder uma falha crítica custa muito mais que inspecionar em excesso, recall recebe mais peso — mas o guardrail de carga impede alertar tudo.

Em eventos raros, acurácia pode enganar: se 1% das ordens é crítica, responder “não crítica” sempre produz 99% de acurácia e recall zero. A documentação oficial do scikit-learn sobre avaliação apresenta métricas por tipo de tarefa; a escolha concreta continua sendo uma decisão do domínio.

5. O conjunto de dados é uma amostra do mundo

Um conjunto de dados é uma coleção organizada de exemplos. Para triagem, a unidade de análise pode ser “uma OS no instante em que entrou na fila”. Cada exemplo contém:

• atributos de entrada (features): informações disponíveis para produzir a sugestão;
• rótulo (label): resposta usada para treino ou avaliação;
• metadados de proveniência: origem, período, unidade, versão e condições de coleta.

Exemplo conceitual:

{
  "os_id": "OS-104",
  "instante_da_decisao": "2026-06-02T08:15:00-03:00",
  "entradas": {
    "criticidade_cadastrada": 5,
    "equipamento_parado": true,
    "tipo_de_ativo": "chiller",
    "descricao": "pressão caiu e compressor desligou"
  },
  "rotulo": "exigiu_intervencao_critica_em_4_horas",
  "proveniencia": "ERP/manutencao/unidade-norte"
}

O ID não deve virar atributo de previsão apenas porque está no arquivo. Ele serve a rastreabilidade. Nomes de técnico, telefone e texto livre podem conter dados pessoais e não entram automaticamente: cada campo precisa de finalidade, necessidade e controle.

Rótulo não é “a verdade” por natureza

Rótulos podem vir de sensores, resultado operacional, regra, especialista ou comportamento do usuário. Cada origem possui erro:

• “prioridade escolhida pelo supervisor” pode reproduzir hábito inconsistente;
• “OS encerrada em quatro horas” pode medir facilidade, não criticidade;
• “houve troca de componente” pode depender de estoque disponível;
• “usuário clicou na sugestão” mede interação, não correção.

O guia do Google sobre rótulos diferencia rótulos diretos e proxies e recomenda inspeção manual e comparação com avaliação humana. Para o ERP, defina um protocolo: dois especialistas classificam uma amostra sem ver a previsão; divergências são conciliadas e registradas. Se nem especialistas concordam, primeiro refine a definição da tarefa.

6. Amostragem e representatividade

A população-alvo é o conjunto de situações em que o sistema será usado. A amostra é a parte observada dessa população. Representatividade significa que a amostra cobre suficientemente as condições relevantes do uso; não significa apenas “ter muitas linhas”.

Uma base com um milhão de OS de iluminação pode ser inadequada para priorizar falhas de chillers. Uma amostra pequena, mas deliberadamente distribuída por unidade, tipo de ativo, estação, turno e severidade, pode revelar mais sobre o risco.

Procure:

• viés de cobertura: parte da população nem pode aparecer na coleta;
• viés de seleção: a forma de escolher casos altera sistematicamente a amostra;
• viés de sobrevivência: só restam casos que passaram por determinado processo;
• não resposta: certos grupos deixam menos feedback;
• cauda rara: poucos casos, mas com impacto alto.

O material oficial do Google sobre qualidade e interpretação de dados descreve como vieses de amostragem e dados incorretos distorcem conclusões. O NIST AI RMF exige governar, mapear, medir e gerenciar riscos no contexto; uma média agregada não substitui essa análise.

7. Treino, validação e teste: três papéis diferentes

• Treino: dados usados para ajustar parâmetros ou construir a solução.
• Validação: dados usados durante escolhas de atributos, regras, limiares e configurações.
• Teste: prova preservada para estimar desempenho após as escolhas.

Se você consulta o teste, muda o prompt e testa novamente, transformou o teste em validação. É necessário um novo conjunto de teste ou uma avaliação externa.

Escolha a divisão conforme a pergunta de generalização

Pergunta real	Divisão adequada
funcionará em OS futuras dos mesmos ativos?	corte temporal
funcionará em equipamentos nunca vistos?	grupos por equipamento
funcionará em nova unidade?	holdout por unidade
há exemplos independentes e estáveis?	aleatória, possivelmente estratificada

Em manutenção, linhas do mesmo equipamento são correlacionadas. Sortear aleatoriamente pode colocar sintomas quase idênticos do mesmo incidente nos dois lados. Se o objetivo é generalizar para ativos novos, mantenha todo o histórico de um equipamento no mesmo grupo.

8. Vazamento: quando a prova recebe uma pista do futuro

Vazamento de dados (data leakage) ocorre quando treino, seleção ou avaliação usa informação que não estaria disponível no instante real da decisão. O resultado offline fica artificialmente otimista.

Exemplos no ERP:

1. usar “horas de parada acumuladas” calculadas depois do encerramento para priorizar na abertura;
2. normalizar valores com média calculada sobre treino e teste juntos;
3. deduplicar depois do split, deixando cópias do mesmo texto nos dois lados;
4. escolher o melhor prompt olhando repetidamente o holdout;
5. incluir status final da OS como atributo;
6. deixar incidentes do mesmo equipamento em treino e teste quando o objetivo era avaliar equipamento novo.

A documentação oficial do scikit-learn sobre armadilhas comuns recomenda separar treino e teste antes do pré-processamento e nunca ajustar transformações com o teste. Um Pipeline ajuda a aplicar fit somente no treino, mas não corrige um campo semanticamente futuro. A equipe precisa conhecer o processo.

Teste da máquina do tempo

Para cada atributo, pergunte:

Este valor existia, com esta qualidade e neste sistema, no instante exato em que a recomendação seria produzida?

Se a resposta for “não”, “às vezes” ou “só depois de uma correção manual”, o atributo não pode entrar sem uma regra explícita de disponibilidade.

9. Qualidade de dados é adequação ao uso

“Dados limpos” é insuficiente. Avalie dimensões concretas:

Dimensão	Pergunta	Controle
completude	campos essenciais estão preenchidos?	taxa de nulos por origem e período
validade	valor respeita formato e domínio?	schema e limites físicos
consistência	sistemas discordam sobre o mesmo fato?	reconciliação e fonte de verdade
unicidade	o mesmo evento foi duplicado?	chave e regra de deduplicação antes do split
atualidade	dado chega antes da decisão?	timestamp de evento e ingestão
exatidão	campo corresponde ao mundo?	amostragem e auditoria humana/sensor
estabilidade	significado mudou no tempo?	versionamento de taxonomia e drift
proveniência	sabemos de onde veio e o que ocorreu?	linhagem, versão e responsável

Documente também ausências. “Temperatura nula” pode significar sensor quebrado, ativo sem sensor, integração atrasada ou valor removido por privacidade. Preencher tudo com zero mistura estados distintos.

O trabalho Datasheets for Datasets propõe registrar motivação, composição, coleta, usos e limitações do dataset. A pesquisa Data Cascades in High-Stakes AI mostra empiricamente como problemas de dados negligenciados propagam efeitos a jusante. A lição prática é tratar o dataset como produto versionado, com dono e teste, não como arquivo descartável.

10. Privacidade desde a formulação

Dados de OS podem revelar nome, turno, localização, comportamento, voz, imagem e condição de trabalho. A pergunta não é apenas “podemos acessar?”, mas “é necessário para esta finalidade?”. Os princípios de finalidade, adequação, necessidade, segurança, prevenção e qualidade previstos na LGPD devem orientar o ciclo. Consulte a síntese oficial dos princípios da LGPD e, em projeto real, envolva responsáveis jurídicos e de privacidade.

Controles mínimos:

• declarar finalidade e base aplicável antes da coleta;
• excluir campos que não agregam valor comprovado;
• pseudonimizar identificadores quando a identidade não é necessária;
• restringir acesso por função e ambiente;
• criptografar transporte e armazenamento;
• registrar proveniência, acesso e exportação;
• definir retenção e exclusão, inclusive para cópias de experimento;
• impedir que texto livre com segredo seja enviado a fornecedor sem contrato e controle;
• testar métricas por segmento sem publicar grupos tão pequenos que reidentifiquem pessoas.

Anonimizar não é apagar uma coluna de nome: combinações de horário, unidade, cargo e incidente podem reidentificar alguém.

11. O critério de parada precisa existir antes do experimento

Sem condição de parada, a equipe pode perseguir indefinidamente uma demonstração melhor. Declare quatro saídas legítimas:

Saída	Evidência
adotar baseline não-IA	atende valor e guardrails com menor custo/risco
corrigir processo/dados	não há definição ou observação confiável
testar IA em shadow mode	há padrão complexo, avaliação válida e risco contido
encerrar iniciativa	ganho mínimo não aparece ou custo/risco é incompatível

Exemplo de gate:

Parar e manter a regra se ela alcançar recall crítico ≥ 0,90, falsos alarmes ≤ 15 por semana e tempo de decisão < 200 ms. Testar IA somente se a análise de erros mostrar um segmento material que a regra não captura. Não liberar se qualquer unidade tiver recall < 0,80, se houver atributo indisponível na abertura ou se a revisão humana exceder a capacidade acordada.

Critérios podem mudar quando o negócio aprende, mas a mudança deve ser registrada antes de consultar novamente o teste.

12. Caminho completo no sistema de manutenção

sequenceDiagram
  participant T as Técnico
  participant ERP as ERP
  participant B as Baseline versionado
  participant C as Candidato
  participant S as Supervisor
  participant E as Avaliação
  T->>ERP: abre OS com dados validados
  ERP->>B: calcula prioridade por regra
  ERP->>C: solicita sugestão em shadow mode
  B-->>E: registra saída e versão
  C-->>E: registra saída e versão
  ERP->>S: exibe fila oficial + sugestão não vinculante
  S->>ERP: decide e justifica correção
  ERP-->>E: resultado posterior curado
  E-->>E: compara valor, erros, segmentos, custo e guardrails

No shadow mode, o candidato roda e é medido, mas sua saída não controla a operação. Isso permite descobrir vazamento, latência, custo e erro sem delegar o efeito. Depois, se os gates forem cumpridos, um piloto limitado pode exibir a sugestão a usuários treinados, com retirada imediata para a regra.

13. Erros comuns e diagnóstico

Sintoma	Causa provável	Diagnóstico	Correção
offline excelente, produção ruim	leakage ou mudança de distribuição	reconstruir linha do tempo de cada atributo	split coerente e teste de disponibilidade
média boa, uma unidade ruim	amostra não representativa	métricas por unidade/ativo/turno	coletar e avaliar segmentos relevantes
especialistas discordam	definição de rótulo ambígua	medir concordância e revisar casos	protocolo de rotulagem e adjudicação
modelo “melhora” clique, não resultado	proxy inadequado	seguir cadeia até desfecho operacional	métrica de valor e guardrails
todo experimento parece melhor	teste reutilizado	auditar histórico de decisões	novo holdout e registro de experimentos
coleta cresce sem limite	finalidade vaga	inventário de campos, acesso e retenção	minimização e descarte verificável

14. Critérios de aceite do problem card

Seu artefato está pronto quando outra pessoa consegue responder, sem explicação oral:

• quem é o usuário e qual decisão recebe apoio;
• quais informações existem no instante da decisão;
• qual saída é permitida e qual efeito é proibido;
• qual baseline reproduzível representa o processo atual;
• qual hipótese de valor será refutada ou sustentada;
• qual métrica principal, alvo e guardrails foram definidos antes do resultado;
• qual é a população-alvo e como a amostra a representa;
• como o rótulo é produzido, auditado e contestado;
• por que o split simula o futuro relevante;
• quais campos foram rejeitados por leakage ou privacidade;
• qual decisão será tomada em cada faixa de resultado;
• quando “não usar IA” será registrado como conclusão.

15. Exercícios

Exercício 1 — retire a palavra IA

Reescreva “usar IA para prever falhas” sem mencionar tecnologia. Inclua usuário, decisão, instante, ação permitida, resultado e limite. Evidência: uma frase no molde do contrato e três perguntas ainda não respondidas.

Exercício 2 — duelo de baselines

Crie dois baselines para priorização: fila por ordem de chegada e regra por criticidade. Rode ambos em pelo menos 30 casos históricos. Entregue matriz de confusão, tempo de decisão, esforço de revisão e três piores erros. Não treine modelo.

Exercício 3 — caça ao vazamento

Classifique cada campo como “disponível”, “indisponível” ou “incerto” no instante da abertura: data de encerramento, peça substituída, temperatura inicial, texto do laudo final, histórico anterior do ativo, nome do aprovador. Para cada “incerto”, identifique o sistema e timestamp que provariam disponibilidade.

Exercício 4 — transferência

Aplique o mesmo método a um assistente que sugere respostas de suporte. Defina baseline de busca, rótulo, split, dois vazamentos possíveis, um guardrail de privacidade e a condição de não adotar.

16. Recuperação ativa

Responda sem consultar:

1. Por que “90% de acurácia” não é uma hipótese de valor?
2. Qual diferença entre métrica principal e guardrail?
3. Quando uma regra simples é um resultado melhor que um modelo?
4. Por que o rótulo “prioridade escolhida” pode ser um proxy ruim?
5. Qual split usaria para avaliar equipamentos nunca vistos?
6. Dê dois exemplos de leakage no ERP.
7. O que torna uma amostra representativa para a decisão?
8. Qual evidência faria você encerrar a iniciativa de IA?

Conclusão

A primeira competência de um engenheiro de IA não é escolher modelo; é transformar uma necessidade em decisão mensurável e saber recusar complexidade sem evidência. O baseline protege contra a sedução da demonstração. A hipótese conecta tecnologia a valor. Métricas e guardrails tornam o ganho refutável. Dados, rótulos, amostragem e split definem o que a avaliação realmente significa. Privacidade e leakage delimitam o que pode ser usado. O critério de parada devolve à equipe a opção mais importante: manter a solução simples quando ela já resolve o problema.

O próximo caderno transforma esse raciocínio em um pacote executável, introduz falhas deliberadas e exige uma decisão auditável: adotar, investigar ou não usar IA.

Fontes primárias e oficiais

• NIST — Artificial Intelligence Risk Management Framework 1.0
• NIST — AI RMF Playbook
• Google — Rules of Machine Learning
• Google — Problem Framing: Understand the problem
• Google — Managing ML projects: Experiments
• Google — Datasets: Labels
• Google — Data quality and interpretation
• scikit-learn — Common pitfalls and recommended practices
• scikit-learn — Metrics and scoring
• Gebru et al. — Datasheets for Datasets
• Sambasivan et al. — Data Cascades in High-Stakes AI
• Sculley et al. — Hidden Technical Debt in Machine Learning Systems
• Governo Federal — Princípios da LGPD

Relações

Este capítulo depende de requisitos de produto e fundamentos de probabilidade. Ele prepara o estudo de avaliação, segurança, observabilidade, RAG e operação: todos dependem de um problema bem formulado e de uma prova que não se confunde com a demonstração.