☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Governança. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Governança. Mostrar todas as mensagens

quarta-feira, 9 de setembro de 2026

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

 

Bellacosa Mainframe e o mosaico da segurança os riscos ocultos na ia

☕ Um Café no Bellacosa Mainframe

🕵️‍♂️ O Supermosaico — Segurança da Informação sob a Tutela do Dr. Moriarty

Quando nossos prompts começaram a guardar aquilo que nossa memória deveria esquecer

Imagine uma grande empresa.

Na porta existem seguranças.

Nos computadores, EDR.

Na rede, firewalls.

Nos acessos, MFA.

No mainframe, RACF.

Nos datasets, permissões.

Nos repositórios, controles.

Nos notebooks, DLP.

Nos servidores, logs.

No SOC, dezenas de telas piscando.

Tudo parece protegido.

Então o Dr. Moriarty entra em nossa sala, observa silenciosamente durante alguns minutos e faz uma pergunta desagradavelmente simples:

“Muito interessante. Mas onde seus funcionários conversam quando precisam pensar?”

Silêncio.

Bem-vindo à segurança da informação na era da Inteligência Artificial.



☕ Sob a tutela do Dr. Moriarty

Nossa história começou com uma questão aparentemente simples: profissionais utilizando Inteligência Artificial generativa para trabalhar.

Um advogado coloca partes de um processo em um prompt.

Um programador pergunta sobre um erro COBOL.

Um analista cola algumas mensagens de um dump.

Um DBA tenta entender determinada query.

Um especialista CICS pergunta sobre uma transação problemática.

Um consultor solicita ajuda para documentar uma arquitetura.

Nada disso precisa nascer de má-fé.



Pelo contrário.

O objetivo normalmente é trabalhar melhor.

Esse é justamente o ponto inquietante.

O artigo que motivou esta reflexão chama atenção para o fato de que informações de terceiros podem ser transferidas para sistemas externos durante o uso aparentemente cotidiano de IA e utiliza como exemplo conhecido os incidentes de 2023 envolvendo funcionários da Samsung e informações corporativas inseridas no ChatGPT.

A discussão original concentra-se principalmente em advocacia, sigilo profissional, proteção de dados e governança.

Mas vamos colocar nossa xícara de café sobre a mesa e levar o problema para dentro de uma instalação mainframe.

Moriarty está esperando.



🧩 A primeira tessela

Imagine um jovem programador COBOL.

Ele recebe:

ABEND S0C7

Abre sua ferramenta favorita de IA e pergunta:

Tenho um programa COBOL apresentando S0C7.

O erro acontece nesta rotina.

Pode me ajudar?

Perfeitamente razoável.

A IA pede contexto.

Nosso programador fornece algumas linhas.

Depois mais algumas.

Aparece o nome de um programa.

Depois uma tabela.

Uma transação.

Uma mensagem CICS.

Nada parece particularmente importante.

Temos nossa primeira tessela.

Uma pequena pedra quadrangular daqueles magníficos mosaicos romanos.

Sozinha, ela significa quase nada.



🏛️ O mosaico romano

Na semana seguinte:

TRANID = ABC1

Outra tessela.

Meses depois:

PROGRAM = PAY001

Outra.

Mais tarde:

PAY001 atualiza DB2 antes do MQPUT.

Outra.

Em dezembro:

A fila PAYMENT.REQUEST cresce
durante o fechamento mensal.

Outra.

No ano seguinte:

ABC1 chama PAY001.

Agora coloque as pedras juntas:

ABC1
 │
 ▼
PAY001
 │
 ├────► DB2
 │
 ▼
MQPUT
 │
 ▼
PAYMENT.REQUEST

Curioso.

Nenhum prompt individual descreveu necessariamente toda a arquitetura.

Mas a arquitetura começa a aparecer pela correlação.

Essa é nossa primeira grande lição sob a tutela de Moriarty:

Informações aparentemente insignificantes podem adquirir enorme valor quando possuem relacionamentos.


🧠 O analista começa a documentar a empresa sem perceber

Passemos três anos.

Nosso programador virou analista.

Ele utilizou IA milhares de vezes.

Perguntou sobre:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • MQ;

  • VSAM;

  • RACF;

  • APIs;

  • incidentes;

  • dumps;

  • arquitetura;

  • regras de negócio;

  • migrações;

  • problemas de produção.

Mas existe uma característica interessante.

Normalmente perguntamos à IA justamente sobre aquilo que não entendemos.

Consequentemente, nosso histórico pode acabar concentrando momentos excepcionais:

ERRO
 ↓
DÚVIDA
 ↓
PROMPT

INCIDENTE
 ↓
DÚVIDA
 ↓
PROMPT

ARQUITETURA ESTRANHA
 ↓
DÚVIDA
 ↓
PROMPT

EXCEÇÃO DE NEGÓCIO
 ↓
DÚVIDA
 ↓
PROMPT

O histórico não é necessariamente uma amostra aleatória do ambiente.

Pode ser uma coleção justamente das coisas estranhas, difíceis ou importantes.

Quase um diário operacional involuntário.


📖 “Querido diário, produção caiu novamente...”

Imagine encontrar uma conversa antiga:

“Por que essa rotina precisa executar antes das 22 horas?”

Outra:

“Por que não podemos alterar esse campo?”

Outra:

“Esse programa existe desde a aquisição da empresa XPTO.”

Outra:

“Quando o sistema secundário está indisponível usamos esta contingência.”

Perceba que estamos gradualmente deixando de falar somente de código.

Estamos falando de:

contexto.

E contexto frequentemente vale mais do que código.

Um programa COBOL pode dizer:

IF WS-STATUS = '99'
    PERFORM 9000-CONTINGENCIA
END-IF.

Mas talvez não explique por que 99 existe.

O veterano explica:

“Isso foi criado depois daquele problema de 2008 porque o sistema externo ficava indisponível no fechamento.”

Pronto.

Temos história.

Temos arquitetura.

Temos dependência.

Temos regra operacional.

Temos conhecimento institucional.


🧓 O veterano pode ser mais interessante que o administrador

Aqui Moriarty levanta a sobrancelha.

Tradicionalmente pensamos:

“Quem possui maior privilégio?”

Administrador.

RACF SPECIAL.

DBA.

SYSADM.

ROOT.

Mas existe outra espécie de privilégio:

Knowledge Privilege.

Talvez aquele veterano não possua RACF SPECIAL.

Entretanto ele sabe:

por que X depende de Y;

quem resolve determinado incidente;

qual sistema não pode parar;

qual processo possui contingência;

quais componentes são antigos;

onde existem dependências históricas;

por que determinada decisão foi tomada;

quais problemas aparecem no fechamento.

O usuário privilegiado possui Access Privilege.

O veterano possui Knowledge Privilege.

Em alguns cenários de ameaça, precisamos proteger ambos.


🕰️ Janeiro de 2023

Agora chegamos a uma coisa extraordinária.

O ser humano esquece.

Imagine que nosso especialista tenha resolvido um incidente em janeiro de 2023.

Em setembro de 2026 alguém pergunta:

“Você lembra daquele problema?”

Provavelmente:

“Mais ou menos...”

Depois:

“Não lembro exatamente.”

Isso sempre foi uma espécie de deterioração natural da informação.

Mas imagine que naquele janeiro ele tenha escrito uma longa conversa com uma IA.

Dependendo do serviço, das configurações e das políticas de retenção, aquela conversa poderá ter permanecido armazenada.

Então temos:

MEMÓRIA HUMANA

evento
  ↓
tempo
  ↓
degradação
  ↓
abstração
  ↓
esquecimento

contra:

REGISTRO DIGITAL

evento
  ↓
texto
  ↓
armazenamento
  ↓
pesquisa
  ↓
recuperação

Aquilo que o cérebro deveria esquecer pode permanecer registrado.

Chamemos isso de:

Knowledge Residue

Resíduo de conhecimento.


🚪 O funcionário desligado

Agora Moriarty apresenta outro personagem.

Durante três anos nosso funcionário trabalhou normalmente.

Não roubou nada.

Não planejou fraude.

Não tentou prejudicar ninguém.

Então foi demitido.

Ficou ressentido.

No modelo tradicional de insider threat, talvez esperássemos observar:

download enorme;
cópia para USB;
upload suspeito;
e-mail externo;
ZIP com sources;
impressões anormais.

Mas surge uma possibilidade diferente.

E se informações inadequadamente compartilhadas já estivessem acumuladas em ambientes externos antes de aparecer a intenção maliciosa?

O problema fundamental torna-se:

o momento da aquisição da informação pode estar separado por anos do momento em que aparece a intenção de abusar dela.

No desligamento fazemos:

REVOKE RACF
REMOVE VPN
DISABLE EMAIL
DISABLE GITHUB
RETURN NOTEBOOK
RETURN BADGE
REVOKE CERTIFICATES

Excelente.

Mas Moriarty pergunta:

“E a memória digital externalizada anteriormente?”

É uma pergunta de governança, não uma justificativa para investigar indiscriminadamente contas pessoais de ex-funcionários.

A resposta precisa começar antes, com ferramentas corporativas apropriadas, separação de identidades, classificação, políticas de retenção e regras claras sobre aquilo que pode ser fornecido a sistemas de IA.


🎒 Chega o consultor

Moriarty sorri.

O funcionário conhece uma empresa.

O consultor conhece muitas.

Imagine:

2023 → Banco A
2024 → Seguradora B
2024 → Varejista C
2025 → Governo D
2025 → Montadora E
2026 → Banco F

Em cada organização ele aprende.

Essa transferência de experiência é perfeitamente normal.

Aliás, contratamos consultores justamente porque podem dizer:

“Já encontrei um problema semelhante.”

Existe, entretanto, diferença enorme entre carregar experiência profissional e carregar artefatos detalhados de conhecimento de clientes anteriores.

Historicamente, o cérebro fornecia uma abstração interessante:

experiência específica
       ↓
      tempo
       ↓
   esquecimento
       ↓
   abstração
       ↓
 conhecimento geral

O consultor esquecia nomes, valores, incidentes e detalhes.

Mas permanecia sabendo:

“Esse tipo de arquitetura costuma apresentar este problema.”

Excelente.

Isso é experiência.

Agora imaginemos uma conta pessoal ou ambiente inadequadamente segregado contendo conversas detalhadas provenientes de sucessivos projetos.

Temos potencialmente:

CLIENTE A ─┐
CLIENTE B ─┤
CLIENTE C ─┤
CLIENTE D ─┼──► CORPUS
CLIENTE E ─┤
CLIENTE F ─┘

Nasce nosso:

SUPERMOSAICO.


🌎 O Supermosaico

O mosaico permite reconstruir aspectos de uma empresa.

O Supermosaico acrescenta algo diferente:

comparação.

Cliente A faz X.

Cliente B utiliza X + Y.

Cliente C abandonou X depois de determinado problema.

Cliente D acrescentou Z.

Nenhuma dessas informações isoladamente precisa declarar:

“A possui uma deficiência.”

Mas a comparação pode produzir uma hipótese:

“Por que A aparentemente não possui Y ou Z?”

Nasceu informação que não estava explicitamente escrita.

Temos:

INFORMAÇÃO A
+
INFORMAÇÃO B
+
INFORMAÇÃO C
+
CONTEXTO
+
CORRELAÇÃO
=
INFORMAÇÃO DERIVADA

Esse é um dos pontos mais importantes desta história.

Precisamos proteger não somente informações sensíveis individualmente, mas pensar também em informações correlacionáveis.


🕵️ Moriarty finalmente começa sua aula

Até aqui Moriarty permaneceu sentado.

Agora ele se levanta.

Ele não pergunta:

“Onde está SECRET.DOC?”

Pergunta:

“O que posso inferir?”

Essa é uma mudança monumental.

O invasor caricatural procura:

PASSWORD.TXT

Moriarty procura:

relações;
padrões;
cronologia;
contradições;
dependências;
mudanças;
exceções;
incertezas.

Porque informação de inteligência não precisa estar escrita diretamente.

Ela pode surgir da combinação.


📧 Gmail, Drive, GitHub, WhatsApp, Telegram, celular...

Nossa identidade digital moderna está espalhada.

Temos:

e-mail pessoal
e-mail corporativo
GitHub
Google Drive
OneDrive
celular
notebook
micro pessoal
WhatsApp
Telegram
calendário
redes sociais
conta de IA

Antigamente imaginávamos segurança como uma muralha:

        FIREWALL
████████████████████████
       EMPRESA

Hoje precisamos imaginá-la como um grafo:

          PESSOA
        /   |    \
       /    |     \
   Gmail  GitHub  IA
     |      |      |
   Drive   código contexto
     \      |      /
       \    |     /
         CELULAR
            |
        IDENTIDADE
            |
         EMPRESA

Moriarty não precisa necessariamente perguntar:

“Como atravesso a muralha?”

Ele pode perguntar:

“Quais relações chegam até ela?”

Essa é uma excelente maneira defensiva de fazer threat modeling.


🏰 Primeiro o sentinela

Imagine um castelo.

Atacar diretamente o rei é difícil.

Então nosso Moriarty hipotético observa:

SENTINELA
    ↓
CAPITÃO
    ↓
OFICIAL
    ↓
CONSELHEIRO
    ↓
CASTELO

No mundo corporativo:

JÚNIOR
  ↓
N2
  ↓
N3
  ↓
SME
  ↓
ARQUITETO

Isso não significa que essa sequência permita comprometimento automático.

Não permite.

Mas mostra algo importante:

confiança também possui topologia.

Um funcionário confia em outro.

Uma identidade possui recuperação ligada a outra.

Um dispositivo possui sessões.

Um serviço contém referências a outros serviços.

Um calendário revela relacionamentos.

Um repositório revela tecnologias.

Precisamos analisar o blast radius de identidades, não somente permissões técnicas.


🔐 RACF emocional

Aqui nosso jovem COBOL finalmente entende Moriarty.

No RACF temos algo parecido com:

USER
 ↓
GROUP
 ↓
CONNECT
 ↓
PERMIT
 ↓
RESOURCE

Uma identidade isolada diz pouco.

Os relacionamentos dizem muito.

Agora aplique a mesma ideia à pessoa:

PESSOA
 ↓
IDENTIDADES
 ↓
DISPOSITIVOS
 ↓
SERVIÇOS
 ↓
SESSÕES
 ↓
DADOS
 ↓
RELACIONAMENTOS
 ↓
CONFIANÇA

Voilà!

Temos uma espécie de:

RACF da vida digital.

Só que muito menos organizado.


📦 Contrabando de conhecimento

Agora chegamos a outro conceito surgido durante nossa investigação.

Empresas procuram eventos grandes:

40 MB enviados por e-mail → ALERTA

ZIP com sources → ALERTA

USB → ALERTA

FTP → ALERTA

GitHub público → ALERTA

Enquanto isso:

prompt 001 → 2 KB
prompt 002 → 4 KB
prompt 003 → 1 KB
...
prompt 847 → 6 KB

Tudo pequeno.

Tudo aparentemente cotidiano.

Mas estamos confundindo:

volume físico

com

volume semântico.

Um especialista pode condensar vinte anos de experiência em três parágrafos.

Talvez sejam apenas 5 KB.

Semanticamente podem valer muito.

Por isso “contrabando de conhecimento” é uma excelente metáfora, embora em governança eu preferisse termos como:

transferência de conhecimento não governada

ou

canal cumulativo de exposição de conhecimento.

Porque nem todo prompt constitui exfiltração e nem todo usuário possui intenção indevida.


🛡️ DLP talvez não seja suficiente

Data Loss Prevention tradicionalmente pergunta:

“Que dado está saindo?”

Nosso problema exige outra pergunta:

“Que conhecimento está sendo construído pela soma daquilo que está saindo?”

Daí surge:

KLP — Knowledge Loss Prevention

Não estou propondo aqui um padrão formal universal chamado KLP.

Estou usando o termo como conceito para ampliar nossa maneira de pensar.

DLP:

PROTEJA O DADO

KLP:

PROTEJA:
dados
+
contexto
+
relações
+
acumulação
+
tempo
+
conhecimento derivável

Porque:

PROMPT 1 = VERDE
PROMPT 2 = VERDE
PROMPT 3 = VERDE

...

Σ PROMPTS = VERMELHO

O risco pode emergir da soma.


🐒 Um milhão de chimpanzés bebedores de saquê

É claro que nenhum tratado Bellacosa Mainframe estaria completo sem nossos agentes especiais.

Imagine um corpus contendo:

"Meu CICS conversa telepaticamente com Saturno."

"Verificar MQ amanhã."

"O gato assumiu RACF SPECIAL."

"Por que PAY001 apresenta S0C7?"

"Napoleão teria usado VSAM."

"Não esquecer daquele JOB."

"Um milhão de chimpanzés bebendo saquê
administram produção."

Um investigador humano provavelmente pediria transferência de departamento.

Mas não devemos considerar volume e ruído controles de segurança confiáveis.

Sistemas automatizados conseguem classificar conteúdo, encontrar recorrências e separar grandes quantidades de informação muito mais rapidamente que uma pessoa.

Além disso, existe uma vítima colateral.

Você.

Três anos depois abre a conversa e pergunta:

“Que porra eu quis dizer com isso?”

😂

A contrainteligência funcionou tão bem que derrotou o próprio autor.


🧠 Facebook, dados comportamentais e Moriarty

Agora ampliemos novamente a escala.

Redes sociais mostraram ao mundo o valor da correlação de enormes quantidades de dados comportamentais.

IA conversacional introduz uma diferença conceitualmente importante.

Nas redes sociais frequentemente observamos:

curtiu
clicou
assistiu
compartilhou
seguiu
comprou

e tentamos inferir alguma coisa.

Em conversas com IA o próprio usuário frequentemente fornece:

"meu problema é..."

"não entendo..."

"estou considerando..."

"tenho duas alternativas..."

"minha arquitetura funciona assim..."

"por que isso aconteceu?"

"qual opção você escolheria?"

Isso pode representar contexto cognitivo muito mais explícito.

Não devemos concluir daí que provedores estejam oferecendo conversas privadas para terceiros. Estamos construindo um modelo hipotético de ameaça.

Mas defensivamente precisamos perguntar:

Qual seria o impacto se determinado corpus conversacional fosse indevidamente exposto?

Essa pergunta basta.


🎭 Moriarty não quer apenas saber o que aconteceu

Nosso professor do crime imaginário está interessado também em:

incerteza.

Considere:

“Não sei se devemos migrar X para Y.”

Essa frase revela mais do que parece.

Ela sugere:

X existe.

Y é considerado.

há uma decisão pendente.

o autor participa da discussão.

existe incerteza.

Isso é extraordinariamente interessante para inteligência.

Não estamos observando somente uma decisão passada.

Estamos observando o espaço de possibilidades anterior à decisão.


⚖️ O advogado entra novamente na sala

Voltemos ao artigo original.

Ele argumenta que informações identificáveis de clientes merecem atenção especial e recomenda práticas como anonimização e ambientes apropriados para informações sensíveis.

Nosso Supermosaico acrescenta outra preocupação.

Um advogado pode registrar:

processo;
estratégia;
dúvidas;
hipóteses;
limites de negociação;
fragilidades percebidas;
possíveis argumentos.

Novamente, isso não significa que a contraparte consiga simplesmente acessar essas conversas.

Não consegue.

Seria necessário algum evento adicional de exposição, comprometimento ou falha de governança.

Mas o impacto potencial do corpus merece entrar no threat model.


⚔️ A assimetria computacional

Imagine:

ZÉ DA SILVA
     │
advogado pequeno
notebook
tempo limitado
     │
     VS
     │
MEGACORP S/A
     │
equipe jurídica
especialistas
bases jurídicas
engenharia
automação
análise documental
IA

IA pode democratizar recursos antes inacessíveis ao pequeno advogado.

Isso é excelente.

Mas também pode industrializar capacidades de grandes organizações.

Temos duas forças simultâneas:

IA → DEMOCRATIZAÇÃO

IA → CONCENTRAÇÃO

Qual vencerá?

Provavelmente dependerá de acesso, custo, regulação, educação e governança.


🛡️ Como derrotar Moriarty sem abandonar IA

A resposta não é:

“Proibam tudo!”

Isso desperdiçaria uma tecnologia extraordinariamente útil.

O próprio artigo que iniciou nossa reflexão defende uma abordagem de governança em vez da simples interrupção do uso da IA.

Precisamos tornar Moriarty caro.

1. Separar identidades

PESSOAL ≠ PROFISSIONAL

2. Separar clientes

CLIENTE A ≠ CLIENTE B

3. Separar projetos

Não criar desnecessariamente um Supermosaico.

4. Minimizar

Pergunte:

“A IA realmente precisa saber isso?”

5. Sanitizar

Troque:

BANCO-REAL-XYZ

por:

CLIENTE-A

quando o detalhe real não for necessário.

6. Remover segredos

Tokens, credenciais, dados pessoais, dumps completos e informações confidenciais não devem passear livremente por prompts.

7. Governar retenção

A organização precisa saber onde conversas corporativas ficam e qual é seu ciclo de vida.

8. Governar consultores

A política precisa alcançar terceiros adequadamente, não somente empregados.

9. Pensar cumulativamente

Pergunte não apenas:

“Este prompt é perigoso?”

mas:

“O que cem prompts como este revelariam?”

10. Modelar Knowledge Privilege

Identifique não apenas quem possui grandes permissões.

Identifique funções que possuem enorme contexto institucional.


🔬 Um Red Team diferente

Podemos testar tudo isso sem atacar ninguém.

Crie uma empresa fictícia.

Um banco chamado:

BANCO MORIARTY S/A

Crie:

Carlos — N3 CICS
Maria — DBA
João — arquiteto
Ana — consultora
Watson — segurança

Produza informações sintéticas.

Simule um ano de prompts permitidos.

Depois entregue somente esse corpus para outro time autorizado e pergunte:

“O que vocês conseguem reconstruir sobre nossa empresa fictícia?”

Arquitetura?

Dependências?

Pessoas?

Sistemas críticos?

Cronologia?

Regras de negócio?

Tecnologias?

Incidentes?

Se o resultado for surpreendentemente detalhado, encontramos uma deficiência de governança sem comprometer uma única empresa real.

Esse seria um belíssimo exercício de Red Team de conhecimento.


🕒 03:17 — O incidente

Às 03:17 da madrugada, o telefone toca.

Produção está normal.

Nenhum dataset foi copiado.

Nenhum usuário RACF utilizou SPECIAL.

Nenhum arquivo de 40 GB saiu pela rede.

Nenhum pendrive apareceu.

Nenhum source foi publicado.

Nenhum alarme tradicional disparou.

Watson olha para Moriarty:

“Então não houve incidente?”

Moriarty toma tranquilamente seu café.

“Meu caro Watson... você ainda está procurando o arquivo.”

Sobre a mesa existem 12.847 pequenas tesselas.

Uma transação aqui.

Uma regra ali.

Um incidente acolá.

Uma decisão arquitetural.

Uma dependência.

Um fornecedor.

Uma exceção.

Uma dúvida.

Uma história de vinte anos resumida por alguém em cinco linhas.

Watson começa a juntar as pedras.

A figura aparece.

Não existe MEGACORP-SECRETS.ZIP.

Nunca existiu.

Existe algo potencialmente muito mais interessante:

conhecimento.


☕ A última lição do Dr. Moriarty

Durante décadas construímos excelentes mecanismos para responder:

Quem pode acessar este dado?

RACF responde isso maravilhosamente no mainframe.

IAM responde.

PAM responde.

ACL responde.

MFA ajuda.

Zero Trust ajuda.

DLP ajuda.

Mas IA nos obriga a acrescentar novas perguntas:

Quem pode externalizar esse conhecimento?

Quanto contexto pode ser acumulado ao longo do tempo?

Que informação aparentemente inocente se torna sensível quando correlacionada?

Onde termina experiência profissional e começa memória corporativa portátil?

O que acontece com o corpus depois que o funcionário ou consultor deixa a organização?

Qual é o blast radius do comprometimento de uma identidade que possui anos de conversas profissionais?

E principalmente:

Estamos protegendo somente aquilo que nossos funcionários acessam ou também os lugares onde eles passaram a registrar aquilo que sabem?

Essa talvez seja uma das grandes discussões de segurança da era da Inteligência Artificial.

Não significa abandonar IA.

Significa amadurecer sua utilização.

O profissional que pergunta corretamente para uma IA pode produzir em minutos algo que anteriormente consumiria horas.

Isso é fantástico.

Mas justamente por querermos respostas melhores somos incentivados a fornecer mais contexto.

E contexto é conhecimento.

Conhecimento acumulado cria mosaicos.

Mosaicos correlacionados criam Supermosaicos.

Portanto, sob a tutela do Dr. Moriarty, terminamos com uma regra simples:

O maior segredo talvez não esteja em nenhuma tessela. O segredo pode ser a imagem que aparece quando alguém consegue juntar tesselas suficientes.

E Sherlock Holmes provavelmente acrescentaria:

“Proteja as pedras, Watson.”

Moriarty sorriria.

“Não. Proteja as relações entre elas.”

Bellacosa Mainframe — onde até um simples prompt pode acabar virando uma tessela no mosaico.

domingo, 9 de agosto de 2026

DELETE USER não apaga memória: o quarteirizado, o segredo empresarial e o conhecimento que atravessa a catraca

Bellacosa Mainframe e o delete user


☕ Um Café no Bellacosa Mainframe

DELETE USER não apaga memória: o quarteirizado, o segredo empresarial e o conhecimento que atravessa a catraca

🔴🔵 Matrix, COBOL e o paradoxo das empresas que querem profissionais experientes, mas não querem que a experiência adquirida dentro delas saia pela porta

Por Vagner Bellacosa


Sexta-feira.

17:58.

O projeto terminou.

Depois de dois anos trabalhando dentro de um grande banco, nosso personagem recebe a última mensagem.

Obrigado pela colaboração.

17:59.

O notebook é devolvido.

18:00.

O crachá deixa de funcionar.

18:01.

VPN bloqueada.

Usuário revogado.

E-mail desabilitado.

Token cancelado.

RACF executa seu trabalho.

REVOKE USER .............. RC=00
DELETE ACCESS ............ RC=00
DISABLE VPN .............. RC=00
RETURN NOTEBOOK .......... RC=00
INVALIDATE BADGE ......... RC=00

Excelente.

Auditoria satisfeita.

Segurança satisfeita.

Procurement satisfeito.

Projeto encerrado.

Só esqueceram um comando.

ERASE EXPERIENCE ......... RC=12

Tentamos novamente.

DELETE FROM HUMAN_MEMORY
 WHERE COMPANY = 'BANCO-A';

Resultado:

SQLCODE = -99999

FUNCTION NOT SUPPORTED.

Houston, temos um problema.

Ou melhor:

Morpheus, temos um problema.

Porque aquele profissional acabou de atravessar a catraca levando consigo algo que nenhum detector de metais consegue encontrar.

Conhecimento.

Pegue seu café.

Hoje vamos entrar numa das salas mais estranhas da Matrix corporativa.


💊 Duas pílulas sobre a mesa

Morpheus oferece novamente duas possibilidades.

🔵 Pílula azul:

O profissional assinou contratos.

Existem políticas de segurança.

Existem cláusulas de confidencialidade.

Existem leis.

Existem controles de acesso.

Existem responsabilidades éticas.

Segredo empresarial continua sendo segredo empresarial depois que o contrato termina.

Correto.

Agora a outra.

🔴 Pílula vermelha:

O contrato pode impedir legitimamente determinadas divulgações.

Mas não consegue apagar aquilo que o cérebro aprendeu.

Também correto.

Nosso problema começa exatamente entre essas duas verdades.


🧠 Afinal, o que saiu pela catraca?

Vamos imaginar um programador COBOL contratado para trabalhar dois anos em determinado sistema financeiro.

Quando entrou, conhecia:

COBOL
JCL
CICS
DB2
VSAM
MQ
MAINFRAME

Dois anos depois, continua conhecendo tudo isso.

Mas agora também sabe outras coisas.

Conhece padrões arquiteturais.

Entende determinados processos.

Conhece problemas recorrentes.

Aprendeu como grandes volumes se comportam.

Viu decisões funcionarem.

Viu decisões fracassarem.

Participou de incidentes.

Conheceu integrações.

Aprendeu características daquele segmento de negócio.

Descobriu por que certas abordagens aparentemente óbvias não funcionam.

Percebeu gargalos.

Desenvolveu intuição.

Tudo isso cabe em qual classificação?

PUBLIC?
INTERNAL?
CONFIDENTIAL?
SECRET?
PROFESSIONAL EXPERIENCE?

Agora a coisa ficou interessante.


🔐 Segredo não é experiência

Precisamos estabelecer uma diferença fundamental.

Um profissional não ganha direito de sair distribuindo:

código proprietário,

dados de clientes,

credenciais,

documentação confidencial,

planos estratégicos,

informações comerciais protegidas,

segredos empresariais,

informações pessoais,

arquivos internos.

O fim do contrato não transforma material confidencial em domínio público.

Não existe:

IF CONTRACT = EXPIRED
   MOVE CONFIDENTIAL TO PUBLIC
END-IF.

Isso seria absurdo.

Segurança, ética profissional, contratos, propriedade intelectual, proteção de dados e legislação continuam importantes.

Mas existe outra categoria.

Experiência.

Se durante um projeto você descobre que determinada arquitetura apresenta problemas de escalabilidade, não consegue simplesmente desaprender isso.

Se participa de um incidente causado por determinada decisão, aquela experiência passa a fazer parte do seu repertório.

Se descobre uma maneira melhor de organizar determinada rotina batch, você não volta magicamente ao estado anterior quando troca de empresa.

É aí que a fronteira começa.


🧳 A bagagem invisível

Imagine que nosso profissional atravesse a catraca carregando uma mochila.

Segurança verifica:

NOTEBOOK ............... DEVOLVIDO
TOKEN .................. DEVOLVIDO
DOCUMENTOS .............. OK
PENDRIVE ................ NENHUM
CELULAR ................. OK

Tudo certo.

Mas existe outra mochila.

Invisível.

Dentro dela:

EXPERIÊNCIA
│
├── decisões que funcionaram
├── decisões que fracassaram
├── padrões reconhecidos
├── conhecimento do setor
├── técnicas aprendidas
├── problemas já enfrentados
├── soluções experimentadas
├── intuição
└── memória profissional

Essa mochila pertence a quem?

A empresa?

Ao profissional?

A ambos?

Depende do conteúdo.

E talvez essa seja uma das perguntas mais difíceis da economia do conhecimento.


🏦 Segunda-feira: Banco B

Nosso profissional terminou o projeto sexta-feira.

Existe um detalhe inconveniente.

Segunda-feira chegam:

aluguel,

energia,

água,

alimentação,

escola,

transporte,

impostos,

financiamento,

cartão,

boletos.

Os boletos possuem uma arquitetura extraordinariamente resiliente.

EMPLOYMENT STATUS = INACTIVE

BILLING STATUS = ACTIVE

🤣

O profissional precisa encontrar outro projeto.

Abre o LinkedIn.

Atualiza o perfil.

OPEN TO WORK

E aparece uma oportunidade.

Banco B.

Concorrente do Banco A.

Precisam exatamente de alguém com:

experiência em sistemas financeiros de grande porte.

Ora...

Foi exatamente isso que Banco A passou dois anos ensinando indiretamente ao profissional.

E aqui aparece o paradoxo.

Banco A queria alguém experiente quando contratou.

Banco B também quer.

Mas de onde vem experiência?

De experiências anteriores.


🐔 O ovo e a galinha da experiência

Toda vaga sênior possui uma frase aproximadamente assim:

Necessária experiência comprovada no setor.

Traduzindo:

PROCURA-SE ALGUÉM
QUE TENHA APRENDIDO
TRABALHANDO PARA OUTRA PESSOA.

Isso é perfeitamente normal.

É assim que profissões evoluem.

Mas existe uma tensão interessante.

Empresas querem contratar experiência acumulada em outros lugares.

Ao mesmo tempo, naturalmente prefeririam que conhecimentos estratégicos adquiridos dentro delas não beneficiassem concorrentes.

As duas coisas não são completamente compatíveis.

Não podemos dizer:

Quero seus vinte anos de experiência.

e simultaneamente:

Mas tudo aquilo que aprender aqui deverá desaparecer da sua cabeça quando sair.

A humanidade ainda não implementou essa API.


🧓 O veterano carrega erros pagos por outros

Existe algo ainda mais valioso que soluções.

Erros.

Um profissional experiente carrega um verdadeiro cemitério de decisões ruins.

SOLUÇÃO A
RESULTADO: FALHOU

SOLUÇÃO B
RESULTADO: CARA DEMAIS

SOLUÇÃO C
RESULTADO: FUNCIONOU PARCIALMENTE

SOLUÇÃO D
RESULTADO: FUNCIONOU

No próximo projeto alguém propõe A.

O veterano imediatamente diz:

— Eu evitaria isso.

— Por quê?

— Já vi dar problema.

Pronto.

Talvez tenha acabado de economizar seis meses e alguns milhões.

Ele roubou segredo empresarial?

Não necessariamente.

Pode simplesmente ter utilizado experiência profissional legítima.

E aqui aparece uma frase que deveria estar em toda discussão sobre senioridade:

Experiência é, em parte, um banco de dados de erros que alguém já pagou para você presenciar.

Quanto vale isso?

Boa pergunta.


💰 O custo invisível da terceirização

Quando procurement compara alternativas, a planilha talvez apresente:

MODELO A - FUNCIONÁRIO
CUSTO: XXXXX

MODELO B - CONSULTORIA
CUSTO: XXXX

MODELO C - TERCEIRIZAÇÃO
CUSTO: XXX

MODELO D - QUARTEIRIZAÇÃO
CUSTO: XX

Excelente.

Mas talvez estejam faltando algumas colunas.

RETENÇÃO DE CONHECIMENTO ............. ???
TRANSFERÊNCIA DE KNOW-HOW ............ ???
ROTATIVIDADE ......................... ???
RECONSTRUÇÃO DE CONTEXTO ............. ???
DEPENDÊNCIA DE TERCEIROS ............. ???
EXPOSIÇÃO COMPETITIVA ................ ???
TEMPO PARA TREINAR SUBSTITUTO ........ ???

De repente o modelo mais barato ficou um pouco mais difícil de identificar.

Isso não significa que terceirizar seja errado.

Existem excelentes razões para terceirização.

Elasticidade.

Especialização.

Velocidade.

Acesso a talentos.

Redução de estruturas permanentes.

Projetos temporários.

Transferência de determinadas responsabilidades.

Tudo legítimo.

A pílula vermelha não diz:

Terceirização é ruim.

Ela pergunta:

Estamos contabilizando todos os custos da terceirização ou apenas aqueles que cabem facilmente numa planilha?


🧱 E então terceirizamos a terceirização

Agora vamos adicionar algumas camadas.

BANCO
  ↓
CONSULTORIA A
  ↓
CONSULTORIA B
  ↓
FORNECEDOR C
  ↓
PROFISSIONAL

O banco possui contrato com A.

A possui contrato com B.

B possui contrato com C.

C encontrou o profissional.

Cada camada pode possuir controles perfeitamente válidos.

Mas surge uma questão de governança:

qual é o vínculo real entre o profissional que conhece o sistema e a organização proprietária daquele sistema?

Talvez muito pequeno.

Ele pode não possuir:

carreira dentro do banco,

perspectiva de longo prazo,

participação futura,

estabilidade,

identificação organizacional,

incentivo econômico para permanecer.

Mas pode possuir:

ACCESS TO CRITICAL SYSTEM = YES
KNOWLEDGE OF BUSINESS     = YES
INCIDENT EXPERIENCE       = YES
ARCHITECTURE KNOWLEDGE    = YES
LONG-TERM RELATIONSHIP    = NO

Essa combinação deveria pelo menos despertar curiosidade.


🕶️ Agent Smith entra na sala

Agent Smith olha a planilha.

— Mr. Anderson, seu contrato termina sexta-feira.

Anderson responde:

— Certo.

— Você devolverá o notebook.

— Sim.

— Seu acesso será revogado.

— Sim.

— Não poderá levar arquivos.

— Evidentemente.

— Não poderá divulgar informações confidenciais.

— Concordo.

Smith faz uma pausa.

— E tudo que aprendeu aqui?

Anderson olha para Morpheus.

Morpheus sorri.

Não existe checkbox para isso.


⏳ A meia-vida do conhecimento

Agora chegamos a um conceito fascinante.

Nem todo conhecimento mantém seu valor estratégico para sempre.

Algumas informações envelhecem rapidamente.

Outras sobrevivem décadas.

Podemos imaginar uma espécie de:

Meia-Vida do Conhecimento

Um segredo sobre uma operação que acontecerá amanhã pode valer muito hoje.

Na semana seguinte talvez valha quase nada.

Uma negociação empresarial pode ser altamente sensível durante meses.

Depois de concluída e anunciada, seu valor confidencial muda.

Uma estratégia tecnológica pode permanecer relevante durante anos.

Conhecimento de negócio pode durar muito mais.

E experiência?

Experiência pode acompanhar o profissional pelo resto da vida.

CREDENCIAL ............... HORAS / DIAS
OPERAÇÃO ................. DIAS
NEGOCIAÇÃO ............... MESES
ROADMAP .................. MESES / ANOS
ARQUITETURA .............. ANOS
REGRA DE NEGÓCIO ......... ANOS
KNOW-HOW .................. DÉCADAS
EXPERIÊNCIA .............. VIDA

Não é uma escala científica.

É um modelo mental.

Mas ajuda a perceber algo fundamental:

informações possuem velocidades diferentes de envelhecimento.


🌳 Garden Leave: quando a empresa compra tempo

Algumas organizações e profissões reconhecem exatamente esse problema.

Em determinadas relações contratuais e jurisdições existe aquilo que costuma ser chamado de garden leave.

Simplificando muito:

o profissional deixa de atuar operacionalmente, mas permanece remunerado durante determinado período e sujeito às condições aplicáveis ao vínculo.

Por quê?

Tempo.

A empresa está, entre outras coisas, comprando distância temporal.

Durante esse período:

projetos avançam,

estratégias mudam,

negociações terminam,

preços mudam,

equipes mudam,

informações envelhecem.

O profissional deixa de receber conhecimento novo.

Parte do conhecimento sensível que carregava perde valor competitivo.

É quase:

KNOWLEDGE-TTL

Time To Live.

Isso não apaga memória.

Mas permite que determinadas informações percam atualidade.


💵 Espere... então conhecimento possui preço?

Aqui aparece uma ironia maravilhosa.

Se uma organização aceita pagar alguém durante meses para que ele não leve imediatamente determinado conhecimento para outro contexto competitivo, ela implicitamente reconhece uma coisa:

aquilo que está na cabeça dele possui valor econômico.

Pense nisso.

Não estamos mais discutindo metafísica.

Existe dinheiro sendo utilizado para administrar a velocidade com que conhecimento circula.

CONHECIMENTO SENSÍVEL
        +
TEMPO
        =
REDUÇÃO POTENCIAL
DO VALOR ESTRATÉGICO

Naturalmente isso depende de legislação, contrato, função e jurisdição.

Não é uma solução universal.

Mas conceitualmente é extraordinário.


🤔 E o quarteirizado?

Agora coloque as duas situações lado a lado.

EXECUTIVO / FUNÇÃO ESTRATÉGICA

Sai
 ↓
Afastamento remunerado
 ↓
Tempo
 ↓
Informação envelhece
 ↓
Mercado

Agora:

QUARTEIRIZADO

Sai sexta 18h
 ↓
Sem projeto
 ↓
Sem receita
 ↓
Boletos
 ↓
Segunda 08h
 ↓
Mercado

Não estou dizendo que deveriam receber tratamento idêntico.

Responsabilidades, contratos e níveis de acesso são diferentes.

Mas existe uma pergunta legítima:

Será que classificamos corretamente a sensibilidade pelo cargo ou deveríamos classificá-la também pelo conhecimento efetivamente acumulado?

Porque o organograma pode dizer:

EXTERNAL RESOURCE

enquanto a realidade diz:

KNOWS WHERE THE BODIES ARE BURIED

Metaforicamente, espero.

😂


🔐 Zero Trust deveria chegar ao conhecimento?

Segurança moderna trabalha muito com princípios como:

least privilege,

need to know,

segregation of duties,

zero trust,

monitoramento,

auditoria.

Excelente.

Mas frequentemente pensamos principalmente em acesso.

CAN USER READ DATASET X?

Talvez precisemos perguntar também:

WHY DOES USER NEED TO KNOW X?
FOR HOW LONG?
WHAT WILL USER KNOW AFTER PROJECT?
WHO WILL RETAIN THIS KNOWLEDGE?

Isso muda a conversa.

Porque controle de acesso é temporal.

Conhecimento adquirido é cumulativo.


📚 Documentar também é segurança

Existe outro lado do problema.

Quando o terceirizado vai embora levando experiência, talvez o maior risco nem seja aquilo que ele leva.

Pode ser aquilo que a empresa perde.

Ele conhecia determinado processo.

Saiu.

Ninguém documentou.

Seis meses depois:

— Por que isso funciona assim?

Resposta:

— Pergunta para o fulano.

— Onde está?

— Saiu.

Parabéns.

Criamos um SPOF.

Single Point of Failure.

Só que feito de carne, café e COBOL.

CRITICAL KNOWLEDGE
COPIES = 1

STATUS = LEFT COMPANY

Isso é um incidente esperando acontecer.


🧠 Knowledge Escrow

Talvez organizações precisem pensar em algo semelhante a um escrow de conhecimento.

Antes que pessoas críticas saiam:

documentar decisões,

registrar racional arquitetural,

capturar runbooks,

fazer sessões de transferência,

parear profissionais,

registrar incidentes históricos,

explicar exceções,

mapear dependências,

preservar contexto.

Não para tentar copiar uma pessoa.

Isso é impossível.

Mas para reduzir:

BUS FACTOR = 1

Ou, na versão Bellacosa:

LOTTERY FACTOR = 1

Porque ninguém precisa ser atropelado por um ônibus.

Pode simplesmente ganhar na Mega-Sena e decidir nunca mais responder ao Teams.

O risco é exatamente o mesmo.

🤣


🤖 E agora temos IA

Aqui nossa Matrix ganha outra camada.

Imagine uma organização capaz de capturar:

documentação,

decisões arquiteturais,

post-mortems,

runbooks,

histórico técnico,

FAQs,

padrões,

explicações.

Uma IA corporativa pode ajudar a tornar esse conhecimento pesquisável.

Interessante.

Mas cuidado.

Porque agora temos outro problema:

o repositório de conhecimento tornou-se ele próprio um ativo extremamente sensível.

Antes:

SEGREDOS ESPALHADOS
EM 200 CABEÇAS

Depois:

SEGREDOS INDEXADOS
NUM ÚNICO SISTEMA
PESQUISÁVEL
EM LINGUAGEM NATURAL

Parabéns.

Resolvemos um problema.

Criamos outro.

Bem-vindo à segurança da informação.


⚖️ Ética continua sendo fundamental

Existe algo que nenhuma arquitetura substitui.

Ética profissional.

Um especialista pode trabalhar para cinco bancos durante a carreira.

Isso não significa que deva chegar ao Banco B dizendo:

Vou contar como Banco A faz tudo.

Profissionais constroem reputação justamente sabendo separar:

aquilo que aprenderam

daquilo que não têm direito de revelar.

Essa fronteira nem sempre é simples.

Mas existe.

E profissionais experientes normalmente entendem que confiança também é patrimônio.

Talvez um dos ativos mais importantes da carreira.

Você pode levar experiência para o próximo projeto.

Mas se levar segredos indevidamente, talvez leve também algo que destrua sua própria reputação.


🔵 A pílula azul está certa

Precisamos reconhecer:

empresas precisam contratar temporariamente.

Nem todo profissional precisa virar funcionário permanente.

Contratos de confidencialidade são necessários.

Controles técnicos funcionam.

A maioria dos profissionais é ética.

Experiência precisa circular.

Mobilidade profissional é saudável.

Mercados precisam de conhecimento circulando.

Tudo verdadeiro.


🔴 A pílula vermelha também

Agora o outro lado.

Quanto mais fragmentamos relações profissionais...

quanto mais terceirizamos...

quanto mais quarteirizamos...

quanto mais transformamos especialistas em recursos temporários...

maior pode se tornar a circulação das pessoas.

E pessoas carregam experiência.

Logo:

ALTA ROTATIVIDADE
       ↓
ALTA CIRCULAÇÃO DE PESSOAS
       ↓
ALTA CIRCULAÇÃO DE EXPERIÊNCIA

Não necessariamente de segredos.

De experiência.

E talvez seja exatamente isso que o modelo econômico pretendia comprar quando contratou aquele profissional experiente.

Aqui está o paradoxo completo.


🐇 Follow the white rabbit

Então talvez uma organização madura devesse perguntar antes de terceirizar:

O conhecimento envolvido é commodity ou estratégico?

Quanto tempo ele permanece sensível?

Quem precisa realmente acessá-lo?

Quanto conhecimento tácito será criado?

Como será transferido?

Quem permanecerá depois do projeto?

Existe documentação suficiente?

Existe redundância humana?

Existe plano de saída?

Existe retenção seletiva para funções críticas?

Existem obrigações claras de confidencialidade?

O profissional entende essas obrigações?

A cadeia de subcontratação é conhecida?

Quem responde por quem?

E principalmente:

Estamos terceirizando trabalho ou terceirizando memória institucional?

Essa pergunta muda tudo.


🕶️ Wake up, Neo

Sexta-feira.

18:00.

Nosso profissional atravessa a catraca.

O crachá fica.

O notebook fica.

O token fica.

O código fica.

Os datasets ficam.

Os documentos ficam.

As credenciais ficam.

Mas alguma coisa atravessa a porta.

Trinta anos de experiência.

Dois anos de contexto.

Centenas de decisões observadas.

Dezenas de incidentes.

Milhares de pequenas conexões mentais.

Segunda-feira ele precisa trabalhar novamente.

Talvez no concorrente.

Isso não faz dele traidor.

Faz dele trabalhador.

E talvez seja responsabilidade da organização ter projetado sua arquitetura considerando essa possibilidade desde o primeiro dia.

Porque segurança madura não depende de:

"Espero que essa pessoa nunca vá embora."

Isso não é controle.

É fé.


☕ Cambio final, Torre de Controle

Talvez tenhamos cometido um erro conceitual durante décadas.

Tratamos conhecimento como se fosse arquivo.

Arquivo possui owner.

Arquivo possui ACL.

Arquivo possui backup.

Arquivo possui classificação.

Arquivo pode ser apagado.

Conhecimento não funciona exatamente assim.

Você pode revogar acesso ao sistema.

Mas não pode revogar a experiência produzida pelo acesso anterior.

Pode exigir confidencialidade.

Mas não pode exigir amnésia.

Pode proteger segredos.

Mas não pode impedir que profissionais aprendam.

E ainda bem.

Porque se conseguíssemos impedir conhecimento de circular, provavelmente ainda estaríamos reinventando os mesmos erros geração após geração.

A questão, portanto, não é:

como impedir o profissional de levar conhecimento?

Talvez seja:

Como proteger aquilo que realmente precisa permanecer secreto enquanto permitimos que experiência legítima continue fazendo aquilo que conhecimento sempre fez — circular, combinar-se e produzir conhecimento novo?

Essa é uma pergunta muito mais difícil.

E muito mais interessante.

Na próxima sexta-feira, quando algum profissional crítico terminar o projeto, não pergunte apenas:

USER REVOKED?

Pergunte:

KNOWLEDGE RETAINED?

E depois:

CONFIDENTIALITY PROTECTED?

E finalmente:

CRITICAL KNOWLEDGE
DEPENDENT ON ONE HUMAN?

Y/N

Se a resposta for Y...

talvez o problema nunca tenha sido o profissional atravessar a catraca.

Talvez o problema tenha começado anos antes, quando decidimos colocar conhecimento estratégico dentro de uma pessoa temporária sem construir uma arquitetura para preservá-lo.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. DELETE-USER.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-ACCESS          PIC X VALUE 'Y'.
       01 WS-MEMORY          PIC X VALUE 'Y'.
       01 WS-EXPERIENCE      PIC X VALUE 'Y'.

       PROCEDURE DIVISION.

           MOVE 'N' TO WS-ACCESS.

           DISPLAY 'ACCESS REVOKED'.

           IF WS-MEMORY = 'Y'
               DISPLAY 'MEMORY STILL ACTIVE'
           END-IF.

           IF WS-EXPERIENCE = 'Y'
               DISPLAY 'EXPERIENCE LEAVING BUILDING'
           END-IF.

           DISPLAY 'DESIGN FOR PEOPLE TO LEAVE.'.

           STOP RUN.

🔴🔵

Wake up, Neo.

DELETE USER apaga o usuário.

Não apaga o que ele aprendeu.

E talvez a verdadeira segurança não seja tentar impedir o conhecimento de atravessar a catraca.

Talvez seja construir uma organização que saiba exatamente o que pode atravessar, o que precisa ser protegido e o que não pode desaparecer quando aquela pessoa for embora.

Cambio final, Torre de Controle.

☕ Um Café no Bellacosa Mainframe // IT JOB MARKET RADAR

Mercado de Trabalho em TI: Quando Conhecimento Vira Commodity, Poder e Risco

Cinco leituras sobre salário, memória técnica, conhecimento legado, leilão reverso de profissionais e o êxodo de especialistas COBOL. Um pequeno mapa de um mercado em que experiência vale muito — até alguém tentar transformá-la em desconto.

> ANALYZE IT_WORKFORCE
STATUS=KNOWLEDGE_CRITICAL
SALARY_PRESSURE=HIGH
LEGACY_SKILLS=SCARCE
CORPORATE_MEMORY=VOLATILE
ACTION=READ_THE_EVIDENCE
01

O Spread do Conhecimento: Matrix, COBOL e o Valor do Saber

Quando conhecimento raro deixa de ser apenas competência técnica e passa a funcionar como ativo econômico dentro das organizações.

Knowledge Economics
02

Quanto Custa um Programador? Salário, Valor e Mercado

O preço de um profissional de tecnologia não é simplesmente salário: envolve experiência, escassez, produtividade, conhecimento acumulado e risco operacional.

Salary Economics
03

DELETE USER Não Apaga Memória: O Conhecimento que Sai da Empresa

Demitir ou perder um especialista é simples no RH. Recuperar décadas de contexto operacional depois pode ser impossível.

Corporate Memory
04

O Leilão Reverso do Conhecimento

Quando empresas tentam comprar cada vez mais experiência por cada vez menos dinheiro, o mercado pode transformar contratação em um leilão reverso de conhecimento.

Reverse Auction
05

O Êxodo dos COBOLzeiros

O que acontece quando profissionais que conhecem sistemas críticos descobrem que permanecer onde estão pode valer menos do que sair?

COBOL Exodus

🧠 O problema não é COBOL. É economia do conhecimento.

Empresas costumam tratar conhecimento técnico como se fosse um recurso facilmente substituível. Entretanto, sistemas corporativos acumulam décadas de regras de negócio, exceções, interfaces, decisões históricas e conhecimento informal que raramente aparece integralmente na documentação.

Quando o profissional sai, o USERID pode ser apagado imediatamente. O contexto que ele carregava não possui um comando equivalente.

01 Pressão salarial
02 Saída do especialista
03 Perda de contexto
04 Incidente
05 Consultoria cara

📚 Leituras sobre mercado de trabalho, COBOL e conhecimento em TI

BELLACOSA MAINFRAME // KNOWLEDGE IS NOT A REPLACEABLE RESOURCE

segunda-feira, 13 de julho de 2026

Inteligência Não é o Resultado: Tokens, Contexto e a Nova Economia da IA Corporativa

 

Bellacosa Mainframe fala sobre tokens contexto e a ia

☕ Um Café no Bellacosa Mainframe

Inteligência Não é o Resultado: Tokens, Contexto e a Nova Economia da IA Corporativa

Imagine a cena.

É madrugada no datacenter. As luzes azuis dos corredores refletem nos gabinetes, os ventiladores trabalham em ritmo constante e, no centro da sala, um programador COBOL padawan observa um painel moderno repleto de gráficos sobre inteligência artificial.

No painel aparecem números impressionantes:

  • bilhões de parâmetros;

  • milhões de tokens processados;

  • GPUs operando em paralelo;

  • latência inferior a um segundo;

  • custo de inferência caindo mês após mês;

  • modelos cada vez maiores e mais rápidos.

O padawan sorri e pergunta ao mestre:

— Então vencemos? Nossa IA está pronta?

O mestre toma um gole de café, olha para o terminal e responde:

— Depende. O que ela fez pela empresa?

O jovem programador fica em silêncio.

A resposta resume um dos maiores desafios da inteligência artificial corporativa:

Inteligência não é o resultado. Inteligência é apenas um componente do caminho até o resultado.

Uma empresa não recebe dinheiro porque processou mais tokens. Não conquista clientes porque sua GPU executou inferências mais rapidamente. Não reduz perdas simplesmente porque instalou um modelo de linguagem com centenas de bilhões de parâmetros.

O valor aparece quando a inteligência é transformada em ação.

Quando uma fraude é bloqueada.

Quando uma transação é concluída.

Quando um cliente recebe a resposta correta.

Quando uma falha é evitada.

Quando uma operação é automatizada com segurança.

Quando uma decisão é tomada com base em dados confiáveis, contexto adequado e regras de negócio governadas.

É sobre essa transformação que vamos conversar neste café.


1. O grande engano da economia dos tokens

Nos primeiros anos da popularização da inteligência artificial generativa, grande parte da discussão se concentrou nos modelos.

As perguntas mais comuns eram:

  • Qual modelo possui mais parâmetros?

  • Qual gera textos melhores?

  • Qual responde mais rápido?

  • Qual possui a maior janela de contexto?

  • Quanto custa um milhão de tokens?

  • Quantas GPUs são necessárias?

  • Qual modelo venceu determinado benchmark?

Essas métricas são importantes. Entretanto, elas medem principalmente capacidade técnica.

Elas não demonstram, por si só, valor de negócio.

É parecido com avaliar um programa COBOL apenas pela quantidade de instruções executadas por segundo.

Imagine que um programa processa dez milhões de registros em dois minutos. Parece excelente. Porém, ao final, ele gera valores incorretos nas contas dos clientes.

Foi rápido?

Sim.

Foi eficiente?

Talvez.

Gerou valor?

Não.

Na realidade, criou um problema mais rapidamente.

O mesmo acontece com a IA.

Uma organização pode reduzir o custo de um milhão de tokens em 80%, aumentar o throughput e utilizar servidores mais poderosos. Contudo, se o sistema continuar produzindo respostas irrelevantes, decisões erradas ou tarefas incompletas, o benefício econômico é pequeno.

O erro está em confundir uma unidade de processamento com uma unidade de valor.

O token é uma unidade técnica.

O resultado é uma unidade de negócio.


2. O que é um token, afinal?

Para um programador COBOL acostumado com registros, campos, bytes e layouts, podemos comparar o token a uma pequena unidade usada pelo modelo para interpretar uma informação.

Uma palavra pode ser formada por um ou vários tokens.

Por exemplo, uma frase como:

O cliente solicitou o cancelamento do cartão.

é dividida internamente em partes menores. O modelo processa essas partes, identifica padrões e calcula quais tokens devem aparecer na resposta.

O custo de muitos serviços de IA é calculado com base na quantidade de tokens de entrada e saída.

Temos então:

Tokens de entrada:
pergunta, documentos, histórico, instruções.

Tokens de saída:
resposta gerada pelo modelo.

Em uma aplicação simples, isso funciona bem.

Entretanto, em uma empresa, o objetivo raramente é apenas gerar texto.

Considere esta solicitação:

Cliente:
Perdi meu cartão e há uma compra que não reconheço.

Um chatbot baseado apenas em texto pode responder:

Sinto muito pelo ocorrido.
Entre em contato com a central do banco para bloquear o cartão.

A resposta pode ser educada e tecnicamente correta.

Mas o problema continua existindo.

O cartão não foi bloqueado.

A transação não foi contestada.

O cliente ainda corre risco.

Nenhuma investigação foi aberta.

A IA gerou tokens, mas não gerou um resultado.


3. Da resposta para a ação

Uma aplicação corporativa madura precisa transformar a solicitação em uma sequência de operações.

Por exemplo:

1. Identificar o cliente.
2. Confirmar a autenticação.
3. Consultar os cartões ativos.
4. Verificar as últimas transações.
5. Bloquear o cartão comprometido.
6. Abrir uma contestação.
7. Solicitar um novo cartão.
8. Registrar a operação para auditoria.
9. Enviar confirmação ao cliente.

Agora não estamos mais falando apenas de um modelo.

Estamos falando de um sistema completo.

Esse sistema precisa conectar:

Modelo de IA
    +
Dados
    +
Aplicações
    +
APIs
    +
Segurança
    +
Governança
    +
Infraestrutura
    +
Operações

A inteligência artificial interpreta a intenção.

Os sistemas corporativos executam a ação.

Essa distinção é essencial.

O modelo pode compreender que o cliente deseja bloquear um cartão. Porém, quem realiza o bloqueio é uma aplicação transacional, talvez escrita em COBOL, executando em CICS e acessando dados no Db2.

O modelo não substitui necessariamente o sistema de negócio.

Ele passa a conversar com ele.


4. Tokens ficam baratos, contexto fica valioso

Uma das ideias mais importantes da nova economia da IA é a seguinte:

Tokens tendem a se tornar abundantes. Contexto confiável continuará sendo raro.

Os modelos estão ficando mais eficientes.

O custo da inferência tende a cair.

A capacidade computacional continua aumentando.

Modelos abertos e comerciais competem intensamente.

Consequentemente, o acesso à inteligência genérica tende a se tornar cada vez mais comum.

A pergunta estratégica deixa de ser:

Qual empresa possui acesso a um modelo de IA?

E passa a ser:

Qual empresa consegue fornecer ao modelo o contexto correto, no momento correto, com segurança e governança?

Vamos comparar duas situações.

Situação A: modelo sem contexto

Usuário:
O cliente João pode receber aumento de limite?

Resposta da IA:

Para avaliar um aumento de limite, considere renda,
histórico de pagamentos e nível de endividamento.

A resposta é genérica.

Pode ter sido escrita por qualquer modelo.

Situação B: modelo com contexto corporativo

Usuário:
O cliente João pode receber aumento de limite?

O sistema consulta:

CRM:
Cliente desde 2012.

Db2:
Nenhum atraso nos últimos 36 meses.

Sistema de crédito:
Score interno 892.

Sistema antifraude:
Nenhum alerta ativo.

Folha de pagamento:
Renda média aumentou 18%.

Política corporativa:
Aumento automático permitido até 20%.

Resposta:

O cliente está elegível para aumento de até 20%,
conforme a política de crédito vigente.

Motivos:
- relacionamento de 14 anos;
- ausência de atraso em 36 meses;
- score interno elevado;
- aumento comprovado de renda;
- nenhum alerta de fraude.

A recomendação exige confirmação do analista.

A diferença não está apenas no modelo.

Está no contexto.


5. O contexto proprietário como vantagem competitiva

Qualquer empresa pode contratar acesso a um modelo.

Porém, nenhuma concorrente possui exatamente:

  • seu histórico de clientes;

  • suas regras de negócio;

  • seus contratos;

  • seus dados operacionais;

  • seus registros de fraude;

  • seus manuais;

  • sua experiência acumulada;

  • seus sistemas legados;

  • seus fluxos de aprovação;

  • seu conhecimento institucional.

Esse conjunto forma o chamado contexto proprietário.

No mundo mainframe, uma parcela significativa desse contexto pode estar armazenada em:

  • tabelas Db2;

  • bancos IMS;

  • arquivos VSAM;

  • filas MQ;

  • transações CICS;

  • programas COBOL;

  • copybooks;

  • logs SMF;

  • datasets sequenciais;

  • catálogos;

  • regras codificadas durante décadas.

Eis um detalhe que muitos projetos modernos ignoram:

O mainframe não armazena apenas dados antigos. Ele contém contexto operacional acumulado.

Um programa COBOL de quarenta anos pode representar regras de negócio que nunca foram formalmente documentadas em outro lugar.

Por exemplo:

IF CLIENTE-SEGMENTO = 'P'
   AND DIAS-ATRASO = ZERO
   AND SCORE-CREDITO > 850
   AND VALOR-SOLICITADO <= LIMITE-AUTOMATICO
       MOVE 'APROVADO' TO STATUS-PROPOSTA
ELSE
       MOVE 'ANALISE' TO STATUS-PROPOSTA
END-IF.

Esse trecho não é apenas código.

Ele é conhecimento empresarial executável.

É uma política.

É contexto.

É parte da inteligência corporativa.


6. O perigo de construir agentes sobre dados desorganizados

Muitas empresas estão correndo para implementar agentes de IA.

O problema é que um agente pode automatizar decisões e executar tarefas. Portanto, um erro cometido por ele pode se espalhar muito mais rapidamente do que um erro em um chatbot tradicional.

Um chatbot errado gera uma resposta ruim.

Um agente errado pode:

  • cancelar um pedido;

  • bloquear um cliente;

  • aprovar um pagamento;

  • alterar um cadastro;

  • abrir milhares de chamados;

  • executar uma rotina indevida;

  • enviar informações confidenciais;

  • interromper um processo produtivo.

Observe esta arquitetura problemática:

Agente de IA
    |
    +--> CRM desatualizado
    |
    +--> planilha manual
    |
    +--> base duplicada
    |
    +--> documentação antiga
    |
    +--> API sem controle

O agente pode ser sofisticado.

O modelo pode ser excelente.

A infraestrutura pode ser poderosa.

Mesmo assim, o resultado será frágil.

No mundo COBOL, aprendemos há décadas a regra:

Garbage In, Garbage Out

Entrada ruim produz saída ruim.

Na era dos agentes, podemos acrescentar:

Garbage In, Automated Disaster Out

Entrada ruim pode produzir desastre automatizado.

É um pouco dramático, mas é verdade.


7. O custo por token não é o custo por tarefa concluída

Aqui aparece uma armadilha financeira importante.

Uma empresa pode celebrar a redução do custo por token, enquanto o custo real de completar uma tarefa continua aumentando.

Imagine um agente responsável por resolver chamados.

Modelo antigo:

Custo por milhão de tokens: US$ 10
Tokens por tarefa: 10.000
Taxa de sucesso: 80%

Modelo novo:

Custo por milhão de tokens: US$ 2
Tokens por tarefa: 40.000
Taxa de sucesso: 45%

O novo modelo parece mais barato por token.

Entretanto, ele usa quatro vezes mais tokens e falha com maior frequência.

Precisamos calcular o custo da tarefa concluída.

Exemplo simplificado

Modelo antigo:

10.000 tokens por tentativa
US$ 10 por 1.000.000 de tokens

Custo por tentativa:
10.000 / 1.000.000 x 10 = US$ 0,10

Com 80% de sucesso:

Custo aproximado por tarefa concluída:
0,10 / 0,80 = US$ 0,125

Modelo novo:

40.000 tokens por tentativa
US$ 2 por 1.000.000 de tokens

Custo por tentativa:
40.000 / 1.000.000 x 2 = US$ 0,08

Com 45% de sucesso:

Custo aproximado por tarefa concluída:
0,08 / 0,45 = US$ 0,177

O token ficou mais barato.

A tarefa ficou mais cara.

E ainda nem consideramos:

  • retrabalho;

  • intervenção humana;

  • erros operacionais;

  • consumo de APIs;

  • processamento de banco de dados;

  • armazenamento;

  • auditoria;

  • observabilidade;

  • impacto de decisões incorretas.

Esse é um dos grandes ensinamentos:

O indicador correto não é somente custo por token. É custo por resultado confiável.


8. A jornada em três fases

A imagem apresenta uma evolução poderosa:

Tokens → Contexto → Outcomes

Vamos aprofundar cada estágio.

Fase 1 — Tokens

É a fase da inteligência genérica.

A empresa mede:

  • preço;

  • velocidade;

  • capacidade;

  • latência;

  • tamanho do modelo;

  • consumo de GPU.

O objetivo é gerar uma boa resposta.

Fase 2 — Contexto

A empresa conecta o modelo aos seus dados.

Entram em cena:

  • RAG;

  • bancos vetoriais;

  • catálogos;

  • metadados;

  • APIs;

  • documentos;

  • sistemas transacionais;

  • dados históricos;

  • regras corporativas.

O objetivo é gerar uma resposta relevante para a organização.

Fase 3 — Resultado confiável

A empresa transforma a resposta em ação controlada.

Entram em cena:

  • agentes;

  • automação;

  • workflows;

  • aprovações;

  • autenticação;

  • autorização;

  • observabilidade;

  • auditoria;

  • rollback;

  • compliance.

O objetivo é gerar uma ação mensurável, segura e repetível.


9. RAG: dando memória ao modelo

Um dos mecanismos mais comuns para fornecer contexto a um modelo é o RAG, sigla para Retrieval-Augmented Generation.

Em português, algo como geração aumentada por recuperação de informação.

O fluxo básico é:

Pergunta
   |
   v
Busca de documentos relevantes
   |
   v
Documentos adicionados ao prompt
   |
   v
Modelo gera resposta baseada no contexto

Vamos imaginar um assistente para suporte COBOL.

Pergunta:

Como resolver o ABEND S0C7 do programa PAGT001?

Sem RAG, o modelo responde genericamente:

S0C7 normalmente indica dados inválidos em uma operação numérica.

Com RAG, o sistema consulta:

  • manual interno;

  • dump do programa;

  • copybook;

  • histórico de incidentes;

  • documentação do batch;

  • versão do módulo.

O contexto recuperado informa:

O campo WS-VALOR-ENTRADA é lido da posição 81,
mas o arquivo recebido possui caracteres em branco.

A resposta passa a ser:

No programa PAGT001, o S0C7 ocorre porque o campo
WS-VALOR-ENTRADA recebe espaços do registro de entrada.

Antes da conversão, valide o conteúdo:

IF CAMPO-ENTRADA NUMERIC
    MOVE CAMPO-ENTRADA TO WS-VALOR
ELSE
    MOVE ZERO TO WS-VALOR
END-IF.

Agora a resposta possui contexto real.


10. Do RAG ao agente

RAG responde.

Agente executa.

Considere este pedido:

Reprocesse o job de faturamento que falhou.

Um agente corporativo poderia seguir este fluxo:

1. Localizar o job no JES2.
2. Consultar o retorno no SDSF.
3. Identificar o step com falha.
4. Ler mensagens do sistema.
5. Correlacionar com incidentes anteriores.
6. Validar se o reprocessamento é permitido.
7. Solicitar aprovação, quando necessário.
8. Reexecutar o job.
9. Monitorar o novo processamento.
10. Registrar tudo na auditoria.

Perceba a diferença.

O agente não pode simplesmente encontrar um exemplo de JCL e submetê-lo.

Ele precisa respeitar:

  • autorização RACF;

  • regras operacionais;

  • janela batch;

  • dependências;

  • datasets;

  • estado do processamento;

  • políticas de reexecução;

  • impacto financeiro;

  • aprovação humana.

É aí que governança e segurança deixam de ser acessórios.

Elas tornam-se componentes centrais.


11. Segurança: o agente não pode ser um superusuário irresponsável

Um agente precisa operar segundo o princípio do menor privilégio.

Em ambientes z/OS, isso significa respeitar controles como:

  • RACF;

  • SAF;

  • perfis de dataset;

  • classes de recurso;

  • autorização de comandos;

  • acesso a transações;

  • controle de APIs;

  • trilhas SMF;

  • segregação de funções.

Imagine um agente que pode:

  • submeter qualquer job;

  • ler qualquer dataset;

  • alterar tabelas;

  • cancelar transações;

  • acessar dados pessoais.

Mesmo que a intenção seja legítima, esse desenho cria um risco gigantesco.

O correto é limitar o agente.

Exemplo:

Agente de suporte batch:

Pode:
- consultar spool;
- ler mensagens;
- comparar incidentes;
- sugerir correções;
- reexecutar jobs pré-autorizados.

Não pode:
- alterar loadlibs de produção;
- modificar datasets críticos;
- submeter JCL fora da whitelist;
- acessar dados de clientes;
- ignorar aprovações.

Uma boa arquitetura trata o agente como qualquer identidade corporativa.

Ele possui:

  • credencial;

  • função;

  • escopo;

  • permissões;

  • responsabilidade;

  • trilha de auditoria.


12. Governança: quem decidiu, por quê e com quais dados?

Em ambientes regulados, não basta uma decisão estar correta.

Ela precisa ser explicável.

Considere um agente de crédito.

Ele nega uma proposta.

A empresa precisa responder:

  • Qual modelo foi utilizado?

  • Qual versão?

  • Quais dados foram consultados?

  • Qual política estava vigente?

  • Houve intervenção humana?

  • A decisão pode ser reproduzida?

  • Existia viés?

  • Os dados estavam atualizados?

  • O cliente pode contestar?

Sem essas respostas, a automação se torna uma caixa-preta perigosa.

Uma trilha de auditoria pode registrar:

Data/Hora: 2026-07-14 14:35:12
Agente: AGT-CREDITO-01
Modelo: MODELO-CREDITO-V3
Política: POL-CRED-2026-04
Cliente: ID anonimizado 984521
Dados consultados:
- score interno;
- renda declarada;
- histórico de pagamento;
- alertas de fraude.

Decisão:
Encaminhado para análise humana.

Motivo:
Divergência entre renda declarada e histórico de movimentação.

Esse registro transforma uma ação de IA em uma ação corporativamente defensável.


13. O papel da infraestrutura

A imagem apresenta uma fundação composta por tecnologias como LinuxONE, OpenShift, IBM Fusion, Storage Scale, Ceph e watsonx.

A mensagem não é que uma única tecnologia resolve tudo.

A mensagem é que IA corporativa exige uma base coordenada.

Vamos interpretar cada camada.

LinuxONE

LinuxONE representa uma plataforma voltada a cargas Linux empresariais com forte ênfase em:

  • escalabilidade;

  • consolidação;

  • segurança;

  • disponibilidade;

  • eficiência operacional.

Ele pode hospedar aplicações, APIs, bancos de dados, containers e serviços de IA próximos dos sistemas corporativos.

Red Hat OpenShift

OpenShift atua como camada de orquestração de containers.

Ele permite executar:

  • microsserviços;

  • APIs;

  • pipelines;

  • modelos;

  • aplicações;

  • agentes;

  • componentes de integração.

Para o padawan COBOL, podemos compará-lo a uma grande plataforma que administra milhares de aplicações empacotadas em containers, distribuindo recursos, reiniciando componentes e aplicando políticas.

IBM Fusion

IBM Fusion aparece como uma fundação para dados e operações.

Em uma arquitetura de IA, armazenamento não significa apenas “guardar arquivos”.

É necessário:

  • disponibilizar dados;

  • proteger dados;

  • mover dados;

  • criar cópias;

  • restaurar ambientes;

  • aplicar políticas;

  • manter consistência;

  • fornecer desempenho.

Storage Scale

Storage Scale é associado ao acesso paralelo e distribuído a grandes volumes de informação.

Em cargas de IA, muitos processos podem precisar acessar enormes conjuntos de dados simultaneamente.

Um armazenamento lento transforma GPUs caras em máquinas esperando dados.

É o velho problema de I/O.

O programador COBOL conhece isso bem.

Não adianta possuir CPU rápida se o programa passa o tempo inteiro aguardando leitura.

Ceph

Ceph fornece armazenamento distribuído em diferentes formatos:

  • objeto;

  • bloco;

  • arquivo.

É bastante útil em ambientes de nuvem e containers, especialmente quando aplicações precisam de armazenamento resiliente e escalável.

watsonx

O watsonx representa a camada de IA, dados e governança.

De forma conceitual:

watsonx.ai
Modelos, desenvolvimento e inferência.

watsonx.data
Dados preparados para análise e IA.

watsonx.governance
Controle, risco, transparência e auditoria.

O ponto central é importante:

A IA empresarial não é apenas o modelo. Ela depende de dados e governança na mesma proporção.


14. O mainframe como servidor de contexto

Muitos projetos cometem um erro cultural: tratam o mainframe como um sistema antigo que precisa ser contornado.

Entretanto, nas grandes empresas, o mainframe frequentemente contém o contexto mais confiável.

É nele que estão:

  • o saldo verdadeiro;

  • o estoque verdadeiro;

  • o contrato vigente;

  • o pagamento confirmado;

  • a apólice ativa;

  • o cadastro oficial;

  • a transação contabilizada.

Uma IA pode ler milhares de documentos, mas a resposta definitiva pode depender de uma única consulta ao Db2.

Exemplo:

SELECT STATUS_CONTA,
       SALDO_DISPONIVEL,
       LIMITE_CREDITO
  FROM CONTAS
 WHERE NUMERO_CONTA = :WS-CONTA;

Essa consulta retorna o estado operacional real.

O documento explica a política.

O sistema transacional informa a verdade atual.

A combinação dos dois produz contexto confiável.


15. Exemplo completo: agente de atendimento bancário

Vamos montar uma arquitetura passo a passo.

Solicitação

Cliente:
Quero contestar a compra de R$ 2.500 realizada ontem.

Etapa 1 — Interpretação

O modelo identifica:

Intenção:
Contestar transação.

Entidades:
Valor: R$ 2.500.
Período: ontem.

Etapa 2 — Autenticação

Antes de consultar informações, o sistema confirma a identidade do cliente.

MFA validado.
Sessão autenticada.
Token de acesso emitido.

Etapa 3 — Consulta de transações

Uma API chama o sistema transacional.

OpenShift
   |
   v
API corporativa
   |
   v
z/OS Connect
   |
   v
CICS
   |
   v
Programa COBOL
   |
   v
Db2

O COBOL recebe os dados:

01 REQUEST-DATA.
   05 REQ-CONTA          PIC X(12).
   05 REQ-DATA-INICIAL   PIC X(10).
   05 REQ-VALOR          PIC 9(7)V99.

01 RESPONSE-DATA.
   05 RESP-CODIGO        PIC X(04).
   05 RESP-DESCRICAO     PIC X(100).
   05 RESP-ID-TRANSACAO  PIC X(20).

Etapa 4 — Aplicação das regras

A política determina:

Compras acima de R$ 2.000 exigem análise adicional.

O agente não pode simplesmente devolver o dinheiro.

Ele precisa:

- bloquear temporariamente a transação;
- gerar protocolo;
- abrir análise antifraude;
- avisar o cliente;
- registrar a decisão.

Etapa 5 — Auditoria

Tudo é registrado.

Quem solicitou.
Qual agente atuou.
Quais dados foram consultados.
Qual regra foi aplicada.
Qual ação foi executada.

Etapa 6 — Resultado

Resposta final:

A transação de R$ 2.500 foi localizada.

Foi aberto o protocolo 845219.
O valor está em análise.
O cartão permanece ativo, mas novas transações suspeitas
serão monitoradas.

Prazo estimado: até 5 dias úteis.

Agora existe um resultado real.

Não apenas uma resposta elegante.


16. TTO: Time to Outcome

A sigla TTO significa Time to Outcome, ou tempo até o resultado.

Durante muitos anos, a tecnologia falou sobre:

  • Time to Market;

  • Time to Value;

  • tempo de resposta;

  • tempo de processamento;

  • SLA.

O TTO mede quanto tempo uma organização leva para transformar uma necessidade em um resultado concluído.

Considere um incidente batch.

Processo tradicional

08:00 — job falha.
08:20 — operador identifica.
08:45 — chamado é aberto.
09:30 — equipe analisa.
10:15 — causa é descoberta.
11:00 — correção é aprovada.
11:30 — job é reexecutado.
12:00 — processamento termina.

TTO:

4 horas.

Processo assistido por IA

08:00 — job falha.
08:01 — agente lê mensagens.
08:02 — correlaciona com incidente anterior.
08:03 — valida pré-requisitos.
08:04 — solicita aprovação.
08:07 — operador aprova.
08:08 — agente reexecuta.
08:30 — processamento termina.

TTO:

30 minutos.

A IA não criou valor porque leu o spool rapidamente.

Criou valor porque reduziu o tempo até a recuperação.


17. Métricas melhores para IA corporativa

Além do custo por token, uma organização deveria acompanhar:

Taxa de conclusão

Quantas tarefas foram realmente concluídas?

Tarefas iniciadas: 1.000
Tarefas concluídas: 760
Taxa de conclusão: 76%

Taxa de intervenção humana

Quantas tarefas exigiram correção?

Tarefas concluídas: 760
Intervenções humanas: 180
Taxa: 23,7%

Custo por resultado

Inclui:

  • tokens;

  • infraestrutura;

  • APIs;

  • processamento;

  • armazenamento;

  • retrabalho;

  • supervisão humana.

Tempo até o resultado

Quanto tempo o processo completo levou?

Taxa de erro operacional

Quantas ações precisaram ser revertidas?

Conformidade

Quantas ações possuíam:

  • autorização;

  • justificativa;

  • trilha;

  • evidência;

  • política associada?

Essas métricas aproximam IA de operação real.


18. Um exemplo COBOL: preparando contexto para uma API

Imagine um programa COBOL que consulta dados de um cliente para um agente.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CLIENTE-CONTEXTO.

       DATA DIVISION.
       WORKING-STORAGE SECTION.

       01 WS-CLIENTE-ID        PIC 9(10).
       01 WS-NOME              PIC X(40).
       01 WS-SEGMENTO          PIC X(10).
       01 WS-SCORE             PIC 9(03).
       01 WS-DIAS-ATRASO       PIC 9(03).
       01 WS-STATUS            PIC X(10).

       01 WS-CONTEXTO.
          05 FILLER            PIC X(12) VALUE
             '"cliente":"'.
          05 WS-JSON-NOME      PIC X(40).
          05 FILLER            PIC X(14) VALUE
             '","segmento":"'.
          05 WS-JSON-SEGMENTO  PIC X(10).
          05 FILLER            PIC X(10) VALUE
             '","score":'.
          05 WS-JSON-SCORE     PIC 9(03).
          05 FILLER            PIC X(01) VALUE '}'.

       PROCEDURE DIVISION.

           MOVE 1234567890 TO WS-CLIENTE-ID

           EXEC SQL
               SELECT NOME,
                      SEGMENTO,
                      SCORE,
                      DIAS_ATRASO,
                      STATUS
                 INTO :WS-NOME,
                      :WS-SEGMENTO,
                      :WS-SCORE,
                      :WS-DIAS-ATRASO,
                      :WS-STATUS
                 FROM CLIENTES
                WHERE CLIENTE_ID = :WS-CLIENTE-ID
           END-EXEC

           IF SQLCODE = 0
               MOVE WS-NOME     TO WS-JSON-NOME
               MOVE WS-SEGMENTO TO WS-JSON-SEGMENTO
               MOVE WS-SCORE    TO WS-JSON-SCORE
               DISPLAY WS-CONTEXTO
           ELSE
               DISPLAY 'ERRO SQLCODE: ' SQLCODE
           END-IF

           GOBACK.

O objetivo do exemplo não é apresentar um gerador JSON perfeito, mas mostrar a ideia.

O programa:

  1. recebe o identificador do cliente;

  2. consulta dados no Db2;

  3. organiza as informações;

  4. disponibiliza o contexto para outro componente.

O LLM não precisa conhecer a estrutura interna do banco.

Uma API intermediária pode transformar os dados em um contrato bem definido.

Exemplo:

{
  "cliente": "Maria Silva",
  "segmento": "Platinum",
  "score": 920,
  "diasAtraso": 0,
  "status": "Ativo"
}

Esse JSON se torna contexto para a decisão.


19. Easter egg: o mainframe já fazia “agentes” antes da moda

Existe uma curiosidade divertida.

Muito antes dos atuais agentes de IA, o mainframe já executava cadeias automáticas de decisões.

JCL, schedulers, CICS, IMS, MQ e automação operacional já permitiam:

  • detectar eventos;

  • disparar jobs;

  • avaliar códigos de retorno;

  • chamar programas;

  • executar contingências;

  • registrar resultados.

Considere este exemplo simplificado:

//STEP01 EXEC PGM=VALIDA
//STEP02 EXEC PGM=PROCESSA,COND=(0,NE,STEP01)
//STEP03 EXEC PGM=NOTIFICA,COND=(0,NE,STEP02)

A lógica diz:

Valide.
Se estiver tudo certo, processe.
Se o processamento terminar corretamente, notifique.

Isso é uma forma primitiva de orquestração orientada a resultados.

A diferença moderna é que a IA pode interpretar linguagem, analisar informações não estruturadas e escolher ferramentas dinamicamente.

Mas o princípio de automação controlada não nasceu ontem.

O mainframe já ensinava isso quando muitos dos atuais especialistas em IA ainda brincavam com disquetes.


20. Faster complexity: complexidade mais rápida

Uma frase poderosa do texto é:

Isso não é transformação. É complexidade mais rápida.

Automatizar um processo ruim não o transforma automaticamente em um processo bom.

Imagine um fluxo com:

  • cinco planilhas;

  • três aprovações redundantes;

  • dados duplicados;

  • políticas conflitantes;

  • sistemas sem integração.

Adicionar IA pode acelerar o fluxo.

Mas também pode acelerar:

  • inconsistências;

  • erros;

  • retrabalho;

  • decisões conflitantes;

  • consumo de recursos;

  • dívida operacional.

Antes de automatizar, a empresa deveria perguntar:

Este processo ainda faz sentido?
Os dados são confiáveis?
As regras estão documentadas?
As responsabilidades estão claras?
A decisão pode ser auditada?
Existe mecanismo de reversão?

A IA não elimina arquitetura.

Ela aumenta a importância da arquitetura.


21. Um roteiro prático para o programador COBOL padawan

Como começar essa jornada?

Passo 1 — Identifique um resultado

Não comece com:

Vamos usar IA.

Comece com:

Queremos reduzir o tempo de análise de um ABEND de 90 para 15 minutos.

Passo 2 — Localize o contexto

Pergunte:

Onde estão os dados necessários?

Talvez em:

  • spool;

  • Db2;

  • SMF;

  • documentação;

  • Git;

  • tickets;

  • datasets;

  • copybooks.

Passo 3 — Defina as fontes confiáveis

Nem toda informação possui o mesmo peso.

Fonte oficial:
Db2 de produção.

Fonte complementar:
manual interno.

Fonte histórica:
tickets anteriores.

Fonte não confiável:
planilha local sem atualização.

Passo 4 — Crie uma camada de integração

Evite permitir acesso direto e irrestrito ao sistema.

Use:

  • APIs;

  • z/OS Connect;

  • MQ;

  • serviços CICS;

  • stored procedures;

  • camadas de autorização.

Passo 5 — Aplique governança

Registre:

  • modelo;

  • versão;

  • fonte;

  • decisão;

  • ação;

  • usuário;

  • horário;

  • resultado.

Passo 6 — Comece com aprovação humana

Antes de permitir ação autônoma:

IA sugere.
Humano aprova.
Sistema executa.

Depois, tarefas simples e de baixo risco podem ganhar maior autonomia.

Passo 7 — Meça o resultado

Acompanhe:

  • tempo economizado;

  • taxa de sucesso;

  • retrabalho;

  • custo por tarefa;

  • falhas;

  • impacto operacional.


22. Conclusão: a verdadeira corrida da IA

A corrida da inteligência artificial está mudando.

Na primeira fase, todos buscavam modelos maiores.

Na segunda, perceberam que o modelo sem contexto possui valor limitado.

Na terceira, as empresas vencedoras aprenderão a transformar contexto em ação confiável.

A fórmula é simples de escrever:

Compute
   +
Data
   +
Storage
   +
Context
   +
Applications
   +
Security
   +
Governance
   +
Operations
   =
Trusted Outcomes

Mas implementá-la exige engenharia.

Exige integração entre o novo e o legado.

Exige APIs, segurança, arquitetura, armazenamento, observabilidade e governança.

Exige reconhecer que o COBOL, o CICS, o IMS, o Db2 e o IBM Z não são obstáculos à inteligência artificial.

Eles podem ser a fonte do contexto mais valioso da organização.

Os tokens ficarão mais baratos.

Os modelos serão cada vez mais acessíveis.

A capacidade computacional continuará crescendo.

Contudo, o contexto confiável continuará raro.

E o resultado governado será ainda mais valioso.

No final, a pergunta correta não será:

Quantos tokens sua empresa processou?

Será:

Quantos problemas reais ela resolveu, com segurança, velocidade, rastreabilidade e confiança?

O mestre termina o café, olha novamente para o jovem programador e conclui:

— Padawan, o modelo pode conhecer milhares de respostas. Mas somente o sistema completo consegue entregar o resultado.

E, no fundo do datacenter, enquanto o IBM Z continua processando milhões de transações, uma antiga verdade da computação reaparece com nova roupa:

Tecnologia não vale pelo que promete. Vale pelo que consegue concluir.

 

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...