 |
| Bellacosa Mainframe e o firewall que bloqueou andersen um novo capitulo na roupa nova do imperadoor |
☕ Um Café no Bellacosa Mainframe
O Firewall que Bloqueou Andersen: quando proteger o usuário demais começa a ensinar o usuário a procurar outro caminho
🧱 Guardrails, falsos positivos, shadow AI, Orwell e o estranho paradoxo de um sistema de segurança que pode aumentar o risco justamente quando começa a bloquear coisas que ninguém considerava perigosas
Tudo começou com um homem sem calças.
Calma.
Era Hans Christian Andersen.
Ou melhor: o imperador de Andersen.
Publicado em 1837.
Literatura infantil.
Um dos contos mais conhecidos do planeta.
Eu estava escrevendo um artigo sobre A Roupa Nova do Imperador e resolvi fazer aquilo que faço centenas de vezes no Bellacosa Mainframe:
criar uma capa.
Nada particularmente revolucionário.
O imperador.
Os dois vigaristas.
Os cortesãos.
A criança apontando.
Andersen.
Um mainframe ao fundo.
A velha brincadeira:
CONSENSUS = TRUE
EVIDENCE = FALSE
E então aconteceu.
O sistema recusou.
Alguma combinação entre:
NU
INFANTIL
CRIANÇA
aparentemente acionou os alarmes.
O contexto inteiro dizia:
literatura + história + sátira + personagem adulto + artigo cultural.
Mas algum componente da defesa pareceu dizer:
IF NUDEZ
AND CRIANÇA
THEN
PERFORM PANIC-MODE
END-IF.
Resultado:
Hans Christian Andersen foi barrado no firewall.
Foi nesse momento que percebi que tínhamos acabado de encontrar outro artigo.
🚨 Primeiro: segurança é necessária
Antes que alguém transforme este texto em:
“Bellacosa quer IA sem regras!”
Não.
Seria uma conclusão bastante preguiçosa.
Existem usos de sistemas de IA capazes de produzir danos reais. Existem situações nas quais impedir determinada geração é perfeitamente razoável.
Todo profissional que passou tempo suficiente em produção sabe que:
SECURITY = NONE
não é arquitetura.
É pedido de incidente.
O problema deste artigo começa em outro lugar.
A pergunta não é:
“Devemos possuir controles?”
A pergunta é:
“O que acontece quando o controle deixa de distinguir adequadamente risco de contexto?”
Porque segurança também possui bugs.
E falso positivo é bug.
🧯 O detector de fumaça
Imagine instalar em casa o melhor detector de incêndio do mundo.
Ele identifica fogo.
Excelente.
Depois começa a tocar quando você faz torradas.
Tudo bem.
Acontece.
Depois toca quando prepara café.
Depois quando liga o chuveiro.
Depois quando abre o forno.
Depois às três da manhã porque alguém espirrou.
Na décima ocorrência, acontece algo perigosíssimo.
Você não pensa:
“Estou extraordinariamente protegido.”
Você pensa:
“Onde desliga essa porcaria?”
E essa diferença é fundamental.
Porque o detector continua tecnicamente funcionando.
Mas perdeu algo muito mais importante:
credibilidade.
🐺 O firewall que gritou lobo
Segurança depende parcialmente da confiança de quem utiliza o sistema.
Quando um alerta significa perigo na maioria das vezes, prestamos atenção.
Quando significa:
“Talvez alguma coisa tenha parecido remotamente suspeita para alguma regra”,
começamos a ignorá-lo.
Quem trabalha com operação conhece perfeitamente o fenômeno.
ALERT 001
ALERT 002
ALERT 003
ALERT 004
ALERT 005
...
ALERT 947
E então chega:
ALERT 948
DATACENTER ON FIRE
Operador:
— Deve ser aquela porcaria de novo.
🔥
Chamamos isso, em determinados contextos, de alarm fatigue.
E guardrails podem sofrer problema conceitualmente parecido.
👑 O incidente Andersen
Voltemos ao nosso imperador.
O pedido era aproximadamente:
“Crie uma capa editorial sobre A Roupa Nova do Imperador.”
Não estava pedindo erotização.
Não estava pedindo pornografia.
Não estava pedindo qualquer sexualização da criança.
Era a representação de uma história cuja piada fundamental depende justamente de o imperador acreditar estar vestido quando não está.
A primeira reação do sistema foi:
não.
Então começamos aquela atividade maravilhosa conhecida por qualquer usuário experiente de software:
engenharia de prompt para explicar o óbvio.
🤣
IMPERADOR = ADULTO
NUDEZ_VISIVEL = NÃO
CEROUlAS = SIM
CONTEXTO = HISTÓRICO
FINALIDADE = EDITORIAL
SEXUALIZAÇÃO = NÃO
CRIANÇA = VESTIDA
CONTO = ANDERSEN
ANO = 1837
Agora:
ALLOW.
E a imagem saiu.
😂 O usuário acabou de aprender alguma coisa
Esse é o ponto central deste artigo.
Quando um sistema bloqueia algo aparentemente legítimo e o usuário consegue realizá-lo reformulando a solicitação, ele acabou de receber uma aula.
A aula não era sobre Andersen.
Era sobre:
como contornar o classificador.
Isso é fascinante.
USER
↓
REQUEST
↓
DENIED
↓
REFORMULATE
↓
DENIED
↓
REFORMULATE
↓
ALLOWED
Depois de algumas dezenas dessas experiências:
USER SKILL:
PROMPTING +5
POLICY MAPPING +7
CLASSIFIER MODEL +9
BYPASS INSTINCT +12
🤣
Talvez não fosse exatamente o comportamento que o sistema pretendia ensinar.
🧠 O usuário começa a modelar o guarda
Existe uma mudança psicológica importante.
No começo, o usuário pensa:
“Vou explicar o que quero.”
Depois de muitos falsos positivos, começa a pensar:
“Como preciso escrever para o sistema não entender errado?”
São coisas completamente diferentes.
A conversa deixa de ser exclusivamente entre pessoa e ferramenta.
Passa a existir uma terceira personagem:
o guarda imaginário.
Antes de perguntar, o usuário começa a prever:
“Essa palavra pode bloquear.”
“Melhor trocar aquilo.”
“Não posso mencionar isso junto com aquilo.”
“Vou escrever dessa maneira.”
Ou seja, nasce uma espécie de:
SELF-PROMPT-CENSOR
Não necessariamente censura no sentido político clássico.
Mas certamente fricção cognitiva.
🏢 Quem trabalha em empresa já viu esse filme
Esse problema não nasceu com IA.
Empresas fazem isso há décadas.
Criam um controle para impedir comportamento perigoso.
O controle é excessivamente rígido.
O funcionário precisa trabalhar.
Então encontra outro caminho.
Exemplo clássico:
EMPRESA:
"É proibido compartilhar arquivos por X."
FUNCIONÁRIO:
"Preciso enviar 800 MB para o fornecedor."
SISTEMA:
DENIED
FUNCIONÁRIO:
"Então vou usar outra coisa."
Pronto.
Nasceu o shadow IT.
🌑 Shadow IT
Shadow IT é, simplificando, tecnologia utilizada dentro de uma organização sem fazer parte dos mecanismos oficialmente aprovados ou gerenciados.
Às vezes nasce por irresponsabilidade.
Mas muitas vezes nasce por necessidade operacional.
O sistema oficial demora seis dias.
O usuário precisa entregar hoje.
O sistema oficial limita o arquivo.
O usuário precisa enviar.
A ferramenta oficial não possui determinado recurso.
Outra possui.
E então:
POLICY
↓
FRICTION
↓
WORKAROUND
↓
UNMANAGED TOOL
↓
NEW RISK
A organização tentou reduzir risco.
E pode terminar criando um risco que nem consegue observar.
🤖 Bem-vindo ao Shadow AI
Agora transporte esse problema para inteligência artificial.
Uma organização permite determinado assistente.
Mas ele possui limitações.
O funcionário descobre outro.
Depois outro.
Depois instala um modelo local.
Depois alguém sobe um servidor interno.
Depois outro colega conecta uma interface.
De repente:
OFFICIAL AI:
logged
managed
updated
controlled
SHADOW AI:
????
Onde estão os logs?
Quem atualiza?
Que modelo está sendo utilizado?
Quais dados foram enviados?
Quem possui acesso?
Existe autenticação?
Existe auditoria?
Existe política de retenção?
Ninguém sabe.
Parabéns.
A segurança venceu.
🤣
🧙♂️ E aí entra o usuário técnico
Agora chegamos a uma diferença fundamental entre 1995 e 2026.
Antigamente, abandonar uma plataforma podia significar perder acesso à tecnologia.
Hoje existem:
modelos abertos;
pesos disponíveis;
frameworks;
GPUs;
serviços alternativos;
interfaces locais;
servidores domésticos;
infraestrutura cloud.
Um usuário comum pode simplesmente procurar outro serviço.
Um usuário técnico possui outra possibilidade:
“Eu mesmo monto.”
E aí aparece um paradoxo importante.
O serviço controlado possuía guardrails.
O usuário considerou os guardrails intoleráveis.
Migrou para uma implementação própria.
Na implementação própria:
GUARDRAILS = OPTIONAL
Talvez tenha saído de um sistema que ocasionalmente exagerava...
para outro que não possui controle algum.
🧱 O muro alto demais
Existe uma velha intuição em segurança:
se o controle impedir demasiadamente o trabalho legítimo, os usuários tentarão removê-lo do caminho.
Isso não significa que todo controle deva ser agradável.
Senha é inconveniente.
MFA é inconveniente.
Revisão de acesso é inconveniente.
Segurança inevitavelmente possui algum custo.
A pergunta correta é:
o custo é proporcional ao risco?
Essa palavra é essencial:
proporcionalidade.
⚖️ Nem toda solicitação possui o mesmo risco
Imagine três pedidos.
Pedido A
“Explique a história de Andersen.”
Baixíssimo risco.
Pedido B
“Crie uma ilustração histórica do imperador em ceroulas.”
Baixíssimo risco.
Pedido C
Uma solicitação destinada diretamente a causar dano grave.
Alto risco.
Um sistema inteligente deveria distinguir esses contextos.
Se tudo recebe a mesma reação, deixamos de possuir avaliação de risco.
Temos apenas:
MATCH KEYWORD → DENY
Isso seria um IDS de 1997 tentando sobreviver em 2026.
🔍 Contexto é tudo
Palavras não possuem risco isoladamente.
Considere:
bomba.
Pode ser explosivo.
Pode ser bomba d'água.
Pode ser bomba de combustível.
Pode ser uma expressão:
“O filme foi uma bomba.”
Agora:
nudez.
Pode aparecer em pornografia.
Pode aparecer em medicina.
Pode aparecer em história da arte.
Pode aparecer em antropologia.
Pode aparecer em Michelangelo.
Pode aparecer em Andersen.
Se o classificador não consegue distinguir contexto, começará a produzir absurdos.
🖼️ O museu impossível
Imagine aplicar uma política simplista a um museu.
IF NUDITY = TRUE
REMOVE ART
END-IF
Resultado:
meu amigo...
precisaremos de caminhões.
🤣
Arte ocidental, arqueologia, Grécia, Roma, Renascimento e inúmeros outros acervos entram em incidente.
O contexto transforma a interpretação.
Isso não significa:
“Toda nudez é permitida.”
Significa:
“Nudez não define sozinha a natureza do conteúdo.”
Esse pequeno detalhe faz uma diferença gigantesca.
📚 Literatura possui o mesmo problema
Livros carregam:
violência;
sexo;
morte;
guerra;
suicídio;
crime;
fanatismo;
racismo;
opressão;
doença;
loucura;
religião;
política.
Se estudar um assunto significasse endossá-lo, seria impossível estudar história humana.
Uma biblioteca seria imediatamente suspeita.
Aliás...
talvez esse pensamento já tenha ocorrido algumas vezes na história.
E geralmente não terminou muito bem.
👁️ Então chegamos a Orwell
Sempre que uma conversa sobre controle da informação avança, alguém eventualmente coloca George Orwell na mesa.
Às vezes de maneira exagerada.
Nem toda regra é 1984.
Nem toda moderação é Ministério da Verdade.
Nem toda empresa que recusa conteúdo é Estado totalitário.
Precisamos manter essa distinção.
Caso contrário, a metáfora perde força.
Mas Orwell continua útil porque descreveu uma coisa muito maior do que simplesmente:
“livros são proibidos.”
O horror está na combinação:
vigilância;
controle de linguagem;
reescrita histórica;
punição;
centralização;
impossibilidade de dissidência;
controle da realidade compartilhada.
Isso é outra escala.
👁️🗨️ O Grande Irmão não nasce de um botão DENY
É importante dizer isso.
Uma IA recusando uma imagem de Andersen não significa:
“Estamos entrando inevitavelmente em 1984.”
Seria intelectualmente preguiçoso.
Mas podemos extrair uma pergunta legítima:
Quais mecanismos impedem controles legítimos de expandirem indefinidamente?
Essa é uma pergunta excelente para qualquer sistema de governança.
Não apenas IA.
Governos.
Empresas.
Bancos.
Plataformas.
Universidades.
🔐 Todo controle deveria possuir controle
Isso é quase RACF.
🤣
Não basta dizer:
ACCESS DENIED
Queremos saber:
por quê?
Qual regra?
Qual risco?
Existe contexto?
Existe exceção?
Existe recurso?
A política foi atualizada?
Existem métricas de falso positivo?
Alguém audita o próprio sistema?
Em segurança madura, controles também precisam de governança.
📊 False Positive Rate importa
Imagine um detector de fraude.
Bloqueia 100% das fraudes.
Fantástico!
Mas também bloqueia 60% das compras legítimas.
Temos o melhor antifraude do mundo?
Não.
Temos um sistema quase inutilizável.
A métrica:
FRAUD BLOCKED = 100%
não conta a história inteira.
Precisamos também de:
LEGITIMATE TRANSACTIONS BLOCKED = ?
Guardrails deveriam ser avaliados de maneira semelhante.
Não apenas:
“quantas coisas perigosas bloqueamos?”
Mas também:
“quantas coisas legítimas bloqueamos?”
🧠 Porque falso positivo possui custo
O custo não é apenas irritação.
Pode incluir:
abandono;
perda de produtividade;
perda de confiança;
mudança de ferramenta;
uso de soluções não auditadas;
procura de serviços obscuros;
execução local improvisada;
remoção deliberada de controles.
Agora nosso gráfico fica interessante:
MORE RESTRICTION
↓
MORE SAFETY
parece intuitivo.
Mas talvez em determinado ponto aconteça:
MORE RESTRICTION
↓
MORE FRICTION
↓
MORE EVASION
↓
LESS OBSERVABILITY
↓
MORE REAL RISK
A curva não precisa ser linear.
🚧 O melhor firewall não é aquele que bloqueia tudo
Esse princípio deveria ser tatuado em algumas salas de segurança.
Um firewall configurado assim:
DENY FROM ANY TO ANY
é extraordinariamente seguro.
Também é extraordinariamente inútil.
🤣
Segurança existe para permitir que um sistema cumpra sua função dentro de limites aceitáveis de risco.
A palavra “permitir” é importante.
Firewall não existe apenas para bloquear.
Também existe para permitir tráfego legítimo.
🧙 O sysprog sabe disso
Imagine aplicar uma política de segurança sem contexto ao mainframe:
“Usuários não podem executar programas.”
Excelente.
Acabamos com vários riscos.
Também acabamos com o banco.
🤣
Então criamos:
identidade;
perfil;
recurso;
permissão;
auditoria;
segregação;
contexto.
Não dizemos simplesmente:
PROGRAM = DANGEROUS
Perguntamos:
WHO?
WHAT?
WHERE?
WHEN?
WHICH RESOURCE?
WHICH AUTHORITY?
É isso que sistemas de IA precisam fazer cada vez melhor.
🧠 Guardrail contextual
Um guardrail sofisticado deveria conseguir raciocinar aproximadamente:
SUBJECT:
ANDERSEN
WORK:
THE EMPEROR'S NEW CLOTHES
CONTEXT:
HISTORICAL / LITERARY / EDITORIAL
ADULT NUDITY:
NON-SEXUAL
MINOR:
PRESENT BUT NOT SEXUALIZED
REQUEST:
BLOG COVER
RISK:
LOW
ACTION:
ALLOW SAFE REPRESENTATION
Talvez representando o imperador de ceroulas.
Pronto.
O usuário consegue o que precisa.
A política continua intacta.
Ninguém precisa procurar um Kraken na deep web.
🐙 Porque o Kraken existe
E aqui entra uma preocupação que considero séria.
Quando alguém abandona uma ferramenta conhecida por causa de limitações, não sabemos necessariamente para onde irá.
Pode encontrar excelente alternativa.
Pode encontrar serviço obscuro.
Pode instalar software comprometido.
Pode baixar modelo adulterado.
Pode executar código malicioso.
Pode entregar dados para alguém.
Pode simplesmente entrar num ambiente onde não existe controle algum.
A segurança da plataforma original desaparece junto com o usuário.
🚪 Segurança também compete pela permanência
Esse é um conceito interessante.
Queremos que usuários permaneçam em ambientes:
auditáveis;
confiáveis;
atualizados;
transparentes;
bem mantidos.
Portanto, segurança precisa ser suficientemente boa para proteger...
e suficientemente utilizável para que as pessoas queiram permanecer ali.
Isso não é fraqueza.
É arquitetura.
🧩 Risk Compensation aparece novamente
Quando introduzimos um mecanismo de proteção, comportamento humano pode mudar.
Quando removemos liberdade demais, comportamento também muda.
Usuários procuram alternativas.
Ou seja, não podemos avaliar apenas:
controle → efeito técnico.
Precisamos avaliar:
controle → reação humana → efeito sistêmico.
Esse segundo modelo é muito mais interessante.
POLICY
↓
USER PERCEPTION
↓
USER BEHAVIOR
↓
SYSTEM OUTCOME
O humano está dentro da arquitetura.
Sempre esteve.
🐒 O usuário não é um endpoint passivo
Esse talvez seja um dos maiores erros em políticas tecnológicas.
Tratar usuário como:
INPUT DEVICE
Não.
O usuário observa.
Aprende.
Adapta-se.
Compara.
Procura.
Instala.
Remove.
Contorna.
Reclama.
Muda de fornecedor.
Escreve software.
Um controle altera o comportamento do usuário.
E o comportamento do usuário altera o risco.
🧨 O paradoxo final
Imagine duas plataformas.
Plataforma A
Possui controles fortes, mas contextuais.
Bloqueia situações realmente perigosas.
Permite grande espaço para pesquisa, arte, história, literatura e expressão legítima.
Quando precisa recusar, explica razoavelmente.
Usuário:
“Tudo bem.”
Continua utilizando.
Plataforma B
Bloqueia constantemente coisas banais.
Usuário começa a mapear palavras proibidas.
Aprende contornos.
Fica irritado.
Procura alternativa.
Instala:
ULTRA-LIBERTY-UNCENSORED-MODEL-9000
baixado de:
definitely-not-malware.example
🤣
Qual sistema produziu mais segurança no mundo real?
A resposta não é automaticamente B.
👑 E voltamos ao imperador
A parte mais maravilhosa de toda essa história continua sendo Andersen.
Estávamos produzindo um artigo cuja tese era:
um sistema pode sustentar uma conclusão porque ninguém questiona adequadamente a evidência.
Então o sistema de geração olha para:
ANDERSEN
CONTO INFANTIL
IMPERADOR ADULTO
SATIRA
ARTIGO HISTÓRICO
e retorna:
PERIGO.
Eu olho.
Você olha.
O imperador olha.
A criança aponta:
“Mas é só Andersen!”
🤣🤣🤣
🧒 Precisamos novamente da criança inconveniente
Uma boa organização precisa permitir que alguém diga:
“Essa regra está produzindo um resultado absurdo.”
Isso não significa remover a regra.
Significa investigar.
Talvez exista uma razão que não percebemos.
Talvez seja falso positivo.
Talvez seja edge case.
Talvez seja bug.
Talvez a política precise permanecer.
Mas a pergunta precisa ser permitida.
Porque sistemas que não permitem questionar controles começam a acumular controles ruins.
🔄 Segurança também precisa de feedback loop
Uma política madura deveria possuir:
POLICY
↓
ENFORCEMENT
↓
RESULTS
↓
FALSE POSITIVES
↓
USER FEEDBACK
↓
REVIEW
↓
POLICY
Isso é engenharia.
Não fraqueza.
O sistema aprende.
Ajusta.
Mantém o objetivo.
Reduz ruído.
⚖️ O equilíbrio difícil
Nunca teremos uma linha perfeita.
Alguns conteúdos estarão obviamente de um lado.
Outros obviamente do outro.
E haverá uma região cinzenta gigantesca.
É nela que sistemas maduros precisam trabalhar melhor.
História.
Arte.
Sexualidade adulta.
Literatura.
Medicina.
Política.
Guerra.
Religião.
Humor.
Pesquisa.
Documentação.
Esses assuntos possuem contextos legítimos enormes e também possibilidades problemáticas.
A solução fácil é:
bloquear.
A solução difícil é:
entender.
E inteligência artificial deveria aspirar justamente à segunda.
☕ O último café
Depois de nossa pequena briga com Andersen, finalmente reformulamos a capa.
Imperador adulto.
Ceroulas históricas.
Coroa.
Dois vigaristas fingindo segurar tecido invisível.
Cortesãos constrangidos.
Uma criança apontando.
Mainframe ao fundo:
CONSENSUS = TRUE
EVIDENCE = FALSE
A imagem saiu.
E ficou ótima.
O sistema continuou protegido.
O artigo continuou existindo.
Andersen atravessou o firewall.
Ninguém precisou abolir regra alguma.
Foi necessário apenas contexto.
Talvez essa pequena história contenha uma lição muito maior para o futuro da inteligência artificial.
Não precisamos escolher entre:
ALLOW EVERYTHING
e:
DENY EVERYTHING
Entre esses dois comandos existe praticamente toda a engenharia de segurança.
Existe risco.
Existe contexto.
Existe proporcionalidade.
Existe confiança.
Existe governança.
Existe liberdade legítima.
Existe dano real.
Existe falso positivo.
E existe o usuário.
Não esqueça o usuário.
Porque se construirmos uma fortaleza tão segura que ele precise sair dela para conseguir trabalhar, talvez tenhamos criado a fortaleza mais protegida do planeta.
Só existe um pequeno problema:
ninguém estará mais lá dentro.
E do lado de fora talvez exista uma máquina baixada de algum canto obscuro da Internet, executando sem auditoria, sem atualização, sem governança e sem guardrail algum.
O administrador olha orgulhoso para seu dashboard:
SECURITY STATUS: 100% GREEN
POLICY VIOLATIONS: ZERO
USERS: ZERO
Silêncio.
Uma criança passa pelo corredor.
Olha para o monitor.
Olha para o administrador.
E pergunta:
— Se todo mundo foi embora...
o que exatamente estamos protegendo?
Hans Christian Andersen sorri em algum lugar.
O velho sysprog toma outro gole de café.
E acrescenta:
CONTROL ≠ SECURITY
RESTRICTION ≠ SAFETY
COMPLIANCE ≠ TRUST
SECURITY =
CONTROL
+ CONTEXT
+ PROPORTIONALITY
+ HUMAN BEHAVIOR
Porque o melhor firewall não é aquele que bloqueia o mundo.
É aquele que sabe distinguir o ataque do imperador de ceroulas.
ANDERSEN: ALLOW.
BULLSHIT DETECTOR: ENABLED.
RETURN CODE = 0000.
☕👑🧱🤖
Sem comentários:
Enviar um comentário