✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta seguranca. Mostrar todas as mensagens

domingo, 30 de agosto de 2026

Dr. House Entra no Centro de Operações — Seis Etapas de IA, um Programa COBOL em Coma e o Diagnóstico que o Logo Bonito Não Faz

Bellacosa Mainframe e as 6 etapas de ia para um programador cobol

☕ Um Café no Bellacosa Mainframe

Dr. House Entra no Centro de Operações — Seis Etapas de IA, um Programa COBOL em Coma e o Diagnóstico que o Logo Bonito Não Faz

Ou: por que assinar vinte ferramentas de inteligência artificial não salva um processo mal definido, não conserta um `S0C7` e certamente não dá alta para produção sem exame, teste e alguém disposto a dizer “isso não fecha”

Prólogo — O paciente chegou falando em produtividade

Eram 7h12 quando um jovem padawan COBOL entrou na sala de diagnóstico do hospital imaginário de Princeton-Plainsboro, carregando um notebook, três abas abertas, uma apresentação com quarenta logos coloridos e uma expressão de quem acabara de descobrir o Santo Graal da produtividade.

— Doutor House, encontrei o mapa definitivo. São seis etapas para fazer mais com IA: pensar, programar, criar conteúdo, trabalhar melhor, fazer imagens e automatizar tudo.

House nem levantou os olhos da bengala.

— “Automatizar tudo” é uma frase linda. Também é uma ótima maneira de automatizar um desastre inteiro antes do café.

O rapaz ficou imóvel.

— Mas tem ChatGPT, Claude, Perplexity, Cursor, Replit, Midjourney, n8n, Zapier…

— Exatamente — respondeu House. — Uma ambulância cheia de aparelhos não cura o paciente se ninguém souber qual órgão está falhando. Agora me diga: qual é o problema?

E ali começa a conversa que todo iniciante precisa ter. Inteligência artificial não é uma coleção de aplicativos com ícones bonitos. É uma camada de apoio para pensar, pesquisar, escrever, programar, revisar, criar, organizar e automatizar. Quando usada com método, poupa tempo e melhora a qualidade. Quando usada como caixa-preta, produz uma quantidade industrial de respostas convincentes, código aparentemente elegante, imagens espetaculares e erros muito bem embalados.

No mainframe, onde um detalhe de dado, segurança ou processamento pode afetar milhares — às vezes milhões — de operações, essa diferença é ainda maior.

O Dr. House, naturalmente, não está interessado em “qual IA é a melhor”. Ele quer saber: qual é o sintoma? Qual dado confirma a hipótese? O que pode estar escondido? E qual ação ainda precisa de um ser humano com responsabilidade e café suficiente?

1. Primeira etapa: pensar e perguntar — antes de pedir resposta, descubra a pergunta

A primeira camada do quadro reúne ferramentas como ChatGPT, Claude e Perplexity. Em aparência, elas fazem a mesma coisa: você escreve uma pergunta e recebe uma resposta. Na prática, o uso saudável é mais profundo.

Uma ferramenta conversacional pode ajudar a:

organizar uma ideia confusa;
explicar um conceito técnico em vários níveis;
criar exemplos;
comparar soluções;
revisar um texto;
transformar um requisito em casos de teste;
fazer o papel de aluno iniciante, arquiteto, revisor ou advogado do diabo.

Já uma ferramenta focada em pesquisa tende a ser mais útil quando você precisa localizar fontes, comparar documentação, verificar onde uma afirmação apareceu e continuar a investigação por conta própria.

A primeira lição do padawan COBOL é simples: a IA responde à pergunta que você fez, não à pergunta que você queria ter feito.

Compare:

“Explique CICS.”

Agora compare:

“Explique HANDLE CONDITION em CICS para um programador COBOL iniciante. Diferencie-o de HANDLE ABEND, apresente um exemplo de erro ao tratar NOTFND e explique por que capturar um abend e simplesmente retornar pode esconder um problema de integridade.”

A segunda pergunta tem objetivo, contexto, profundidade e critérios de qualidade. Ela força a ferramenta a trabalhar. A primeira pede uma apostila genérica, algo entre “CICS é um monitor de transações” e uma vontade súbita de fechar a aba.

House bateu com a bengala na mesa.

— Todo mundo mente. Inclusive o requisitante. Ele diz que precisa de “uma explicação sobre Db2”, mas na verdade precisa descobrir por que o programa Java recebe -805 e o SELECT no SPUFI funciona.

É uma provocação, mas ela carrega uma verdade operacional: perguntas vagas produzem respostas vagas. Em tecnologia, o problema real costuma estar escondido atrás da primeira descrição.

Um método simples para perguntar melhor

Antes de chamar uma IA, organize cinco itens:

Objetivo: o que você quer decidir, aprender ou produzir?
Contexto: qual ambiente, linguagem, versão, público ou restrição?
Entrada: quais dados, logs, trecho de código ou fontes são confiáveis?
Saída esperada: explicação, checklist, código, teste, tabela, roteiro?
Critério de aceitação: como você saberá que a resposta presta?

Exemplo aplicado:

“Tenho um programa COBOL batch que lê um arquivo sequencial e recebe S0C7 ao calcular valor líquido. Crie hipóteses ordenadas por probabilidade, diga quais campos devo inspecionar, mostre um exemplo seguro de validação antes do cálculo e não invente o conteúdo do dump.”

Essa é uma excelente conversa técnica. A IA pode sugerir que campos numéricos contêm espaços, caracteres inválidos, sinal inesperado, desalinhamento de layout ou uma origem de dados mal tratada. Mas o dump, o DISPLAY, o FILE STATUS, o layout real e a evidência ainda são seus.

A IA pode levantar diagnóstico diferencial. Não pode declarar o paciente curado sem exame.

2. A segunda etapa: construir e programar — velocidade não substitui entendimento

Cursor, Replit, Lovable, Base44 e ferramentas semelhantes prometem construir aplicações rapidamente. E cumprem parte da promessa. Elas conseguem gerar telas, APIs simples, formulários, protótipos, integrações comuns e até estruturas iniciais de projetos em tempo muito menor que o desenvolvimento manual.

Mas existe uma diferença histórica entre:

fazer uma demonstração funcionar;
fazer um sistema sobreviver à realidade.

No hospital de House, o jovem padawan mostra um aplicativo de cadastro de clientes gerado em vinte minutos.

— Ele cria, altera e exclui clientes — comemora.

House olha para a tela.

— Quem pode excluir? Exclusão é física ou lógica? O CPF pode mudar? Como você evita que dois operadores alterem o mesmo registro? Cadê o log de auditoria? Onde está o rollback? O que acontece se o banco cair entre atualizar o cadastro e registrar a transação? Quem validou a autorização?

Silêncio.

Em COBOL, nós já conhecemos esse filme. Um MOVE é fácil. O difícil é saber se ele deveria acontecer. Um WRITE é fácil. O difícil é garantir que o registro não foi duplicado, que a chave é válida, que o arquivo está consistente e que o operador não está vendo uma mensagem bonita escondendo um erro grave.

A IA é muito boa para acelerar tarefas mecânicas:

criar o esqueleto de um programa;
explicar um trecho legado;
gerar comentários iniciais;
sugerir refatorações;
criar casos de ZUnit;
transformar regras descritas em linguagem natural em cenários de teste;
elaborar uma matriz de entradas e saídas;
ajudar a escrever JCL de laboratório;
documentar um fluxo CICS, Db2 ou VSAM.

Mas ela precisa ser tratada como um desenvolvedor júnior muito rápido, muito disponível e perigosamente confiante. Ela não conhece o seu ambiente por osmose. Ela não sabe quais copybooks são padrão, quais campos carregam regras históricas, qual job tem janela crítica, qual transação depende de outra nem que um campo aparentemente inocente é usado por um sistema de fraude há quinze anos.

O teste da pergunta incômoda

Antes de aceitar código gerado por IA, pergunte:

Compila?
Passa nos testes?
Trata erro?
Mantém o padrão do projeto?
Expõe dado sensível?
Tem permissão excessiva?
Entende concorrência?
É reversível?
Foi revisado por alguém que conhece a regra de negócio?

Se a resposta a qualquer uma for “não sei”, o código não está pronto. Está apenas escrito.

A produtividade verdadeira não é gerar mais linhas. É reduzir o tempo entre entender uma necessidade e entregar uma mudança correta, testada, auditável e sustentável.

3. Terceira etapa: criar conteúdo — a IA multiplica formatos, não fabrica autoridade

A terceira faixa do mapa fala de ferramentas para texto, avatar, vídeo, edição, cortes e newsletter. Aqui existe um ganho extraordinário para quem cria conteúdo técnico.

Uma explicação boa sobre COBOL pode virar várias peças:

artigo detalhado para blog;
roteiro de vídeo;
short de 45 segundos;
carrossel para LinkedIn;
infográfico;
checklist;
newsletter;
exercício para alunos;
perguntas e respostas;
thumbnail para YouTube.

A IA reduz o esforço de conversão entre formatos. Ela pode pegar um texto longo e sugerir títulos, cortes, pontos de curiosidade, estrutura de carrossel ou uma lista de dúvidas frequentes.

Mas atenção: converter não é repetir.

Se você pega um artigo técnico e manda a IA “criar dez posts”, ela provavelmente entregará dez versões da mesma sopa requentada: “No mundo acelerado de hoje…”, “Você sabia?”, “A revolução chegou…”. É conteúdo que não ofende ninguém e também não permanece em ninguém.

A conexão nasce de uma voz própria, de um exemplo realista e de uma tese. Um texto sobre S0C7 é mais memorável quando explica que o programa não “ficou louco”: alguém mandou o COBOL tratar como número algo que, em algum ponto da cadeia, deixou de ser número. O abend é o médico gritando que o exame de sangue não combina com o diagnóstico.

House aprovaria essa parte.

— O sintoma não é a doença. Febre não é diagnóstico. S0C7 também não.

Para conteúdo técnico, a IA deve ajudar a estruturar e editar; a experiência humana deve fornecer o cheiro de produção. É ela que sabe por que um ICH408I em homologação pode ser uma configuração inocente ou a primeira pista de uma concessão de acesso feita sem controle. É ela que sabe que o programa “simples” costuma ter uma regra escondida no copybook, uma exceção em um IF e uma história antiga que ninguém documentou.

A máquina produz texto. O autor produz significado.

4. Quarta etapa: trabalhar com mais inteligência — não é só escrever melhor, é construir memória confiável

Ferramentas de correção, anotações, e-mail, ditado, pesquisa de documentos e organização parecem menos glamourosas do que gerar um vídeo cinematográfico. Mas, para quem trabalha com conhecimento, elas podem ser mais úteis.

A maior virada de chave ocorre quando a IA deixa de conversar apenas com “a internet” e passa a trabalhar sobre material confiável e permitido: documentação oficial, runbooks, procedimentos, atas, manuais, apostilas, normas, código autorizado e notas técnicas.

Imagine duas perguntas.

A primeira:

“Como resolver um ICH408I?”

A segunda:

“Com base no procedimento de acesso de homologação, explique o fluxo aprovado para investigar ICH408I, indicando que evidências devem ser coletadas antes de solicitar alteração de perfil.”

A primeira pode oferecer boas ideias gerais. A segunda pode ajudar no trabalho real — desde que a base de documentos esteja correta e que a empresa autorize esse tratamento.

Aqui entra um cuidado sério: dados de produção, dumps, credenciais, informações pessoais, chaves, código proprietário e documentação interna não devem ser enviados automaticamente para qualquer serviço externo. O entusiasmo com IA não suspende LGPD, contrato, sigilo profissional, política de segurança ou bom senso.

No mainframe, segurança não é enfeite de apresentação. É controle de acesso, segregação de funções, trilha de auditoria e mínima permissão necessária. Uma ferramenta inteligente com acesso amplo continua sendo uma ferramenta com acesso amplo. E isso é exatamente o tipo de coisa que House chamaria de “ideia ruim com interface amigável”.

5. Quinta etapa: voz, imagem, vídeo e design — visual forte exige direção, não apenas geração

Ferramentas de imagem, vídeo, música, voz e design permitem testar ideias com uma rapidez que seria impensável há pouco tempo. Você pode imaginar um mainframe como uma usina, um cowboy CICS perseguindo um abend ou Dr. House examinando um programa COBOL em coma — e transformar essa cena em imagem.

Isso é valioso. O visual prende atenção, facilita a memória e abre a porta para a explicação.

Mas imagem gerada não é documentação técnica. Ela ilustra uma ideia; não prova um fato. E qualquer texto técnico dentro de uma imagem exige revisão. Nomes de comandos, mensagens de erro, campos COBOL, números de versão e sintaxe são terreno fértil para pequenas deformações que o olho passa por cima e o leitor atento percebe.

Um bom processo visual tem quatro partes:

Definir a mensagem: qual é a única ideia que a imagem deve transmitir?
Gerar a cena-base: usar IA para composição, personagens, cor e atmosfera.
Revisar os detalhes: corrigir termos, legibilidade, logo, dados e contexto.
Manter identidade: repetir elementos visuais que façam o leitor reconhecer sua marca.

A imagem não precisa explicar tudo. Ela deve fazer o leitor querer entrar no texto.

6. Sexta etapa: automatizar — o ponto onde a produtividade vira operação

Automação é a etapa mais poderosa e, por isso mesmo, a que exige mais disciplina.

Ferramentas como n8n, Zapier, agentes, conectores, robôs de coleta e serviços de integração permitem ligar eventos e ações. Um arquivo chegou? O fluxo lê, organiza, gera resumo e envia para revisão. Uma fonte oficial publicou notícia? O fluxo coleta links, classifica assuntos e prepara o radar semanal. Uma planilha mudou? O processo atualiza uma base ou cria uma tarefa.

Isso poupa horas. Mas “automatizar tudo” é uma frase que deveria vir com sirene, extintor e uma pessoa segurando o botão de desligar.

O fluxo saudável é:

Evento → coleta → organização → rascunho → revisão humana → ação externa

O fluxo perigoso é:

Evento → IA interpreta → IA decide → IA publica → IA responde → problema

A diferença é a aprovação humana. Quanto maior o impacto da ação, maior deve ser a trava.

Para automatizar com segurança, siga o passo a passo do jovem padawan:

Escolha uma tarefa repetitiva e bem compreendida.
Execute o processo manualmente algumas vezes e documente cada passo.
Defina entradas, saídas e exceções.
Automatize primeiro apenas a coleta ou o rascunho.
Mantenha aprovação humana para publicar, enviar, apagar, pagar, conceder acesso ou alterar registros críticos.
Registre logs.
Crie limite de volume, tentativas e custo.
Teste falhas de propósito.
Garanta que exista um botão de desligar.
Revise o fluxo periodicamente.

Em linguagem de mainframe: não entregue ALTER, DELETE, acesso privilegiado e SUBMIT de produção para um processo que ninguém consegue explicar. Primeiro defina o procedimento. Depois teste. Depois limite. Depois monitore. Só então escale.

7. A etapa esquecida no infográfico: validar

O grande buraco de muitos mapas de IA é a ausência da validação. Eles mostram pensar, criar e automatizar, mas pulam justamente a parte em que o adulto entra na sala e pergunta: “como sabemos que isso está certo?”

A versão madura das seis etapas seria:

definir o problema;
pesquisar e raciocinar;
produzir um rascunho;
validar tecnicamente e contextualmente;
publicar ou executar;
automatizar o que já funciona.

A validação depende do tipo de trabalho:

Entrega	Validação mínima
Texto técnico	fontes, exemplos, termos e versão correta
Código	compilação, testes, revisão e segurança
Imagem	legibilidade, fidelidade de termos e direitos
Automação	logs, limites, falhas e reversão
Resposta operacional	evidência, procedimento e responsável

House fecha a pasta do paciente.

— Então qual é o diagnóstico?

O padawan respira e responde:

— IA não é um substituto para pensar. É uma forma de encurtar a distância entre uma pergunta bem feita e uma entrega revisada.

House dá um meio sorriso, o equivalente médico a fogos de artifício.

— Agora você pode ter alta. Mas não toque em produção.

Epílogo — O logo não tem a culpa, mas também não faz o trabalho

As ferramentas do infográfico são úteis. Muitas são excelentes. Algumas serão substituídas, incorporadas por outras ou mudarão de preço, recurso e qualidade em poucos meses. Esse é o detalhe menos importante.

O que permanece é o método.

Use IA para pensar melhor, não para terceirizar o pensamento. Use-a para acelerar código, mas teste antes de confiar. Use-a para multiplicar um conteúdo que tenha substância. Use-a para organizar conhecimento permitido e confiável. Use-a para criar visuais que abram a conversa. Use-a para automatizar o repetitivo — nunca para entregar decisões perigosas a uma caixa-preta simpática.

O programador COBOL iniciante que aprende isso cedo leva uma vantagem enorme. Ele não será a pessoa que sabe pedir “faça um sistema bancário completo”. Será a pessoa que entende a pergunta, identifica a regra, procura a evidência, testa a resposta, protege os dados e sabe onde a automação deve parar.

No fim, o mainframe e o Dr. House concordam em algo: confiança não vem de uma tela bonita dizendo que deu certo. Confiança vem de evidência, controle, rastreabilidade e da capacidade de descobrir o que aconteceu quando, inevitavelmente, alguma coisa der errado.

E quando o primeiro S0C7 aparecer no plantão, não entre em pânico. Pegue o café, reúna os fatos, faça perguntas melhores e desconfie de toda resposta que parece fácil demais.

segunda-feira, 24 de agosto de 2026

Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte

Bellacosa Mainframe e o prenda-me se for capaz ia e ibm z17 contra fraudes

☕ Um Café no Bellacosa Mainframe

Prenda-me se For Capaz — Quando o IBM z17 Colocou uma IA na Alfândega da Transação e Mandou a Fraude Mostrar o Passaporte

Ou: Frank Abagnale entrou no banco vestido de piloto, o programa COBOL consultou o histórico, o Telum II calculou um score em menos de um milissegundo — e o Spyre ficou no andar de cima investigando por que o cheque tinha sido emitido por uma companhia aérea que não existia

Há uma cena clássica em qualquer bom filme de vigaristas.

O sujeito entra pela porta principal usando um uniforme impecável. Caminha como se conhecesse o prédio, cumprimenta o segurança pelo nome, segura uma pasta de couro e parece tão legítimo que ninguém se lembra de fazer a pergunta fundamental:

— Quem é você?

Frank Abagnale Jr., personagem central de Catch Me If You Can, construiu sua carreira cinematográfica exatamente nesse intervalo entre parecer legítimo e alguém conferir os dados.

Ele não precisava derrubar o sistema bancário. Não precisava explodir o datacenter, quebrar a criptografia ou fazer engenharia reversa no CICS.

Precisava apenas parecer verdadeiro durante tempo suficiente.

Fraude funciona assim.

Ela raramente entra pela janela usando máscara preta e carregando um saco com cifrão. Normalmente chega pela porta da frente com:

nome aparentemente correto;
cartão válido;
senha correta;
documento convincente;
dispositivo conhecido;
comportamento quase normal;
história razoavelmente plausível.

O problema da segurança moderna não é encontrar aquilo que parece completamente falso. Isso costuma ser fácil.

O problema é identificar aquilo que possui 97% de verdade e esconde a fraude nos 3% restantes.

E o banco precisa perceber isso antes que a autorização seja concluída.

Não amanhã.

Não depois do fechamento do movimento.

Não quando o cliente ligar informando que nunca comprou vinte televisores em Vladivostok.

A decisão precisa acontecer enquanto a transação ainda está atravessando o corredor.

É nesse ponto que entra o IBM z17, seu processador Telum II, o acelerador Spyre e uma ideia aparentemente simples, mas arquiteturalmente poderosa:

Em vez de mandar os dados até a inteligência artificial, colocamos a inteligência artificial perto dos dados.

Puxe uma cadeira, abra o ISPF e peça mais um café. Hoje acompanharemos uma transação bancária como se ela fosse Frank Abagnale tentando atravessar a alfândega vestido de piloto.

1. A fraude não começa com um crime: começa com uma história

Imagine que um cliente normalmente faça compras assim:

supermercados em Itatiba;
combustível duas vezes por mês;
serviços digitais recorrentes;
pequenas compras durante o dia;
um restaurante aos sábados;
nenhuma transação internacional recente.

Subitamente aparece uma tentativa de compra:

três notebooks;
às 3h17 da madrugada;
em outro país;
utilizando um dispositivo nunca visto;
depois de quatro tentativas recusadas;
com endereço de entrega diferente;
poucos minutos depois de uma alteração cadastral.

Nenhuma dessas características, sozinha, prova uma fraude.

Pessoas viajam.

Pessoas compram notebooks.

Pessoas trocam de celular.

Pessoas esquecem senhas.

Pessoas compram presentes de madrugada porque a insônia também participa da economia mundial.

Entretanto, quando combinamos todos os sinais, surge uma história estranha.

É exatamente esse tipo de relação que um modelo de machine learning procura aprender.

Ele não está buscando apenas uma regra rígida como:

SE VALOR > 10000
    ENTÃO RECUSAR

Ele tenta responder uma pergunta mais sofisticada:

Considerando dezenas ou centenas de características, o quanto esta transação se parece com as fraudes que observamos anteriormente?

A resposta geralmente não é “sim” ou “não”.

É um score.

Por exemplo:

RISCO-DE-FRAUDE = 0,91

Isso significa que o modelo encontrou uma combinação fortemente associada a comportamento fraudulento. Não significa que ele tenha presenciado o crime, interrogado o suspeito e recuperado o dinheiro numa mala escondida no aeroporto.

A IA não produz uma sentença judicial.

Ela produz evidência probabilística para ajudar o sistema a tomar uma decisão.

Esse será nosso primeiro ensinamento para o programador COBOL iniciante:

Machine learning não elimina a lógica de negócio. Ele acrescenta uma nova informação à lógica de negócio.

2. Treinamento e inferência: a escola e a prova oral

Antes de entender o Telum II, precisamos separar duas fases frequentemente misturadas.

Treinamento

Durante o treinamento, apresentamos ao modelo dados históricos:

compras legítimas;
fraudes confirmadas;
contestações;
chargebacks;
dispositivos comprometidos;
contas invadidas;
identidades roubadas;
comportamentos considerados normais;
comportamentos considerados suspeitos.

O modelo tenta encontrar relações matemáticas entre as características e os resultados conhecidos.

É como mostrar milhares de cheques a um investigador e dizer:

— Estes eram legítimos. Estes eram falsificados. Descubra os padrões.

O treinamento pode ser computacionalmente pesado. Pode utilizar GPUs, plataformas de ciência de dados, clusters, ambientes cloud ou infraestrutura especializada.

Esse trabalho não precisa acontecer dentro da transação bancária.

Nenhum cliente aceitará esperar três semanas diante da maquininha enquanto o modelo reaprende a história do sistema financeiro.

Inferência

Depois de treinado, o modelo pode receber uma nova transação e aplicar aquilo que aprendeu.

Essa aplicação é chamada de inferência.

O modelo recebe informações como:

VALOR
HORARIO
LOCALIZACAO
TIPO-DE-ESTABELECIMENTO
IDADE-DA-CONTA
DISPOSITIVO
QUANTIDADE-DE-TENTATIVAS
MEDIA-DE-GASTOS
DISTANCIA-DA-ULTIMA-COMPRA

E devolve algo como:

SCORE-DE-RISCO = 0,8734

Treinamento é a escola de investigadores.

Inferência é o momento em que o inspetor olha para o passaporte, compara os sinais e decide se chamará o supervisor.

O IBM z17 é especialmente interessante nessa segunda fase: executar a inferência rapidamente, em grande escala e suficientemente perto da aplicação transacional para que o resultado ainda possa influenciar a autorização.

3. O que acontece quando o cartão encosta na maquininha?

Vamos acompanhar nossa transação passo a passo.

A implementação real varia entre instituições, bandeiras, adquirentes e sistemas, mas o fluxo conceitual pode ser representado assim:

MAQUININHA
    ↓
ADQUIRENTE
    ↓
REDE OU BANDEIRA
    ↓
BANCO EMISSOR
    ↓
SISTEMA DE AUTORIZAÇÃO
    ↓
ANÁLISE DE RISCO
    ↓
APROVAR, NEGAR OU DESAFIAR

Dentro do banco, o sistema pode consultar:

situação do cartão;
senha ou credencial;
saldo;
limite;
bloqueios;
restrições geográficas;
quantidade de operações recentes;
perfil do cliente;
regras antifraude;
resultado de modelos de IA.

Em um ambiente mainframe, partes desse processamento podem envolver:

CICS;
IMS;
Db2;
VSAM;
IBM MQ;
programas COBOL;
serviços Java;
APIs;
z/OS Connect;
componentes Linux executando no IBM Z;
rotinas de segurança;
mecanismos de criptografia;
serviços de inferência.

O programa COBOL não precisa “virar uma IA”.

Ele pode continuar fazendo aquilo que sempre fez muito bem: orquestrar regras de negócio, validar campos, controlar estados, registrar decisões e preservar a integridade da transação.

A diferença é que agora ele pode receber um score calculado por um modelo.

Conceitualmente, nossa lógica poderia se parecer com isto:

       EVALUATE TRUE
           WHEN CARTAO-BLOQUEADO
               MOVE '05' TO CODIGO-RESPOSTA

           WHEN SCORE-FRAUDE > 900
               MOVE 'N' TO AUTORIZAR
               MOVE 'FRAUDE ALTA' TO MOTIVO-DECISAO

           WHEN SCORE-FRAUDE > 650
               MOVE 'S' TO EXIGIR-AUTENTICACAO
               MOVE 'VALIDACAO ADICIONAL'
                 TO MOTIVO-DECISAO

           WHEN LIMITE-DISPONIVEL < VALOR-COMPRA
               MOVE 'N' TO AUTORIZAR
               MOVE 'LIMITE INSUFICIENTE'
                 TO MOTIVO-DECISAO

           WHEN OTHER
               MOVE 'S' TO AUTORIZAR
               MOVE 'APROVADA' TO MOTIVO-DECISAO
       END-EVALUATE.

Naturalmente, um sistema bancário real será muito mais sofisticado. A ordem das verificações, os limites, as exceções e as regras serão governados por políticas específicas.

Mas o princípio é este:

IA calcula o risco.
A aplicação toma a decisão.

Essa separação é saudável.

O modelo não deve possuir autoridade ilimitada simplesmente porque tem “inteligência artificial” no nome.

4. O orçamento de tempo da transação

Quando alguém lê que o z17 pode executar inferências com tempo de resposta inferior a 1 milissegundo, pode imaginar que toda a compra será concluída nesse intervalo.

Não é isso.

Um milissegundo é:

[
1\text{ ms} = 0{,}001\text{ segundo}
]

O número divulgado refere-se ao processamento da inferência no cenário medido, não ao tempo total da transação desde a maquininha até a resposta final.

A operação completa ainda pode incluir:

transmissão pelas redes;
validação criptográfica;
leitura de bancos de dados;
execução de regras;
verificação de limite;
gravação de logs;
atualização de saldos;
journaling;
construção da resposta;
retorno à maquininha.

Pense na transação como um filme de duas horas e na inferência como uma cena importante dentro dele.

O Telum II não precisa filmar o longa-metragem inteiro em um milissegundo. Ele precisa executar sua cena sem estourar o cronograma da produção.

Isso é fundamental porque toda aplicação crítica possui um orçamento de latência.

Se a autorização inteira precisa responder em determinado intervalo, não podemos entregar quase todo esse orçamento a um modelo remoto.

Uma chamada externa pode exigir:

montar uma requisição;
serializar os dados;
criptografar;
atravessar a rede;
autenticar no serviço;
entrar numa fila;
executar a inferência;
montar a resposta;
retornar pela rede;
tratar timeouts e erros.

Mesmo que a média seja boa, há uma pergunta mais importante:

O comportamento continuará previsível durante os picos?

Em ambiente crítico, não basta dizer que a resposta média foi de 5 ms.

Precisamos conhecer:

percentil 95;
percentil 99;
percentil 99,9;
comportamento em saturação;
impacto sobre outros workloads;
tempo máximo aceitável;
estratégia de fallback;
resultado quando o serviço não responder.

Uma média bonita pode esconder um pequeno grupo de respostas terrivelmente lentas.

E o sistema bancário não pode dizer ao comerciante:

— Tivemos um excelente tempo médio hoje. Infelizmente, sua venda caiu no percentil azarado.

5. Telum II: o investigador sentado dentro do banco

O Telum II é o processador que equipa o IBM z17 e inclui a segunda geração do acelerador integrado de IA.

A palavra mais importante é “integrado”.

A inferência pode acontecer muito perto da carga transacional, sem depender de um acelerador remoto pendurado do outro lado de uma rede.

Segundo a IBM, o acelerador do Telum II oferece quatro vezes a capacidade computacional da geração anterior, chegando a 24 TOPS, além de suporte a INT8 e melhorias destinadas a ampliar a variedade de modelos executáveis. O processador também trabalha com caches maiores, melhorias de roteamento e uma DPU destinada a auxiliar operações de entrada e saída. IBM Telum II.

O que são TOPS?

TOPS significa trillions of operations per second, ou trilhões de operações por segundo.

É uma medida da capacidade computacional do acelerador.

Entretanto, TOPS não contam toda a história.

Dois aceleradores com números semelhantes podem produzir resultados diferentes devido a:

arquitetura;
precisão numérica;
eficiência do compilador;
movimentação de dados;
memória;
cache;
tipo do modelo;
tamanho do lote;
utilização dos núcleos;
integração com a aplicação.

É como comparar dois restaurantes apenas pelo número de fogões. O resultado também depende da cozinha, dos ingredientes, dos garçons e de alguém lembrar que o cliente pediu o bife sem cebola.

Por que INT8 importa?

Modelos de IA podem trabalhar com diferentes precisões numéricas.

INT8 utiliza números inteiros de oito bits. Em muitos cenários de inferência, isso permite:

representar os parâmetros com menos espaço;
movimentar menos dados;
executar mais operações;
consumir menos energia;
aumentar o throughput.

Essa redução de precisão precisa ser validada para garantir que o modelo continue suficientemente acurado.

Não adianta tornar a inferência quatro vezes mais rápida se ela passar a confundir Frank Abagnale com o gerente da agência.

6. Spyre: a equipe de inteligência no andar de cima

Se o Telum II é o agente posicionado diretamente no balcão de imigração, o Spyre é uma equipe adicional de inteligência.

O IBM Spyre Accelerator é fornecido em placas PCIe e possui 32 núcleos de aceleração por chip. Várias placas podem ser combinadas para atender cargas maiores. O produto tornou-se disponível para IBM z17 e LinuxONE 5 em outubro de 2025. Anúncio oficial do Spyre.

Ele foi pensado para complementar o acelerador do Telum II em cenários como:

modelos maiores;
vários modelos trabalhando conjuntamente;
IA generativa;
modelos de linguagem;
aplicações multimodais;
assistentes;
agentes de IA;
análise de dados estruturados e textuais.

Imagine uma transação suspeita.

O Telum II pode executar rapidamente o modelo preditivo principal:

Risco calculado: 78%.

Uma arquitetura mais sofisticada pode combinar outros modelos:

um modelo para o comportamento do dispositivo;
outro para identidade;
outro para lavagem de dinheiro;
um encoder examinando descrições textuais;
um modelo avaliando relações entre contas;
um sistema generativo produzindo um resumo para o analista.

Isso é chamado de abordagem multimodelo ou, em certos contextos, ensemble.

O benchmark dos 450 bilhões de inferências antifraude não deve ser apresentado como resultado obrigatório da soma Telum II mais Spyre.

A alegação foi originalmente associada ao acelerador integrado do Telum II. O Spyre amplia a capacidade e o repertório do sistema, principalmente para modelos mais complexos e novas cargas de IA.

Em resumo:

TELUM II
Inferência transacional rápida, integrada e previsível.

SPYRE
Capacidade complementar para modelos maiores, múltiplos e generativos.

Os dois podem trabalhar dentro da mesma estratégia, mas não são peças idênticas.

7. Cinco milhões por segundo não são 450 bilhões por dia

Agora chegamos ao Easter egg matemático escondido no roteiro.

Originalmente diziamos que o z17 podia processar até 5 milhões de inferências por segundo, equivalentes a mais de 450 bilhões por dia.

Vamos convocar o programa COBOL da contabilidade:

[
5.000.000 \times 86.400 = 432.000.000.000
]

Um dia possui 86.400 segundos.

Portanto, cinco milhões de inferências por segundo equivalem a 432 bilhões por dia.

Para chegar a 450 bilhões, precisaríamos de aproximadamente:

[
450.000.000.000 \div 86.400
= 5.208.333
]

Ou cerca de 5,21 milhões de inferências por segundo.

Isso não significa necessariamente que a IBM tenha cometido um erro.

A IBM apresenta números arredondados e indicadores derivados de cenários específicos:

até 5 milhões de inferências por segundo;
até 450 bilhões de inferências por dia;
resposta de aproximadamente 1 ms ou inferior, dependendo da declaração.

O erro aparece quando alguém liga as duas frases com “ou seja”, transformando indicadores de benchmark em uma conversão matemática exata.

Uma formulação mais segura seria:

O IBM z17 pode alcançar até 5 milhões de inferências por segundo em determinado cenário e, segundo outro indicador divulgado pela IBM, até 450 bilhões de inferências por dia.

Curiosidade para o programador iniciante: sempre desconfie de expressões como:

“ou seja”;
“equivale a”;
“portanto”;
“isso representa”.

Elas parecem conectores inocentes, mas frequentemente escondem o exato lugar onde marketing, arredondamento e matemática decidiram falsificar um cheque juntos.

8. O que o benchmark realmente mediu?

O número de 450 bilhões por dia não caiu do céu diretamente na capa de uma revista.

Segundo a metodologia publicada pela IBM, o resultado foi extrapolado de testes internos com:

hardware IBM tipo 9175;
modelo LSTM sintético para detecção de fraude em cartões;
batch size de 160;
ambientes Red Hat Enterprise Linux e z/OS;
z/OS Container Extensions;
configuração específica de CPUs, IFLs, zIIPs e memória.

A IBM também informa claramente que os resultados podem variar. Metodologia do benchmark do z17.

O que é LSTM?

LSTM significa Long Short-Term Memory.

É um tipo de rede neural recorrente desenvolvido para trabalhar com sequências e dependências temporais.

Em fraude, isso pode ser útil porque o significado de uma transação depende frequentemente daquilo que aconteceu antes.

Exemplo:

10:01 — compra de R$ 25 em Itatiba
10:04 — compra de R$ 19 em Itatiba
10:07 — compra de R$ 12.000 em Tóquio

A última transação não é suspeita apenas pelo valor. Ela é suspeita pela relação temporal e geográfica com as anteriores.

Modelos atuais podem empregar outras arquiteturas, mas a LSTM continua sendo uma referência útil para determinados problemas sequenciais.

O que é batch size?

Batch size é a quantidade de amostras processadas conjuntamente.

No teste divulgado, o lote era de 160 inferências.

Isso ajuda o acelerador a utilizar melhor seus recursos, assim como uma transportadora consegue mover caixas com mais eficiência quando carrega um caminhão inteiro em vez de enviar um veículo para cada pacote.

Entretanto, batching cria uma consideração importante:

throughput mede quanto trabalho total é concluído;
latência mede quanto tempo cada solicitação espera e leva para ser respondida.

Grandes lotes podem aumentar o throughput, mas, dependendo da implementação, também podem fazer uma solicitação aguardar o lote ser formado.

Por isso, nunca analise apenas um número.

Pergunte:

Qual era o modelo?
Qual era o tamanho do lote?
Quantas threads foram usadas?
Qual era a configuração?
A latência apresentada é média ou percentil?
O resultado foi medido ou extrapolado?
Havia carga transacional concorrente?
O modelo era real ou sintético?

Essa é uma dica de ouro para qualquer benchmark, não apenas de mainframe.

9. Inferência não é sinônimo de transação

Outra armadilha está na palavra “operação”.

Quando ouvimos “450 bilhões de operações de inferência”, é tentador imaginar 450 bilhões de compras analisadas.

Mas uma transação pode executar vários modelos:

MODELO 1 — fraude do cartão
MODELO 2 — risco do dispositivo
MODELO 3 — identidade comprometida
MODELO 4 — localização anômala
MODELO 5 — lavagem de dinheiro
MODELO 6 — conta-laranja

Uma única compra poderia gerar seis inferências.

Logo:

1 transação ≠ obrigatoriamente 1 inferência

Também é possível processar inferências em lotes ou utilizar modelos diferentes conforme o tipo de operação.

O número demonstra capacidade de execução de modelos. Não deve ser convertido automaticamente em quantidade de cartões, clientes ou compras.

É como olhar o contador de instruções executadas pelo processador e concluir que cada instrução representa um cliente atendido.

O COBOLzeiro olha para isso, toma um gole de café e pergunta:

— Onde está o copybook com a definição dessa unidade?

Pergunta correta.

10. “Levar a IA até os dados” não significa eliminar toda movimentação

Uma das frases mais fortes da apresentação do z17 é a ideia de executar IA onde os dados residem.

Mas precisamos interpretá-la corretamente.

Não significa que nenhum byte jamais se mova.

Dentro do sistema ainda haverá:

leitura de registros;
acesso a memória;
comunicação entre componentes;
preparação das variáveis;
busca de características;
passagem de parâmetros;
gravação do resultado.

O que pode ser evitado é a necessidade de enviar a transação para um serviço remoto de inferência, fora do ambiente em que a aplicação crítica está sendo executada.

Isso reduz:

dependência da rede;
latência externa;
serialização;
pontos adicionais de falha;
exposição de dados sensíveis;
fronteiras operacionais;
complexidade de auditoria.

Compare os dois caminhos.

Inferência remota

COBOL/CICS
    ↓
API
    ↓
GATEWAY
    ↓
REDE
    ↓
SERVIÇO EXTERNO
    ↓
MODELO
    ↓
REDE
    ↓
RESPOSTA
    ↓
DECISÃO

Inferência local

COBOL/CICS
    ↓
SERVIÇO DE INFERÊNCIA NO AMBIENTE IBM Z
    ↓
TELUM II
    ↓
SCORE
    ↓
DECISÃO

O segundo caminho não é magicamente gratuito, mas reduz fronteiras.

E cada fronteira removida significa menos um lugar para:

perder tempo;
falhar;
expirar;
autenticar;
converter dados;
abrir uma porta de ataque;
explicar para a auditoria.

11. O cloud não é o vilão do filme

Seria confortável transformar esta história num duelo:

MAINFRAME = HERÓI
CLOUD = VIGARISTA

Mas arquitetura séria não funciona como desenho animado.

Cloud pode ser excelente para:

treinamento de modelos;
experimentação;
notebooks;
ciência de dados;
armazenamento histórico;
elasticidade;
processamento assíncrono;
comparação de versões;
grandes modelos;
investigação posterior.

O IBM Z pode ser particularmente apropriado para:

inferência na transação;
dados regulados;
baixa latência previsível;
enorme volume;
integração com sistemas existentes;
disponibilidade;
segurança e auditoria;
continuidade operacional.

Uma arquitetura híbrida madura pode funcionar assim:

PLATAFORMA DE DADOS OU CLOUD
    ↓
TREINAMENTO
    ↓
VALIDAÇÃO
    ↓
APROVAÇÃO DO MODELO
    ↓
EMPACOTAMENTO
    ↓
IMPLANTAÇÃO NO IBM Z
    ↓
INFERÊNCIA TRANSACIONAL
    ↓
MONITORAMENTO E FEEDBACK

O modelo aprende em um ambiente e trabalha em outro.

Isso também cria responsabilidades importantes:

versionar o modelo;
registrar quem o aprovou;
controlar sua implantação;
medir drift;
comparar versões;
permitir rollback;
manter explicabilidade;
preservar evidências.

O modelo é um componente de produção. Deve receber disciplina semelhante à de qualquer outro artefato crítico.

Se você jamais colocaria um load module não testado diretamente em produção, também não deveria instalar um modelo treinado na sexta-feira por alguém que escreveu no change:

“Melhorias diversas. Baixo risco.”

12. Falso positivo: quando o FBI prende o piloto verdadeiro

Um sistema antifraude pode errar de duas maneiras principais.

Falso negativo

A transação era fraudulenta, mas foi considerada legítima.

Consequências possíveis:

perda financeira;
chargeback;
investigação;
desgaste com o cliente;
impacto regulatório.

Falso positivo

A transação era legítima, mas foi considerada fraudulenta.

Consequências:

compra recusada;
cliente constrangido;
perda da venda;
chamada ao atendimento;
cancelamento do cartão;
deterioração da confiança.

Imagine o cliente viajando pela Europa depois de meses comprando apenas em São Paulo.

O comportamento mudou bruscamente, mas existe uma explicação legítima.

Um modelo ruim pode confundir “fora do padrão” com “fraude”.

Essa é uma distinção essencial:

Anomalia não é prova de crime. É motivo para investigar ou aplicar controles proporcionais.

Por isso, uma instituição pode criar diferentes respostas:

risco baixo: aprovar;
risco moderado: solicitar biometria;
risco alto: enviar notificação;
risco muito alto: bloquear;
caso complexo: análise humana.

Quanto mais rápido o score estiver disponível, mais opções o banco terá.

Em vez de escolher apenas entre aprovar e negar, pode inserir autenticação adaptativa sem destruir a experiência do cliente.

13. Segurança local não é segurança automática

Colocar a IA no mainframe não elimina:

credenciais roubadas;
engenharia social;
fraude interna;
dados de treinamento contaminados;
modelos enviesados;
configuração incorreta;
permissões excessivas;
falhas de aplicação;
ataques adversariais;
decisões de negócio ruins.

O ambiente local pode ajudar a proteger:

confidencialidade dos dados;
propriedade intelectual do modelo;
tráfego sensível;
disponibilidade;
cadeia de auditoria;
previsibilidade operacional.

Mas o sistema ainda precisa de:

RACF bem administrado;
princípio do menor privilégio;
criptografia;
segregação de funções;
logging;
monitoramento;
revisão de modelos;
gestão de vulnerabilidades;
resposta a incidentes;
governança de IA.

A IA é apenas uma camada.

A arquitetura completa se parece mais com isto:

IDENTIDADE
    +
DADOS CONFIÁVEIS
    +
MODELO VALIDADO
    +
APLICAÇÃO CORRETA
    +
REGRAS DE NEGÓCIO
    +
AUDITORIA
    +
RESPOSTA OPERACIONAL

Se qualquer camada estiver comprometida, o vigarista poderá atravessar o sistema usando um belo uniforme e um crachá perfeitamente impresso.

14. Passo a passo para o COBOLzeiro entender uma integração com IA

Você não precisa se transformar imediatamente em cientista de dados. Comece fazendo as perguntas corretas.

Passo 1 — Entenda o evento de negócio

Defina exatamente o que será avaliado:

compra?
PIX?
abertura de conta?
alteração cadastral?
saque?
pedido de empréstimo?

Passo 2 — Identifique as entradas

Descubra quais informações alimentam o modelo:

VALOR
HORARIO
PAIS
DISPOSITIVO
HISTORICO
TENTATIVAS
IDADE-DA-CONTA
TIPO-DE-CANAL

Passo 3 — Conheça o contrato

O serviço deve possuir um contrato claro:

ENTRADA:
    DADOS-DA-TRANSACAO

SAIDA:
    SCORE-DE-RISCO
    VERSAO-DO-MODELO
    CODIGO-DE-STATUS
    MOTIVO
    TEMPO-DE-INFERENCIA

A versão do modelo é fundamental para auditoria.

Passo 4 — Defina o timeout

O que acontecerá se a inferência não responder?

negar tudo;
aprovar tudo;
usar regras tradicionais;
chamar um modelo alternativo;
encaminhar para validação adicional?

Não responder também é um resultado operacional, e precisa de regra.

Passo 5 — Separe score de decisão

Evite permitir que o modelo controle diretamente a transação.

MODELO → SCORE
REGRA → DECISÃO

Passo 6 — Registre evidências

Grave pelo menos:

identificador da transação;
horário;
score;
versão do modelo;
decisão;
regra aplicada;
resultado posterior conhecido.

Isso permite reconstruir a história.

Passo 7 — Monitore desempenho e qualidade

Observe:

latência;
throughput;
erros;
timeouts;
falsos positivos;
falsos negativos;
mudança no perfil dos dados;
queda de acurácia.

Passo 8 — Prepare rollback

Se o novo modelo começar a bloquear metade da população de Itatiba, você precisa retornar rapidamente à versão anterior.

MLOps sem rollback é apenas aventura.

15. Easter eggs recuperados do cheque falsificado

Easter egg número 1 — O mainframe já fazia “IA” antes da moda

Bancos utilizam modelos estatísticos, regras, scores e análise de risco há décadas.

O que mudou não foi a descoberta repentina de que padrões podem indicar fraude. Mudaram:

escala;
variedade dos modelos;
integração;
velocidade;
capacidade de processar mais sinais;
uso de aceleradores especializados.

A inteligência transacional não nasceu ontem. Ela ganhou músculos novos.

Easter egg número 2 — O COBOL não perdeu o emprego para a IA

A IA pode calcular a probabilidade de fraude, mas alguém ainda precisa:

validar a mensagem;
aplicar o limite;
controlar a conta;
atualizar o saldo;
produzir o registro;
garantir atomicidade;
tratar exceções;
responder ao canal.

O modelo pode dizer que o cheque parece suspeito.

O COBOL continua sendo o funcionário que decide se o cheque entra no movimento e garante que o livro-caixa feche no final do dia.

Easter egg número 3 — Frank Abagnale trabalhou para o FBI

A melhor ironia da história é que o fraudador pode ensinar o sistema a identificar fraudes.

Na segurança, o conhecimento ofensivo frequentemente fortalece a defesa.

Da mesma forma, fraudes confirmadas tornam-se exemplos de treinamento. O atacante, involuntariamente, deixa material para melhorar o próximo modelo.

É quase um programa de estágio não remunerado do Red Team.

Easter egg número 4 — A velocidade pode reduzir fraude sem aumentar bloqueios

Com mais capacidade de inferência, o banco pode executar vários modelos em vez de depender de uma única regra agressiva.

Isso permite distinguir melhor:

comportamento incomum;
comportamento realmente malicioso;
cliente viajando;
conta comprometida;
compra legítima de alto valor;
fraude coordenada.

Mais inteligência pode significar não apenas bloquear mais, mas bloquear melhor.

Easter egg número 5 — O mainframe não precisa aparecer na manchete

Quando uma transação é aprovada corretamente, ninguém comemora:

— Fantástico! O sistema consultou o limite, avaliou o risco, atualizou os registros e respondeu dentro do SLA!

O cliente apenas guarda o cartão.

O sucesso do sistema crítico é frequentemente invisível.

Ele só vira notícia quando para.

16. O verdadeiro “Catch Me If You Can” da fraude moderna

Frank Abagnale precisava manter sua história por alguns minutos.

A fraude digital precisa parecer legítima por milissegundos.

Ela corre entre:

a captura dos dados;
a autenticação;
a análise;
a autorização;
a liquidação.

O IBM z17 procura fechar esse intervalo colocando capacidade de inferência dentro do núcleo transacional.

Não é uma solução mágica.

Não elimina a necessidade de investigadores, regras, autenticação, governança, criptografia ou analistas.

O que ele faz é permitir que a aplicação pergunte, no momento decisivo:

Esta operação se parece com aquilo que afirma ser?

E receba uma resposta antes que o suspeito chegue ao portão de embarque.

A grande inovação não está apenas em fazer cinco milhões de cálculos por segundo. Está em realizar a análise cedo o bastante para mudar o destino da transação.

Antes, muitos sistemas descobriam a fraude depois:

a operação era aprovada;
o dinheiro seguia seu caminho;
o cliente reclamava;
começava a investigação;
alguém tentava recuperar o prejuízo.

Era perícia.

Com a inferência transacional, a inteligência pode participar do processo antes da conclusão:

a operação chega;
os dados são avaliados;
o modelo produz o score;
as regras interpretam o risco;
o sistema aprova, bloqueia ou desafia;
a decisão é registrada.

É a diferença entre encontrar a falsificação no arquivo morto e pará-la no balcão.

Epílogo — O cheque, o COBOL e o homem de uniforme

No final do filme, o vigarista não é derrotado porque alguém construiu uma parede infinitamente alta.

Ele é alcançado porque o investigador aprende a reconhecer seus padrões.

O papel usado.

A forma de imprimir.

As cidades escolhidas.

O modo como ele conta a história.

Fraude é repetição disfarçada de improviso.

A inteligência artificial encontra valor justamente nessa repetição: relações pequenas demais, rápidas demais ou numerosas demais para depender exclusivamente da observação humana.

O Telum II aproxima essa análise do lugar onde a decisão acontece.

O Spyre amplia o repertório para modelos maiores e abordagens mais complexas.

O z17 fornece o ambiente para executar isso com a velocidade, a escala, o isolamento e a previsibilidade exigidos por sistemas críticos.

E o COBOL?

O COBOL continua no balcão.

Recebe a mensagem.

Valida o cartão.

Consulta o limite.

Interpreta o score.

Executa a regra.

Grava a decisão.

Libera ou recusa a transação.

Talvez ele não apareça no trailer. Talvez ninguém compre uma camiseta escrito PERFORM UNTIL FRAUD-DETECTED. Mas, quando Frank Abagnale chegar usando o uniforme de piloto, será o velho programa transacional que olhará o score calculado em menos de um milissegundo e dirá:

       IF IDENTIDADE-PARECE-PERFEITA
          AND HISTORIA-NAO-FECHA
              MOVE 'N' TO AUTORIZAR
              MOVE 'PRENDA-ME-SE-FOR-CAPAZ'
                TO MOTIVO-RECUSA
       END-IF.

No andar de cima, o Spyre cruza os dossiês.

Dentro do processador, o Telum II examina o próximo passageiro.

No CICS, outra tarefa começa.

E em algum lugar do datacenter, um COBOL escrito quando Leonardo DiCaprio ainda era criança continua protegendo uma transação que jamais saberá seu nome.

Para ir mais longe

https://eljefemidnightlunch.blogspot.com/2024/01/megafilmeshd-quando-um-casal-do.html

https://eljefemidnightlunch.blogspot.com/2026/08/spy-vs-spy-no-tribunal-as-trapacas.html

https://eljefemidnightlunch.blogspot.com/2026/08/red-team-e-os-doze-trabalhos-de-asterix.html

segunda-feira, 14 de abril de 2025

Configure o ChatGPT do Zero — O Mapa de Jake Sparrow para Navegar entre Chat, Work, Codex, Projetos, Plugins e Skills sem Afundar o Datacenter

Bellacosa Mainframe e o mapa do tesouro para usar ChatGPT

☕ Um Café no Bellacosa Mainframe

Configure o ChatGPT do Zero — O Mapa de Jake Sparrow para Navegar entre Chat, Work, Codex, Projetos, Plugins e Skills sem Afundar o Datacenter

Ou: o capitão trouxe um mapa incompleto, Jake Sparrow acrescentou cinco ilhas entre dois copos de rum, os chimpanzés abasteceram o batch com saquê — e Igor descobriu tarde demais que “Full Access” não era o nome de uma banda de rock progressivo

Havia neblina sobre o datacenter quando Jake Sparrow apareceu caminhando de lado pelo corredor das fitas. Ninguém soube explicar como ele atravessara a catraca sem crachá, por que carregava uma bússola que apontava para o servidor com mais café ou de onde havia retirado um mapa desenhado sobre o verso de um listing COBOL de 1987.

— Este é o arquipélago do ChatGPT — anunciou, pousando um copo de rum ao lado do console.

Igor, que se pronuncia Eye-gor, examinou o pergaminho.

— Mas aqui existem somente sete ilhas: Aplicativo, Personalização, Projetos, Aplicativos Conectados, Work, Codex e Skills.

Jake bebeu um gole, olhou para os chimpanzés bebedores de saquê que tentavam submeter um JOB pelo teclado numérico e respondeu:

— Então deram a vocês o mapa turístico. Serve para chegar à praia, mas não mostra os recifes, os canhões, as correntes marítimas nem o lugar onde enterraram as permissões administrativas.

É exatamente esse o problema dos guias intitulados “Configure o ChatGPT do zero”. Eles normalmente acertam a direção, mas transformam um ecossistema inteiro numa sequência de botões. Parece que basta instalar um aplicativo, escolher uma cor, conectar o Gmail, criar uma Skill e pronto: nasceu um mordomo digital onisciente, obediente e incapaz de cometer erros.

Não nasceu.

O ChatGPT moderno deve ser entendido como um ambiente composto por camadas. Há um modelo que raciocina, uma conversa que transporta contexto, projetos que organizam fontes, memórias que preservam preferências, plugins que adicionam capacidades, conectores que alcançam sistemas externos, Work para delegar entregáveis, Codex para trabalhar diretamente com arquivos e código, Skills para repetir procedimentos e permissões para impedir que Igor transforme uma experiência didática num incidente com número de protocolo.

Portanto, prepare o café. Jake Sparrow assumirá o leme. Os chimpanzés cuidarão do saquê — decisão operacional questionável — e nós construiremos um mapa suficientemente completo para um programador COBOL iniciante entender não apenas onde clicar, mas o que realmente acontece por baixo do convés.

O mapa completo: as doze ilhas do arquipélago

O desenho original apresentava sete etapas. Jake acrescentou cinco territórios que não podem ser ignorados: Prompt, Fontes, Permissões, Verificação e Automação.

Ilha	Pergunta que ela responde	Exemplo no Bellacosa Mainframe
1. Superfície	Onde vou trabalhar?	Web, aplicativo desktop, CLI ou IDE
2. Prompt	Qual é o objetivo desta conversa?	“Explique RACF para um coboleiro iniciante”
3. Personalização	Como o agente deve falar e trabalhar comigo?	Tom de boteco, profundidade técnica e humor
4. Memória	O que vale a pena carregar para conversas futuras?	Preferências, projetos recorrentes e convenções
5. Projetos	Quais conversas, arquivos e regras pertencem ao mesmo assunto?	Projeto IBM Mainframe Technical Manager L1
6. Fontes	Em quais dados a resposta deve se apoiar?	Manuais IBM, notas do curso e arquivos enviados
7. Plugins e conectores	Quais sistemas externos podem ser consultados ou acionados?	Drive, GitHub, calendário ou repositório documental
8. Permissões	O que o agente pode ler, modificar, executar ou publicar?	Somente leitura, escrita no projeto ou aprovação prévia
9. Work	Qual entregável completo deve ser produzido?	Apostila, apresentação, análise ou plano semanal
10. Codex	O que deve ser construído, editado, testado ou automatizado?	Site, programa, relatório, script ou correção de código
11. Skills	Qual método precisa ser repetido de maneira consistente?	Artigo Bellacosa com SEO, marcadores e easter egg
12. Verificação e automação	Como comprovar o resultado e repeti-lo com segurança?	Testes, revisão, agendamento e monitoramento

Essas ilhas não formam obrigatoriamente uma linha reta. Você pode conversar sem criar projeto, usar um projeto sem instalar plugin e pedir uma análise ao Work sem escrever uma Skill. O mapa representa maturidade, não burocracia.

A sequência saudável é simples: comece com uma necessidade real, acrescente contexto, organize o que se tornar recorrente, conceda somente o acesso necessário, verifique a entrega e automatize apenas aquilo que já funciona manualmente.

Ilha 1 — Escolha a superfície: Chat, Work e Codex não são a mesma cabine

O primeiro cartaz manda baixar o novo aplicativo e informa que Chat, Work e Codex vivem no mesmo lugar. A mensagem geral está correta, mas precisa ser traduzida.

Chat é a mesa do boteco. Você pergunta, debate, aprende, explora possibilidades ou pede um rascunho curto.

“Polindexter, o que diferencia um arquivo sequencial de um VSAM KSDS?”

O resultado principal é uma resposta.

ChatGPT Work é a sala de operações. Você entrega materiais, define um objetivo e espera um produto revisável.

“Use estes manuais e minhas anotações para criar uma apostila introdutória sobre VSAM, com exemplos, laboratório, glossário e dez questões de revisão. Entregue em DOCX e revise a diagramação.”

Agora o resultado não é simplesmente uma mensagem: é um artefato utilizável. Segundo a documentação oficial do ChatGPT Work, ele pode empregar arquivos, plugins e ferramentas aprovadas para buscar informações, executar fluxos e criar resultados prontos para revisão.

Codex é a oficina. Ele foi projetado para trabalhar com arquivos, ambientes e ferramentas. Pode examinar um projeto, alterar código, executar comandos, testar, gerar documentos, construir sites e produzir automações.

“Crie uma aplicação que leia uma lista de URLs do meu Blogspot, identifique links quebrados, extraia títulos e gere um relatório HTML. Inclua testes e não publique nada.”

O Chat explicaria como fazer. O Codex pode efetivamente criar os arquivos, executar os testes e entregar o resultado.

Curiosidade de convés

O aplicativo desktop não é obrigatório para começar. A web oferece Chat e Work; desktop, CLI e extensões de IDE ampliam a integração com arquivos locais e ambientes de desenvolvimento. Escolha a superfície pelo trabalho, não pela moda.

Para um iniciante COBOL:

use Chat para aprender conceitos;
use Work para criar material completo;
use Codex quando houver arquivos, código, testes ou construção;
use a IDE quando precisar analisar o programa ao lado do fonte.

Jake Sparrow anotou no mapa: “Não leve um encouraçado para atravessar uma banheira”. Uma pergunta simples não precisa de um projeto com doze ferramentas.

Ilha 2 — O prompt é a SYSIN do seu JOB

No mainframe, um programa pode estar perfeitamente compilado e ainda produzir uma saída absurda se receber parâmetros errados. Com inteligência artificial ocorre algo semelhante.

O prompt não é um encantamento secreto. É a combinação de pergunta, instrução ou objetivo enviada ao agente. Um bom prompt não precisa ser enorme, mas deve conter o que realmente muda o resultado.

Compare:

“Fale sobre CICS.”

com:

“Explique CICS Transaction Server para um programador COBOL iniciante. Comece pelo problema que ele resolve, compare uma transação CICS com um programa batch, mostre o ciclo de uma tela 3270, explique COMMAREA e canais/containers, inclua um exemplo pseudocódigo e destaque erros comuns. Não presuma experiência com administração CICS.”

O segundo pedido informa:

público;
ponto de partida;
profundidade;
estrutura;
exemplos desejados;
conhecimentos que não devem ser presumidos.

A fórmula de Jake Sparrow

Para tarefas maiores, use cinco campos:

Objetivo: o que deve existir ao final?
Contexto: por que isso está sendo feito e para quem?
Fontes: quais materiais devem ser usados?
Restrições: o que não pode acontecer?
Critérios de aceite: como saberemos que terminou corretamente?

Exemplo:

“Analise este programa Enterprise COBOL 6.3 que recebe IGZ0035S quando o campo de data vem vazio. Preserve o copybook e o layout externo, encontre a menor correção possível, explique a causa para um iniciante e produza casos de teste. Não altere o JCL sem justificar. Considere concluído somente depois de verificar os casos válido, vazio e inválido.”

Isso se parece muito com especificação de programa. O programador COBOL já conhece a lógica; apenas precisa parar de tratar a IA como oráculo e começar a tratá-la como colega de equipe.

Ilha 3 — Personalização não é treinamento do modelo

Ao selecionar personalidade, instruções, memória, aparência ou estilo, você não está treinando um GPT exclusivo dentro de uma torre. Está configurando a forma como o sistema interage com você e quais preferências devem ser consideradas.

Personalidade muda o estilo de comunicação. Pode tornar a resposta mais amigável, pragmática ou neutra. Não aumenta inteligência, não libera ferramentas e não corrige automaticamente fatos errados.

Instruções personalizadas registram preferências recorrentes:

responda em português;
use exemplos mainframe;
trate o leitor como iniciante inteligente;
diferencie fato, inferência e piada;
evite linguagem corporativa burocrática;
chame o assistente de Polindexter.

Aparência modifica cores, tema e fontes da interface. É pintar a sala do computador, não trocar o processador.

Memória pode carregar contexto útil entre conversas, como preferências, objetivos, convenções e projetos recorrentes. A documentação de personalização separa claramente personalidade, instruções e memórias.

Mas memória não é documentação contratual. Se uma regra for obrigatória — “não publicar sem aprovação”, “usar apenas fontes IBM”, “preservar o layout do copybook” — coloque-a no pedido ou nas instruções do projeto.

Analogia COBOL

personalidade é o formato do relatório;
memória é uma tabela de preferências reaproveitáveis;
instrução do projeto é a regra de negócio;
prompt atual é o registro de entrada;
modelo é o programa capaz de interpretar tudo isso.

Igor tentou registrar “sempre execute em produção” como preferência global. A solicitação foi recusada e o chimpanzé responsável pelo Change Management recebeu uma banana sem álcool.

Ilha 4 — Memória é contexto reaproveitável, não um VSAM infinito

Existe uma tentação de imaginar a memória como um arquivo mestre ilimitado contendo cada palavra pronunciada desde o primeiro chat. Não é uma boa representação.

A memória deve preservar elementos úteis e relativamente estáveis:

preferências de linguagem;
formatos recorrentes;
projetos duradouros;
restrições pessoais relevantes;
convenções de trabalho.

Ela não deve ser o único lugar para guardar especificações críticas, manuais inteiros ou o estado detalhado de um projeto complexo.

Além disso, há a janela de contexto: a quantidade de informação que o modelo consegue considerar numa interação. Mesmo em sistemas com grande capacidade, jogar dezenas de arquivos irrelevantes dentro de uma conversa não melhora a resposta. É como carregar todas as gerações de um GDG para calcular o movimento de hoje.

Dica prática

Pergunte-se:

“Isso é uma preferência sobre mim, uma regra deste projeto ou um dado desta tarefa?”

preferência pessoal vai para personalização ou memória;
regra durável do projeto vai para instruções do projeto;
dado momentâneo vai para o prompt ou arquivo atual;
procedimento repetitivo poderá virar Skill.

Essa classificação reduz confusão e evita que o agente use contexto certo no trabalho errado.

Ilha 5 — Projetos são regiões lógicas, quase como aplicações no mainframe

Projetos reúnem chats, arquivos, instruções e fontes relacionados. Eles são úteis quando o trabalho continua no tempo, produz vários resultados ou reutiliza os mesmos materiais.

Imagine um projeto chamado IBM Mainframe Technical Manager L1 contendo:

lista dos vinte cursos;
progresso atual;
badges conquistados;
anotações;
simulados;
cronograma;
instrução para criar um plano semanal aos domingos.

Dentro dele, você poderia manter chats separados:

plano semanal;
revisão de arquitetura IBM Z;
simulado de 44 questões;
análise dos erros;
preparação para a prova final.

O contexto permanece relacionado, mas cada conversa tem um objetivo limpo.

Outro projeto poderia ser Bellacosa Mainframe — Editorial, contendo guia de estilo, exemplos aprovados, identidade visual, regras de SEO, links internos e instruções sobre easter eggs.

A documentação de Projetos recomenda usá-los para manter juntos chats, arquivos, instruções e fontes que pertencem ao mesmo trabalho.

Erro comum: o projeto “Tudo”

Não coloque RACF, anime, viagem à Escócia, Victor Hugo, fraude bancária e alimentação militar dentro de um único projeto chamado “Assuntos”. Isso cria o equivalente cognitivo de uma biblioteca de fitas sem catálogo.

Crie um projeto quando houver continuidade ou contexto compartilhado. Para uma pergunta autônoma, abra um chat simples e preserve a sanidade do catálogo.

Ilha 6 — Fontes: o agente não encontra a verdade só porque o mapa tem uma bússola

Uma resposta pode usar:

conhecimento geral do modelo;
arquivos anexados;
fontes de um projeto;
pesquisa na web;
dados recuperados por conectores;
resultados de ferramentas.

Cada fonte possui limitações. Um manual antigo continua antigo depois de ser anexado. Uma planilha errada continua errada depois de ser analisada. Uma página popular não se transforma em documentação oficial porque apareceu primeiro no buscador.

Para tecnologia que muda rapidamente, peça verificação atual. Para IBM Z, identifique versão e produto. “Explique COBOL” é amplo demais; Enterprise COBOL 6.3, 6.5, COBOL for AIX e ILE COBOL possuem fronteiras diferentes.

Hierarquia prática de confiança

documentação oficial vigente;
normas e especificações primárias;
documentação interna autorizada;
livros e materiais técnicos reconhecidos;
artigos especializados;
fóruns, posts e opiniões;
“um chimpanzé disse depois do terceiro saquê”.

A última fonte pode render um excelente easter egg, mas não deve definir sua política RACF.

Ilha 7 — Plugins, conectores e MCP: três objetos, três funções

Esses nomes aparecem frequentemente misturados, portanto Jake Sparrow desenhou três portos diferentes.

Skill é um procedimento reutilizável: ensina como realizar determinada tarefa.

Conector é a ponte para um serviço externo: permite pesquisar, ler ou executar ações dentro das permissões concedidas.

Plugin é um pacote instalável que pode reunir Skills, conectores e ferramentas.

MCP, Model Context Protocol, é um padrão por meio do qual ferramentas e fontes externas podem ser apresentadas ao agente.

Segundo a documentação oficial de Skills e Plugins, uma Skill empacota instruções e recursos; um plugin pode combinar Skills e conectores; conectores podem ser apoiados por servidores MCP.

Exemplo

Um plugin editorial poderia conter:

Skill “Criar artigo Bellacosa”;
conector para pesquisar documentos autorizados;
modelo de artigo;
ferramenta para conferir o tamanho da meta description;
referência com padrões visuais.

Instalar um plugin, entretanto, não concede automaticamente acesso a todos os sistemas. Um conector pode exigir login, autorização e permissões próprias.

Ilha 8 — Permissões: não dê SPECIAL para quem precisa apenas de READ

Esta é a ilha que os infográficos alegres quase sempre esquecem.

Há diferença entre:

ler um arquivo;
editar um arquivo;
executar um comando;
acessar a internet;
consultar um serviço externo;
enviar uma mensagem;
publicar conteúdo;
apagar dados.

O princípio correto é o menor privilégio necessário.

Se o objetivo é analisar documentos, comece com leitura. Se o objetivo é propor uma organização, não conceda autoridade para mover ou apagar. Se o agente precisa alterar cinco arquivos do projeto, não ofereça acesso irrestrito ao computador inteiro.

Pedido perigoso:

“Conecte tudo, organize meus arquivos e corrija o que achar necessário.”

Pedido seguro:

“Leia somente a pasta do curso, identifique duplicados e proponha uma estrutura. Não mova, renomeie, envie nem apague arquivos. Apresente o plano para aprovação.”

Isso é Zero Trust aplicado à colaboração com agentes: verifique identidade, limite escopo, registre ações e não transforme conveniência em acesso permanente.

Easter egg operacional

Se você encontrar a expressão UID(0) rabiscada no casco do navio, não é o número do camarote de Igor. É uma boa razão para perguntar por que alguém precisa de tanto poder.

Ilha 9 — Work: delegue resultados, não verbos soltos

“Pesquise”, “analise” e “escreva” são atividades. Uma boa delegação descreve um estado final.

Compare:

“Escreva sobre RACF.”

com:

“Crie uma apostila introdutória sobre RACF para programadores COBOL. Explique usuários, grupos, perfis, classes, acesso e auditoria; compare READ, UPDATE, CONTROL e ALTER; inclua exemplos seguros, laboratório, glossário e perguntas de revisão. Use somente fontes oficiais atuais, identifique a versão quando relevante e entregue um documento revisado. Não execute mudanças em nenhum ambiente.”

O segundo pedido define público, escopo, fontes, formato, segurança e critérios de aceite.

Delegar não significa abandonar. Durante trabalhos longos, você pode acompanhar, corrigir direção, acrescentar contexto e aprovar decisões importantes.

O segredo está em dizer o que deve existir quando terminar.

Ilha 10 — Codex: da explicação para a construção verificável

Codex se torna valioso quando há arquivos, código, comandos, testes ou um ambiente a ser manipulado.

Para o programador COBOL, ele pode:

explicar um fonte existente;
localizar campos e dependências;
comparar copybooks;
sugerir casos de teste;
gerar JCL de exemplo;
documentar interfaces;
criar utilitários auxiliares;
analisar logs e mensagens;
construir uma interface web em torno de dados simulados;
executar verificações permitidas.

Mas o contexto técnico importa. Informe:

compilador e versão;
sistema operacional;
CICS, IMS, Db2 ou batch;
layouts de registros;
comandos de build e teste;
mensagens completas;
restrições da instalação.

Não diga apenas “meu COBOL quebrou”. Isso equivale a telefonar ao suporte e declarar que “o mainframe está estranho”.

Fronteira essencial

O Codex pode reduzir brutalmente a barreira de implementação, mas não elimina a responsabilidade do usuário. Alguém ainda precisa saber qual problema está sendo resolvido, quais dados são sensíveis, quais resultados são corretos e o que jamais deve ser feito.

Ilha 11 — Skills: transforme experiência tácita em procedimento executável

Uma Skill não é simplesmente “um prompt que gostei”. É um pacote de instruções e recursos para repetir um método de maneira confiável.

O processo editorial Bellacosa já possui formato de Skill:

receber assunto, imagem ou notícia;
identificar tese central;
pesquisar fatos atuais;
separar documentação, inferência e humor;
explicar para um iniciante inteligente;
adicionar história, curiosidades e exemplos;
construir analogias mainframe;
inserir Igor, Polindexter ou outro personagem quando fizer sentido;
incluir easter egg;
revisar coerência;
gerar SEO dentro do limite;
produzir marcadores;
preparar conceitos visuais.

A documentação de construção de Skills explica que elas podem reunir instruções, referências, recursos e scripts opcionais.

Uma estrutura possível seria:

bellacosa-mainframe-article/
├── SKILL.md
├── references/
│   ├── estilo-editorial.md
│   └── exemplos-aprovados.md
├── assets/
│   └── modelo-artigo.md
└── scripts/
    ├── validar-seo
    └── conferir-marcadores

Quando criar uma Skill?

Crie quando:

a tarefa se repete;
os passos são relativamente estáveis;
existem regras fáceis de esquecer;
bons exemplos melhoram o resultado;
outras pessoas poderiam reaproveitar o método.

Não crie uma Skill para cada pergunta. Uma Skill para “explicar OCCURS DEPENDING ON uma única vez” seria como instalar um CICS inteiro para somar dois números.

Ilha 12 — Verifique primeiro, automatize depois

O agente produziu um arquivo. Terminou?

Ainda não.

“Gerado” e “correto” são estados diferentes.

Para código, verifique:

compilação;
testes;
casos extremos;
alterações realizadas;
impacto em interfaces;
mensagens e retornos.

Para documentos:

estrutura;
fatos;
fontes;
consistência;
ortografia;
diagramação.

Para planilhas:

fórmulas;
totais;
referências;
tipos de dados;
recálculo.

Para artigos:

título;
tese;
datas;
distinção entre fato e piada;
links;
SEO;
ausência de contradições.

Somente depois de estabilizar o processo vale automatizá-lo. Uma automação pode executar uma tarefa em determinado horário, repetir um relatório ou verificar se uma condição mudou.

Seu plano semanal do IBM Mainframe Technical Manager L1 aos domingos às 20h é um exemplo perfeito: o método está definido, os dados de progresso mudam e existe uma periodicidade útil.

Automatizar um processo ruim apenas produz erros pontualmente, toda semana, com admirável disciplina.

Passo a passo de Jake Sparrow para configurar sem naufragar

Passo 1 — Escolha um problema real

Não comece conectando tudo. Comece com algo útil:

“Quero transformar minhas anotações de RACF numa aula para iniciantes.”

Passo 2 — Defina o entregável

Decida se precisa de explicação, artigo, apostila, apresentação, planilha, site ou programa.

Passo 3 — Forneça contexto suficiente

Informe público, versão tecnológica, objetivo, exemplos e limitações.

Passo 4 — Selecione fontes confiáveis

Anexe somente materiais relevantes e indique quando a documentação oficial deve prevalecer.

Passo 5 — Use um projeto se houver continuidade

Reúna conversas, arquivos e instruções do mesmo corpo de trabalho.

Passo 6 — Personalize o que for estável

Estilo, idioma e preferências recorrentes podem ser persistentes. Requisitos críticos continuam explícitos.

Passo 7 — Conecte apenas o necessário

Instale plugins ou autorize conectores quando o trabalho realmente depender de sistemas externos.

Passo 8 — Defina permissões mínimas

Comece com leitura. Autorize escrita, envio ou publicação somente quando necessários e revisados.

Passo 9 — Delegue ao modo adequado

Chat para resposta e exploração;
Work para entregável completo;
Codex para construção, arquivos, código e testes.

Passo 10 — Revise e corrija

Peça verificação, examine o resultado e refine os critérios de aceite.

Passo 11 — Transforme repetição em Skill

Depois de executar bem algumas vezes, documente o método, exemplos e validações.

Passo 12 — Automatize com limites

Agende somente o processo estabilizado. Defina frequência, condição, fontes, resultado e ações proibidas.

O verdadeiro tesouro não é o botão “Novo”

Ao amanhecer, Jake Sparrow enrolou o mapa e descobriu que os chimpanzés haviam consumido o saquê destinado à cerimônia de encerramento. Igor dormia sobre um manual de segurança, abraçado a uma placa onde se lia:

FULL ACCESS — USE SOMENTE QUANDO INTENCIONAL

Por sorte, ninguém havia lhe explicado onde ficava o botão.

O mapa original estava correto ao sugerir uma jornada: instalar, personalizar, organizar, conectar, delegar, construir e criar Skills. Entretanto, o verdadeiro domínio nasce quando entendemos as fronteiras entre essas etapas.

Personalidade não é capacidade. Memória não é documentação. Projeto não é depósito. Plugin não é autorização. Conector não é acesso ilimitado. Work não é abandono. Codex não é licença para alterar produção. Skill não é mágica. Automação não é garantia de qualidade.

O ChatGPT torna-se poderoso quando recebe um objetivo claro, o contexto certo, fontes confiáveis, ferramentas adequadas e permissões proporcionais. Torna-se confiável quando o resultado é verificado. Torna-se escalável quando o procedimento correto é transformado em Skill. E torna-se perigoso quando alguém confunde conveniência com autoridade irrestrita.

Para o coboleiro iniciante, há uma notícia excelente: você já conhece a maior parte dessa lógica.

Você sabe que programa precisa de entrada, regra de negócio, arquivo, autoridade, condição de retorno, teste e controle de produção. Basta transportar essa disciplina para o mundo dos agentes.

O prompt é a SYSIN. O projeto é a aplicação. A memória guarda preferências. As fontes alimentam o processamento. O plugin instala capacidades. O conector abre uma interface. A permissão define o perfil de acesso. Work coordena o JOB. Codex opera a oficina. A Skill documenta o procedimento. A verificação examina o RC. A automação coloca tudo no scheduler.

E o ser humano?

O ser humano continua sendo o responsável por decidir por que o JOB existe, quais dados ele pode tocar e se o resultado deve seguir para produção.

Jake Sparrow levantou o último copo de rum, apontou para o horizonte e pronunciou a senha encontrada no rodapé do listing de 1987:

“Nem todo RC=00 significa que o resultado está certo.”

Os chimpanzés aplaudiram. Igor acordou assustado. E, em algum lugar do datacenter, um programa compilado sem erros calculou com absoluta perfeição a idade de um cliente nascido em 30 de fevereiro.

Esse, companheiro, era o easter egg.

Porque a inteligência artificial pode executar exatamente o que você pediu — e ainda assim você pode ter pedido a coisa errada.

Sirva outro café. O arquipélago é grande, mas agora temos um mapa de verdade.

Translate

domingo, 30 de agosto de 2026