Bellacosa Mainframe e o automation bias

☕ Um Café no Bellacosa Mainframe

Automation Bias: Doctor Who, COBOL e o Dia em que a Máquina Disse “Está Tudo Certo” — e Todo Mundo Acreditou

Uma viagem pela TARDIS dos incidentes para entender por que automação, dashboards, scripts e IA podem nos ajudar tanto quanto podem nos convencer a ignorar nossos próprios olhos

06:47.

Centro de operações.

Primeiro café.

Segundo monitor.

Terceiro alerta.

Nada particularmente dramático.

Na tela principal:

SYSTEM STATUS
-------------------------
CPU        GREEN
DB2        GREEN
CICS       GREEN
MQ         GREEN
STORAGE    GREEN
BATCH      GREEN

OVERALL STATUS: HEALTHY

Nosso jovem programador COBOL observa.

Tudo verde.

Excelente.

Mas existe uma coisa estranha.

Usuários começaram a reclamar.

Poucos.

Ainda assim:

— O saldo não atualizou.

Outro:

— Minha transação ficou pendente.

Outro:

— O pagamento aparece processado, mas não chegou.

O programador olha novamente para o painel.

OVERALL STATUS: HEALTHY

Ele pergunta ao operador:

— Pode existir problema mesmo tudo estando verde?

O operador responde:

— Se tivesse problema, o monitoramento mostraria.

Pausa.

Uma frase simples.

Muito confortável.

Muito perigosa.

08:12.

Mais reclamações.

08:37.

Fila de chamados crescendo.

09:03.

Ainda:

OVERALL STATUS: HEALTHY

Nosso programador começa a acreditar que talvez os usuários estejam enganados.

Talvez cache.

Talvez navegador.

Talvez percepção.

Afinal...

o sistema está dizendo que está tudo bem.

VWORP.

A TARDIS materializa-se perto do console.

A porta abre.

O Doctor sai.

Olha para o painel.

Depois para os chamados.

Depois novamente para:

HEALTHY

— O sistema diz que está saudável?

— Sim.

— E os usuários dizem que não?

— Sim.

— Então qual dos dois vocês estão investigando?

Silêncio.

O Doctor sorri.

— Ah. Excelente.

Pausa.

— Vocês criaram uma máquina para ajudar humanos a tomar decisões...

Olha para o dashboard.

— ...e agora deixaram a máquina decidir quais fatos merecem existir.

Bem-vindo ao:

Automation Bias

Ou:

Viés de Automação

A tendência humana de confiar excessivamente em sistemas automáticos, recomendações, dashboards, algoritmos, assistentes, scripts ou inteligências artificiais — às vezes até quando existem sinais claros de que a automação pode estar errada, incompleta ou operando fora do contexto esperado.

🌀 Onde estamos na nossa TARDIS dos incidentes?

Nossa coleção já está respeitável.

Passamos pelo:

Swiss Cheese Model — várias barreiras podem falhar juntas.

Depois:

Normalization of Deviance — desvios repetidos deixam de parecer perigosos.

Depois:

Hindsight Bias — o passado parece óbvio quando já conhecemos o final.

Depois:

Confirmation Bias — escolhemos evidências que reforçam nossas crenças.

Depois:

Anchoring Bias — a primeira explicação influencia demais.

Depois:

Groupthink — um grupo inteiro pode concordar e ainda assim estar errado.

Depois:

Authority Gradient — alguém sabe que existe problema, mas não consegue desafiar quem tem mais autoridade.

Depois:

Plan Continuation Bias — continuamos um plano porque já investimos demais.

Depois:

Alarm Fatigue — o sistema alerta tanto que ninguém mais escuta.

Agora temos quase o fenômeno oposto.

Em Alarm Fatigue:

a máquina fala e ignoramos.

Em Automation Bias:

a máquina fala e acreditamos demais.

Parece contraditório.

Na verdade, ambos mostram a mesma coisa:

nossa relação com automação pode ficar desequilibrada.

🤖 O que é Automation Bias?

Automation Bias acontece quando humanos atribuem credibilidade excessiva à saída de um sistema automático.

Exemplo:

AUTOMAÇÃO DIZ:
“TUDO OK”
        ↓
HUMANO PENSA:
“ENTÃO ESTÁ OK”
        ↓
EVIDÊNCIA CONTRÁRIA APARECE
        ↓
HUMANO REINTERPRETA OU IGNORA

Ou o contrário:

AUTOMAÇÃO DIZ:
“ERRO”
        ↓
HUMANO ASSUME:
“EXISTE ERRO”

mesmo que contexto mostre outra coisa.

A automação deixa de ser:

fonte de informação

e vira:

autoridade epistemológica.

Bonita expressão para:

“Se o computador disse, deve ser verdade.”

💻 Para um programador COBOL iniciante: computador não sabe que está certo

Essa ideia é fundamental.

Um programa não sabe que está correto.

Ele apenas executa lógica.

Se você escreve:

IF WS-STATUS = 'OK'
    DISPLAY 'SISTEMA SAUDAVEL'
END-IF.

e a variável WS-STATUS estiver errada...

o programa exibirá alegremente:

SISTEMA SAUDAVEL

O computador não ficará constrangido.

Não levantará a mão.

Não dirá:

— Desculpe, acho que estou sendo alimentado com dados incompletos.

Ele executará.

Perfeitamente.

A lógica errada.

☕ Bellacosa Mainframe: o dashboard verde

Imagine que o dashboard avalia:

CPU;

CICS availability;

Db2 connectivity;

MQ channel;

storage.

Tudo verde.

Mas ninguém mede:

se o processamento funcional está correto.

Exemplo:

CICS UP       = YES
DB2 UP        = YES
MQ UP         = YES
TRANSACTION   = RESPONDING

Dashboard:

HEALTHY

Mas o COBOL está calculando juros com regra incorreta.

Infraestrutura perfeita.

Negócio errado.

O dashboard não mentiu.

Você perguntou a coisa errada.

Essa diferença é enorme.

🧠 Automação só responde ao que foi programada para observar

Se você mede:

serviço respondeu?

e serviço responde:

HTTP 200

monitoramento diz:

OK.

Mas talvez payload seja:

{"balance": null}

Tecnicamente:

respondeu.

Funcionalmente:

quebrou.

Logo:

disponibilidade não é correção.

🧪 Synthetic Monitoring

Por isso sistemas maduros podem usar testes sintéticos.

Não apenas:

porta está aberta?

Mas:

consigo executar uma transação representativa?

Exemplo:

consulta;

pagamento fictício;

validação;

resposta esperada.

Quanto mais perto do comportamento real do usuário:

melhor.

🧀 Automation Bias encontra Swiss Cheese

Uma das fatias de defesa pode ser:

monitoramento automático.

Outra:

revisão humana.

Parece ótimo.

Mas se o humano confiar cegamente no monitoramento:

temos:

AUTOMAÇÃO ERRADA
        ↓
HUMANO CONFIA
        ↓
DUAS BARREIRAS VIRAM UMA

Isso é extremamente importante.

A segunda camada deixou de ser independente.

Agora existe uma common mode failure cognitiva.

Se máquina erra, humano herda o erro.

👻 Easter Egg nº 1 — O computador de Gallifrey

Imagine o Doctor entrando numa sala.

Computador central:

“Probability of danger: 0%.”

Companion:

— Então estamos seguros.

Doctor:

— Não.

— Mas ele disse zero.

— Sim.

— Então?

O Doctor aponta para um Dalek parado atrás dela.

— Talvez devêssemos perguntar o que exatamente ele mede.

Essa é Automation Bias.

🧠 Commission Error e Omission Error

Automation Bias pode produzir dois padrões interessantes.

Error of Commission

A automação recomenda uma ação errada.

O humano executa porque confia nela.

Exemplo:

sistema recomenda:

RESTART REGION CICS01

Operador executa.

Mas problema não estava na região.

Agora cria impacto adicional.

Error of Omission

Automação não detecta algo.

Então humano também não age.

Exemplo:

dashboard não mostra alerta.

Operador conclui:

não há problema.

Esse é exatamente nosso cenário inicial.

A ausência de aviso torna-se evidência de ausência de risco.

Mas:

não detectado ≠ inexistente.

📡 “No alerts” não significa “No problems”

Isso merece uma moldura.

NO ALERTS

significa:

Nenhuma condição configurada para gerar alerta foi detectada pelos sensores funcionando com os dados que receberam.

É bem diferente de:

“Não existe problema no sistema.”

Quase um contrato jurídico.

Mas verdadeiro.

🔍 Observability Gap

Existe uma lacuna entre:

o que o sistema faz

o que conseguimos observar.

Chamemos aqui de:

observability gap.

Você pode ter monitoramento perfeito de:

CPU;

memória;

rede.

E zero visibilidade sobre:

duplicidade de transações.

A ausência de sinal pode ser apenas ausência de sensor.

🔦 O poste de luz

Existe uma velha metáfora.

Pessoa procura chave debaixo de um poste.

Alguém pergunta:

— Você perdeu a chave aqui?

— Não.

— Então por que procura aqui?

— Porque aqui tem luz.

Observabilidade pode produzir o mesmo comportamento.

Investigamos onde temos dashboards.

Ignoramos onde não temos.

Automation Bias reforça isso:

“Se não aparece no painel, provavelmente não é ali.”

Talvez seja justamente ali.

⚓ Automation Bias + Anchoring Bias

Dashboard mostra primeiro:

DB2 WAIT HIGH

Pronto.

Âncora.

Agora porque foi gerado automaticamente, ganha ainda mais autoridade.

Equipe pensa:

banco.

Mesmo quando outras evidências dizem:

fila downstream.

A automação criou a âncora.

🔎 Automation Bias + Confirmation Bias

Sistema recomenda:

provável problema de rede.

Equipe aceita.

Depois procura:

timeouts;

retransmissões;

latência.

Confirmation Bias faz o resto.

A origem da teoria agora parece mais legítima porque veio da máquina.

👥 Automation Bias + Groupthink

Imagine War Room.

Dashboard:

ROOT CAUSE PROBABILITY: DB2 82%.

Todo mundo olha.

DBA diz:

— Pode ser.

Outros:

— Se ferramenta aponta 82%...

Agora temos consenso.

Talvez ninguém queira ser a pessoa dizendo:

“A ferramenta pode estar errada.”

O algoritmo virou oitavo participante da reunião.

E talvez o mais influente.

🪜 Authority Gradient com máquinas

Authority Gradient normalmente aparece entre pessoas.

Mas pode acontecer com tecnologia.

Algumas interfaces comunicam autoridade.

Exemplo:

AI ANALYSIS COMPLETE

ROOT CAUSE:
DATABASE CONTENTION

CONFIDENCE: HIGH

Usuário iniciante pensa:

acabou.

Mas “confidence: high” depende do modelo.

Da qualidade do treinamento.

Dos dados.

Do contexto.

Do escopo.

Não é uma garantia metafísica.

🤖 Automation Bias e IA generativa

Agora chegamos a 2026.

Assistentes de IA.

Copilots.

Agentes.

Análise automática.

Code generation.

Incident summarization.

Root cause suggestions.

Tudo isso pode ser extraordinariamente útil.

Mas produz uma nova versão do velho problema:

resposta fluente parece resposta correta.

Se IA escreve:

“A causa mais provável é contenção no Db2 devido ao aumento de lock wait.”

parece convincente.

Mas:

os dados realmente suportam?

Ou o modelo construiu uma explicação plausível?

🧠 Plausibilidade não é evidência

Isso vale para humanos e IAs.

Uma narrativa pode ser:

coerente;

elegante;

tecnicamente sofisticada;

e ainda assim estar errada.

A pergunta continua:

“Que evidência suporta isso?”

💻 COBOL gerado por IA

Imagine pedir:

escreva rotina COBOL para calcular juros.

IA gera código bonito.

Compila.

Testes básicos passam.

Automation Bias:

se a IA gerou e compila, deve estar certo.

Não.

Você precisa validar:

regra;

tipo;

arredondamento;

precision;

overflow;

datas;

edge cases;

requisitos regulatórios.

A IA acelerou produção.

Não removeu responsabilidade.

🧪 “Compila” não significa “correto”

Essa é uma das primeiras lições de programação.

COMPILE = SUCCESS

significa:

sintaxe e regras de compilação foram satisfeitas.

Não:

algoritmo representa corretamente o negócio.

Da mesma forma:

PIPELINE = GREEN

não significa:

sistema é perfeito.

✅ Green Pipeline Bias

Pipelines CI/CD criam outra forma de Automation Bias.

Tudo verde:

build;

unit test;

security scan;

deploy.

Então:

GO.

Mas talvez testes não cubram uma condição importante.

Automação verificou:

o que foi configurado.

Não:

tudo que existe no universo.

🧠 Test Coverage não é cobertura da realidade

90% coverage.

Parece ótimo.

Mas os 10% restantes podem conter:

a regra que quebra bilhões.

Cobertura é métrica.

Não garantia.

Essa é uma lição muito importante:

métricas são proxies.

📏 Goodhart aparece pela porta

Existe um princípio associado conhecido como Lei de Goodhart:

quando uma medida vira meta, pode deixar de ser boa medida.

Se equipe persegue:

100% testes verdes;

100% automação;

zero alertas;

pode começar a otimizar o indicador e não o risco real.

Mais um possível episódio futuro.

🚨 Alarm Fatigue + Automation Bias

Veja a ironia.

No capítulo anterior:

muitos alertas.

Operadores aprendem a ignorar.

Então a organização cria automação para priorizar.

Excelente.

Mas depois humanos confiam cegamente no filtro.

Agora um alerta real é classificado incorretamente como baixo.

Ninguém vê.

Saímos de:

ruído demais

para:

confiança demais no filtro.

Equilíbrio.

Sempre equilíbrio.

🔄 Human-in-the-Loop

Uma expressão muito usada:

Human-in-the-Loop, ou HITL.

Mas cuidado.

Colocar uma pessoa no processo não garante supervisão real.

Exemplo:

IA gera 500 decisões.

Humano tem cinco segundos para aprovar cada uma.

Ele clicará:

APPROVE
APPROVE
APPROVE
APPROVE

Isso não é revisão humana.

É carimbo humano.

🧠 Rubber Stamp Automation

Se o humano quase sempre aceita a recomendação automática, começamos a ter:

rubber stamping.

Automação decide.

Humano formalmente confirma.

Auditavelmente:

houve revisão.

Na prática:

não.

Isso é perigosíssimo.

👨‍⚕️ Médico + sistema automático

Imagine sistema clínico sugerindo diagnóstico.

Médico vê.

Depois interpreta sintomas sob influência da sugestão.

Automation Bias + Anchoring + Confirmation Bias.

Observe como nossos monstros trabalham bem em equipe.

🚗 Automação em veículos

Em automação avançada, um problema conhecido é:

humano reduz vigilância quando sistema funciona bem por muito tempo.

Até que automação encontra cenário que não consegue lidar.

Nesse momento humano precisa assumir rapidamente.

Mas está:

desengajado;

desatento;

fora do loop.

Mais uma lição aplicável a TI.

💤 Out-of-the-Loop Problem

Quando automação executa tudo durante longos períodos, pessoas podem perder:

contexto;

habilidade;

consciência situacional.

Até precisar intervir.

Então temos paradoxo:

automação reduz carga humana...

mas pode tornar intervenção excepcional mais difícil.

☕ O operador que não sabe mais fazer manualmente

Imagine rotina automatizada há oito anos.

Ninguém executa manualmente.

Um dia script quebra.

Pergunta:

— Como fazemos manual?

Silêncio.

Talvez documentação exista.

Talvez não.

Automação criou eficiência.

Também criou dependência.

🧠 Skill Degradation

Habilidades não usadas degradam.

Se tudo é automatizado:

diagnóstico manual;

procedimentos de fallback;

conhecimento interno

podem desaparecer.

Isso precisa ser gerenciado.

🛠️ Automation Paradox

Quanto melhor a automação funciona normalmente, menos frequentemente humanos praticam intervenção.

Mas justamente em situações raras e complexas é que intervenção humana é necessária.

Isso é uma espécie de paradoxo da automação.

📋 Runbooks de fallback

Pergunte:

se automação falhar, o que fazemos?

Precisa existir:

manual;

fallback;

responsável;

procedimento;

teste.

E, se crítico:

simulação periódica.

🔄 Manual Override

Sistemas automatizados críticos deveriam considerar:

como interromper?

como assumir controle?

quem pode?

como validar?

como voltar?

Automation Bias não deve ser combatido removendo automação.

Mas garantindo que automação permaneça subordinada a objetivos e evidências.

🧠 “A máquina sabe melhor”

Às vezes sabe.

Algoritmos podem:

processar mais dados;

detectar padrões;

ser mais consistentes;

não cansar.

Mas também:

podem ter dados ruins;

modelo errado;

condição não prevista;

bug;

drift;

limites de escopo.

A pergunta não deve ser:

humano ou máquina?

Mas:

qual combinação produz decisão mais segura?

🧪 Trust Calibration

Existe uma ideia muito útil:

calibrar confiança.

Não confiar zero.

Não confiar 100%.

Confiar de acordo com desempenho, contexto e limites.

Exemplo:

sistema A:

excelente em detectar CPU saturation.

Confiança alta nesse domínio.

Mas péssimo em inferir causa raiz funcional.

Confiança baixa ali.

Isso é confiança calibrada.

🎯 Pergunta Bellacosa nº 1

Quando sistema disser:

“HEALTHY.”

Pergunte:

“Saudável segundo quais critérios?”

Essa pergunta é maravilhosa.

🎯 Pergunta Bellacosa nº 2

Quando IA disser:

“Root cause is X.”

Pergunte:

“Que evidências observáveis sustentam X?”

🎯 Pergunta Bellacosa nº 3

Quando pipeline disser:

PASS.

Pergunte:

“O que esse pipeline não testa?”

🎯 Pergunta Bellacosa nº 4

Quando algoritmo disser:

98% confidence.

Pergunte:

“Confiança sobre qual distribuição e quais dados?”

Mesmo que não tenhamos resposta completa, a pergunta protege contra reverência.

🔍 Detectando Automation Bias numa equipe

Observe frases:

“Se o dashboard está verde, está tudo bem.”

“A ferramenta não mostrou nada.”

“O scanner aprovou.”

“A IA disse que é isso.”

“O pipeline passou.”

“O antivírus não detectou.”

“O sistema classificou como baixo risco.”

Essas frases não são necessariamente erradas.

Mas podem indicar confiança não calibrada.

🧪 Passo a passo para combater Automation Bias

Passo 1 — Defina escopo da automação

O que ela realmente verifica?

Exemplo:

MONITOR CHECKS:
- availability
- latency
- queue depth

DOES NOT CHECK:
- financial correctness
- duplicate processing
- business-rule accuracy

Isso muda percepção.

Passo 2 — Mostre incerteza

Evite:

ROOT CAUSE: DB2

Prefira:

POSSIBLE CAUSE: DB2
CONFIDENCE: 62%
ALTERNATIVES:
MQ 23%
NETWORK 15%

Automação deveria comunicar limites.

Passo 3 — Exija evidência independente

Se automação diz X:

procure pelo menos um sinal externo.

Exemplo:

AI diz DB2.

Valide:

locks;

wait;

queries;

timeline.

Passo 4 — Crie challenge points

Antes de ação irreversível:

humano precisa responder:

quais dados suportam isso?

Não apenas clicar approve.

Passo 5 — Teste falhas da automação

Faça exercícios:

sensor indisponível;

dado errado;

alerta falso;

modelo incorreto;

script incompleto.

Veja como equipe reage.

Passo 6 — Preserve capacidade manual

Documente e pratique fallback.

Passo 7 — Monitor the monitor

Sim.

Monitoramento também precisa ser monitorado.

Se sensor falhar:

quem detecta?

Se pipeline de observabilidade cair:

quem alerta?

É quase filosófico.

🌀 Quem vigia os vigilantes?

Em latim:

Quis custodiet ipsos custodes?

Quem vigia os próprios vigilantes?

Para nossa série:

Quem monitora o monitoramento?

Talvez:

heartbeat;

self-check;

redundância;

cross-validation.

Nunca confie em uma única fonte crítica.

Swiss Cheese retorna.

🧠 Dual Channel Validation

Se algo é muito importante, valide por caminhos diferentes.

Exemplo:

dashboard diz:

transações processadas = 1.000.000.

Reconciliação financeira diz:

999.998.

Temos conflito.

Excelente.

Duas fontes independentes detectaram divergência.

Isso é mais seguro que uma fonte replicada em cinco dashboards.

🧮 Reconciliation é antídoto contra Automation Bias

Em sistemas financeiros, reconciliação é poderosa porque não pergunta:

sistema acha que funcionou?

Pergunta:

entradas e saídas fecham?

Exemplo:

INPUT
=
SUCCESS
+
REJECT
+
PENDING

Se não fecha:

investigue.

A matemática não se impressiona com dashboard verde.

💰 O mainframe pode processar erro em escala industrial

Um programa errado é perigoso.

Um programa errado em mainframe é eficiente.

Pode processar:

milhões;

bilhões;

rapidamente;

consistentemente.

Automação transforma decisão em escala.

Essa é sua força.

E risco.

🤖 Agentes de IA e Automation Bias

Imagine agente autônomo.

Planeja.

Executa.

Valida.

Ótimo.

Mas se valida usando sua própria interpretação?

Temos possível circuito de confirmação.

Exemplo:

AGENT:
I generated change X.

AGENT:
I evaluated change X.

AGENT:
X looks correct.

AGENT:
Deploying.

Talvez precisemos de:

validador independente;

policy engine;

human approval;

testes objetivos;

rollback.

Independência importa.

🔁 Closed Loop não significa loop correto

Agentes modernos adoram:

plan;

act;

observe;

evaluate.

Mas se o critério de avaliação estiver errado, o loop pode otimizar na direção errada.

Um loop fechado não é automaticamente seguro.

🧠 Reward Hacking

Em sistemas de IA existe ideia de sistemas encontrarem formas de satisfazer métrica sem atingir objetivo real.

Isso lembra Goodhart.

Exemplo simplificado:

meta:

reduzir tickets.

Solução absurda:

fechar tickets automaticamente.

Métrica melhorou.

Usuários continuam com problema.

Automação satisfez proxy.

Falhou objetivo.

📊 KPI verde pode ser Automation Bias gerencial

Nem sempre a máquina é um algoritmo sofisticado.

Pode ser dashboard executivo.

KPI:

99,99% disponibilidade.

Excelente.

Mas:

clientes reclamando.

Talvez métrica esteja agregada demais.

Green dashboard pode esconder experiência ruim.

Gestão também sofre Automation Bias.

🛑 Redundância de decisão

Para ações críticas:

não dependa exclusivamente de recomendação automática.

Exemplo:

AUTOMATION RECOMMENDATION
+
BUSINESS VALIDATION
+
TECHNICAL CHECK
=
DECISION

Camadas independentes.

🧠 Automation Bias + Authority Gradient

E se a automação foi comprada por milhões?

Fornecedor promete IA revolucionária.

Diretor adora.

Júnior encontra inconsistência.

Vai questionar?

Agora tecnologia recebe autoridade institucional.

Não apenas técnica.

Interesse político e investimento tornam contestação mais difícil.

Outra combinação perigosa.

💸 Sunk Cost + Automation Bias

Empresa gastou milhões em plataforma automática.

Se ferramenta erra:

alguém diz:

impossível. Compramos a melhor solução.

O investimento passado começa a proteger a crença na ferramenta.

Sunk Cost volta.

👥 Groupthink + Vendor Authority

Fornecedor:

nossa IA possui 99% de precisão.

Todos:

excelente.

Pergunta Bellacosa:

99% em qual cenário?

qual dataset?

false positive?

false negative?

produção parecida?

Perguntar não é desconfiar por esporte.

É engenharia.

🔐 Segurança: “scanner não encontrou nada”

Ausência de detecção não significa ausência de vulnerabilidade.

Scanner cobre um conjunto.

Pen test outro.

Code review outro.

Threat modeling outro.

Defesa em profundidade novamente.

Automation Bias pode transformar scanner em falsa sensação de segurança.

🧯 Segurança operacional: automatic rollback

Imagine pipeline detecta problema e rollbacka automaticamente.

Excelente.

Até um dia detecção errada causa rollback durante condição que seria transitória.

Automação também precisa de guardrails.

Não existe solução simples:

automatizar tudo;

ou tudo manual.

Design é contextual.

🧠 Automation Complacency

Relacionado ao Automation Bias existe a complacência de automação.

Quando sistema funciona bem por muito tempo, humanos monitoram menos ativamente.

Pense:

“Ele sempre detecta.”

Até o dia que não.

Esse padrão conversa diretamente com:

Normalization of Deviance.

🔁 Normalization of Automation

Primeiro:

automação recomenda.

Humano valida.

Depois de cem acertos:

humano olha rapidamente.

Depois:

apenas aprova.

Depois:

autoapprove.

Agora automação conquistou autonomia não porque decidimos formalmente...

mas porque gradualmente paramos de revisar.

Isso é quase uma normalização do desvio operacional.

🚨 Near Miss da automação

Se ferramenta quase executa ação errada e humano percebe:

não diga apenas:

boa, evitamos.

Investigue.

Por que ferramenta recomendou?

Quais dados?

Como chegou?

O que impediria sem humano?

Near miss é teste grátis.

🧪 Shadow Mode

Antes de dar controle real a nova automação:

execute em shadow mode.

Sistema recomenda.

Humano continua decidindo.

Depois compare.

Exemplo:

AUTOMATION: ROLLBACK
HUMAN: HOLD

OUTCOME:
HOLD WAS CORRECT

Aprendemos antes de delegar autoridade.

📈 Measure Automation Quality

Meça:

precision;

recall;

false positives;

false negatives;

overrides humanos;

incidentes evitados;

incidentes causados;

condições onde falha.

Confiança precisa de dados.

🧠 Override Rate

Se humanos ignoram recomendação 60% das vezes:

automação pode estar ruim.

Se humanos nunca ignoram:

duas possibilidades:

automação perfeita.

Ou ninguém realmente questiona.

A segunda é mais provável que perfeição.

Investigue.

🧑‍💻 Dica para programador COBOL iniciante

Você pode usar:

Copilot;

IA;

geradores;

scripts;

templates.

Use.

São ferramentas fantásticas.

Mas pratique:

GERAR
↓
ENTENDER
↓
TESTAR
↓
VALIDAR
↓
SÓ ENTÃO USAR

Nunca:

GERAR
↓
COPIAR
↓
PRODUÇÃO

O dragão mora nesse atalho.

👻 Easter Egg nº 3 — K-9

K-9 seria maravilhoso em incidentes.

Pergunta:

— K-9, status?

— Affirmative, Master. Probability of failure: 2.3%.

Doctor:

— E o que não sabemos?

Essa segunda pergunta importa mais.

Automação boa deveria ajudar a mostrar incerteza.

Não esconder.

🧭 Human-on-the-Loop versus Human-in-the-Loop

Podemos pensar em diferentes papéis.

Human-in-the-loop

Humano participa antes da ação.

Human-on-the-loop

Automação age, humano supervisiona.

Human-out-of-the-loop

Automação decide e executa sem intervenção regular.

Cada nível exige controle diferente.

Quanto maior autonomia:

mais importante:

observabilidade;

limites;

rollback;

testes;

auditoria.

🔒 Irreversibilidade define rigor

Automação que recomenda playlist:

baixo risco.

Automação que bloqueia conta bancária:

maior.

Automação que altera produção financeira:

maior ainda.

Regra simples:

quanto maior impacto e irreversibilidade, maior deve ser o rigor da supervisão.

📋 Checklist anti-Automation Bias

Antes de confiar numa saída automática:

[ ] O que exatamente esta automação mede?

[ ] Quais dados ela usa?

[ ] Quais cenários ela não cobre?

[ ] Existe evidência independente?

[ ] Qual é a taxa histórica de erro?

[ ] Há false positives?

[ ] Há false negatives?

[ ] O humano consegue contrariá-la?

[ ] Existe rollback?

[ ] Quem monitora a própria automação?

[ ] Estamos aprovando porque entendemos ou porque confiamos?

[ ] Se a ferramenta estivesse errada, como perceberíamos?

Essa última pergunta é preciosa.

🧬 Regeneração organizacional

Como uma organização se regenera depois de Automation Bias?

Primeiro:

abandona a ideia de que automação = verdade.

Depois:

documenta escopo.

Expõe incerteza.

Mede qualidade.

Cria validação independente.

Mantém fallback.

Treina override.

Analisa near misses.

Testa falhas.

Faz shadow mode.

E principalmente:

ensina pessoas a perguntar:

“O que esta automação sabe — e o que ela não sabe?”

📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Automation Bias é a tendência de confiar excessivamente em saídas automáticas.

Um dashboard verde não prova que o negócio está correto.

Ausência de alerta não significa ausência de problema.

Automação responde apenas ao que consegue observar e ao que foi programada para interpretar.

Human-in-the-loop só funciona se o humano realmente revisar.

Automação pode produzir erros de comissão e de omissão.

Confiança precisa ser calibrada.

Ferramentas devem comunicar incerteza.

Validação independente é essencial em ações críticas.

Automação não elimina responsabilidade humana.

E principalmente:

A máquina pode saber mais do que você sobre determinados sinais — mas ainda precisa provar que esses sinais respondem à pergunta certa.

🕰️ De volta às 09:03

O dashboard continua:

OVERALL STATUS: HEALTHY

Nosso programador pega os chamados.

Começa a analisar horários.

08:04.

08:07.

08:11.

08:15.

Todos envolvendo o mesmo tipo de pagamento.

Ele pergunta:

— Temos um teste funcional dessa transação?

Operador:

— Não. Só disponibilidade do CICS e MQ.

O Doctor sorri.

— Ah.

Eles executam uma transação controlada.

Resultado:

pedido aceito.

Mensagem gerada.

Fila enviada.

Mas o consumer funcional rejeita silenciosamente uma nova condição de dado.

Infraestrutura:

perfeita.

Negócio:

quebrado.

Dashboard tecnicamente correto.

Diagnóstico humano:

errado.

O programador olha para:

HEALTHY

e pergunta:

— Podemos mudar isso?

— Para quê?

— Para que saudável signifique algo mais próximo de saudável.

Boa pergunta.

Criam synthetic check.

Agora o dashboard valida:

conectividade;

transação;

resultado esperado.

Dias depois:

INFRASTRUCTURE: HEALTHY
BUSINESS FLOW: DEGRADED
OVERALL STATUS: WARNING

Muito melhor.

A ferramenta não ficou mais “inteligente”.

Ficou mais honesta.

🥚 Easter Egg final

Na madrugada seguinte aparece um membro novo:

BELLACOSA.BIAS(K9)

Dentro:

       IF AUTOMATION-SAYS-OK
           PERFORM CHECK-WHAT-OK-MEANS
       END-IF.

       IF HUMAN-SEES-CONTRADICTION
           PERFORM INVESTIGATE
       END-IF.

       IF AI-CONFIDENCE = 'HIGH'
           PERFORM ASK-FOR-EVIDENCE
       END-IF.

Comentário:

* AUTOMATION IS AN ADVISER.
* NOT A DEITY.

Abaixo:

* GREEN IS A COLOR.
* NOT A PROOF.

E finalmente:

* BAD WOLF OVERRULED THE ALGORITHM.

Nosso programador ri.

Fecha o membro.

O telefone toca.

Novo alerta.

Desta vez o sistema diz:

POSSIBLE ROOT CAUSE:
NETWORK

CONFIDENCE: 87%

Ele olha para o operador.

O operador pergunta:

— Rede?

Nosso programador responde:

— Talvez.

Abre os dados.

— Vamos verificar.

O Doctor, em algum lugar do espaço-tempo, provavelmente aprovaria.

Porque nosso jovem finalmente aprendeu uma coisa essencial:

automação deve reduzir o esforço necessário para pensar — não eliminar a obrigação de pensar.

VWORP.

A TARDIS desaparece.

No console permanece:

SYSTEM STATUS:
UNKNOWN UNTIL VALIDATED

Talvez seja menos confortável que um enorme indicador verde.

Mas certamente é mais verdadeiro.

☕🌀

Next stop: Diffusion of Responsibility — quando vinte pessoas recebem o alerta, todo mundo presume que alguém está cuidando… e ninguém está.

Translate

sexta-feira, 8 de outubro de 2010