 |
| Bellacosa Mainframe e o risk compensation |
☕ Um Café no Bellacosa Mainframe
Risk Compensation: Doctor Who, COBOL e o Dia em que Ficamos Mais Seguros — e Começamos a Arriscar Mais
Uma viagem pela TARDIS dos incidentes para entender por que novos controles, automações, backups, guardrails e proteções podem reduzir riscos técnicos enquanto aumentam nossa disposição de assumir riscos comportamentais
08:42.
Segunda-feira.
War Room silenciosa.
Nada quebrado.
Ainda.
Na tela:
NOVO CONTROLE IMPLEMENTADO
AUTOMATIC ROLLBACK:
ENABLED
CANARY:
ENABLED
SNAPSHOT:
ENABLED
MONITORING:
ENABLED
BACKUP:
VALIDATED
O gerente sorri.
— Agora podemos ser mais agressivos.
Nosso jovem programador COBOL pergunta:
— Mais agressivos como?
— Mudanças maiores.
— Por quê?
— Porque agora temos rollback automático.
Outro especialista entra:
— Antes fazíamos deploy de um componente por vez.
O gerente responde:
— Agora podemos fazer seis.
— Por quê?
— Porque estamos muito mais protegidos.
Nosso jovem olha novamente:
AUTOMATIC ROLLBACK:
ENABLED
Parece excelente.
É excelente.
Mas alguma coisa incomoda.
Na sexta-feira anterior:
mudanças pequenas.
Uma por vez.
Segunda-feira:
nova proteção.
Agora alguém propõe:
CHANGE SCOPE:
6 APPLICATIONS
3 COPYBOOKS
2 DB2 TABLES
1 MQ FLOW
Nosso jovem pergunta:
— Se aumentarmos tanto o tamanho da mudança...
— Sim?
— não estamos devolvendo parte da segurança que acabamos de ganhar?
Silêncio.
VWORP.
VWORP.
VWORP.
A TARDIS materializa-se ao lado do quadro de mudanças.
A porta abre.
O Doctor sai.
Olha para o rollback.
Depois para o escopo.
— Vocês ficaram mais seguros?
— Sim.
— Então aumentaram o risco?
— Também.
O Doctor sorri.
— Magnífico.
— Magnífico?!
— Vocês acabaram de descobrir uma das coisas mais humanas possíveis.
Pausa.
— Às vezes, quando reduzimos o risco de uma atividade, as pessoas usam parte dessa redução para fazer a atividade de forma mais arriscada.
Bem-vindo ao:
Risk Compensation
Ou:
Compensação de Risco
E ao conceito frequentemente relacionado chamado:
Peltzman Effect
Em linguagem Bellacosa:
“Colocamos mais proteção no sistema e, porque nos sentimos mais protegidos, começamos a exigir mais dele.”
🧠 Primeiro: Risk Compensation e Peltzman Effect são exatamente a mesma coisa?
São conceitos muito relacionados, mas vale uma pequena precisão.
Risk Compensation é a ideia mais ampla de que pessoas ajustam seu comportamento em resposta ao nível de risco percebido.
Se percebem:
mais perigo,
podem agir com mais cautela.
Se percebem:
mais segurança,
podem assumir mais risco.
O Peltzman Effect, associado ao economista Sam Peltzman, ficou famoso em debates sobre como medidas de segurança podem provocar mudanças comportamentais que compensam parte do benefício esperado.
A ideia não significa:
“medidas de segurança não funcionam.”
Isso seria uma conclusão simplista.
O ponto é:
o benefício técnico de um controle pode ser parcialmente alterado pela resposta comportamental das pessoas ao novo nível de segurança percebido.
☕ O cinto de segurança do mainframe
Imagine:
antes:
sem rollback confiável.
Equipe faz:
mudanças pequenas.
Devagar.
Agora:
rollback automático validado.
Isso é ótimo.
Reduz impacto potencial.
Mas equipe pensa:
“Então podemos aumentar o tamanho do deploy.”
Agora parte do benefício original é consumida.
Não necessariamente todo.
Talvez ainda seja melhor que antes.
Mas:
risco técnico caiu enquanto apetite por risco subiu.
🧠 Um modelo simples
Antes:
PROTEÇÃO:
BAIXA
COMPORTAMENTO:
CAUTELOSO
RISCO FINAL:
MÉDIO
Depois:
PROTEÇÃO:
ALTA
COMPORTAMENTO:
MAIS AGRESSIVO
RISCO FINAL:
MENOR?
IGUAL?
MAIOR?
Depende.
Essa última parte é importantíssima.
Risk Compensation não determina automaticamente o resultado final.
Você precisa medir.
👻 Easter Egg nº 1 — O campo de força
Companion:
— Doctor! Agora temos um campo de força!
Doctor:
— Excelente.
— Então podemos voar direto pelo cinturão de asteroides.
Doctor:
— Não.
— Mas estamos protegidos.
— Contra impactos pequenos.
— Então podemos ir mais rápido.
— Também não.
— Mas para que serve o campo de força?
Doctor olha para ela.
— Para reduzir risco.
Pausa.
— Não para financiar novas maneiras de encontrar perigo.
🧠 Risk Compensation + Zero-Risk Bias
No capítulo anterior:
queríamos zerar risco.
Agora implementamos proteção.
Risco cai.
Então pensamos:
“Temos margem.”
Isso pode ser racional.
Aliás, muitas vezes é exatamente o objetivo.
Você cria controles para poder fazer coisas antes arriscadas.
O problema aparece quando:
o aumento de risco comportamental é maior do que o ganho permitido pelo controle.
☕ Guardrail não é convite para testar o precipício
Guardrail existe para:
reduzir dano.
Não significa:
“Agora dirija sempre encostando nele.”
🧠 Risk Budget
Aqui aparece uma ideia importante.
Talvez algum aumento de risco seja intencional.
Exemplo:
pipeline melhor.
Testes automáticos.
Rollback.
Agora podemos:
deployar mais.
Isso pode ser excelente.
A organização transformou controle em:
velocidade.
Isso não é automaticamente viés.
A questão é:
o risco adicional foi deliberadamente calculado ou simplesmente assumido porque “agora está seguro”?
🎯 Pergunta Bellacosa nº 1
Depois de implementar um controle, pergunte:
“Que comportamento estamos mudando porque nos sentimos mais seguros?”
Essa pergunta é ouro.
🧠 Risk Compensation consciente versus inconsciente
Consciente
“Com canary e rollback, aumentaremos frequência de deploy de 2 para 5 por semana. Monitoraremos change failure rate.”
Isso é estratégia.
Inconsciente
“Tem rollback, então manda tudo.”
Isso é compensação comportamental não calibrada.
☕ “Se der ruim, volta”
Uma das frases mais perigosamente confortáveis da TI.
Rollback pode existir.
Mas:
dados?
Schema?
Mensagens?
Side effects?
External calls?
Nem tudo volta.
🧠 Illusion of Control retorna
Temos rollback.
Logo:
“Controlamos risco.”
Illusion of Control.
Agora Risk Compensation:
“Então podemos arriscar mais.”
A combinação pode ser pesada.
🧠 Dunning-Kruger entra
Pessoa conhece rollback superficialmente.
Acha:
“Volta tudo.”
Não sabe:
irreversibilidade.
Então assume risco extra.
Pouca compreensão aumenta compensação.
☕ Código volta. Dinheiro talvez não.
Você pode rollback:
binário.
Mas não necessariamente:
PIX enviado.
Pagamento processado.
Mensagem entregue.
Email disparado.
Integração externa executada.
Essa distinção é crítica.
💻 COBOL exemplo: rollback imaginário
Programa:
UPDATE CUSTOMER
WRITE AUDIT-LOG
CALL EXTERNAL-PAYMENT
Se código falha depois do CALL:
rollback de DB2 talvez volte a tabela.
Mas pagamento externo?
Talvez já aconteceu.
Logo:
ROLLBACK LOCAL
≠
ROLLBACK DO UNIVERSO
🧠 Risk Compensation + Automation Bias
Automação monitora.
Automação corrige.
Equipe relaxa.
Isso é natural.
Mas agora:
menos atenção manual.
Se automação encontrar um failure mode desconhecido:
problema.
Você melhorou sistema.
E reduziu vigilância humana.
Talvez ainda seja melhor.
Mas precisa ser observado.
☕ Auto-healing
Sistema reinicia sozinho.
Excelente.
Depois de meses:
ninguém mais investiga por que reinicia.
Automation Bias + Risk Compensation + Normalization of Deviance.
Agora o sistema:
se cura.
Mas também pode estar escondendo:
doença crônica.
🧠 O sistema que “sempre volta”
Incident count:
baixo.
Restart count:
alto.
Equipe:
“Alta resiliência.”
Talvez.
Ou:
fragilidade mascarada por auto-recovery.
Precisa investigar.
🌀 Drift Into Failure
Controles podem permitir operar mais perto do limite.
Exemplo:
autoscaling.
Antes:
CPU 60%.
Agora:
autoscaling garante capacidade.
Equipe passa a operar:
85% baseline.
Por quê?
“Se crescer, escala.”
Talvez razoável.
Mas se scaling falhar:
margem desapareceu.
O controle permitiu drift para uma região mais agressiva.
☕ A margem consumida
Adicionamos:
10 unidades de segurança.
Depois usamos:
8
para aumentar performance.
Restaram:
Talvez intencional.
Talvez não.
Meça.
🧠 Safety Margin
Um controle novo não precisa ser totalmente convertido em capacidade.
Pode manter:
margem.
Exemplo:
rollback melhor.
Não significa:
deploys 10x maiores.
Talvez:
deploys 2x mais frequentes com mesmo blast radius.
Essa escolha é arquitetura de risco.
🧠 Risk Compensation e SRE
SRE possui ideia de:
error budget.
Essa é uma forma sofisticada de transformar segurança extra em inovação de forma explícita.
Se confiabilidade está acima do SLO:
pode gastar parte do budget em mudança.
Se budget acaba:
reduz risco.
Isso é muito melhor que:
“Parece seguro, acelera.”
☕ Error Budget é Risk Compensation com contabilidade
Bonita definição.
Você permite mais risco.
Mas mede.
🧠 Action Bias
Nova proteção.
Agora sentimos:
liberdade de agir.
Action Bias aproveita.
Mais mudanças.
Mais experimentos.
Pode ser bom.
Mas:
monitoramento precisa acompanhar.
🧠 Optimism Bias
“Tem backup.”
“Tem rollback.”
“Tem DR.”
“Tem seguro.”
Logo:
“Provavelmente vai ficar tudo bem.”
Optimism Bias aumenta risco comportamental.
🧠 Normalcy Bias
Controles funcionaram várias vezes.
Então:
“Sempre funcionarão.”
Agora equipe aumenta exposição.
Primeira falha do controle é enorme.
👻 Easter Egg nº 2 — O sonic screwdriver
Companion:
— Seu sonic screwdriver abre qualquer porta?
Doctor:
— Quase.
— Então podemos parar de carregar chaves?
— Não.
— Por quê?
— Porque no dia em que ele não abrir...
Pausa.
— você vai descobrir que jogou fora a redundância por excesso de confiança.
Esse Doctor está ficando quase sysprog.
🧠 Redundancy erosion
Quando controle A melhora:
podemos abandonar controle B.
Exemplo:
backup melhor.
Equipe reduz:
reconciliação.
Ou:
MFA implementado.
Security relaxa:
monitoramento de sessão.
A sensação de proteção de uma camada pode enfraquecer outras.
Swiss Cheese perde fatias.
🧀 Swiss Cheese + Risk Compensation
Adicionamos uma fatia.
Excelente.
Depois pensamos:
“Agora podemos remover duas.”
Talvez risco líquido piore.
Defesa em profundidade exige cuidado.
🔐 Segurança: MFA
MFA implementado.
Usuários e gestores sentem:
“Conta está segura.”
Então:
senhas mais fracas.
Menos atenção a phishing.
Session controls esquecidos.
MFA ainda é excelente.
Mas não deve virar:
licença para degradar outras práticas.
🧠 Password manager exemplo
Password manager melhora muito segurança.
Agora usuário pode ter:
senhas únicas e complexas.
Ótimo Risk Compensation?
Nesse caso, a mudança comportamental pode ser exatamente desejada.
Você quer:
usar segurança ganha para tornar comportamento melhor.
Nem toda compensação é ruim.
🧠 O ponto é entender resposta comportamental
Quando um controle muda:
observe pessoas.
Não apenas tecnologia.
Pergunte:
trabalharão mais rápido?
pularão etapas?
aumentarão scope?
reduzirão revisão?
confiarão mais?
Isso faz parte do design.
☕ Controle técnico também é intervenção social
Toda ferramenta muda comportamento.
Essa frase vale guardar.
🧠 Risk Compensation e seguro
Um exemplo clássico do raciocínio:
quando temos seguro:
podemos cuidar menos do risco.
Nem sempre acontece.
Mas é a lógica.
Em TI:
backup é uma espécie de seguro técnico.
Então alguém pensa:
“Pode apagar. Temos backup.”
Ops...
talvez gostaria de conversar.
💾 “Tem backup”
Pergunta:
restore testado?
RPO?
RTO?
Retention?
Backup cobre esse dataset?
Illusion of Control volta.
☕ Backup não transforma DELETE em atividade recreativa
Excelente.
🧠 Snapshot culture
Cloud:
snapshot.
Agora pessoas experimentam mudanças arriscadas diretamente.
Porque:
“volto snapshot.”
Pode ser excelente em lab.
Em produção:
dependências distribuídas podem não voltar juntas.
Contexto.
🧠 Risk Homeostasis
Existe uma ideia relacionada, chamada risk homeostasis, associada a teorias segundo as quais pessoas tenderiam a buscar um nível-alvo de risco.
Essa visão é debatida e não deve ser tratada como uma lei universal.
Mas a intuição é útil:
quando a segurança percebida muda, comportamento pode se adaptar.
Não necessariamente de maneira completa.
Não necessariamente anulando benefício.
☕ Importante: não transforme Peltzman em meme
A versão ruim é:
“Cintos de segurança fazem pessoas dirigirem pior, então não use.”
Não.
Essa é uma caricatura.
Medidas de segurança podem salvar vidas e ainda assim produzir algum ajuste de comportamento.
As duas coisas podem coexistir.
🧠 Bias != invalidation of safety controls
Vale para TI.
Não diga:
“Rollback faz pessoas arriscarem mais, então tire rollback.”
Péssima conclusão.
Melhor:
“Rollback reduz risco. Agora precisamos garantir que o novo comportamento não consuma todo o benefício.”
🎯 Pergunta Bellacosa nº 2
“Quanto da nova margem de segurança estamos convertendo em risco adicional?”
Excelente.
🧠 Safety Dividend
Podemos imaginar:
controle gera:
dividendo de segurança.
Exemplo:
antes:
risco 100.
Depois do controle:
risco técnico cairia para 50.
Mas comportamento mais agressivo adiciona:
Risco final:
Ainda melhor.
Mas não tão bom quanto esperávamos.
📊 Modelo Bellacosa
RISCO INICIAL:
100
GANHO DO CONTROLE:
-50
RISCO ADICIONAL PELO COMPORTAMENTO:
+20
RISCO FINAL:
70
Isso é Risk Compensation.
🧠 E se adicionar 60?
100
-50
+60
=
110
Agora controle paradoxalmente acompanhou risco final maior.
Possível.
Especialmente se mudança de comportamento for extrema.
☕ “Agora podemos fazer Big Bang”
Talvez seja exatamente como desperdiçar o dividendo.
🧠 Canary Deploy
Canary existe para:
reduzir blast radius.
Se depois fazemos:
10 canaries simultâneos de componentes interdependentes,
talvez o conceito tenha sido criativamente reinterpretado.
🧠 Blast Radius Compensation
Novo isolamento reduz blast radius.
Gestão aumenta:
scope.
Pergunte:
o blast radius final caiu?
Não basta dizer:
“tem isolamento.”
🧠 Risk Compensation + Zero-Risk Bias — interessante paradoxo
Antes:
buscamos zero.
Depois conseguimos proteção quase perfeita.
Então:
sentimo-nos tão seguros que aumentamos risco.
O cérebro primeiro:
quer eliminar risco.
Depois:
quando sente segurança, gasta parte dela.
Humano é realmente um sistema distribuído.
☕ Psicologia com eventual consistency
Acho que isso merece camiseta.
🧠 Risk Compensation em change management
Novo pipeline:
unit tests;
static analysis;
rollback;
canary.
Ótimo.
Equipe passa:
10 deploys/mês → 100.
Talvez isso seja desejado.
Agora meça:
change failure rate;
MTTR;
customer impact.
Se indicadores continuam bons:
controle está permitindo velocidade de forma saudável.
Se impacto aumenta:
compensação excessiva.
📈 Frequência sozinha não é risco
Deployar mais não é automaticamente pior.
Pequenos deploys frequentes podem reduzir risco.
Então precisamos evitar simplificação.
A pergunta é:
como comportamento mudou em dimensões relevantes?
🧠 Scope matters
100 pequenos deploys:
pode ser mais seguro que:
1 Big Bang.
Então:
risk compensation precisa ser analisada por:
scope;
frequency;
reversibility.
☕ Não conte só mudanças. Meça blast radius.
Muito melhor.
🧠 Peltzman Effect em segurança corporativa
Nova solução EDR.
Gestão pensa:
“Agora podemos relaxar patching.”
Não.
EDR é outra camada.
Não substitui higiene básica automaticamente.
🧠 Defense substitution
Controle novo pode ser usado como justificativa para remover outro.
Às vezes correto.
Mas precisa de análise.
Exemplo:
MFA forte pode permitir:
reduzir frequência de troca arbitrária de senha.
Isso pode ser bom.
O importante:
não fazer compensação intuitiva.
🔐 Risk-Based Authentication
Novo controle adaptativo.
Agora autenticação pode ser menos friccional em baixo risco e mais forte em alto.
Essa é compensação desenhada.
Ótimo exemplo.
Segurança útil:
permite assumir risco onde é barato.
☕ Segurança não precisa significar sofrimento uniforme
Boa arquitetura reduz risco e fricção.
🧠 Need for Control reaparece
Antes:
controle demais.
Agora implementamos guardrails.
Isso libera autonomia.
Excelente.
Mas gestores talvez:
aumentem autonomia além dos guardrails.
Então novo equilíbrio precisa ser acompanhado.
🧠 Guardrails + Ownership
Boa prática:
defina:
o que equipe pode fazer.
Até onde.
Se controle melhora:
revise guardrail conscientemente.
Não deixe comportamento expandir informalmente.
🎯 Pergunta Bellacosa nº 3
“Quais limites continuam válidos mesmo depois deste novo controle?”
Muito útil.
🧠 Risk Appetite
Se a organização decide:
“aceitamos até X de risco”,
novo controle pode liberar capacidade para:
inovação.
Mas appetite permanece.
Isso evita compensação ilimitada.
☕ O guardrail ganhou reforço
Não significa que mudamos a estrada para beira do abismo.
🧠 Risk Compensation + Self-Serving Bias
Novo controle.
Equipe aumenta risco.
Tudo funciona.
“Somos muito bons.”
Self-Serving.
Depois falha:
“Controle não funcionou.”
Talvez controle funcionou exatamente como projetado.
Mas comportamento ultrapassou limite.
🧠 Outcome Bias
Mudança agressiva dá certo.
Então:
“Podemos fazer sempre.”
Outcome Bias legitima compensação.
🧠 Survivorship Bias
Várias mudanças agressivas dão certo.
Só vemos sobreviventes.
Não vemos:
near misses.
Risk Compensation aumenta silenciosamente.
🧠 Near Misses são fundamentais
Depois de novo controle:
meça:
manual intervention;
rollback triggered;
canary aborts;
warnings.
Se tudo “funciona” graças a controles disparando constantemente:
comportamento talvez esteja consumindo margem.
☕ Rollback automático disparou 18 vezes
Dashboard:
“Zero incidents.”
Pergunta:
por que estamos produzindo 18 mudanças que precisaram ser desfeitas?
Importante.
🧠 Control activation rate
Um indicador interessante:
quantas vezes:
rollback;
circuit breaker;
retry;
fallback
precisam salvar sistema?
Se sobe muito após segurança nova:
risk compensation pode estar ocorrendo.
📊 Safety System Load
Podemos medir:
ROLLBACKS / DEPLOYS
CIRCUIT BREAKER TRIPS
FAILOVER EVENTS
MANUAL OVERRIDES
Se aumentam:
talvez operação esteja empurrando sistema contra defesas.
🧠 ABS analogy
Sistema anti-lock permite frenagem melhor.
Você não quer:
usar ABS em toda esquina.
Em TI:
rollback é ABS.
Excelente quando necessário.
Não transforme em rotina operacional.
☕ “Rollback é feature”
Sim.
Mas se cada deploy precisa dela:
há outra conversa.
🧠 Auto-remediation
Alerta.
Script corrige.
Incidente some.
Equipe pensa:
“Problema resolvido.”
Depois alertas aumentam.
Auto-remediation está compensando deterioração.
Essa é uma forma sistêmica de Risk Compensation:
organização aceita mais fragilidade porque correção automática existe.
🌀 Drift Into Failure novamente
Auto-recovery amplia tolerância a pequenas falhas.
Isso permite drift mais profundo.
Até recovery não conseguir acompanhar.
Então falha grande.
🧠 Resilience masking fragility
Resiliência é ótima.
Mas pode esconder:
fragilidade subjacente.
Precisamos observar:
quanto ela está sendo usada.
☕ Airbag não é manutenção de freio
Boa metáfora.
🧠 Risk Compensation em capacity management
Novo hardware.
Dobrou CPU.
Equipe pensa:
“Agora não precisamos otimizar.”
Aplicações crescem.
Dois anos depois:
CPU de novo em 90%.
Jevons paradox possui alguma semelhança conceitual em uso de recursos: quando eficiência aumenta, consumo pode aumentar.
Não é o mesmo fenômeno.
Mas a analogia é interessante.
🧠 Performance headroom gets consumed
Ganham:
30% margem.
Em pouco tempo:
features;
volume;
ineficiência
consomem.
Isso pode ser esperado.
Mas preserve:
resilience margin.
🎯 Pergunta Bellacosa nº 4
“Quanto da margem nova precisa permanecer margem?”
Excelente para capacity.
🧠 Risk Compensation e technical debt
Test coverage melhora.
Equipe sente confiança.
Aumenta velocidade.
Talvez technical debt cresça porque:
“Testes pegam.”
Mas testes não detectam tudo.
Cobertura técnica não substitui design.
💻 100% coverage
Já vimos Zero-Risk Bias.
Agora:
100% coverage faz equipe se sentir segura.
Então:
review menos cuidadoso.
Risk Compensation.
Métrica boa.
Comportamento inesperado.
🧠 Static analysis
Ferramenta detecta bugs comuns.
Ótimo.
Agora dev pode pensar:
“Se passou no scanner, está bom.”
Automation Bias + Risk Compensation.
☕ Scanner não lê intenção do requisito
Ainda.
🤖 IA e Risk Compensation
Agora isso fica muito interessante.
IA ajuda:
codificar;
revisar;
testar.
Produtividade sobe.
Usuário sente:
“Tenho copiloto.”
Agora tenta:
tarefas mais complexas;
domínios que conhece menos.
Isso pode ser ótimo.
Mas:
Dunning-Kruger + Automation Bias + Risk Compensation.
A proteção cognitiva percebida aumenta apetite por tarefas difíceis.
🧠 AI assistance expands frontier
Com IA:
júnior consegue fazer coisas que antes não faria.
Isso é benefício real.
Mas precisa:
review;
testes;
limites.
Porque fronteira de competência se expandiu mais rápido que capacidade de validação.
☕ A IA virou exoesqueleto
Você levanta mais peso.
Ótimo.
Mas tendão continua humano.
🧠 Human-in-the-loop
Agente tem approval humano.
Gestão sente:
“Seguro.”
Então dá mais autonomia ao agente.
Mas se humano recebe:
200 approvals,
Approval Fatigue.
Controle percebido aumenta.
Controle real pode cair.
Risk Compensation + Need for Control + Alarm Fatigue.
Nossa série está virando crossover.
🧠 Kill switch
Agente tem kill switch.
Ótimo.
Agora pode:
executar mais rápido.
Mas humano consegue detectar e reagir a tempo?
Controle técnico pode não acompanhar velocidade operacional.
🎯 Pergunta Bellacosa nº 5
“O controle continua eficaz na nova velocidade e escala que ele próprio permitiu?”
Essa é fantástica para agentes.
🧠 Backups e ransomware
Empresa melhora backup.
Agora sente:
“Mesmo se ransomware, restauramos.”
Pode relaxar prevenção.
Mas ransomware pode:
exfiltrar;
destruir backup;
atacar restore.
Backup é camada.
Não licença.
🔐 Cyber insurance
Seguro financeiro pode reduzir perda.
Mas não reduz necessariamente:
reputação;
operacional.
Se organização relaxa controles porque tem seguro:
risk compensation.
🧠 Least Privilege
Implementa PAM.
Agora gestores liberam privilégios temporários com mais facilidade porque:
“está monitorado.”
Talvez seguro.
Talvez expansão de acesso consuma benefício.
Meça.
☕ Auditado não significa inofensivo
Log de desastre ainda é desastre.
🧠 Seatbelts of software
Quais são nossos cintos?
rollback;
backups;
testing;
canary;
feature flags;
monitoring;
redundancy.
Todos excelentes.
Para cada um pergunte:
“Que comportamento mais arriscado esta proteção pode incentivar?”
Essa é a lente do capítulo.
📋 Tabela Bellacosa
CONTROLE POSSÍVEL COMPENSAÇÃO
ROLLBACK deploy maior
BACKUP menos cuidado ao apagar
AUTO-HEALING menos investigação
MFA relaxar outras camadas
TEST AUTOMATION menos revisão manual
CANARY scope maior
REDUNDANCY mais carga baseline
AI REVIEW mais confiança no código
Não significa:
vai acontecer.
Significa:
observe.
🧠 Risk Compensation + Planning Fallacy
Nova automação aumenta produtividade.
Gestor reduz prazo.
Todo ganho técnico vira:
expectativa maior.
Agora margem desaparece.
Isso acontece muito.
☕ Tool saves 20%
Prazo cai 30%.
Matemática corporativa misteriosa.
🧠 Productivity Compensation
Ferramenta melhora produtividade.
Em vez de:
menos pressão,
organização pede:
mais output.
Pode ser racional.
Mas se consumir mais que ganho:
burnout.
Erro.
Risco.
🧠 Safety versus productivity trade
Um controle talvez tenha sido criado para:
aumentar segurança.
Mas organização captura ganho como:
produtividade.
Agora segurança final pouco melhora.
Esse é Risk Compensation organizacional.
🎯 Pergunta Bellacosa nº 6
“Para que finalidade foi criado o ganho de segurança — margem ou produtividade?”
Decida antes.
🧠 Precommitment
Antes de novo controle:
defina:
“não aumentaremos scope por 3 meses.”
Meça.
Depois revise.
Isso impede compensação inconsciente.
🧠 Safety Gain Allocation
Uma ideia prática:
controle reduz risco em X.
Decida:
50% vira:
margem.
50%:
velocidade.
Talvez.
Não precisa ser fórmula literal.
Mas a ideia é poderosa:
aloque conscientemente o dividendo de segurança.
☕ Não deixe o mercado emocional gastar o budget sozinho
🧠 Risk Dashboard depois de controles
Não mostre apenas:
“rollback enabled.”
Mostre:
deployment size;
failure rate;
rollback rate;
blast radius.
Assim vemos comportamento compensatório.
📊 Before / After
BEFORE ROLLBACK
Deploy size: 1
Failure rate: 4%
Customer impact: 3%
AFTER ROLLBACK
Deploy size: 8
Failure rate: 8%
Customer impact: 2%
Interessante.
Mais falhas, menos impacto.
Isso pode ser aceitável.
Precisa de objetivos.
🧠 Outcome depends on what we optimize
Talvez sistema esteja melhor.
Mesmo com mais falhas.
Se recuperação é rápida.
SRE conhece isso.
Logo:
não moralize Risk Compensation.
Analise.
🧠 Change Failure Rate vs Recovery
Mais deploy.
Mais falhas pequenas.
Menos mega-incidentes.
Talvez excelente.
O risco foi redistribuído.
☕ Pequenos tombos controlados podem ser melhores que nunca cair até o precipício
Boa metáfora.
🧠 Error Budget novamente
Aceita:
algumas falhas.
Mas impede:
excesso.
Isso é governança adaptativa.
🧠 Risk Compensation + psychological safety
Melhores guardrails permitem:
experimentar.
Isso é bom.
Pessoas aprendem.
Sem risco controlado:
estagnação.
Então objetivo não é impedir compensação.
É:
canalizá-la.
☕ Use segurança para aprender, não para ficar imprudente
Perfeito.
🧠 Sandboxes
Sandbox reduz risco.
Agora usuário experimenta mais.
Excelente Risk Compensation!
Esse é exatamente o comportamento desejado.
Porque:
impacto limitado.
Controle foi desenhado para permitir risco seguro.
🧠 Game Days
Redundância permite falhar de propósito.
Também é compensação intencional.
Assumimos risco controlado para:
aprender.
Bom.
🧠 Chaos Engineering
Você adiciona resiliência.
Depois injeta falhas.
Parece paradoxal.
Mas risco é:
controlado;
medido;
bounded.
Essa é maturidade.
☕ Risk Compensation não é o vilão
Descontrole é.
🧠 A diferença:
Ruim
“Tem backup, pode apagar.”
Boa
“Tem ambiente isolado e restore validado, então podemos testar falhas aqui.”
Ambos usam proteção para assumir risco.
Mas:
contexto.
🎯 Pergunta Bellacosa nº 7
“O risco adicional está acontecendo em ambiente onde o blast radius é realmente controlado?”
Excelente.
🧠 Production vs Sandbox
Use segurança para mover experimentação:
para lugares baratos.
Não para justificar aventura em produção.
☕ “Mas tem rollback”
Resposta:
“Ótimo. Mesmo assim, use canary.”
Camadas.
🧠 Risk Compensation em War Room
Implementamos melhor monitoring.
Agora equipe espera mais antes de agir porque:
“Se piorar, alerta.”
Isso pode ser bom.
Menos Action Bias.
Ou ruim:
Normalcy Bias.
Depende.
🧠 Monitoring changes behavior
Alerta confiável pode permitir:
menos vigilância manual.
Ótimo.
Mas se alerta falhar:
skill degradation.
Treine.
Test alerts.
🧠 Skill Atrophy
Automação assume tarefas.
Humanos praticam menos.
Agora quando automação falha:
capacidade humana caiu.
Risk Compensation indireta.
☕ Autopilot syndrome
Piloto automático excelente.
Mas piloto humano precisa continuar capaz.
Em IT:
auto-remediation.
🧠 Runbook drills
Se sistema normalmente se auto-recupera:
faça exercícios manuais.
Preserve skills.
🧠 Peltzman Effect and humans are adaptive
A grande lição é:
humanos não são componentes passivos.
Você muda:
o ambiente.
Eles mudam:
o comportamento.
Então previsões de risco que assumem comportamento constante podem falhar.
☕ Instalar controle sem imaginar reação humana é modelar metade do sistema
🧠 Sociotechnical Systems
TI é:
tecnologia + pessoas + processos.
Um controle técnico altera:
processos e incentivos.
Logo análise precisa ser sociotécnica.
🧠 Economic incentives
Se rollback reduz custo de falha:
gestor racionalmente pode autorizar mais experimentos.
Isso não é necessariamente bias.
Pode ser decisão econômica.
A fronteira entre:
rational risk-taking
e:
risk compensation excessiva
depende de calibração.
🧠 Importante: Risk Compensation não significa irracionalidade sempre
Às vezes:
mais segurança deveria mesmo permitir mais atividade.
Exemplo:
carro mais seguro permite dirigir em condições antes inviáveis.
Software:
canary permite deploy mais frequente.
Isso pode aumentar valor total.
A pergunta:
a nova exposição permanece dentro do risco aceitável?
☕ Essa série adora a palavra “depende”
Porque especialista vive nela.
🧠 Need for Control + Risk Compensation paradox
Mais controle pode:
liberar mais risco.
Então gestores podem responder:
mais controle ainda.
Risk Compensation:
mais risco.
Novo controle.
Mais risco.
Loop.
🌀 Control Escalation Loop
NEW CONTROL
↓
MORE CONFIDENCE
↓
MORE RISK-TAKING
↓
NEW INCIDENTS
↓
MORE CONTROLS
↓
MORE CONFIDENCE
Se não medir comportamento:
ciclo.
☕ Burocracia e ousadia crescendo juntas
Parece impossível.
Corporativamente, nem tanto.
🧠 Zero-Risk Bias vs Risk Compensation
Esses dois parecem opostos.
Zero-Risk:
queremos eliminar risco.
Risk Compensation:
quando segurança aumenta, assumimos mais.
Na mesma pessoa podem coexistir.
Queremos:
zero risco percebido
enquanto fazemos:
mais coisas arriscadas.
Porque controles nos fazem acreditar:
risco continua zero.
Illusion of Control completa o trio.
🧠 O triângulo Bellacosa
ZERO-RISK BIAS
"Quero zero."
ILLUSION OF CONTROL
"Agora controlei."
RISK COMPENSATION
"Então posso arriscar mais."
Lindo.
Perigoso.
🧠 Overconfidence
Se controles funcionam:
confiança sobe.
Overconfidence pode aumentar compensação.
🧠 Dunning-Kruger
Se pessoa não entende limites do controle:
compensação ainda maior.
🧠 Self-Serving Bias
Se tudo dá certo:
mérito.
Quando falha:
controle falhou.
Ciclo protegido.
🧠 Hindsight Bias
Depois:
“Era óbvio que não deveríamos confiar tanto no rollback.”
Antes:
todos celebravam.
Decision journal ajuda.
📝 Safety Assumption Log
Ao implantar controle:
CONTROL:
Auto rollback
EXPECTED BENEFIT:
Reduce customer impact
ASSUMPTION:
Deployment scope remains <= current baseline
RISK:
Teams may increase change size
Fantástico.
Agora antecipamos comportamento.
🧠 Behavioral Monitoring
Depois:
verifique:
scope mudou?
frequência?
review?
Isso transforma psicologia em observabilidade.
☕ Telemetria humana
Não precisa ser creepy.
Meça processo, não pessoas.
🧠 Governance question
Controle técnico mudou?
Revise policy.
Se rollback melhora:
talvez deploy policy possa relaxar.
Mas deliberadamente.
Com métricas.
🧠 Risk-based adaptation
Não:
“mais seguro = libera geral.”
Mas:
“mais seguro = recalcula risk envelope.”
📐 Risk Envelope
Imagine:
zona segura.
Novo controle expande.
Ótimo.
Mas ainda existe borda.
ANTES:
[------SAFE------]
DEPOIS:
[-------------SAFE-------------]
Risk Compensation ocorre quando comportamento salta:
para além da nova borda.
☕ Mais pista não significa ausência de muro no final
📋 Checklist anti-Risk Compensation
[ ] O novo controle mudou nosso comportamento?
[ ] Estamos aumentando scope, frequência ou velocidade?
[ ] Esse aumento foi intencional?
[ ] Quanto da margem de segurança estamos consumindo?
[ ] Os limites do controle são conhecidos?
[ ] O controle cobre efeitos irreversíveis?
[ ] Estamos relaxando outras defesas?
[ ] O número de rollbacks aumentou?
[ ] Auto-remediation está escondendo problemas?
[ ] Near misses aumentaram?
[ ] O risk appetite mudou oficialmente?
[ ] A nova velocidade ainda permite supervisão efetiva?
[ ] Estamos usando segurança para experimentar em local controlado ou para arriscar em produção?
[ ] O benefício técnico continua maior que a compensação comportamental?
🧪 Como combater Risk Compensation — passo a passo
Passo 1 — Defina baseline comportamental
Antes do controle.
Deploy size.
Frequency.
Interventions.
Passo 2 — Implemente o controle
Rollback.
MFA.
Backup.
Passo 3 — Observe mudança de comportamento
Não apenas failures.
Passo 4 — Defina risk appetite
Qual nova exposição é aceitável?
Passo 5 — Reserve margem
Não consuma 100% do benefício.
Passo 6 — Teste limites do controle
Rollback real.
Restore.
Passo 7 — Preserve camadas independentes
Não remova defesa sem análise.
Passo 8 — Meça ativação das proteções
Rollback rate.
Failover.
Passo 9 — Faça review após alguns ciclos
Segurança líquida melhorou?
Passo 10 — Ajuste guardrails
Com evidência.
🧠 Safety Margin Policy
Uma ideia prática:
novo controle entrega:
margem.
Defina:
parte obrigatória como reserva.
Exemplo:
ganho de capacidade 30%.
Permitir workload crescer:
até 15%.
Outros 15%:
resilience buffer.
Simples.
☕ Não transforme todo espaço livre em móveis
Às vezes corredor precisa continuar corredor.
🧠 Capacity example
z/OS CPU:
60%.
Upgrade dobra capacidade.
Depois de um ano:
95%.
Por quê?
Novos workloads.
Natural.
Mas se novo planejamento assume:
autoscaling/flex capacity sempre disponível,
risco.
Mantenha:
headroom.
🧠 Risk Compensation no storage
Storage aumenta.
Retention rules relaxam.
Uso cresce.
Logo cheio de novo.
Controle técnico virou consumo.
☕ Todo disco eventualmente chega a 80%
Talvez lei de Bellacosa.
🧠 Risk Compensation in observability
Logs melhores.
Agora equipe adiciona:
mais complexidade porque “vamos detectar”.
Mas detecção não impede impacto.
Visibility != prevention.
Illusion of Control.
🧠 Detection and response
Mais detecção pode justificar:
mais risco,
se resposta é rápida.
Mas precisa medir:
MTTD;
MTTR.
Não apenas log volume.
☕ Ter câmera não impede ladrão automaticamente
Outro bom paralelo.
🧠 Risk Compensation e regulatory compliance
Novo controle atende requisito.
Equipe sente:
“compliant = safe.”
Relaxa:
risk thinking.
Compliance Bias + Risk Compensation.
🧠 Checkbox safety
Quanto mais checkboxes verdes:
mais confiança.
Pergunte:
risco real?
🧠 Culture matters
Se organização celebra:
“temos controles”
em vez de:
“medimos segurança líquida”,
compensação passa despercebida.
🎯 Pergunta Bellacosa nº 8
“Depois de todas as proteções e todas as mudanças de comportamento, o risco final realmente caiu?”
Essa é a pergunta final.
🧬 Regeneração organizacional
Uma organização madura contra Risk Compensation:
trata controles como intervenções sociotécnicas;
mede comportamento antes e depois;
define risk appetite;
preserva margem;
monitora ativação de defesas;
distingue sandbox de produção;
usa error budgets;
e não confunde proteção com invulnerabilidade.
Principalmente:
ela entende que:
um controle novo muda não apenas o sistema — muda a coragem das pessoas que operam o sistema.
E essa coragem extra pode ser:
excelente;
produtiva;
inovadora.
Ou:
perigosa.
Depende de onde ela é gasta.
📓 Diário do Doctor
Se guardar algumas ideias desta viagem, guarde estas:
Risk Compensation é o ajuste de comportamento em resposta à mudança do risco percebido.
O Peltzman Effect é uma formulação relacionada ao modo como medidas de segurança podem provocar comportamentos que compensam parte do benefício esperado.
Isso não significa que controles de segurança sejam inúteis.
Uma proteção pode reduzir risco técnico e simultaneamente aumentar apetite por risco.
Rollback, backups, MFA, canary, auto-healing e IA podem mudar o comportamento das equipes.
Outcome Bias e Self-Serving Bias podem transformar sucessos em excesso de confiança.
Automation Bias pode fazer controles parecerem mais abrangentes do que são.
A taxa de ativação das defesas é um indicador importante.
Safety margin não precisa ser totalmente convertida em produtividade.
Error budgets são uma forma inteligente de gastar risco conscientemente.
Sandbox e Game Days são exemplos em que Risk Compensation pode ser desejável porque o risco adicional ocorre dentro de limites controlados.
E principalmente:
Segurança que não muda comportamento existe apenas no diagrama. Na vida real, toda nova proteção altera aquilo que as pessoas se sentem confortáveis em fazer. Engenharia madura mede os dois lados.
🕰️ De volta às 08:42
Antes:
um deploy por vez.
Depois do rollback automático:
seis.
Nosso jovem propõe:
— Vamos começar com dois.
O gerente pergunta:
— Por que não seis?
— Porque queremos primeiro medir como o novo controle funciona em produção.
— Mas o rollback foi testado.
— Em ambiente controlado.
— Então você não confia?
— Confio.
Pausa.
— O suficiente para aumentar velocidade. Não o suficiente para fingir que deixou de existir risco.
O Doctor sorri.
— Excelente.
🔧 Dois meses depois
Métricas:
DEPLOY FREQUENCY:
+180%
CHANGE SIZE:
+20%
CHANGE FAILURE RATE:
-35%
CUSTOMER IMPACT:
-62%
ROLLBACK RATE:
4%
Ótimo.
A organização usou parte do dividendo de segurança para:
entregar mais.
Mas manteve:
scope pequeno.
Resultado:
risco líquido caiu.
Isso é:
Risk Compensation administrada conscientemente.
Não precisamos impedir que pessoas usem segurança.
Precisamos:
decidir como usá-la.
🥚 Easter Egg final
Na manhã seguinte aparece:
BELLACOSA.BIAS(RISK-COMPENSATION)
Dentro:
IF NEW-SAFETY-CONTROL = 'YES'
PERFORM CHECK-BEHAVIOR-CHANGE
END-IF.
IF SAFETY-MARGIN > ZERO
PERFORM RESERVE-SOME-MARGIN
END-IF.
IF RISK-TAKING-INCREASES
PERFORM MEASURE-NET-RISK
END-IF.
IF ROLLBACK-EXISTS
DO NOT
MOVE 'INVULNERABLE'
TO SYSTEM-STATUS
END-IF.
Comentário:
* SAFER
* DOES NOT MEAN
* INVINCIBLE.
Outro:
* A GUARDRAIL
* IS NOT A RACING LINE.
Outro:
* KEEP SOME
* OF THE SAFETY DIVIDEND.
Mais um:
* BACKUP IS NOT
* PERMISSION TO DELETE.
E naturalmente:
* THE TARDIS HAS
* A FORCE FIELD.
* THE DOCTOR STILL RUNS.
Nosso jovem fecha o membro.
Pouco depois chega uma proposta:
— Instalamos uma ferramenta de IA para revisar código. Podemos diminuir review humano?
Ele pergunta:
— Quanto?
— Talvez eliminar.
Ele olha para os relatórios.
— Ainda não sabemos qual classe de erro a ferramenta deixa passar.
— Mas ela é muito boa.
— Ótimo.
— Então?
Ele sorri.
— Vamos usar a segurança que ela adiciona para melhorar nossa capacidade.
Pausa.
— Não para fingir que compramos infalibilidade.
A equipe mantém review humano em mudanças críticas.
Automatiza as triviais.
Mede.
Ajusta.
Menos burocracia.
Mais velocidade.
E uma coisa importante:
a margem não desapareceu inteira.
VWORP.
VWORP.
VWORP.
A TARDIS desaparece.
No quadro da War Room fica uma última frase:
Um bom controle deve permitir que façamos mais com segurança. O erro começa quando transformamos “mais seguro” em “nada mais pode dar errado”.
☕🌀
Next stop: Moral Hazard — quando a proteção contra as consequências de uma decisão muda os incentivos e faz alguém assumir riscos porque parte do prejuízo será suportada por outra pessoa, outro time, um fornecedor, uma seguradora ou pela própria organização.
