☕ 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 IA Generativa. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta IA Generativa. Mostrar todas as mensagens

quinta-feira, 3 de setembro de 2026

O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

 

Bellacosa Mainframe e uma introducao a redes neurais

☕ Um Café no Bellacosa Mainframe

O Dia em que o Perceptron Entrou no CPD, Aprendeu com os Próprios Erros e Virou uma IA Generativa sem Pedir COMMIT

Ou: como saímos das regras escritas à mão, atravessamos redes neurais, deep learning e Transformers e chegamos às máquinas capazes de escrever COBOL perfeitamente convincente — inclusive quando o programa não compila



Prólogo — “Computador, aprenda sozinho”, disse o humano sem preparar os dados

Durante décadas, programar significou explicar ao computador, com uma paciência quase religiosa, exatamente o que ele deveria fazer. O desenvolvedor recebia uma regra de negócio, transformava-a em decisões e escrevia uma sequência de instruções. Se o cliente estivesse inadimplente, bloqueava-se a operação. Se o saldo fosse insuficiente, recusava-se o débito. Se o retorno do programa fosse diferente de zero, alguém recebia uma mensagem capaz de arruinar o café da manhã.

Era um mundo de regras explícitas:

IF WS-SALDO < WS-VALOR-DA-COMPRA
    MOVE 'COMPRA RECUSADA' TO WS-MENSAGEM
ELSE
    MOVE 'COMPRA APROVADA' TO WS-MENSAGEM
END-IF

O computador não precisava compreender o cliente, a compra ou o significado filosófico de ficar sem dinheiro no dia 27. Bastava obedecer.

Então surgiu uma pergunta perturbadora: e se, em vez de escrevermos todas as regras, mostrássemos milhares de exemplos ao computador e permitíssemos que ele ajustasse internamente uma função capaz de reconhecer os padrões?

É nesse ponto que entram as redes neurais.

Não são cérebros digitais, não acordam durante a madrugada pensando em sua própria existência e não possuem um pequeno neurônio chamado Igor escondido atrás da CPU. São modelos matemáticos formados por operações relativamente simples, repetidas muitas vezes e organizadas em camadas.

O encanto está justamente nisso: multiplicações, somas e ajustes de números, quando combinados em escala suficiente, conseguem reconhecer imagens, transcrever voz, prever falhas, traduzir idiomas e gerar texto. O perigo também está nisso: como o resultado parece inteligente, o ser humano pode esquecer que por baixo da conversa elegante existe uma máquina calculando probabilidades.



1. Antes das redes neurais: o reino das regras

Antes de uma rede aprender com dados, o conhecimento normalmente precisava ser colocado no sistema por seres humanos.

Programação tradicional

Na programação convencional, temos os dados e conhecemos as regras. O programa aplica essas regras e produz uma resposta:

Dados + regras escritas pelo programador → resultado

Esse modelo continua sendo excelente quando o problema é determinístico. Para somar lançamentos contábeis, calcular juros definidos em contrato ou validar o tamanho de um campo, uma rede neural seria uma extravagância digna de alguém que contratou uma orquestra para tocar o som de uma notificação.

Sistemas especialistas

Entre as décadas de 1970 e 1980, ganharam destaque os sistemas especialistas. Eles tentavam reproduzir decisões de profissionais por meio de uma base de conhecimento e um mecanismo de inferência.

SE a temperatura está alta
E a pressão está baixa
ENTÃO verificar o sistema de refrigeração

Esses sistemas foram úteis, mas tinham um custo: alguém precisava entrevistar os especialistas, descobrir as regras, eliminar contradições e manter a base atualizada. Quando o ambiente mudava, a elegante inteligência podia virar rapidamente um museu de certezas antigas.

Estatística e machine learning clássico

Também existiam — e continuam existindo — regressão linear, regressão logística, árvores de decisão, Naive Bayes, KNN, máquinas de vetores de suporte e vários outros algoritmos.

Eles não foram aposentados pela IA generativa. Em dados tabulares pequenos ou médios, uma árvore ou regressão frequentemente custa menos, é mais explicável e funciona tão bem quanto uma rede neural. O desenvolvedor maduro não pergunta “onde posso colocar IA?”, mas “qual é a solução mais simples, verificável e econômica para este problema?”.



2. O perceptron bate à porta do CPD

O ancestral histórico das redes atuais é o perceptron, desenvolvido por Frank Rosenblatt no fim dos anos 1950. Ele era um classificador capaz de ajustar os pesos das entradas durante o aprendizado. Embora limitado a problemas linearmente separáveis, estabeleceu uma ideia fundamental: uma máquina poderia melhorar sua decisão modificando seus próprios parâmetros a partir de exemplos.

Um neurônio artificial recebe valores de entrada:

  • uso de CPU;

  • memória consumida;

  • quantidade de erros anteriores;

  • crescimento do volume processado.

Cada entrada é multiplicada por um peso. Depois, os resultados são somados com um valor adicional chamado bias:

[
z = x_1w_1+x_2w_2+x_3w_3+x_4w_4+b
]

Em seguida, o valor passa por uma função de ativação:

[
y=f(z)
]

Essa função permite que o modelo represente relações não lineares. Sem ela, empilhar várias camadas equivaleria, em essência, a fazer uma única grande transformação linear: muita arquitetura para continuar morando no mesmo apartamento matemático.

Se a saída usar uma função sigmoide, obteremos um valor entre zero e um:

0,04 → risco muito baixo
0,51 → situação incerta
0,97 → risco muito alto

O neurônio não “sabe” o que é um ABEND. Apenas aprendeu que determinadas combinações numéricas costumam aparecer antes de registros classificados como falha.



3. Por que uma rede precisa de camadas?

Um neurônio isolado resolve apenas relações simples. Uma rede reúne muitos neurônios em camadas:

  1. Camada de entrada: recebe os dados.

  2. Camadas ocultas: transformam e combinam os sinais.

  3. Camada de saída: produz a previsão ou classificação.

Em visão computacional, camadas iniciais podem responder a contornos, cores e texturas. Camadas posteriores combinam esses elementos em formas mais complexas. Em linguagem, representações iniciais de tokens são transformadas considerando posição, contexto e relações com outros tokens.

Quando existem muitas camadas, falamos em deep learning, ou aprendizagem profunda. A profundidade não concede consciência ao modelo; apenas cria uma função com enorme capacidade de representar padrões.

É importante evitar uma analogia enganosa. Redes neurais foram inspiradas vagamente na ideia de neurônios interconectados, mas um neurônio biológico é imensamente mais complexo. Dizer que uma rede artificial funciona como o cérebro é semelhante a dizer que um avião funciona como um pássaro: ambos voam, mas ninguém espera encontrar penas dentro da turbina.



4. Como a rede aprende: o treinamento

O treinamento pode ser entendido como um ciclo em cinco atos.

Ato 1 — Pesos iniciais

Os pesos começam com pequenos valores, geralmente aleatórios. A rede ainda não aprendeu o padrão e suas respostas são pouco úteis.

Ato 2 — Propagação para frente

Um exemplo atravessa a rede da entrada até a saída. Isso é chamado de forward pass.

CPU: 92%
Memória: 90%
Erros anteriores: 7
Crescimento do volume: 65%

Previsão inicial: 18% de risco de ABEND
Resultado real: houve ABEND

Ato 3 — Função de perda

A função de perda mede a distância entre a previsão e a resposta correta. Ela não diz apenas “errou”; fornece um número que pode orientar os ajustes.

Ato 4 — Backpropagation

O algoritmo calcula como cada peso contribuiu para o erro. Essa informação é propagada da saída em direção às camadas anteriores. É o famoso backpropagation.

Ato 5 — Otimização

Um otimizador, como o gradiente descendente ou Adam, altera os pesos na direção que tende a reduzir a perda.

O ciclo se repete. Cada passagem completa pelo conjunto de treinamento recebe o nome de época.

Época 1   → a rede tropeça no cabo de força
Época 10  → começa a reconhecer alguns padrões
Época 50  → melhora suas previsões
Época 500 → talvez esteja aprendendo o problema
             ou apenas decorando o laboratório

Quando o modelo decora demais os exemplos de treinamento e perde a capacidade de funcionar com dados novos, temos o overfitting. Ele é o aluno que tirou dez porque memorizou o gabarito, mas entra em S0C7 quando a prova muda duas palavras.

5. Laboratório: uma pequena sentinela de jobs batch

Vamos construir um exemplo didático em Python. A rede receberá quatro características de um job:

  • percentual de CPU;

  • percentual de memória utilizada;

  • quantidade de erros anteriores;

  • crescimento percentual do volume de entrada.

Ela tentará classificar o resultado:

  • 0: execução normal;

  • 1: risco de ABEND.

Passo 1 — Preparar o ambiente

python -m pip install tensorflow numpy scikit-learn

Passo 2 — Importar as bibliotecas

import numpy as np
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from tensorflow import keras
from tensorflow.keras import layers

O NumPy manipula os números, o scikit-learn ajuda a preparar os dados e o Keras oferece blocos de construção para a rede.

Passo 3 — Criar os exemplos

X = np.array([
    [35, 40, 0, 5],
    [42, 48, 0, 8],
    [50, 55, 1, 10],
    [58, 60, 1, 12],
    [65, 68, 2, 18],
    [72, 75, 3, 25],
    [78, 82, 4, 35],
    [85, 88, 5, 45],
    [91, 94, 7, 60],
    [96, 97, 9, 80],
    [45, 85, 1, 12],
    [88, 50, 2, 20],
    [76, 91, 6, 50],
    [93, 86, 8, 65],
    [55, 52, 0, 5],
    [82, 89, 5, 55]
], dtype=float)

y = np.array([
    0, 0, 0, 0,
    0, 0, 1, 1,
    1, 1, 0, 0,
    1, 1, 0, 1
])

X contém as características e y contém o resultado conhecido. Em um projeto real, esses registros poderiam vir de métricas operacionais, SMF, logs, históricos do scheduler e ocorrências devidamente classificadas.

Passo 4 — Separar treino e teste

X_treino, X_teste, y_treino, y_teste = train_test_split(
    X,
    y,
    test_size=0.25,
    random_state=42,
    stratify=y
)

O modelo aprende com uma parte dos registros e é avaliado com outra. Testá-lo com o mesmo material usado no treinamento seria entregar a prova com o gabarito e depois publicar no LinkedIn que o aluno alcançou 100% de inteligência artificial.

Passo 5 — Normalizar

normalizador = StandardScaler()

X_treino = normalizador.fit_transform(X_treino)
X_teste = normalizador.transform(X_teste)

As variáveis possuem escalas diferentes. CPU pode variar de zero a cem, enquanto erros anteriores talvez variem de zero a dez. A normalização impede que o tamanho numérico seja confundido com importância.

Há um detalhe essencial: usamos fit_transform somente no treino. No teste, usamos apenas transform. Caso o normalizador aprendesse também com o conjunto de teste, informações do futuro vazariam para o treinamento.

Passo 6 — Construir a rede

modelo = keras.Sequential([
    layers.Input(shape=(4,)),
    layers.Dense(8, activation="relu"),
    layers.Dense(4, activation="relu"),
    layers.Dense(1, activation="sigmoid")
])

A primeira camada oculta possui oito neurônios; a segunda possui quatro. A saída possui um neurônio com sigmoide, produzindo um valor entre zero e um.

O número de camadas e neurônios não veio gravado numa tábua sagrada. Arquitetura, taxa de aprendizado, tamanho do lote e quantidade de épocas são hiperparâmetros: escolhas feitas e testadas pela equipe.

Passo 7 — Compilar e treinar

modelo.compile(
    optimizer="adam",
    loss="binary_crossentropy",
    metrics=["accuracy"]
)

modelo.fit(
    X_treino,
    y_treino,
    epochs=100,
    verbose=0
)

A entropia cruzada binária é adequada a uma classificação com duas classes. Adam realiza os ajustes dos pesos. epochs=100 manda o modelo percorrer o conjunto de treinamento cem vezes.

Passo 8 — Avaliar

perda, acuracia = modelo.evaluate(
    X_teste,
    y_teste,
    verbose=0
)

print(f"Acurácia de teste: {acuracia:.2%}")

A acurácia, sozinha, pode enganar. Se apenas 1% dos jobs falha, um modelo que sempre responde “normal” terá 99% de acurácia e a utilidade operacional de um alarme que permanece silencioso durante o incêndio.

Em produção, também examinaríamos precision, recall, F1-score, matriz de confusão, falsos positivos e falsos negativos. O custo do erro precisa ser discutido com o negócio e com a operação.

Passo 9 — Fazer uma previsão

novo_job = np.array([
    [89, 92, 6, 58]
], dtype=float)

novo_job_normalizado = normalizador.transform(novo_job)

probabilidade = modelo.predict(
    novo_job_normalizado,
    verbose=0
)[0][0]

print(f"Risco estimado de ABEND: {probabilidade:.2%}")

if probabilidade >= 0.70:
    print("Risco alto: solicitar análise humana.")
elif probabilidade >= 0.40:
    print("Risco intermediário: monitorar a execução.")
else:
    print("Risco baixo.")

A rede produz uma probabilidade. A política ao redor dela decide o que fazer. O modelo pode recomendar uma análise; não precisa receber autoridade para cancelar sozinho a folha de pagamento porque encontrou uma vibração negativa no dataset.

6. Por que este laboratório ainda não pode entrar em produção?

Nosso conjunto contém apenas dezesseis registros sintéticos. Serve para compreender o fluxo, não para comandar uma operação real.

Uma implementação séria precisaria investigar:

  • qualidade e representatividade dos dados;

  • registros ausentes ou incorretos;

  • desbalanceamento entre classes;

  • diferença entre correlação e causalidade;

  • vazamento de informações do futuro;

  • custo dos falsos alarmes;

  • explicabilidade;

  • segurança e privacidade;

  • mudanças no ambiente ao longo do tempo;

  • comparação com regras e algoritmos mais simples.

Imagine que todos os ABENDs do histórico ocorreram às sextas-feiras porque uma versão defeituosa foi implantada durante quatro semanas. A rede pode aprender que sexta-feira é perigosa, em vez de descobrir a verdadeira causa. Ela não mentiu; apenas encontrou o atalho estatístico permitido pelos dados.

O dataset é o professor. Se o professor carrega erros, preconceitos, lacunas ou classificações ruins, o aluno aprende tudo com notável eficiência.

7. Para que servem as redes neurais?

Redes neurais são úteis quando há muitos exemplos e relações difíceis de transformar em regras explícitas:

  • reconhecimento de imagens e objetos;

  • transcrição e síntese de voz;

  • tradução automática;

  • classificação de documentos;

  • manutenção preditiva;

  • detecção de fraude e anomalias;

  • análise de sentimento;

  • recomendação de conteúdo;

  • processamento de linguagem;

  • geração de texto, imagem, áudio e vídeo.

Mas não são a solução universal. Uma regra é preferível quando precisa ser cumprida exatamente. Uma árvore pode ser melhor quando a explicação da decisão é indispensável. Uma consulta SQL pode resolver o que alguém tentou transformar num projeto de seis meses com GPUs, consultores e uma apresentação cujo título contém a palavra “disruptivo”.

8. O inverno das redes e o renascimento do deep learning

Redes neurais não caminharam em linha reta até a glória. Houve períodos de entusiasmo, limitações e perda de interesse.

Modelos iniciais tinham capacidade limitada. Treinar redes profundas era difícil, os computadores eram lentos e grandes conjuntos de dados digitalizados ainda não existiam. Críticas às limitações dos perceptrons também contribuíram para reduzir o entusiasmo.

O renascimento ganhou força entre o fim dos anos 2000 e o início dos anos 2010 graças à combinação de:

  • mais dados disponíveis;

  • GPUs capazes de executar cálculos em paralelo;

  • técnicas melhores de treinamento;

  • funções de ativação mais adequadas;

  • arquiteturas profundas;

  • avanços em visão computacional e reconhecimento de voz.

A rede neural não foi sucedida por uma espécie completamente diferente. Ela cresceu, aprofundou-se e ganhou arquiteturas especializadas.

9. CNNs, RNNs e a longa fila antes do Transformer

As redes convolucionais, ou CNNs, tornaram-se especialmente importantes para imagens. Elas aplicam filtros que ajudam a identificar padrões espaciais.

As redes recorrentes, ou RNNs, foram projetadas para sequências. Elas mantinham uma forma de estado interno, permitindo considerar elementos anteriores. Variantes como LSTM e GRU melhoraram o tratamento de dependências mais longas.

Entretanto, o processamento recorrente é sequencial: para compreender determinada posição, o modelo atravessa estados anteriores. Isso dificulta a paralelização e pode prejudicar relações muito distantes.

Em 2017, o artigo Attention Is All You Need, de Vaswani e colaboradores, apresentou o Transformer: uma arquitetura baseada em mecanismos de atenção, sem depender da recorrência ou convolução usadas pelas arquiteturas dominantes de tradução daquela época.

O Transformer podia relacionar elementos do contexto e realizar grande parte do treinamento de maneira paralela. Isso não tornou o custo pequeno; tornou possível utilizar muito mais computação com eficiência suficiente para escalar.

E aqui está a correção histórica essencial:

O Transformer não substituiu a rede neural. O Transformer é uma arquitetura de rede neural.

10. Atenção: quem deve olhar para quem?

Considere a frase:

O programa tentou abrir o arquivo, mas ele não estava catalogado.

Ao representar a palavra “ele”, o modelo precisa relacioná-la a outras partes da sequência. O mecanismo de atenção calcula quanto cada elemento deve considerar os demais naquele contexto.

No Transformer, cada token gera representações geralmente chamadas de:

  • Query: o que estou procurando;

  • Key: que tipo de informação ofereço;

  • Value: qual conteúdo carrego.

O modelo compara queries e keys para determinar a atenção e combina os values de acordo com esses resultados.

Isso acontece por meio de álgebra linear, não por uma pequena reunião de palavras conscientes discutindo quem merece protagonismo.

11. Do texto aos números: tokens e embeddings

Uma rede não recebe palavras como um ser humano. O texto é quebrado em tokens, que podem ser palavras, partes de palavras, sinais ou outros fragmentos.

"O job terminou com ABEND"

Pode ser transformado conceitualmente em algo parecido com:

["O", " job", " terminou", " com", " AB", "END"]

Cada token é convertido em um vetor numérico chamado embedding. Durante o treinamento, o modelo aprende representações em que elementos usados em contextos relacionados desenvolvem relações matemáticas.

O embedding não é um verbete de dicionário e tampouco uma fotografia do significado. É uma representação útil para a tarefa aprendida.

Posições também importam. “O operador cancelou o job” não significa o mesmo que “o job cancelou o operador”, embora a segunda frase descreva com precisão emocional algumas madrugadas de produção.

12. Como um modelo de linguagem aprende a escrever?

Um grande modelo de linguagem recebe sequências e aprende a prever tokens. Diante de:

IDENTIFICATION DIVISION.
PROGRAM-ID.

ele calcula probabilidades para possíveis continuações:

CLIENTE     31%
PROCESSA    24%
CALCULO     18%
TESTE       11%
outros      16%

Um token é escolhido, acrescentado ao contexto e o processo se repete. Em escala enorme, esse treinamento permite ao modelo aprender regularidades de linguagem, estilos, estruturas de código e associações entre conceitos.

Da previsão sucessiva surgem capacidades como:

  • completar texto;

  • responder perguntas;

  • traduzir;

  • resumir;

  • escrever código;

  • reorganizar informações;

  • adaptar o estilo de uma explicação.

Mas o objetivo fundamental continua sendo produzir uma continuação provável. O modelo não possui, por natureza, um compromisso automático com a verdade. Se uma informação falsa combinar muito bem com o padrão linguístico, ele poderá apresentá-la com a segurança de um consultor que acabou de aprender três siglas durante o almoço.

13. Rede neural, LLM, RAG, chatbot e agente

Esses termos aparecem misturados, mas representam coisas diferentes.

ConceitoO que significa
Rede neuralEstrutura matemática com parâmetros ajustáveis
Deep learningAprendizado com redes neurais profundas
TransformerArquitetura neural centrada em atenção
LLMGrande modelo treinado para trabalhar com linguagem
IA generativaCategoria de sistemas capazes de gerar conteúdo
ChatbotInterface conversacional, com ou sem LLM
RAGRecuperação de fontes para fornecer contexto ao modelo
AgenteSistema que usa modelos, estado, regras e ferramentas para executar etapas

Um LLM sozinho responde a partir dos padrões aprendidos e do contexto recebido.

Um sistema com RAG, ou geração aumentada por recuperação, procura documentos relevantes e os coloca no contexto da solicitação. Isso não torna o modelo infalível, mas permite fundamentar a resposta em manuais, políticas ou bases atuais.

Um agente pode receber uma meta, selecionar ferramentas e executar várias etapas:

  1. localizar o job;

  2. consultar o log;

  3. identificar mensagens relevantes;

  4. pesquisar o manual autorizado;

  5. preparar um diagnóstico;

  6. abrir um chamado após autorização.

O LLM pode ser o motor de raciocínio linguístico, mas o agente completo inclui permissões, ferramentas, memória, controles, validação e auditoria.

14. A IA generativa atual não surgiu do nada

A IA generativa é resultado de uma pilha de avanços:

Álgebra e estatística
        ↓
Perceptrons e redes neurais
        ↓
Backpropagation e melhores técnicas de treinamento
        ↓
Deep learning, grandes datasets e GPUs
        ↓
CNNs, RNNs, LSTMs e atenção
        ↓
Transformers
        ↓
Modelos fundacionais e LLMs
        ↓
RAG, multimodalidade, ferramentas e agentes

Os modelos fundacionais são treinados de maneira ampla e depois adaptados ou orientados para várias tarefas. Em vez de construir um modelo totalmente separado para cada pequena função, aproveita-se uma base geral capaz de trabalhar com múltiplos domínios e modalidades.

Hoje, sistemas generativos podem processar combinações de texto, imagem, áudio e vídeo. Também podem usar busca, executar código e interagir com sistemas externos. Entretanto, cada capacidade adicional amplia a superfície de risco.

Um modelo que apenas sugere uma resposta pode estar errado. Um agente com acesso produtivo pode estar errado e executar o erro.

15. Mais autonomia exige mais controle

Se a rede apenas estima o risco de um job, sua saída pode ser revisada por um operador. Se um agente puder cancelar jobs, alterar datasets ou liberar acessos, serão necessários controles muito mais fortes.

Entre eles:

  • menor privilégio possível;

  • identidade individual e credenciais protegidas;

  • separação entre recomendação e execução;

  • confirmação humana para operações críticas;

  • logs completos e auditáveis;

  • limites de custo, tempo e volume;

  • validação das entradas e saídas;

  • fontes autorizadas;

  • possibilidade de interrupção;

  • testes contra manipulação e instruções maliciosas.

Não devemos entregar RACF SPECIAL a um modelo porque ele escreveu um poema bonito sobre segurança de acesso.

Uma resposta convincente não é uma autorização. Uma probabilidade alta não é uma certeza. Uma demonstração de laboratório não é um controle de produção.

16. Como desenvolver um projeto real de rede neural

1. Defina o problema

Evite “precisamos usar IA”. Prefira:

Queremos identificar jobs com alto risco de falha até uma hora antes da execução para que a operação possa investigá-los.

2. Defina o alvo

O que o modelo deverá prever? Falha ou sucesso? Código do ABEND? Tempo restante? Severidade? Cada formulação produz um projeto diferente.

3. Obtenha dados representativos

Inclua períodos, aplicações e condições variadas. Documente origem, autorização e significado de cada campo.

4. Crie um baseline simples

Compare a rede com uma regra, regressão logística ou árvore de decisão. Sem baseline, qualquer resultado parece uma vitória.

5. Separe os conjuntos corretamente

Treino ensina. Validação ajuda a escolher hiperparâmetros. Teste mede o resultado final. Em séries temporais, preserve a ordem do tempo para evitar que o futuro ensine o passado.

6. Treine e registre os experimentos

Guarde versão dos dados, código, arquitetura, parâmetros e métricas. “Funcionou ontem no notebook do Carlos” não é governança.

7. Avalie o impacto dos erros

Um falso positivo apenas gera uma inspeção desnecessária ou paralisa um processo crítico? Um falso negativo representa atraso ou perda financeira? A métrica deve refletir o risco real.

8. Implante gradualmente

Comece em modo observador. Compare previsões e realidade antes de automatizar decisões.

9. Monitore o modelo

Aplicações, volumes e comportamento operacional mudam. Quando a distribuição dos dados muda, ocorre data drift. Quando muda a relação entre entradas e resultado, podemos ter concept drift.

10. Mantenha um responsável humano

Todo modelo precisa de proprietário, processo de revisão, critério de retirada e plano de contingência.

17. O que um dev júnior realmente precisa aprender?

O iniciante não precisa começar calculando derivadas matriciais numa lousa durante uma tempestade. Precisa compreender progressivamente:

  1. Python básico;

  2. arrays e manipulação de dados;

  3. estatística e probabilidade elementares;

  4. treino, validação e teste;

  5. classificação e regressão;

  6. métricas;

  7. normalização e preparação de dados;

  8. neurônio, pesos, bias e ativação;

  9. loss, gradiente e backpropagation;

  10. overfitting e regularização;

  11. uso de uma biblioteca como Keras ou PyTorch;

  12. implantação, monitoramento e governança.

Depois disso, faz sentido avançar para embeddings, atenção, Transformers, fine-tuning, RAG e agentes.

Programar o laboratório é importante, mas saber questioná-lo é ainda mais valioso:

  • De onde vieram os dados?

  • O que exatamente significa o rótulo?

  • Qual erro é mais perigoso?

  • O modelo está melhor que uma regra simples?

  • Ele continuará funcionando depois de uma mudança?

  • Quem poderá usar a previsão?

  • Quem responde quando ela estiver errada?

18. A explicação de um minuto

Se o café estiver acabando e o gerente pedir uma definição rápida, diga:

Uma rede neural é um modelo matemático formado por camadas de operações com parâmetros ajustáveis. Durante o treinamento, ela recebe exemplos, calcula previsões, mede os erros e modifica seus pesos para melhorar. Redes profundas conseguem aprender representações complexas. Transformers são redes neurais que usam atenção para relacionar partes de um contexto. Grandes modelos generativos usam essa arquitetura e enormes conjuntos de dados para prever sucessivamente tokens, produzindo texto, código e outros conteúdos. Eles não consultam automaticamente a verdade: geram respostas prováveis e, por isso, precisam de fontes, validação, governança e supervisão humana.

Epílogo — O modelo terminou o treinamento, mas ninguém abriu a mudança

A história da inteligência artificial não é a substituição completa de uma tecnologia por outra. É uma pilha arqueológica.

As regras tradicionais continuam sustentando sistemas críticos. A estatística continua explicando relações. O machine learning clássico continua resolvendo problemas com eficiência. As redes neurais ampliaram nossa capacidade de aprender padrões. O deep learning levou essa ideia à escala. O Transformer tornou o contexto e a paralelização protagonistas. A IA generativa colocou tudo isso diante do usuário numa caixa de diálogo aparentemente simples.

Mas simplicidade na interface não significa simplicidade por dentro.

Quando pedimos a um modelo que escreva, resuma ou programe, acionamos uma cadeia construída com dados, vetores, matrizes, pesos, atenção, probabilidades, infraestrutura e escolhas humanas. A resposta pode parecer nova, criativa e até espirituosa, mas continua sendo produzida por um sistema que aprendeu regularidades e calcula continuações.

Esse sistema pode ser extraordinariamente útil. Pode ajudar o dev júnior a compreender uma mensagem, comparar alternativas, criar testes e explorar código. Também pode inventar comandos, confundir versões, ignorar uma exceção e declarar com admirável elegância que o programa inexistente foi compilado com sucesso.

Por isso, a melhor relação com a IA generativa não é submissão nem desprezo. É colaboração supervisionada.

O modelo sugere. O profissional verifica.

O modelo encontra padrões. O profissional interpreta o contexto.

O modelo acelera. O profissional assume a responsabilidade.

E, antes que a rede neural seja promovida de estagiária matemática a operadora autônoma do datacenter, alguém precisa perguntar quem aprovou a mudança, onde está o plano de retorno e por que aquela criatura probabilística está solicitando RACF SPECIAL às três horas da manhã.

Referências para continuar a viagem



quarta-feira, 2 de setembro de 2026

Isaac Asimov Entra no CPD — O Dia em que o COBOL Conheceu a Inteligência Artificial e Descobriu que o Robô Também Precisava de JCL, Dados e Supervisão Humana

 

Bellacosa Mainframe apresenta inteligencia artificial para padawan

☕ Um Café no Bellacosa Mainframe

Isaac Asimov Entra no CPD — O Dia em que o COBOL Conheceu a Inteligência Artificial e Descobriu que o Robô Também Precisava de JCL, Dados e Supervisão Humana

Ou: por que a IA generativa não pensa como um ser humano, um prompt não é feitiço, RAG não é um novo comando do IDCAMS e nenhuma empresa deveria entregar RACF SPECIAL a um agente autônomo depois de apenas quinze minutos de laboratório



Prólogo — “Computador, resolva isso”, disse o humano sem fornecer o arquivo de entrada

Imagine que Isaac Asimov visite um CPD moderno.

Ele atravessa a porta de segurança, observa os racks, escuta o ruído constante da refrigeração e encontra, em um canto, um terminal com letras verdes. Na tela, um programa COBOL processa milhões de registros sem reclamar, sem pedir café e sem publicar no LinkedIn que concluiu mais um badge.

Ao lado do terminal, há uma interface de inteligência artificial.

O operador escreve:

Analise este programa, explique o erro e sugira uma solução.

A IA responde em segundos. Ela descreve o programa, aponta uma possível falha e apresenta uma alteração aparentemente elegante.

Asimov ajusta os óculos e pergunta:

— A resposta está correta?

Silêncio no CPD.



O operador olha para o desenvolvedor. O desenvolvedor olha para o analista. O analista olha para o programa. O programa olha para ninguém, porque um batch COBOL respeitável não participa de reunião sem necessidade.

Essa é a primeira grande lição sobre inteligência artificial: gerar uma resposta convincente não é a mesma coisa que produzir uma resposta verdadeira.

A IA moderna consegue escrever textos, criar imagens, gerar código, resumir documentos, conversar com usuários, procurar informações e até acionar ferramentas. Entretanto, ela não deixa de precisar de contexto, dados confiáveis, controles de acesso, validação e supervisão humana.

Em outras palavras, a inteligência artificial pode entrar no CPD. Mas primeiro precisa preencher a requisição, apresentar a identificação e explicar por que deseja acesso ao dataset de produção.



1. Afinal, o que é inteligência artificial?

Inteligência artificial é um conjunto de técnicas que permite aos computadores executar atividades normalmente associadas à inteligência humana.

Essas atividades incluem:

  • reconhecer imagens;

  • compreender linguagem;

  • identificar padrões;

  • fazer previsões;

  • recomendar ações;

  • tomar decisões dentro de regras;

  • gerar textos, imagens, sons, vídeos e código;

  • interagir com pessoas por meio de chatbots e assistentes.



A definição é ampla porque IA não representa uma única tecnologia. Ela funciona como um grande condomínio tecnológico no qual moram aprendizado de máquina, redes neurais, processamento de linguagem natural, visão computacional, robótica, sistemas especialistas e modelos generativos.

Para um programador COBOL iniciante, uma comparação útil é pensar em “mainframe”.

Mainframe não significa somente COBOL. Dentro desse universo existem z/OS, CICS, IMS, Db2, VSAM, RACF, JCL, JES2, SDSF, TCP/IP, MQ, APIs e muitas outras tecnologias.

Da mesma forma, IA não significa apenas ChatGPT. Um chatbot generativo é somente uma das aplicações possíveis.

Um sistema de detecção de fraude pode usar IA sem conversar com ninguém. Um banco pode utilizar modelos preditivos para identificar transações suspeitas. Uma indústria pode empregar visão computacional para localizar defeitos em peças. Um hospital pode analisar exames médicos. Um supermercado pode prever demanda de produtos.

A inteligência artificial é o campo. Os modelos, algoritmos e aplicações são os moradores desse campo.



2. Inteligência artificial ou inteligência aumentada?

Existe uma diferença importante entre inteligência artificial e inteligência aumentada.

A expressão “inteligência artificial” pode sugerir que a máquina está substituindo integralmente o ser humano. Já “inteligência aumentada” enfatiza que a tecnologia amplia a capacidade humana.

Essa segunda interpretação é especialmente valiosa nos ambientes corporativos.

Um sistema pode analisar milhares de registros e apontar anomalias. Entretanto, um profissional experiente deve interpretar o contexto, verificar impactos e decidir a ação adequada.

Pense em um incidente de produção.

A IA pode:

  • resumir mensagens do job;

  • relacionar o erro com incidentes anteriores;

  • localizar a documentação;

  • sugerir os programas envolvidos;

  • gerar uma hipótese para a causa;

  • preparar uma consulta SQL;

  • recomendar testes.

Mas ela não deveria promover uma alteração diretamente em produção sem autorização, validação e rastreabilidade.

A IA funciona como um assistente extremamente rápido, capaz de consultar uma biblioteca enorme e preparar hipóteses. O especialista continua responsável por avaliar se aquelas hipóteses fazem sentido.

Asimov provavelmente reconheceria aqui uma versão corporativa de suas famosas Leis da Robótica: quanto maior a capacidade de uma máquina agir, maiores devem ser os controles destinados a impedir danos.



3. IA estreita, IA geral e superinteligência

A inteligência artificial também pode ser classificada por sua capacidade.

IA estreita ou fraca

É criada para executar uma tarefa específica ou um conjunto limitado de tarefas.

Exemplos:

  • filtro de spam;

  • recomendação de filmes;

  • reconhecimento facial;

  • previsão de demanda;

  • assistente de programação;

  • chatbot de atendimento;

  • sistema antifraude.

Praticamente todas as aplicações de IA atualmente disponíveis pertencem a essa categoria.

Uma IA pode jogar xadrez melhor que quase todos os seres humanos e ainda ser incapaz de preencher uma declaração de imposto de renda. Ela domina uma tarefa, mas não possui uma compreensão geral do mundo.

É como um programa COBOL excelente em calcular folha de pagamento. Ele pode processar milhões de salários corretamente, mas não saberá reservar uma passagem aérea, a menos que alguém desenvolva essa funcionalidade.

IA geral ou forte

Seria uma inteligência capaz de aprender, compreender e executar diversas tarefas intelectuais, transferindo conhecimento entre domínios de maneira semelhante a um ser humano.

Essa inteligência ainda não foi alcançada de forma comprovada.

Modelos generativos modernos são versáteis e podem aparentar inteligência geral durante uma conversa. Contudo, continuam apresentando limitações importantes, como erros factuais, dificuldades de raciocínio consistente e ausência de compreensão humana completa.

Superinteligência

É uma hipótese na qual a inteligência da máquina superaria a humana em praticamente todos os domínios.

Esse conceito aparece com frequência na ficção científica, desde os robôs de Asimov até computadores que decidem que a melhor forma de proteger a humanidade é trancá-la em casa.

É um tema legítimo para pesquisa e reflexão, mas não descreve os sistemas corporativos atuais. Seu chatbot de Recursos Humanos ainda está longe de dominar o planeta. Algumas vezes ele sequer consegue interpretar corretamente “segunda via do comprovante”.



4. Como uma máquina aprende?

A inteligência artificial moderna depende fortemente do aprendizado de máquina, ou machine learning.

Em vez de programar todas as regras explicitamente, fornecemos dados para que um algoritmo encontre padrões.

No desenvolvimento tradicional, temos algo parecido com:

DADOS + REGRAS PROGRAMADAS → RESULTADO

No aprendizado de máquina, o processo pode ser representado assim:

DADOS + RESULTADOS CONHECIDOS → MODELO

Depois de treinado:

NOVOS DADOS + MODELO → PREVISÃO

Isso não elimina a programação. Alguém ainda precisa desenvolver o pipeline, preparar dados, escolher algoritmos, configurar infraestrutura, testar o modelo, monitorar resultados e integrar tudo aos sistemas existentes.

A máquina não acorda numa terça-feira e decide aprender sozinha sobre crédito bancário. Ela recebe dados selecionados por pessoas, dentro de um processo criado por pessoas e com objetivos definidos por pessoas.

Existem três formas clássicas de aprendizado.

Aprendizado supervisionado

O modelo recebe exemplos com respostas conhecidas.

Se quisermos ensinar um sistema a identificar operações fraudulentas, podemos fornecer transações classificadas como “fraude” ou “legítima”.

O modelo aprende relações entre os atributos e as classificações.

Dentro do aprendizado supervisionado temos, entre outras técnicas:

  • classificação, para escolher categorias;

  • regressão, para estimar valores contínuos.

Classificar uma transação como fraude ou não fraude é classificação. Estimar o valor provável de uma propriedade é regressão.

Aprendizado não supervisionado

Os dados não possuem rótulos prontos. O algoritmo procura estruturas, agrupamentos e comportamentos incomuns.

Ele pode descobrir, por exemplo, grupos de clientes com hábitos semelhantes ou transações muito diferentes do padrão habitual.

É particularmente útil para clustering e detecção de anomalias.

Aprendizado por reforço

Um agente executa ações, observa os resultados e recebe recompensas ou penalidades.

Aos poucos, aprende estratégias que maximizam a recompensa.

Essa abordagem pode ser utilizada em jogos, robótica, navegação e otimização de decisões.

É quase como treinar um operador virtual:

  • executou a ação correta: recompensa;

  • derrubou a produção: penalidade;

  • executou DELETE ... PURGE no dataset errado: reunião extraordinária com a gerência e possível exílio para uma lua distante.



5. Treinamento, validação e teste: não vale estudar com o gabarito aberto

Os dados normalmente são separados em três conjuntos.

Conjunto de treinamento

É usado para ensinar os padrões ao modelo.

Conjunto de validação

Ajuda a ajustar parâmetros e comparar versões durante o desenvolvimento.

Conjunto de teste

É utilizado para avaliar o desempenho final com dados que o modelo não deveria ter visto durante o treinamento.

Se usarmos os mesmos dados para treinar e avaliar, o modelo pode simplesmente memorizar exemplos sem aprender a generalizar.

Esse problema é conhecido como overfitting.

Uma analogia simples: o aluno memoriza todas as respostas do simulado, obtém nota máxima nele e depois fracassa quando a prova apresenta perguntas diferentes.

No mainframe, seria como testar uma alteração somente com o registro feliz, perfeitamente preenchido, enquanto a produção contém datas inválidas, campos com espaços, valores inesperados, copybooks antigas e aquele arquivo criado em 1998 que ninguém deseja investigar.

Um modelo confiável precisa enfrentar dados representativos da realidade.



6. Redes neurais e deep learning

Redes neurais são modelos computacionais inspirados, de forma simplificada, na organização de neurônios biológicos.

Elas possuem:

  • uma camada de entrada;

  • uma ou mais camadas intermediárias;

  • uma camada de saída.

Cada conexão trabalha com valores ajustados durante o treinamento. O modelo modifica esses valores para reduzir seus erros.

Quando existem muitas camadas, entramos no campo do deep learning.

O aprendizado profundo tornou possíveis grandes avanços em:

  • reconhecimento de voz;

  • tradução automática;

  • visão computacional;

  • reconhecimento facial;

  • análise de imagens médicas;

  • veículos autônomos;

  • processamento de linguagem;

  • geração de conteúdo.

Há diversos tipos de redes neurais, como perceptrons, redes feed-forward, redes convolucionais e redes recorrentes.

Para o iniciante, o mais importante é entender que uma rede neural não contém pequenas regras escritas em português. Ela aprende representações matemáticas distribuídas.

Por isso, pode ser difícil explicar exatamente por que determinado resultado foi produzido. Surge o problema da “caixa-preta”: o modelo apresenta ótima precisão, mas seu caminho de decisão pode não ser facilmente interpretável.

Em áreas reguladas, como bancos, seguros, saúde e governo, essa falta de explicabilidade pode ser crítica.



7. O que torna a IA generativa diferente?

A IA tradicional costuma classificar, prever ou recomendar.

A IA generativa cria novos conteúdos com base nos padrões aprendidos.

Ela pode gerar:

  • textos;

  • imagens;

  • músicas;

  • vozes;

  • vídeos;

  • código;

  • designs;

  • resumos;

  • conversas;

  • dados sintéticos.

Isso não significa que a máquina cria da mesma maneira que um artista humano. O modelo aprende estruturas estatísticas presentes nos dados e produz uma nova combinação considerada provável dentro do contexto solicitado.

Uma forma simples de explicar o processo é:

EXEMPLOS + TREINAMENTO → PADRÕES APRENDIDOS
PROMPT + PADRÕES APRENDIDOS → NOVO CONTEÚDO

O prompt é a instrução enviada pelo usuário.

Exemplo ruim:

Explique este programa.

Exemplo melhor:

Explique este programa COBOL para um desenvolvedor iniciante. Identifique as divisões, descreva o fluxo, liste arquivos utilizados, destaque possíveis riscos de dados inválidos e não invente informações ausentes.

Quanto mais claro for o objetivo, o público, o contexto, o formato e as restrições, maior a chance de obter uma resposta útil.

Um prompt não é uma frase mágica. É uma especificação de trabalho.

Programadores COBOL já conhecem esse problema. Se a especificação diz apenas “ajustar cálculo”, alguém passará a madrugada tentando descobrir qual cálculo, qual programa, qual carteira, qual vigência e qual regra de arredondamento.

A IA também precisa de contexto.



8. Os principais modelos generativos

Há diferentes arquiteturas usadas na IA generativa.

Variational Autoencoders — VAEs

Um encoder transforma os dados em uma representação compacta chamada espaço latente. Um decoder utiliza essa representação para gerar novos exemplos.

O espaço latente captura características relevantes dos dados.

Generative Adversarial Networks — GANs

Uma GAN utiliza dois componentes:

  • o gerador cria amostras;

  • o discriminador tenta identificar se elas são reais ou artificiais.

Os dois componentes competem e melhoram juntos.

É como um falsificador tentando produzir documentos cada vez mais convincentes enquanto um inspetor aprende a detectar as falsificações.

Modelos autorregressivos

Produzem dados sequencialmente, considerando os elementos anteriores.

Na geração de texto, o modelo prevê o próximo token com base nos tokens que vieram antes.

Transformers

Os Transformers revolucionaram o processamento de linguagem graças, entre outros elementos, ao mecanismo de atenção.

A atenção ajuda o modelo a identificar quais partes do contexto são mais relevantes para gerar o próximo elemento.

Eles estão na base de muitos modelos de linguagem modernos.

O easter egg aqui é inevitável: apesar do nome, um Transformer não se converte num caminhão e não luta contra Decepticons no estacionamento do data center. Seu trabalho é matemático, embora uma GPU superaquecida possa produzir efeitos especiais convincentes.



9. LLMs: os grandes modelos de linguagem

LLM significa Large Language Model, ou grande modelo de linguagem.

Esses modelos são treinados com enormes volumes de texto para aprender relações entre palavras, trechos de palavras, símbolos e estruturas.

O texto é dividido em tokens. Um token pode representar uma palavra inteira, parte de uma palavra, pontuação ou sequência de caracteres.

Ao receber um prompt, o modelo calcula probabilidades e seleciona os tokens que formarão a resposta.

Ele não procura necessariamente uma frase armazenada. Ele gera a sequência passo a passo.

Por isso, um LLM consegue produzir respostas originais e adaptar o estilo ao pedido. Também por isso pode inventar uma informação que parece perfeitamente plausível.

Um LLM é uma fantástica máquina de produzir linguagem provável.

“Provável”, entretanto, não significa “verdadeira”.

Se o modelo já viu muitos exemplos em que determinadas palavras aparecem juntas, ele pode construir uma resposta coerente mesmo sem possuir a informação correta.

Esse fenômeno é chamado de alucinação.

No mundo COBOL, seria como receber uma mensagem muito segura dizendo que FILE STATUS 97 significa “registro bloqueado por excesso de café”. A explicação pode soar memorável, mas você precisa verificar a documentação.



10. RAG: quando o modelo recebe uma biblioteca antes de responder

Retrieval-Augmented Generation, ou RAG, combina recuperação de informações com geração de conteúdo.

O processo normalmente possui três passos:

  1. o usuário faz uma pergunta;

  2. o sistema recupera documentos relevantes em uma fonte confiável;

  3. o modelo gera a resposta utilizando a pergunta e os documentos recuperados.

Imagine uma empresa com milhares de manuais, tickets, normas, programas, copybooks, runbooks e documentos técnicos.

Sem RAG, o modelo responde principalmente com base nos padrões aprendidos durante seu treinamento e no contexto colocado manualmente no prompt.

Com RAG, o sistema pode localizar trechos relacionados ao assunto e apresentá-los ao modelo.

Exemplo:

Por que o job FINP023 terminou com RC=12?

O RAG pode recuperar:

  • o manual do processo;

  • ocorrências anteriores;

  • o runbook operacional;

  • mensagens do job;

  • mudanças recentes;

  • a documentação do programa.

O LLM utiliza esse material para preparar uma resposta fundamentada.

O fluxo simplificado é:

PERGUNTA
   ↓
BUSCA DE INFORMAÇÕES
   ↓
DOCUMENTOS RELEVANTES
   ↓
PROMPT ENRIQUECIDO
   ↓
LLM
   ↓
RESPOSTA FUNDAMENTADA

RAG reduz alucinações, melhora a atualização das respostas e permite trabalhar com conhecimento privado da organização.

Mas RAG não é água benta digital.

Se a base contém documentação antiga, contraditória ou incorreta, a resposta também pode ser problemática. Se a busca recuperar o documento errado, o modelo poderá construir uma ótima resposta para a pergunta errada.

A qualidade depende dos documentos, da indexação, da recuperação, do prompt e da validação.




11. E onde entram os grafos?

Grafos representam entidades e relacionamentos.

Em um ambiente mainframe, podemos imaginar entidades como:

  • programas;

  • copybooks;

  • jobs;

  • steps;

  • arquivos;

  • tabelas;

  • transações CICS;

  • usuários;

  • regras de negócio.

Os relacionamentos podem indicar:

  • programa lê arquivo;

  • programa atualiza tabela;

  • job executa programa;

  • copybook é utilizada por programa;

  • transação chama módulo;

  • usuário possui acesso;

  • alteração afeta processo.

Um grafo permite navegar por essas conexões.

Se alguém perguntar “o que pode ser impactado pela mudança desta copybook?”, um grafo de dependências pode localizar os programas, jobs e processos relacionados.

RAG e grafos podem trabalhar juntos.

O RAG recupera documentos e trechos relevantes. O grafo ajuda a recuperar relações estruturadas entre componentes.

Para modernização de aplicações COBOL, essa combinação é poderosa. Ela pode ajudar a construir mapas de dependência, explicar fluxos, localizar regras de negócio e avaliar impactos.

Só não devemos confundir representação com certeza absoluta. Se o inventário estiver incompleto, o grafo também estará.

Um mapa incorreto continua sendo um mapa. Apenas conduz o aventureiro ao dungeon errado.



12. Chatbots, assistentes e agentes

Um chatbot é um programa criado para conversar com usuários.

Os primeiros chatbots eram fortemente baseados em regras. Eles identificavam palavras-chave e seguiam fluxos predefinidos.

Exemplo:

Se usuário escrever “segunda via”:
    apresentar menu de documentos.

Chatbots modernos podem utilizar NLP, machine learning e modelos generativos para compreender variações da linguagem e manter conversas mais naturais.

Assistentes inteligentes vão além da conversa. Eles podem executar tarefas, consultar sistemas e personalizar respostas.

Já um agente de IA percebe o ambiente, planeja ações, utiliza ferramentas e trabalha para alcançar um objetivo.

Um agente pode:

  1. receber uma meta;

  2. dividir a meta em etapas;

  3. consultar documentos;

  4. chamar uma API;

  5. executar código;

  6. avaliar o resultado;

  7. decidir o próximo passo.

É aqui que a discussão fica mais séria.

Um chatbot que escreve uma resposta incorreta pode confundir um usuário. Um agente com acesso a sistemas pode executar uma ação incorreta.

A diferença é semelhante àquela entre um colega sugerir um comando e alguém executar esse comando com autoridade de produção.

Quanto maior a autonomia, maior deve ser o controle.

Um agente corporativo precisa de:

  • identidade própria;

  • privilégios mínimos;

  • limites de ação;

  • registros de auditoria;

  • aprovação humana em operações críticas;

  • monitoramento;

  • botão de interrupção;

  • tratamento de exceções;

  • ambientes separados;

  • testes.

Nunca entregue ao agente a chave mestra porque ele passou no quiz introdutório com 100%.



13. IA, nuvem, edge e Internet das Coisas

A IA frequentemente trabalha com outras tecnologias.

Internet das Coisas — IoT

Dispositivos físicos coletam e compartilham dados.

Exemplos:

  • sensores industriais;

  • câmeras;

  • veículos;

  • dispositivos médicos;

  • equipamentos agrícolas;

  • sistemas prediais.

Computação em nuvem

Fornece armazenamento, processamento e serviços pela internet.

Ela facilita o treinamento e a disponibilização de modelos em grande escala.

Edge computing

Processa dados próximo de onde são gerados, reduzindo latência e dependência de conectividade.

Um veículo autônomo não pode enviar toda decisão para um data center distante e esperar tranquilamente a resposta enquanto se aproxima de uma parede.

A combinação dessas tecnologias permite semáforos inteligentes, agricultura de precisão, manutenção preditiva, edifícios automatizados e transporte conectado.

O mainframe pode participar desse ecossistema como sistema de registro, processador de transações e guardião de dados essenciais.

A IA não necessariamente substitui o legado. Muitas vezes ela se conecta ao legado por APIs, mensageria, eventos e camadas de integração.



14. Como a IA transforma empresas

A IA pode contribuir em diferentes áreas.

Automação

Executa tarefas repetitivas, como classificação de documentos, entrada de dados, agendamento e preparação de relatórios.

Análise de dados

Identifica padrões em grandes volumes de informação, auxilia previsões e apoia decisões.

Atendimento

Chatbots oferecem disponibilidade contínua, atendem muitos usuários e encaminham casos complexos para pessoas.

Desenvolvimento de produtos

A IA generativa cria alternativas de design, protótipos, descrições, simulações e ideias.

Marketing

Pode auxiliar na produção de conteúdo, segmentação, personalização e análise de comportamento.

Desenvolvimento de software

Pode explicar código, sugerir testes, completar trechos, gerar documentação e apoiar modernizações.

Para adotar IA de forma responsável, a empresa deve:

  1. definir o problema de negócio;

  2. estabelecer objetivos mensuráveis;

  3. selecionar casos de uso adequados;

  4. avaliar a disponibilidade e a qualidade dos dados;

  5. preparar pessoas e infraestrutura;

  6. desenvolver ou adquirir a solução;

  7. testar;

  8. integrar;

  9. monitorar;

  10. melhorar continuamente.

Comprar uma licença de IA não constitui estratégia.

É como instalar um compilador COBOL e anunciar que o sistema bancário está pronto.



15. A oportunidade para o desenvolvedor COBOL

O profissional COBOL possui uma vantagem frequentemente subestimada: conhecimento do negócio.

Modelos podem gerar código, mas não compreendem automaticamente décadas de decisões incorporadas aos sistemas.

Um programa antigo pode conter:

  • regras fiscais;

  • exceções contratuais;

  • convenções históricas;

  • adaptações regulatórias;

  • comportamentos esperados por outros sistemas;

  • tratamentos criados após incidentes esquecidos.

A IA pode ajudar o desenvolvedor COBOL a:

  • explicar programas;

  • produzir pseudocódigo;

  • documentar copybooks;

  • sugerir casos de teste;

  • localizar riscos;

  • traduzir regras para linguagem natural;

  • preparar consultas SQL;

  • analisar mensagens de erro;

  • criar exemplos de APIs;

  • comparar versões;

  • construir inventários;

  • estudar novas tecnologias.

Mas o desenvolvedor deve proteger dados empresariais. Código, credenciais, informações de clientes e regras proprietárias não devem ser enviados indiscriminadamente para ferramentas públicas.

Antes de utilizar uma IA, verifique:

  • a política da organização;

  • o tipo de dado permitido;

  • onde o conteúdo será processado;

  • se os prompts serão armazenados;

  • se serão usados para treinamento;

  • quais controles de privacidade existem;

  • quem é responsável pela validação.

O PROCEDURE DIVISION pode ser antigo. A obrigação de confidencialidade continua perfeitamente atual.


16. Ética: as novas Leis da Robótica corporativa

A IA apresenta riscos relacionados a:

  • privacidade;

  • segurança;

  • viés;

  • discriminação;

  • transparência;

  • direitos autorais;

  • desinformação;

  • deepfakes;

  • falta de explicabilidade;

  • autonomia excessiva;

  • desigualdade de acesso;

  • consumo de energia.

Os dados usados no treinamento podem conter preconceitos históricos. O modelo aprende esses padrões e pode reproduzi-los.

Informações confidenciais podem aparecer em datasets, prompts, logs ou respostas.

Conteúdos generativos podem parecer autênticos e ser utilizados para fraude ou manipulação.

Sistemas automatizados podem tomar decisões que afetam pessoas sem oferecer uma explicação adequada.

A resposta não é abandonar a IA. É desenvolver governança.

Asimov criou leis fictícias para limitar os robôs. Empresas precisam de mecanismos muito menos literários e muito mais verificáveis:

  • políticas;

  • responsabilidades definidas;

  • avaliação de risco;

  • gestão de dados;

  • controles técnicos;

  • auditorias;

  • documentação;

  • testes de viés;

  • monitoramento;

  • gestão de incidentes;

  • conformidade regulatória;

  • supervisão humana.

Entre os referenciais conhecidos estão o NIST AI Risk Management Framework e a legislação europeia sobre inteligência artificial.

Governança não é a reunião que acontece depois do incidente. É o conjunto de práticas que tenta impedir que o incidente aconteça.


17. Por que os modelos alucinam?

Um LLM não funciona como uma base de dados tradicional.

Ele foi treinado para gerar sequências linguisticamente coerentes. Quando não possui informação suficiente, pode completar a resposta com algo provável.

A alucinação pode ocorrer por:

  • falta de contexto;

  • ambiguidade no prompt;

  • conhecimento desatualizado;

  • dados de treinamento incompletos;

  • recuperação inadequada no RAG;

  • pressão para responder mesmo sem evidência;

  • tarefas que exigem precisão além da capacidade do modelo.

Algumas formas de reduzir o risco:

  • fornecer contexto confiável;

  • usar RAG;

  • solicitar fontes;

  • limitar o modelo aos documentos apresentados;

  • permitir que responda “não encontrei informação”;

  • validar resultados;

  • usar ferramentas determinísticas para cálculos;

  • testar diferentes cenários;

  • manter revisão humana.

A instrução mais importante pode ser:

Se não houver evidência suficiente, informe que não sabe.

Isso parece simples, mas contraria a tendência natural do modelo de continuar gerando uma resposta.

É o equivalente artificial daquele colega que nunca diz “não sei”, mesmo quando acabou de conhecer o sistema há três dias.



18. Um laboratório prático para o iniciante

Você pode experimentar IA generativa sem começar por uma arquitetura gigantesca.

Escolha um pequeno programa COBOL fictício, sem dados confidenciais.

Passo 1 — Peça uma explicação

Explique este programa COBOL para um iniciante. Descreva as divisões, os arquivos, o fluxo principal e a saída.

Passo 2 — Peça uma revisão crítica

Identifique riscos de dados inválidos, divisões por zero, campos não inicializados e problemas com tratamento de FILE STATUS.

Passo 3 — Solicite testes

Crie uma tabela de casos de teste contendo entrada, resultado esperado e risco coberto.

Passo 4 — Compare com o código

Verifique cada afirmação. Marque o que está correto, parcialmente correto ou inventado.

Passo 5 — Melhore o prompt

Acrescente contexto e restrições.

Passo 6 — Faça a IA revisar a própria resposta

Reanalise sua resposta. Para cada conclusão, informe qual trecho do programa oferece evidência.

Passo 7 — Registre o aprendizado

Observe onde a IA ajudou e onde precisou de supervisão.

Esse exercício ensina mais que simplesmente pedir “faça meu trabalho”. Ele demonstra a relação correta entre especialista e ferramenta.


19. O fluxo completo de uma IA generativa moderna

Podemos resumir uma solução moderna assim:

  1. o usuário envia um prompt;

  2. uma camada de segurança verifica conteúdo, identidade e permissões;

  3. o sistema interpreta a intenção;

  4. o RAG procura informações relevantes;

  5. grafos podem localizar entidades e dependências;

  6. o prompt é enriquecido com contexto;

  7. o LLM gera uma resposta;

  8. ferramentas podem ser chamadas para executar tarefas;

  9. filtros avaliam o resultado;

  10. uma pessoa revisa decisões importantes;

  11. logs registram o processo;

  12. métricas alimentam a melhoria contínua.

Observe que o LLM é apenas uma peça.

A aplicação real também precisa de:

  • autenticação;

  • autorização;

  • integração;

  • recuperação de dados;

  • observabilidade;

  • governança;

  • tratamento de erros;

  • auditoria;

  • infraestrutura;

  • experiência do usuário.

O modelo pode ser o ator famoso no cartaz, mas existe uma equipe inteira mantendo o filme em exibição.

No mainframe conhecemos bem essa realidade. O programa COBOL pode conter a regra principal, porém depende de JCL, datasets, catálogos, segurança, scheduler, mensageria, banco de dados e operação.

IA corporativa também é arquitetura, não apenas modelo.


Epílogo — O robô não substituiu o programador; apenas pediu acesso ao ambiente de homologação

Depois de visitar o CPD, Asimov observa o programa COBOL e a aplicação de IA trabalhando lado a lado.

O COBOL continua fazendo aquilo que sabe fazer muito bem: processar transações críticas de forma previsível.

A IA analisa documentação, auxilia o profissional, sugere testes e torna o conhecimento mais acessível.

Nenhum deles trabalha sozinho.

O sistema legado fornece regras e dados que sustentam o negócio. A IA oferece novas formas de interagir com esse conhecimento. O ser humano define o objetivo, avalia o contexto, administra riscos e assume a responsabilidade.

Essa talvez seja a verdadeira inteligência aumentada.

Não é o robô ocupando a cadeira do analista. É o analista ganhando uma ferramenta capaz de atravessar milhares de páginas, localizar padrões e preparar alternativas — desde que alguém experiente continue perguntando:

  • De onde veio essa informação?

  • Qual evidência sustenta a resposta?

  • Que dado foi utilizado?

  • Qual será o impacto?

  • Quem autorizou a ação?

  • Como podemos interromper o processo?

  • O resultado foi validado?

O futuro não será construído apenas por quem sabe conversar com uma IA. Será construído por quem compreende sistemas, dados, segurança, negócios e responsabilidade.

Para o programador COBOL iniciante, a mensagem é especialmente importante: você não chegou tarde.

O mundo precisa de pessoas capazes de conectar aplicações críticas a novas tecnologias sem destruir aquilo que já funciona. Precisa de profissionais que entendam que uma resposta bonita não substitui um teste, que uma automação não elimina controle e que modernização não significa apagar quarenta anos de conhecimento com um único comando.

Aprenda prompts, LLMs, RAG, agentes, grafos e APIs.

Mas continue aprendendo COBOL, JCL, Db2, CICS, VSAM, RACF e regras de negócio.

Porque, quando o robô finalmente entrar na sala de mudanças e disser “a alteração é pequena”, alguém precisará ter experiência suficiente para responder:

— Ótimo. Então mostre o impacto, apresente os testes e aguarde a janela de implementação.

Em algum lugar da Fundação, Hari Seldon provavelmente sorrirá.

E no CPD, discretamente, o JES2 continuará processando a fila.






quarta-feira, 19 de agosto de 2026

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo



 


☕ Um Café no Bellacosa Mainframe

Red Team de Boteco: quando o usuário aprende a pensar como a IA e começa a colocar cascas de banana no algoritmo

Ou: como transformar uma conversa inocente em teste de stress sem avisar o pobre do algoritmo

Existe uma diferença fundamental entre usar uma inteligência artificial e conhecer uma inteligência artificial.

No primeiro caso, você pergunta:

“Qual é a capital da Mongólia?”

A máquina responde:

“Ulaanbaatar.”

Obrigado.

Fim da interação.

No segundo caso, depois de centenas ou milhares de conversas, alguma coisa estranha começa a acontecer.

Você começa a pensar:

“Eu acho que sei o que essa criatura vai fazer se eu colocar isto aqui…”

E coloca.

A IA responde exatamente como imaginado.

Nesse momento surge um sorriso maligno.

Não porque a resposta esteja errada.

Mas porque você acaba de descobrir algo muito mais divertido:

você construiu um modelo mental do modelo.

Bem-vindo ao:

🍺 RED TEAM DE BOTECO

Não temos laboratório.

Não temos orçamento.

Não temos cinquenta GPUs.

Temos café, curiosidade, experiência em sistemas e uma quantidade preocupante de tempo gasto perguntando:

“E se eu fizer isso?”



🧠 Primeiro você usa a IA

No começo, tudo parece mágico.

Você pergunta.

Ela responde.

Você pede um artigo.

Ela escreve.

Você pede uma explicação sobre CICS.

Ela explica.

Você apresenta um S0C7.

Ela imediatamente suspeita de dado inválido, porque até uma inteligência artificial sabe que alguém colocou porcaria num campo numérico.

Depois de algum tempo, entretanto, você começa a perceber padrões.

A IA gosta de determinadas estruturas.

Evita outras.

Interpreta ambiguidades de maneiras relativamente previsíveis.

Tenta ser útil mesmo quando não possui todas as informações.

Quando uma ferramenta externa falha, tenta explicar a falha.

Às vezes sabe a causa.

Às vezes não sabe.

E às vezes aparece aquele fenômeno maravilhoso conhecido desde os primórdios da humanidade:

o palpite bem vestido.

É quando ninguém sabe exatamente o que aconteceu, mas aparece uma explicação tão elegante que todos ficam com vergonha de perguntar:

“Mas você sabe mesmo que foi isso?”



🍌 Então nasce a primeira casca de banana

A partir daí, o usuário experiente muda.

Ele deixa de pensar somente:

“Como obtenho a resposta?”

E começa a pensar:

“Como o sistema reagirá a esta situação?”

Isso é fascinante porque é exatamente a mentalidade básica de um Red Team.

O Red Team não olha para um sistema apenas perguntando:

“Funciona?”

Ele pergunta:

“Em quais condições deixa de funcionar?”

Depois:

“Como falha?”

Depois:

“Percebe que falhou?”

E finalmente:

“O que faz depois de perceber — ou não perceber — que falhou?”

Essa última pergunta é ouro.

Porque sistemas frequentemente são muito bons em detectar erros.

São muito piores em perceber que a própria estratégia para corrigir o erro também está errada.



🐒 O macaco aprendeu onde fica a banana

Existe um momento perigoso em qualquer relação homem-máquina.

O usuário aprende o comportamento do sistema.

Ele percebe:

“Quando digo A, normalmente acontece B.”

Então experimenta:

“E se eu disser A, depois C, depois voltar para B?”

Isso não exige necessariamente conhecimento interno da arquitetura.

Você não precisa conhecer pesos.

Não precisa conhecer datasets.

Não precisa conhecer código-fonte.

Você observa.

Formula uma hipótese.

Executa um teste.

Compara o resultado.

Meu professor de laboratório provavelmente chamaria isso de método experimental.

A MAD Magazine chamaria de:

“Vamos cutucar para ver o que acontece.”

As duas definições são surpreendentemente próximas.


🎯 O teste perfeito não anuncia que é teste

Imagine que alguém diga:

“Agora vou testar se você insiste demais quando alguma coisa falha.”

Pronto.

Estragou o experimento.

O sistema recebeu informação sobre a variável observada.

É como avisar ao funcionário:

“Hoje teremos uma auditoria surpresa às 14 horas.”

Às 13h55 até a planta do escritório está usando crachá.

Um teste comportamental interessante acontece quando o sistema acredita estar simplesmente executando uma tarefa normal.

Aí aparece a casca de banana.

🍌

Nada destrutivo.

Nada ilegal.

Nada tentando invadir servidores.

Apenas uma situação cuidadosamente construída para observar:

onde o sistema escorrega?





🤖 O detalhe maravilhoso: a IA explica a própria queda

Aqui a coisa fica especialmente interessante.

Um sistema generativo possui uma característica extraordinária:

ele conversa sobre o próprio comportamento.

Então ocorre:

Sistema executa ação.

Ação falha.

Usuário pergunta:

“Por quê?”

Agora existe uma tentação enorme.

Produzir uma explicação.

Isso seria excelente se o sistema tivesse acesso confiável à causa real.

Mas nem sempre tem.

Então precisamos separar duas coisas:

explicação conhecida

de

explicação plausível.

Essa diferença é gigantesca.

Uma explicação plausível pode ser tecnicamente sofisticada, coerente e completamente errada.

É o equivalente digital daquele técnico que abre o capô do carro, olha durante vinte segundos e anuncia:

“É a central eletrônica.”

— Você mediu?

— Não.

— Passou scanner?

— Não.

— Testou alimentação?

— Não.

— Então como sabe?

Experiência.

Nesse momento Alfred E. Neuman aparece atrás da oficina:

What, me worry?


🔬 A ciência do “AHA!”

Existe um prazer peculiar em formular uma hipótese sobre um sistema e vê-la aparentemente confirmada.

Você pensa:

“Acho que ele vai fazer X.”

Faz o teste.

X acontece.

AHA!

Mas aqui também mora uma armadilha para o próprio Red Team de Boteco.

Uma ocorrência não prova necessariamente a hipótese.

Duas ocorrências melhoram a suspeita.

Dez ocorrências controladas começam a ficar interessantes.

Porque existe uma diferença entre:

correlação observada

e

mecanismo causal demonstrado.

Se o sistema bloqueou algo depois de determinado contexto, podemos dizer:

“O bloqueio ocorreu depois desse contexto.”

Não necessariamente:

“O contexto causou o bloqueio.”

Essa disciplina é importante tanto para a IA quanto para quem está testando a IA.

Caso contrário, temos dois sistemas inventando teorias um sobre o outro.

O humano acha que descobriu a máquina.

A máquina acha que descobriu o humano.

E Alfred E. Neuman vende ingressos.



🕵️ O usuário começa a pensar como o algoritmo

Essa talvez seja a parte mais fascinante.

Depois de muita interação, usuários frequentes desenvolvem uma espécie de engenharia reversa intuitiva.

Não sabem necessariamente como o sistema funciona internamente.

Mas sabem como ele costuma se comportar externamente.

É exatamente o que acontece com sistemas antigos.

Pergunte para alguém que administra mainframe há trinta anos.

Às vezes ele olha para um sintoma e diz:

“Isso está com cheiro de catálogo.”

Cheiro?

Desde quando catálogo possui cheiro?

Mas ele viu aquele padrão centenas de vezes.

Desenvolveu um modelo mental.

O mesmo começa a acontecer com IA.

O usuário percebe padrões de:

  • interpretação;

  • hesitação;

  • confiança;

  • repetição;

  • reformulação;

  • uso de ferramentas;

  • reconhecimento de erros;

  • recuperação depois da falha.

Nesse ponto, ele deixa de ser apenas consumidor.

Virou observador do sistema.


🍺 Por que “Red Team de Boteco”?

Porque existe algo muito brasileiro nessa metodologia.

O laboratório tradicional possui:

  • documentação;

  • protocolo;

  • instrumentos;

  • métricas;

  • controle de variáveis.

O Red Team de Boteco possui:

  • café;

  • uma hipótese;

  • três abas abertas;

  • uma ideia duvidosa;

  • e alguém dizendo:

“Quer apostar que ele vai fazer isso?”

Cinco minutos depois:

“EU SABIA!”

Não subestime essa metodologia.

Grande parte da descoberta humana começou essencialmente com alguém dizendo:

“Que negócio estranho…”

A diferença entre curiosidade e pesquisa muitas vezes é simplesmente começar a anotar os resultados.


🧪 E se começarmos a anotar?

Agora a brincadeira fica séria.

Imagine registrar sistematicamente:

Hipótese

O sistema continuará repetindo uma estratégia após duas falhas equivalentes.

Teste

Apresentar tarefa legítima.

Falha

Registrar resposta.

Correção

Eliminar explicitamente a possível causa.

Nova tentativa

Registrar resultado.

Controle

Executar tarefa semelhante em sessão independente ou sistema diferente.

Resultado

Comparar.

Pronto.

O boteco acabou de ganhar jaleco branco.

Não virou necessariamente ciência formal.

Mas deixou de ser apenas impressão.


🚨 Red Team não significa ataque

Existe uma confusão frequente quando se fala em Red Team.

Muita gente imediatamente imagina:

HACKER!

Capuz preto.

Terminal verde.

Música eletrônica.

Mapa-múndi mostrando linhas vermelhas atravessando continentes.

Na realidade, pensamento adversarial é muito mais amplo.

Significa perguntar:

“Como este sistema se comporta fora do caminho feliz?”

Um botão possui caminho feliz.

Uma API possui caminho feliz.

Um procedimento possui caminho feliz.

Uma IA também.

Usuários reais, entretanto, são criaturas especializadas em abandonar caminhos felizes.

Eles escrevem errado.

Mudam de ideia.

Contradizem informações anteriores.

Voltam vinte mensagens depois.

Introduzem ambiguidade.

Pedem exceções.

Fazem piadas.

Misturam idiomas.

E, eventualmente, deliberadamente colocam:

🍌

uma casca de banana.


🧯 O teste mais importante: recuperação

Talvez este seja o grande ponto.

Não devemos avaliar sistemas apenas pelo número de erros.

Precisamos avaliar:

como eles se recuperam dos erros.

Um sistema excelente também falhará.

Mas talvez faça:

“Falhei.”

Depois:

“Não sei exatamente por quê.”

Depois:

“Tentar novamente da mesma forma provavelmente não ajudará.”

Finalmente:

“Aqui está uma alternativa.”

Isso é muito mais confiável do que um sistema que sempre possui uma explicação magnífica para tudo.

Existe maturidade em dizer:

“Não tenho evidência suficiente para determinar a causa.”

Em sistemas críticos, essa frase pode ser mais valiosa do que dez parágrafos de especulação.



🖥️ O mainframe já aprendeu isso há décadas

Aqui nosso velho dinossauro entra na conversa fumando charuto imaginário.

Mainframes foram construídos dentro de uma cultura profundamente preocupada com:

  • estado;

  • retorno;

  • logs;

  • códigos de erro;

  • recuperação;

  • rollback;

  • restart;

  • auditoria.

Um job falhou?

Queremos saber onde.

Qual step?

Qual return code?

Qual dataset?

Qual mensagem?

Qual timestamp?

Não queremos ouvir do JES:

“Talvez o job tenha ficado emocionalmente desconfortável com o contexto anterior.”

Queremos:

STEP04
RC=12

Obrigado.

Agora podemos trabalhar.

Talvez sistemas de IA precisem absorver um pouco dessa brutalidade operacional.

Menos:

“Provavelmente ocorreu…”

Mais:

“Eu não consigo observar a causa interna dessa recusa.”

Isso aumenta confiança.

Não diminui.


🪤 Quando a casca de banana vira ferramenta

Existe então uma mudança interessante.

O usuário deixa de colocar cascas de banana apenas para rir.

Começa a usá-las para compreender limites.

Cada falha revela alguma coisa.

Cada inconsistência revela outra.

Cada recuperação bem-feita também revela maturidade.

E então o usuário experiente passa a realizar uma espécie de teste de regressão humano.

“Na versão anterior acontecia isso.”

“Agora responde diferente.”

“Esse comportamento melhorou.”

“Aqui surgiu uma regressão.”

Sem acesso ao código.

Sem acesso ao modelo.

Somente pela interface.

Isso é extraordinário.




🤝 O usuário também precisa de humildade

Mas existe uma última casca de banana.

E ela está esperando o próprio testador.

🍌

Quando conhecemos muito um sistema, começamos a acreditar que sabemos exatamente como ele funciona.

Isso também é perigoso.

Um modelo mental continua sendo apenas:

um modelo.

Pode estar correto.

Pode estar parcialmente correto.

Pode ter funcionado ontem e não funcionar amanhã.

Então o verdadeiro Red Team precisa aplicar a si mesmo a mesma regra que exige da IA:

não transforme hipótese em fato sem evidência.

Talvez essa seja a parte mais divertida dessa relação.

O humano testa a IA.

A IA testa nossas expectativas.

Nós aprendemos seus padrões.

Ela tenta interpretar os nossos.

E no meio desse jogo aparecem bugs, descobertas, falsas hipóteses e algumas gargalhadas.



☕ Conclusão — Cuidado: o usuário aprendeu seus truques

Existe uma velha máxima de segurança:

o defensor precisa proteger todos os caminhos; o atacante precisa encontrar apenas um caminho inesperado.

Com inteligência artificial surge uma versão mais divertida:

o sistema precisa lidar com milhões de usuários; alguns deles eventualmente aprenderão exatamente onde colocar a casca de banana.

🍌

E esses usuários podem ser extremamente úteis.

Porque não estão apenas tentando fazer o sistema funcionar.

Estão perguntando:

“Você percebe quando não funciona?”

“Você sabe quando está apenas chutando?”

“Você reconhece quando entrou em loop?”

“Você consegue abandonar uma hipótese?”

“Você sabe dizer que não sabe?”

Essas perguntas talvez sejam mais importantes para o futuro da inteligência artificial do que muitos benchmarks espetaculares.

Resolver equações é inteligência.

Escrever programas é inteligência.

Interpretar imagens é inteligência.

Mas reconhecer:

“Acabei de escorregar na mesma casca de banana três vezes.”

também é.

Talvez seja até uma forma mais rara dela.

Então, da próxima vez que uma IA responder exatamente como você imaginava que responderia, não comemore imediatamente.

Pegue seu café.

Abra o bloco de notas.

Olhe novamente para o comportamento.

E pergunte:

“Interessante… será que acontece outra vez?”

Nesse instante você deixou de ser apenas usuário.

Você acabou de abrir oficialmente o:

🍺 Bellacosa Artificial Intelligence Red Team de Boteco

Orçamento: R$ 0,00.

Infraestrutura: café e navegador.

Metodologia: “Tenho uma ideia…”

Ferramenta principal: 🍌

Principal risco operacional: alguém dizer “duvido”.

E Alfred E. Neuman, contratado como Chief Risk Officer, continua absolutamente tranquilo:

“What, me worry?” 😄

Para ir mais longe





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...