IA em Sistemas Legados: Fazendo Mainframes e COBOL…

💡 TL;DR (Muito Longo; Não Li)

A Realidade: 70% do volume global de transações bancárias ainda roda em COBOL. "Substituir o mainframe" é uma armadilha de uma década. A oportunidade real é aumentação, não substituição imediata.

A Estratégia: Não deixe a IA escrever COBOL. Use IA para entender código legado (via RAG), extrair especificações (para guiar migração) e orquestrar operações seguras via ferramentas estritamente tipadas.

A Arquitetura: Implemente "IA na Borda" (RAG somente leitura) primeiro. Mova para "Mediação In-Band" (IA usando APIs autorizadas) apenas com guardrails estritos. Trate o mainframe como o kernel imutável, e a IA como a camada de interface flexível.

O ferramental moderno de IA é otimizado para greenfield: microsserviços, APIs REST/GraphQL, JSON em todo lugar, CI/CD sobre GitHub. A realidade em grandes empresas é o oposto. A receita principal ainda flui através de mainframes, COBOL, PL/I, IMS, CICS, JCL, Oracle forms e jobs batch noturnos que ninguém quer tocar.

"IA em sistemas legados" não é um slogan de marketing; é um problema de engenharia difícil:

Você não pode quebrar SLAs em sistemas processando bilhões de dólares por dia.
Você não pode simplesmente fazer upload do fonte COBOL para um LLM na nuvem.
Você deve contornar décadas de conhecimento implícito codificado em código e scripts de controle de jobs.

Este artigo é um passo a passo técnico de como tornar a IA útil neste ambiente sem transformar seu mainframe em um tijolo caro.

1. O Que Conta como "Sistema Legado" Aqui?

Não estamos falando apenas de "código antigo". Neste contexto, sistema legado geralmente significa:

Plataforma: z/OS, IBM i, mainframes ou variantes UNIX antigas
Linguagem: COBOL, PL/I, NATURAL, RPG, às vezes monólitos da era Java 1.4 inicial
Dados: VSAM, IMS/DB, DB2 no mainframe, codificação EBCDIC, formatos binários customizados
Modelo de Interação:
- Transações CICS/IMS (telas verdes)
- Jobs batch JCL
- Filas de mensagens (MQ)

Restrições típicas:

Dados regulados (PCI, HIPAA, bancário).
Sem acesso externo à rede ou acesso limitado a partir do mainframe.
Propriedade indefinida de seções de código (autores originais já se foram há muito tempo).
Enorme conhecimento de domínio implícito codificado em "nós sempre rodamos o job X antes do job Y".

A integração de IA deve respeitar essa realidade.

2. Padrões de Integração: Como a IA Toca o Legado com Segurança

Existem três padrões amplos que tendem a funcionar em produção:

2.1 IA na Borda (Sem Acesso Direto ao Mainframe)

A IA nunca toca o mainframe diretamente. Em vez disso, ela aumenta os humanos que o fazem.

Exemplos:

Um "explicador de COBOL" que:
- Analisa copybooks.
- Resolve includes.
- Produz resumos em linguagem natural de parágrafos/seções.
Um assistente de runbook:
- Você cola JCL ou logs.
- Ele explica o que o job faz, o que os códigos RC significam e o que verificar a seguir.

Tecnicamente, isso é apenas RAG (Retrieval-Augmented Generation) sobre:

Clones locais de repositórios de fonte COBOL.
Wikis operacionais.
Logs de execução.

Sem integração em tempo de execução, sem acesso de escrita. Menor risco; alto ROI em entendimento e onboarding.

2.2 Integração de IA Somente Leitura

A IA pode acessar visualizações somente leitura semelhantes à produção:

Cópias de sombra (shadow copies) de tabelas DB2.
Snapshots sanitizados de VSAM.
Logs do sistema.

Casos de uso:

Análise de impacto: "Quais programas leem/escrevem na tabela CLIENTE?"
Linhagem de dados: "Quais jobs batch transformam o campo VALOR_LIMITE?"

Você tipicamente constrói:

Conectores/extratores que:
- Despejam metadados de catálogo (tabelas, arquivos, programas).
- Exportam código + copybooks.
- Normalizam tudo para UTF‑8 e armazenam em um índice.
Índice semântico (ex: em um banco de vetores) com:
- Embeddings de segmentos de código, jobs JCL, definições de tabela.
- Metadados: nome do arquivo, sistema, data da última alteração, proprietário, etc.
Frontend LLM que:
- Traduz uma pergunta em linguagem natural em queries de busca.
- Recupera artefatos relevantes.
- Usa-os como contexto para responder.

Ainda sem mutação em tempo de execução. Você ganha entendimento mas não automação.

2.3 Mediação In-Band (APIs + Ferramentas)

É aqui que a IA pode indiretamente agir no sistema legado através de ferramentas estritamente controladas:

Um microsserviço de fachada (façade) na frente do CICS/IMS expondo:
- POST /cliente/{id}/atualizar-endereco
- POST /emprestimo/{id}/alterar-limite
Uma API de orquestrador de jobs para:
- Submeter JCL com parametrização.
- Verificar status de jobs.
- Recuperar logs.

O LLM nunca envia sequências de teclas 3270 brutas ou JCL. Em vez disso, ele chama:

// Descrição de ferramenta em Pseudo‑TypeScript
type Tools = {
  submitJob: (jobName: string, params: Record<string, string>) => Promise<{ jobId: string }>;
  getJobStatus: (jobId: string) => Promise<"PENDING" | "RUNNING" | "SUCCESS" | "FAILED">;
  updateCustomerLimit: (customerId: string, newLimit: number) => Promise<"OK" | "REJECTED">;
};

O LLM está orquestrando operações de alto nível. A lógica difícil permanece na terra do mainframe.

3. Arquitetura: Uma Stack Pragmática IA–Legado

Uma arquitetura típica que sobrevive à revisão de segurança se parece com isto:

Camada Usuário/Cliente
- Web UI, CLI ou interface de chat (ex: bot interno Slack/Teams).
- Autenticação via SSO / IdP corporativo.
Serviço Orquestrador de IA
- Roda em um cluster Kubernetes seguro ou VM dentro da mesma VPC que o gateway do mainframe.
- Conversa com o LLM (seja:
  - modelo on‑prem, ou
  - através de um broker que impõe mascaramento de PII/SPI).
Camada de RAG & Conhecimento
- Índice de:
  - Código COBOL/PL/I.
  - Schemas de DB.
  - Grafos de JCL/job.
  - Docs de arquitetura.
- Busca vetorial + palavra-chave.
Camada de Ferramentas/Gateway
- APIs tipadas para:
  - Submissão de jobs.
  - Consulta de dados operacionais (logs, status).
  - Operações transacionais limitadas (atualizar info de contato, limites, flags).
- Tudo com auditoria e guardrails.
Sistemas Legados
- Mainframes, DB2, IMS, MQ.
- Sem exposição direta ao LLM; apenas via gateway.

Exemplo: Fluxo do Orquestrador (Alto Nível)

python

def handle_user_request(user, nl_request):
    # 1. Classificar a intenção
    intent = classify_intent(nl_request)
    
    # 2. Recuperar conhecimento de domínio relevante (RAG)
    context_docs = rag_search(nl_request, top_k=8)
    
    # 3. Usar o LLM com ferramentas disponíveis
    response = llm.chat(
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": nl_request},
            {"role": "system", "content": f"Context: {serialize_docs(context_docs)}"},
        ],
        tools=TOOLS_SPEC,  # updateCustomerLimit, submitJob, etc.
    )
    
    # 4. Executar chamadas de ferramenta apenas se corresponderem à allow‑list
    actions = extract_tool_calls(response)
    vetted_actions = apply_policies(user, actions)
    
    results = []
    for action in vetted_actions:
        results.append(execute_tool(action))
    
    # 5. Resumir resultado final para o usuário
    return summarize_results(llm, nl_request, context_docs, results)

4. Casos de Uso de LLM que Realmente Funcionam no Legado

4.1 Compreensão de Código e Descoberta de Domínio

Considere um programa COBOL:

cobol

       IDENTIFICATION DIVISION.
       PROGRAM-ID.  CHGCRDL1.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-NEW-LIMIT        PIC 9(7)V99.
       01  WS-CURRENT-LIMIT    PIC 9(7)V99.
       01  WS-RISK-SCORE       PIC 9(3).

       PROCEDURE DIVISION.
       1000-CHANGE-LIMIT.
           IF WS-RISK-SCORE > 700
               AND WS-NEW-LIMIT < (WS-CURRENT-LIMIT * 1.5)
               PERFORM 2000-APPLY-LIMIT
           ELSE
               PERFORM 3000-REJECT-LIMIT
           END-IF.

Um LLM, com prompting e contexto adequados, pode:

Explicar em Português claro a regra de negócio.
Localizar qualquer outro programa que referencie WS-RISK-SCORE.
Construir um mapa de referência cruzada de campos ↔ programas ↔ jobs.

O truque não é apenas "perguntar ao modelo o que isso faz", mas:

Pré‑processar COBOL:
- Resolver declarações COPY.
- Incluir includes inline onde útil.
- Normalizar formatação.
Embutir (Embed) chunks semânticos (nível de parágrafo, não nível de arquivo) e indexá-los.
No tempo de consulta, fornecer o contexto circundante certo para o LLM.

4.2 Geração de Dados de Teste e Cenários (Mascarados)

Sistemas legados são notoriamente difíceis de testar porque os dados de teste são:

Ou semelhantes a produção e sensíveis.
Ou sintéticos e inúteis.

A IA pode ajudar a gerar dados sintéticos mas realistas:

Respeitando restrições de campo (definições PIC).
Respeitando regras de negócio extraídas do código.

Exemplo de pipeline:

Extrair especificações de campo de copybooks.
Pedir ao LLM para gerar dados conforme PIC + restrições.
Validar dados sintéticos com uma engine de regras antes de inserir nos DBs de teste.

4.3 Assistência em Migração (Specs, Não Reescrever Diretamente)

Ingênuo "COBOL → Java" com um LLM é uma má ideia. Você tende a obter traduções linha-por-linha que:

Mantêm o mesmo espaguete de PERFORM aninhado.
Perdem semântica transacional (ex: CICS SYNCPOINT).

Um padrão mais seguro é:

Usar o LLM para extrair uma especificação formal:
- Entradas/saídas.
- Pré/pós‑condições.
- Caminhos de tratamento de erro.
- Expectativas de SLA/throughput.
Ter humanos projetando uma implementação moderna (ex: um serviço stateless + DB).
Usar LLM para gerar scaffolding (DTOs, controller, mappers, testes), não a lógica de negócio central.

Em MDX você poderia até embutir a especificação extraída como um bloco de código:

yaml

contrato:
  operacao: "AlterarLimiteCredito"
  entradas:
    - nome: idCliente
      tipo: string
    - nome: novoLimite
      tipo: decimal(9,2)
    - nome: scoreRisco
      tipo: inteiro
  invariantes:
    - "novoLimite <= limiteAtual * 1.5 quando scoreRisco > 700"
    - "Rejeitar alteração se scoreRisco <= 700"
  efeitos_colaterais:
    - "Persistir novo limite na tabela LIMITES_CLIENTE"
    - "Escrever registro de auditoria em AUDIT_LIMITES"

É aqui que LLMs brilham: transformando código bagunçado em especificações estruturadas.

5. Modos de Falha e Como Evitá-los

Quando você deixa a IA perto de sistemas legados, existem alguns modos de falha clássicos.

5.1 Operações Alucinadas

O modelo pode "inventar" um passo JCL, código de transação ou tabela DB que parece plausível mas não existe.

Mitigação:

Ferramentas devem ter validação estrita de schema/comando.
Toda operação solicitada pela IA é verificada contra:
- Um registro de templates JCL permitidos.
- Um registro de schema de tabelas/colunas.
- Códigos de transação permitidos (whitelist).

5.2 Problemas de Codificação de Caracteres & Layout de Dados

Muitos pipelines de LLM assumem UTF‑8, JSON e texto delimitado por nova linha.

Realidade legado:

EBCDIC em disco.
Registros de largura fixa.
Decimais compactados (COMP‑3).

Mitigação:

Todos os fluxos de extração/ingestão devem:
- Decodificar EBCDIC → UTF‑8.
- Preservar offsets e limites de campo.
- Anotar cada campo com metadados de layout.
Ao gerar código que toca o layout de dados, a saída do LLM deve ser:
- Validada por parsers (ex: um parser COBOL ou parser de copybook).
- Rejeitada se limites de campo não alinharem.

5.3 Latência e Throughput

LLMs têm latência de inferência não trivial. Amarrá-los em transações online síncronas é arriscado.

Padrões de mitigação:

Usar LLMs offline/async:
- Para análise, especificação, documentação.
- Para planejamento de orquestração batch, não decisões por transação.
Para fluxos tempo-real:
- Pré-computar estratégias ou modelos offline.
- Implantar artefatos destilados/baseados em regras ao lado do sistema legado.

6. Um Fluxo Ponta-a-Ponta Concreto

Vamos percorrer um cenário realista:

"Aumentar o limite de aprovação de cartão de crédito de 1.5x para 1.8x para clientes de alto risco."

Passo 1 — Entendimento da Query

O engenheiro digita a solicitação no assistente de IA. O LLM:

Identifica o domínio: "regras de limite de crédito".
Busca no índice RAG por:
- Programas relacionados a LIMIT, RISK, CREDIT.
- Tabelas DB como CUSTOMER_LIMIT, CUSTOMER_RISK.
- Jobs JCL implantando esses módulos.

Passo 2 — Localização em Código Legado

O sistema encontra o programa COBOL CHGCRDL1 anterior e destaca:

cobol

IF WS-RISK-SCORE > 700
    AND WS-NEW-LIMIT < (WS-CURRENT-LIMIT * 1.5)
    PERFORM 2000-APPLY-LIMIT
ELSE
    PERFORM 3000-REJECT-LIMIT
END-IF.

O LLM propõe um diff, não uma reescrita cega:

diff

-        AND WS-NEW-LIMIT < (WS-CURRENT-LIMIT * 1.5)
+        AND WS-NEW-LIMIT < (WS-CURRENT-LIMIT * 1.8)

Passo 3 — Revisão Humana + Análise de Impacto

Antes de qualquer mudança:

Análise de impacto:
- Quais outros programas chamam CHGCRDL1?
- Quais jobs batch empacotam e implantam ele?
- Existem regras de auditoria/compliance amarradas ao valor 1.5x?
A IA sugere:
- Casos de teste para:
  - Score risco = 701 com limite = 1.7x atual.
  - Score risco = 699 com limite = 1.6x atual.

Passo 4 — Implementação da Mudança

Dependendo da governança:

A IA gera:
- Um arquivo de patch.
- Casos de teste atualizados.
- Snippet de documentação para o change log.
Um humano:
- Revisa o patch.
- Roda através do CI de mainframe (ex: pipelines de build z/OS).
- Aprova implantação.

A IA é o acelerador, não a fonte da verdade.

7. Conclusões Práticas

Para times rodando sistemas legados e querendo usar IA seriamente, o playbook é:

Comece com entendimento, não automação Construa assistentes baseados em RAG para compreensão de código, linhagem de dados e documentação primeiro.
Nunca dê credenciais brutas de mainframe ao LLM Sempre medeie através de ferramentas tipadas e auditadas com allow‑lists.
Faça do layout de dados um conceito de primeira classe Trate copybooks e schemas como seus "contratos". Parseie e valide tudo contra eles.
Use IA para extrair specs, não para "portar código" O sucesso da migração depende de modelos de domínio limpos, não de reescritas automágicas COBOL→Java.
Mantenha humanos no loop de commit A IA pode propor patches, mas humanos devem possuir os merges para código de missão crítica.

Feito corretamente, IA em sistemas legados não significa "substituir o mainframe". Significa transformar décadas de código opaco e arriscado em um sistema que seus engenheiros atuais possam entender, evoluir e eventualmente — quando fizer sentido econômico — modernizar com confiança.

IA em Sistemas Legados: Fazendo Mainframes e COBOL Trabalharem com LLMs

✨TL;DR / Sumário Executivo

💡 TL;DR (Muito Longo; Não Li)