 |
| Bellacosa Mainframe fala sobre tokens contexto e a ia |
☕ Um Café no Bellacosa Mainframe
Inteligência Não é o Resultado: Tokens, Contexto e a Nova Economia da IA Corporativa
Imagine a cena.
É madrugada no datacenter. As luzes azuis dos corredores refletem nos gabinetes, os ventiladores trabalham em ritmo constante e, no centro da sala, um programador COBOL padawan observa um painel moderno repleto de gráficos sobre inteligência artificial.
No painel aparecem números impressionantes:
bilhões de parâmetros;
milhões de tokens processados;
GPUs operando em paralelo;
latência inferior a um segundo;
custo de inferência caindo mês após mês;
modelos cada vez maiores e mais rápidos.
O padawan sorri e pergunta ao mestre:
— Então vencemos? Nossa IA está pronta?
O mestre toma um gole de café, olha para o terminal e responde:
— Depende. O que ela fez pela empresa?
O jovem programador fica em silêncio.
A resposta resume um dos maiores desafios da inteligência artificial corporativa:
Inteligência não é o resultado. Inteligência é apenas um componente do caminho até o resultado.
Uma empresa não recebe dinheiro porque processou mais tokens. Não conquista clientes porque sua GPU executou inferências mais rapidamente. Não reduz perdas simplesmente porque instalou um modelo de linguagem com centenas de bilhões de parâmetros.
O valor aparece quando a inteligência é transformada em ação.
Quando uma fraude é bloqueada.
Quando uma transação é concluída.
Quando um cliente recebe a resposta correta.
Quando uma falha é evitada.
Quando uma operação é automatizada com segurança.
Quando uma decisão é tomada com base em dados confiáveis, contexto adequado e regras de negócio governadas.
É sobre essa transformação que vamos conversar neste café.
1. O grande engano da economia dos tokens
Nos primeiros anos da popularização da inteligência artificial generativa, grande parte da discussão se concentrou nos modelos.
As perguntas mais comuns eram:
Qual modelo possui mais parâmetros?
Qual gera textos melhores?
Qual responde mais rápido?
Qual possui a maior janela de contexto?
Quanto custa um milhão de tokens?
Quantas GPUs são necessárias?
Qual modelo venceu determinado benchmark?
Essas métricas são importantes. Entretanto, elas medem principalmente capacidade técnica.
Elas não demonstram, por si só, valor de negócio.
É parecido com avaliar um programa COBOL apenas pela quantidade de instruções executadas por segundo.
Imagine que um programa processa dez milhões de registros em dois minutos. Parece excelente. Porém, ao final, ele gera valores incorretos nas contas dos clientes.
Foi rápido?
Sim.
Foi eficiente?
Talvez.
Gerou valor?
Não.
Na realidade, criou um problema mais rapidamente.
O mesmo acontece com a IA.
Uma organização pode reduzir o custo de um milhão de tokens em 80%, aumentar o throughput e utilizar servidores mais poderosos. Contudo, se o sistema continuar produzindo respostas irrelevantes, decisões erradas ou tarefas incompletas, o benefício econômico é pequeno.
O erro está em confundir uma unidade de processamento com uma unidade de valor.
O token é uma unidade técnica.
O resultado é uma unidade de negócio.
2. O que é um token, afinal?
Para um programador COBOL acostumado com registros, campos, bytes e layouts, podemos comparar o token a uma pequena unidade usada pelo modelo para interpretar uma informação.
Uma palavra pode ser formada por um ou vários tokens.
Por exemplo, uma frase como:
O cliente solicitou o cancelamento do cartão.
é dividida internamente em partes menores. O modelo processa essas partes, identifica padrões e calcula quais tokens devem aparecer na resposta.
O custo de muitos serviços de IA é calculado com base na quantidade de tokens de entrada e saída.
Temos então:
Tokens de entrada:
pergunta, documentos, histórico, instruções.
Tokens de saída:
resposta gerada pelo modelo.
Em uma aplicação simples, isso funciona bem.
Entretanto, em uma empresa, o objetivo raramente é apenas gerar texto.
Considere esta solicitação:
Cliente:
Perdi meu cartão e há uma compra que não reconheço.
Um chatbot baseado apenas em texto pode responder:
Sinto muito pelo ocorrido.
Entre em contato com a central do banco para bloquear o cartão.
A resposta pode ser educada e tecnicamente correta.
Mas o problema continua existindo.
O cartão não foi bloqueado.
A transação não foi contestada.
O cliente ainda corre risco.
Nenhuma investigação foi aberta.
A IA gerou tokens, mas não gerou um resultado.
3. Da resposta para a ação
Uma aplicação corporativa madura precisa transformar a solicitação em uma sequência de operações.
Por exemplo:
1. Identificar o cliente.
2. Confirmar a autenticação.
3. Consultar os cartões ativos.
4. Verificar as últimas transações.
5. Bloquear o cartão comprometido.
6. Abrir uma contestação.
7. Solicitar um novo cartão.
8. Registrar a operação para auditoria.
9. Enviar confirmação ao cliente.
Agora não estamos mais falando apenas de um modelo.
Estamos falando de um sistema completo.
Esse sistema precisa conectar:
Modelo de IA
+
Dados
+
Aplicações
+
APIs
+
Segurança
+
Governança
+
Infraestrutura
+
Operações
A inteligência artificial interpreta a intenção.
Os sistemas corporativos executam a ação.
Essa distinção é essencial.
O modelo pode compreender que o cliente deseja bloquear um cartão. Porém, quem realiza o bloqueio é uma aplicação transacional, talvez escrita em COBOL, executando em CICS e acessando dados no Db2.
O modelo não substitui necessariamente o sistema de negócio.
Ele passa a conversar com ele.
4. Tokens ficam baratos, contexto fica valioso
Uma das ideias mais importantes da nova economia da IA é a seguinte:
Tokens tendem a se tornar abundantes. Contexto confiável continuará sendo raro.
Os modelos estão ficando mais eficientes.
O custo da inferência tende a cair.
A capacidade computacional continua aumentando.
Modelos abertos e comerciais competem intensamente.
Consequentemente, o acesso à inteligência genérica tende a se tornar cada vez mais comum.
A pergunta estratégica deixa de ser:
Qual empresa possui acesso a um modelo de IA?
E passa a ser:
Qual empresa consegue fornecer ao modelo o contexto correto, no momento correto, com segurança e governança?
Vamos comparar duas situações.
Situação A: modelo sem contexto
Usuário:
O cliente João pode receber aumento de limite?
Resposta da IA:
Para avaliar um aumento de limite, considere renda,
histórico de pagamentos e nível de endividamento.
A resposta é genérica.
Pode ter sido escrita por qualquer modelo.
Situação B: modelo com contexto corporativo
Usuário:
O cliente João pode receber aumento de limite?
O sistema consulta:
CRM:
Cliente desde 2012.
Db2:
Nenhum atraso nos últimos 36 meses.
Sistema de crédito:
Score interno 892.
Sistema antifraude:
Nenhum alerta ativo.
Folha de pagamento:
Renda média aumentou 18%.
Política corporativa:
Aumento automático permitido até 20%.
Resposta:
O cliente está elegível para aumento de até 20%,
conforme a política de crédito vigente.
Motivos:
- relacionamento de 14 anos;
- ausência de atraso em 36 meses;
- score interno elevado;
- aumento comprovado de renda;
- nenhum alerta de fraude.
A recomendação exige confirmação do analista.
A diferença não está apenas no modelo.
Está no contexto.
5. O contexto proprietário como vantagem competitiva
Qualquer empresa pode contratar acesso a um modelo.
Porém, nenhuma concorrente possui exatamente:
seu histórico de clientes;
suas regras de negócio;
seus contratos;
seus dados operacionais;
seus registros de fraude;
seus manuais;
sua experiência acumulada;
seus sistemas legados;
seus fluxos de aprovação;
seu conhecimento institucional.
Esse conjunto forma o chamado contexto proprietário.
No mundo mainframe, uma parcela significativa desse contexto pode estar armazenada em:
Eis um detalhe que muitos projetos modernos ignoram:
O mainframe não armazena apenas dados antigos. Ele contém contexto operacional acumulado.
Um programa COBOL de quarenta anos pode representar regras de negócio que nunca foram formalmente documentadas em outro lugar.
Por exemplo:
IF CLIENTE-SEGMENTO = 'P'
AND DIAS-ATRASO = ZERO
AND SCORE-CREDITO > 850
AND VALOR-SOLICITADO <= LIMITE-AUTOMATICO
MOVE 'APROVADO' TO STATUS-PROPOSTA
ELSE
MOVE 'ANALISE' TO STATUS-PROPOSTA
END-IF.
Esse trecho não é apenas código.
Ele é conhecimento empresarial executável.
É uma política.
É contexto.
É parte da inteligência corporativa.
6. O perigo de construir agentes sobre dados desorganizados
Muitas empresas estão correndo para implementar agentes de IA.
O problema é que um agente pode automatizar decisões e executar tarefas. Portanto, um erro cometido por ele pode se espalhar muito mais rapidamente do que um erro em um chatbot tradicional.
Um chatbot errado gera uma resposta ruim.
Um agente errado pode:
cancelar um pedido;
bloquear um cliente;
aprovar um pagamento;
alterar um cadastro;
abrir milhares de chamados;
executar uma rotina indevida;
enviar informações confidenciais;
interromper um processo produtivo.
Observe esta arquitetura problemática:
Agente de IA
|
+--> CRM desatualizado
|
+--> planilha manual
|
+--> base duplicada
|
+--> documentação antiga
|
+--> API sem controle
O agente pode ser sofisticado.
O modelo pode ser excelente.
A infraestrutura pode ser poderosa.
Mesmo assim, o resultado será frágil.
No mundo COBOL, aprendemos há décadas a regra:
Garbage In, Garbage Out
Entrada ruim produz saída ruim.
Na era dos agentes, podemos acrescentar:
Garbage In, Automated Disaster Out
Entrada ruim pode produzir desastre automatizado.
É um pouco dramático, mas é verdade.
7. O custo por token não é o custo por tarefa concluída
Aqui aparece uma armadilha financeira importante.
Uma empresa pode celebrar a redução do custo por token, enquanto o custo real de completar uma tarefa continua aumentando.
Imagine um agente responsável por resolver chamados.
Modelo antigo:
Custo por milhão de tokens: US$ 10
Tokens por tarefa: 10.000
Taxa de sucesso: 80%
Modelo novo:
Custo por milhão de tokens: US$ 2
Tokens por tarefa: 40.000
Taxa de sucesso: 45%
O novo modelo parece mais barato por token.
Entretanto, ele usa quatro vezes mais tokens e falha com maior frequência.
Precisamos calcular o custo da tarefa concluída.
Exemplo simplificado
Modelo antigo:
10.000 tokens por tentativa
US$ 10 por 1.000.000 de tokens
Custo por tentativa:
10.000 / 1.000.000 x 10 = US$ 0,10
Com 80% de sucesso:
Custo aproximado por tarefa concluída:
0,10 / 0,80 = US$ 0,125
Modelo novo:
40.000 tokens por tentativa
US$ 2 por 1.000.000 de tokens
Custo por tentativa:
40.000 / 1.000.000 x 2 = US$ 0,08
Com 45% de sucesso:
Custo aproximado por tarefa concluída:
0,08 / 0,45 = US$ 0,177
O token ficou mais barato.
A tarefa ficou mais cara.
E ainda nem consideramos:
Esse é um dos grandes ensinamentos:
O indicador correto não é somente custo por token. É custo por resultado confiável.
8. A jornada em três fases
A imagem apresenta uma evolução poderosa:
Tokens → Contexto → Outcomes
Vamos aprofundar cada estágio.
Fase 1 — Tokens
É a fase da inteligência genérica.
A empresa mede:
preço;
velocidade;
capacidade;
latência;
tamanho do modelo;
consumo de GPU.
O objetivo é gerar uma boa resposta.
Fase 2 — Contexto
A empresa conecta o modelo aos seus dados.
Entram em cena:
RAG;
bancos vetoriais;
catálogos;
metadados;
APIs;
documentos;
sistemas transacionais;
dados históricos;
regras corporativas.
O objetivo é gerar uma resposta relevante para a organização.
Fase 3 — Resultado confiável
A empresa transforma a resposta em ação controlada.
Entram em cena:
agentes;
automação;
workflows;
aprovações;
autenticação;
autorização;
observabilidade;
auditoria;
rollback;
compliance.
O objetivo é gerar uma ação mensurável, segura e repetível.
9. RAG: dando memória ao modelo
Um dos mecanismos mais comuns para fornecer contexto a um modelo é o RAG, sigla para Retrieval-Augmented Generation.
Em português, algo como geração aumentada por recuperação de informação.
O fluxo básico é:
Pergunta
|
v
Busca de documentos relevantes
|
v
Documentos adicionados ao prompt
|
v
Modelo gera resposta baseada no contexto
Vamos imaginar um assistente para suporte COBOL.
Pergunta:
Como resolver o ABEND S0C7 do programa PAGT001?
Sem RAG, o modelo responde genericamente:
S0C7 normalmente indica dados inválidos em uma operação numérica.
Com RAG, o sistema consulta:
manual interno;
dump do programa;
copybook;
histórico de incidentes;
documentação do batch;
versão do módulo.
O contexto recuperado informa:
O campo WS-VALOR-ENTRADA é lido da posição 81,
mas o arquivo recebido possui caracteres em branco.
A resposta passa a ser:
No programa PAGT001, o S0C7 ocorre porque o campo
WS-VALOR-ENTRADA recebe espaços do registro de entrada.
Antes da conversão, valide o conteúdo:
IF CAMPO-ENTRADA NUMERIC
MOVE CAMPO-ENTRADA TO WS-VALOR
ELSE
MOVE ZERO TO WS-VALOR
END-IF.
Agora a resposta possui contexto real.
10. Do RAG ao agente
RAG responde.
Agente executa.
Considere este pedido:
Reprocesse o job de faturamento que falhou.
Um agente corporativo poderia seguir este fluxo:
1. Localizar o job no JES2.
2. Consultar o retorno no SDSF.
3. Identificar o step com falha.
4. Ler mensagens do sistema.
5. Correlacionar com incidentes anteriores.
6. Validar se o reprocessamento é permitido.
7. Solicitar aprovação, quando necessário.
8. Reexecutar o job.
9. Monitorar o novo processamento.
10. Registrar tudo na auditoria.
Perceba a diferença.
O agente não pode simplesmente encontrar um exemplo de JCL e submetê-lo.
Ele precisa respeitar:
autorização RACF;
regras operacionais;
janela batch;
dependências;
datasets;
estado do processamento;
políticas de reexecução;
impacto financeiro;
aprovação humana.
É aí que governança e segurança deixam de ser acessórios.
Elas tornam-se componentes centrais.
11. Segurança: o agente não pode ser um superusuário irresponsável
Um agente precisa operar segundo o princípio do menor privilégio.
Em ambientes z/OS, isso significa respeitar controles como:
RACF;
SAF;
perfis de dataset;
classes de recurso;
autorização de comandos;
acesso a transações;
controle de APIs;
trilhas SMF;
segregação de funções.
Imagine um agente que pode:
submeter qualquer job;
ler qualquer dataset;
alterar tabelas;
cancelar transações;
acessar dados pessoais.
Mesmo que a intenção seja legítima, esse desenho cria um risco gigantesco.
O correto é limitar o agente.
Exemplo:
Agente de suporte batch:
Pode:
- consultar spool;
- ler mensagens;
- comparar incidentes;
- sugerir correções;
- reexecutar jobs pré-autorizados.
Não pode:
- alterar loadlibs de produção;
- modificar datasets críticos;
- submeter JCL fora da whitelist;
- acessar dados de clientes;
- ignorar aprovações.
Uma boa arquitetura trata o agente como qualquer identidade corporativa.
Ele possui:
credencial;
função;
escopo;
permissões;
responsabilidade;
trilha de auditoria.
12. Governança: quem decidiu, por quê e com quais dados?
Em ambientes regulados, não basta uma decisão estar correta.
Ela precisa ser explicável.
Considere um agente de crédito.
Ele nega uma proposta.
A empresa precisa responder:
Qual modelo foi utilizado?
Qual versão?
Quais dados foram consultados?
Qual política estava vigente?
Houve intervenção humana?
A decisão pode ser reproduzida?
Existia viés?
Os dados estavam atualizados?
O cliente pode contestar?
Sem essas respostas, a automação se torna uma caixa-preta perigosa.
Uma trilha de auditoria pode registrar:
Data/Hora: 2026-07-14 14:35:12
Agente: AGT-CREDITO-01
Modelo: MODELO-CREDITO-V3
Política: POL-CRED-2026-04
Cliente: ID anonimizado 984521
Dados consultados:
- score interno;
- renda declarada;
- histórico de pagamento;
- alertas de fraude.
Decisão:
Encaminhado para análise humana.
Motivo:
Divergência entre renda declarada e histórico de movimentação.
Esse registro transforma uma ação de IA em uma ação corporativamente defensável.
13. O papel da infraestrutura
A imagem apresenta uma fundação composta por tecnologias como LinuxONE, OpenShift, IBM Fusion, Storage Scale, Ceph e watsonx.
A mensagem não é que uma única tecnologia resolve tudo.
A mensagem é que IA corporativa exige uma base coordenada.
Vamos interpretar cada camada.
LinuxONE
LinuxONE representa uma plataforma voltada a cargas Linux empresariais com forte ênfase em:
escalabilidade;
consolidação;
segurança;
disponibilidade;
eficiência operacional.
Ele pode hospedar aplicações, APIs, bancos de dados, containers e serviços de IA próximos dos sistemas corporativos.
Red Hat OpenShift
OpenShift atua como camada de orquestração de containers.
Ele permite executar:
Para o padawan COBOL, podemos compará-lo a uma grande plataforma que administra milhares de aplicações empacotadas em containers, distribuindo recursos, reiniciando componentes e aplicando políticas.
IBM Fusion
IBM Fusion aparece como uma fundação para dados e operações.
Em uma arquitetura de IA, armazenamento não significa apenas “guardar arquivos”.
É necessário:
disponibilizar dados;
proteger dados;
mover dados;
criar cópias;
restaurar ambientes;
aplicar políticas;
manter consistência;
fornecer desempenho.
Storage Scale
Storage Scale é associado ao acesso paralelo e distribuído a grandes volumes de informação.
Em cargas de IA, muitos processos podem precisar acessar enormes conjuntos de dados simultaneamente.
Um armazenamento lento transforma GPUs caras em máquinas esperando dados.
É o velho problema de I/O.
O programador COBOL conhece isso bem.
Não adianta possuir CPU rápida se o programa passa o tempo inteiro aguardando leitura.
Ceph
Ceph fornece armazenamento distribuído em diferentes formatos:
É bastante útil em ambientes de nuvem e containers, especialmente quando aplicações precisam de armazenamento resiliente e escalável.
watsonx
O watsonx representa a camada de IA, dados e governança.
De forma conceitual:
watsonx.ai
Modelos, desenvolvimento e inferência.
watsonx.data
Dados preparados para análise e IA.
watsonx.governance
Controle, risco, transparência e auditoria.
O ponto central é importante:
A IA empresarial não é apenas o modelo. Ela depende de dados e governança na mesma proporção.
14. O mainframe como servidor de contexto
Muitos projetos cometem um erro cultural: tratam o mainframe como um sistema antigo que precisa ser contornado.
Entretanto, nas grandes empresas, o mainframe frequentemente contém o contexto mais confiável.
É nele que estão:
Uma IA pode ler milhares de documentos, mas a resposta definitiva pode depender de uma única consulta ao Db2.
Exemplo:
SELECT STATUS_CONTA,
SALDO_DISPONIVEL,
LIMITE_CREDITO
FROM CONTAS
WHERE NUMERO_CONTA = :WS-CONTA;
Essa consulta retorna o estado operacional real.
O documento explica a política.
O sistema transacional informa a verdade atual.
A combinação dos dois produz contexto confiável.
15. Exemplo completo: agente de atendimento bancário
Vamos montar uma arquitetura passo a passo.
Solicitação
Cliente:
Quero contestar a compra de R$ 2.500 realizada ontem.
Etapa 1 — Interpretação
O modelo identifica:
Intenção:
Contestar transação.
Entidades:
Valor: R$ 2.500.
Período: ontem.
Etapa 2 — Autenticação
Antes de consultar informações, o sistema confirma a identidade do cliente.
MFA validado.
Sessão autenticada.
Token de acesso emitido.
Etapa 3 — Consulta de transações
Uma API chama o sistema transacional.
OpenShift
|
v
API corporativa
|
v
z/OS Connect
|
v
CICS
|
v
Programa COBOL
|
v
Db2
O COBOL recebe os dados:
01 REQUEST-DATA.
05 REQ-CONTA PIC X(12).
05 REQ-DATA-INICIAL PIC X(10).
05 REQ-VALOR PIC 9(7)V99.
01 RESPONSE-DATA.
05 RESP-CODIGO PIC X(04).
05 RESP-DESCRICAO PIC X(100).
05 RESP-ID-TRANSACAO PIC X(20).
Etapa 4 — Aplicação das regras
A política determina:
Compras acima de R$ 2.000 exigem análise adicional.
O agente não pode simplesmente devolver o dinheiro.
Ele precisa:
- bloquear temporariamente a transação;
- gerar protocolo;
- abrir análise antifraude;
- avisar o cliente;
- registrar a decisão.
Etapa 5 — Auditoria
Tudo é registrado.
Quem solicitou.
Qual agente atuou.
Quais dados foram consultados.
Qual regra foi aplicada.
Qual ação foi executada.
Etapa 6 — Resultado
Resposta final:
A transação de R$ 2.500 foi localizada.
Foi aberto o protocolo 845219.
O valor está em análise.
O cartão permanece ativo, mas novas transações suspeitas
serão monitoradas.
Prazo estimado: até 5 dias úteis.
Agora existe um resultado real.
Não apenas uma resposta elegante.
16. TTO: Time to Outcome
A sigla TTO significa Time to Outcome, ou tempo até o resultado.
Durante muitos anos, a tecnologia falou sobre:
Time to Market;
Time to Value;
tempo de resposta;
tempo de processamento;
SLA.
O TTO mede quanto tempo uma organização leva para transformar uma necessidade em um resultado concluído.
Considere um incidente batch.
Processo tradicional
08:00 — job falha.
08:20 — operador identifica.
08:45 — chamado é aberto.
09:30 — equipe analisa.
10:15 — causa é descoberta.
11:00 — correção é aprovada.
11:30 — job é reexecutado.
12:00 — processamento termina.
TTO:
4 horas.
Processo assistido por IA
08:00 — job falha.
08:01 — agente lê mensagens.
08:02 — correlaciona com incidente anterior.
08:03 — valida pré-requisitos.
08:04 — solicita aprovação.
08:07 — operador aprova.
08:08 — agente reexecuta.
08:30 — processamento termina.
TTO:
30 minutos.
A IA não criou valor porque leu o spool rapidamente.
Criou valor porque reduziu o tempo até a recuperação.
17. Métricas melhores para IA corporativa
Além do custo por token, uma organização deveria acompanhar:
Taxa de conclusão
Quantas tarefas foram realmente concluídas?
Tarefas iniciadas: 1.000
Tarefas concluídas: 760
Taxa de conclusão: 76%
Taxa de intervenção humana
Quantas tarefas exigiram correção?
Tarefas concluídas: 760
Intervenções humanas: 180
Taxa: 23,7%
Custo por resultado
Inclui:
tokens;
infraestrutura;
APIs;
processamento;
armazenamento;
retrabalho;
supervisão humana.
Tempo até o resultado
Quanto tempo o processo completo levou?
Taxa de erro operacional
Quantas ações precisaram ser revertidas?
Conformidade
Quantas ações possuíam:
autorização;
justificativa;
trilha;
evidência;
política associada?
Essas métricas aproximam IA de operação real.
18. Um exemplo COBOL: preparando contexto para uma API
Imagine um programa COBOL que consulta dados de um cliente para um agente.
IDENTIFICATION DIVISION.
PROGRAM-ID. CLIENTE-CONTEXTO.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-CLIENTE-ID PIC 9(10).
01 WS-NOME PIC X(40).
01 WS-SEGMENTO PIC X(10).
01 WS-SCORE PIC 9(03).
01 WS-DIAS-ATRASO PIC 9(03).
01 WS-STATUS PIC X(10).
01 WS-CONTEXTO.
05 FILLER PIC X(12) VALUE
'"cliente":"'.
05 WS-JSON-NOME PIC X(40).
05 FILLER PIC X(14) VALUE
'","segmento":"'.
05 WS-JSON-SEGMENTO PIC X(10).
05 FILLER PIC X(10) VALUE
'","score":'.
05 WS-JSON-SCORE PIC 9(03).
05 FILLER PIC X(01) VALUE '}'.
PROCEDURE DIVISION.
MOVE 1234567890 TO WS-CLIENTE-ID
EXEC SQL
SELECT NOME,
SEGMENTO,
SCORE,
DIAS_ATRASO,
STATUS
INTO :WS-NOME,
:WS-SEGMENTO,
:WS-SCORE,
:WS-DIAS-ATRASO,
:WS-STATUS
FROM CLIENTES
WHERE CLIENTE_ID = :WS-CLIENTE-ID
END-EXEC
IF SQLCODE = 0
MOVE WS-NOME TO WS-JSON-NOME
MOVE WS-SEGMENTO TO WS-JSON-SEGMENTO
MOVE WS-SCORE TO WS-JSON-SCORE
DISPLAY WS-CONTEXTO
ELSE
DISPLAY 'ERRO SQLCODE: ' SQLCODE
END-IF
GOBACK.
O objetivo do exemplo não é apresentar um gerador JSON perfeito, mas mostrar a ideia.
O programa:
recebe o identificador do cliente;
consulta dados no Db2;
organiza as informações;
disponibiliza o contexto para outro componente.
O LLM não precisa conhecer a estrutura interna do banco.
Uma API intermediária pode transformar os dados em um contrato bem definido.
Exemplo:
{
"cliente": "Maria Silva",
"segmento": "Platinum",
"score": 920,
"diasAtraso": 0,
"status": "Ativo"
}
Esse JSON se torna contexto para a decisão.
19. Easter egg: o mainframe já fazia “agentes” antes da moda
Existe uma curiosidade divertida.
Muito antes dos atuais agentes de IA, o mainframe já executava cadeias automáticas de decisões.
JCL, schedulers, CICS, IMS, MQ e automação operacional já permitiam:
Considere este exemplo simplificado:
//STEP01 EXEC PGM=VALIDA
//STEP02 EXEC PGM=PROCESSA,COND=(0,NE,STEP01)
//STEP03 EXEC PGM=NOTIFICA,COND=(0,NE,STEP02)
A lógica diz:
Valide.
Se estiver tudo certo, processe.
Se o processamento terminar corretamente, notifique.
Isso é uma forma primitiva de orquestração orientada a resultados.
A diferença moderna é que a IA pode interpretar linguagem, analisar informações não estruturadas e escolher ferramentas dinamicamente.
Mas o princípio de automação controlada não nasceu ontem.
O mainframe já ensinava isso quando muitos dos atuais especialistas em IA ainda brincavam com disquetes.
20. Faster complexity: complexidade mais rápida
Uma frase poderosa do texto é:
Isso não é transformação. É complexidade mais rápida.
Automatizar um processo ruim não o transforma automaticamente em um processo bom.
Imagine um fluxo com:
Adicionar IA pode acelerar o fluxo.
Mas também pode acelerar:
inconsistências;
erros;
retrabalho;
decisões conflitantes;
consumo de recursos;
dívida operacional.
Antes de automatizar, a empresa deveria perguntar:
Este processo ainda faz sentido?
Os dados são confiáveis?
As regras estão documentadas?
As responsabilidades estão claras?
A decisão pode ser auditada?
Existe mecanismo de reversão?
A IA não elimina arquitetura.
Ela aumenta a importância da arquitetura.
21. Um roteiro prático para o programador COBOL padawan
Como começar essa jornada?
Passo 1 — Identifique um resultado
Não comece com:
Vamos usar IA.
Comece com:
Queremos reduzir o tempo de análise de um ABEND de 90 para 15 minutos.
Passo 2 — Localize o contexto
Pergunte:
Onde estão os dados necessários?
Talvez em:
spool;
Db2;
SMF;
documentação;
Git;
tickets;
datasets;
copybooks.
Passo 3 — Defina as fontes confiáveis
Nem toda informação possui o mesmo peso.
Fonte oficial:
Db2 de produção.
Fonte complementar:
manual interno.
Fonte histórica:
tickets anteriores.
Fonte não confiável:
planilha local sem atualização.
Passo 4 — Crie uma camada de integração
Evite permitir acesso direto e irrestrito ao sistema.
Use:
APIs;
z/OS Connect;
MQ;
serviços CICS;
stored procedures;
camadas de autorização.
Passo 5 — Aplique governança
Registre:
modelo;
versão;
fonte;
decisão;
ação;
usuário;
horário;
resultado.
Passo 6 — Comece com aprovação humana
Antes de permitir ação autônoma:
IA sugere.
Humano aprova.
Sistema executa.
Depois, tarefas simples e de baixo risco podem ganhar maior autonomia.
Passo 7 — Meça o resultado
Acompanhe:
tempo economizado;
taxa de sucesso;
retrabalho;
custo por tarefa;
falhas;
impacto operacional.
22. Conclusão: a verdadeira corrida da IA
A corrida da inteligência artificial está mudando.
Na primeira fase, todos buscavam modelos maiores.
Na segunda, perceberam que o modelo sem contexto possui valor limitado.
Na terceira, as empresas vencedoras aprenderão a transformar contexto em ação confiável.
A fórmula é simples de escrever:
Compute
+
Data
+
Storage
+
Context
+
Applications
+
Security
+
Governance
+
Operations
=
Trusted Outcomes
Mas implementá-la exige engenharia.
Exige integração entre o novo e o legado.
Exige APIs, segurança, arquitetura, armazenamento, observabilidade e governança.
Exige reconhecer que o COBOL, o CICS, o IMS, o Db2 e o IBM Z não são obstáculos à inteligência artificial.
Eles podem ser a fonte do contexto mais valioso da organização.
Os tokens ficarão mais baratos.
Os modelos serão cada vez mais acessíveis.
A capacidade computacional continuará crescendo.
Contudo, o contexto confiável continuará raro.
E o resultado governado será ainda mais valioso.
No final, a pergunta correta não será:
Quantos tokens sua empresa processou?
Será:
Quantos problemas reais ela resolveu, com segurança, velocidade, rastreabilidade e confiança?
O mestre termina o café, olha novamente para o jovem programador e conclui:
— Padawan, o modelo pode conhecer milhares de respostas. Mas somente o sistema completo consegue entregar o resultado.
E, no fundo do datacenter, enquanto o IBM Z continua processando milhões de transações, uma antiga verdade da computação reaparece com nova roupa:
Tecnologia não vale pelo que promete. Vale pelo que consegue concluir.
