Integrar Sistemas Legados com Agentes de IA: Como Gerar Valor sem Reescrever Tudo do Zero
- 14 de jan.
- 23 min de leitura
Atualizado: 8 de jun.
Empresas de médio e grande porte raramente operam sobre sistemas totalmente modernos. Na prática, muitas operações críticas ainda dependem de aplicações criadas há 10, 15 ou até 20 anos. São sistemas de faturamento, ERPs customizados, plataformas de logística, módulos financeiros, rotinas em banco de dados, integrações SOAP, arquivos batch, filas antigas, rotinas em mainframe e aplicações monolíticas que continuam sustentando o negócio todos os dias.
Esses sistemas podem ter telas antigas, baixa documentação, acoplamentos difíceis de entender e integrações frágeis. Ainda assim, eles carregam regras de negócio valiosas, processos consolidados, histórico operacional e uma estabilidade que não pode ser ignorada.
A pergunta correta, portanto, não é:
“Como substituímos todo o legado?”
A pergunta mais estratégica é:
“Como colocamos agentes de IA para gerar valor sobre o legado atual, sem interromper a operação e sem iniciar uma reescrita arriscada do zero?”
A resposta está em uma arquitetura de integração segura, incremental e governada. Nela, o sistema legado continua protegido, enquanto uma camada moderna de APIs, microsserviços, MCP Servers, ferramentas corporativas e agentes de IA passa a consumir suas capacidades de forma controlada.
Esse modelo permite que a empresa avance para uma arquitetura agêntica sem precisar desmontar, imediatamente, tudo que já sustenta sua operação.
O legado não é o vilão da história
Sistemas legados costumam ser tratados como problema. Em muitos casos, essa leitura é incompleta.
Um sistema legado existe porque, em algum momento, ele resolveu uma necessidade real do negócio. Com o tempo, recebeu ajustes, novas regras, exceções, integrações e adaptações. O resultado pode ser uma aplicação difícil de evoluir, mas ainda central para a operação.
O legado geralmente concentra:
regras de negócio críticas;
histórico de processos;
integrações com parceiros;
cálculos complexos;
rotinas fiscais;
dados transacionais;
dependências operacionais;
lógica acumulada ao longo de anos.
O problema não é sua existência. O problema surge quando esse legado passa a impedir a evolução do negócio. Isso acontece quando qualquer mudança exige semanas de análise, quando integrações quebram com frequência, quando poucos profissionais entendem o funcionamento interno, quando a documentação está desatualizada ou quando a empresa não consegue expor funcionalidades críticas para canais modernos, sistemas móveis, parceiros, plataformas digitais e, agora, agentes de IA.
A modernização não precisa começar com uma substituição total. Em ambientes corporativos complexos, a abordagem mais segura costuma ser criar uma camada de borda que permita consumir o legado de forma controlada, mensurável e evolutiva.
Essa camada atua como uma fronteira entre o mundo moderno e o mundo legado.
De um lado, ficam agentes de IA, APIs, serviços modernos, eventos, governança, observabilidade e autenticação. Do outro, ficam procedures, SOAP, bancos antigos, arquivos, filas, sistemas monolíticos e mainframes.
A função da arquitetura é fazer esses dois mundos conversarem sem expor o legado diretamente e sem obrigar a empresa a reescrever tudo antes de gerar valor.
Integrar Sistemas Legados com Agentes de IA.
O desafio real: integrar sem contaminar
Ao integrar sistemas legados com agentes de IA, o maior erro arquitetural é permitir que o agente acesse diretamente o banco de dados, execute procedures sem controle, leia arquivos sensíveis sem mediação ou invoque rotinas internas sem uma camada de segurança.
Isso cria riscos sérios:
vazamento de dados sensíveis;
execução indevida de operações críticas;
ausência de trilha de auditoria;
dificuldade de limitar permissões;
acoplamento direto entre IA e legado;
exposição de regras internas;
baixa rastreabilidade;
dificuldade de rollback;
aumento do risco operacional.
Agentes de IA precisam de contexto e capacidade de ação, mas não devem receber acesso irrestrito à operação. Em uma arquitetura corporativa madura, o agente não conversa diretamente com o legado. Ele conversa com ferramentas governadas.
Essas ferramentas são expostas por MCP Servers, protegidas por APIs, mediadas por microsserviços e controladas por políticas de segurança, autenticação, autorização, auditoria e observabilidade.
A arquitetura correta precisa responder a algumas perguntas essenciais:
Quais ações o agente pode executar?
Quais dados ele pode consultar?
Quem autorizou essa operação?
Qual usuário iniciou a solicitação?
Qual ferramenta foi chamada?
Qual API foi consumida?
Qual microsserviço acessou o legado?
Qual resultado retornou?
Houve erro, retry ou fallback?
Essa ação precisa de aprovação humana?
Existe trilha de auditoria ponta a ponta?
Sem essas respostas, a integração entre IA e legado vira um risco. Com essas respostas, ela se torna uma base concreta para modernização incremental.
Anti-Corruption Layer: a camada que protege o legado
O conceito central dessa abordagem é o Anti-Corruption Layer, ou camada anticorrupção.
Em termos simples, essa camada impede que o modelo do legado “contamine” os sistemas modernos. Ela traduz estruturas antigas, protocolos obsoletos, formatos proprietários e regras internas para contratos modernos, estáveis e compreensíveis.
Essa camada pode ser composta por:
API Gateway;
microsserviços de borda;
adaptadores para sistemas legados;
conectores para bancos de dados;
conectores SOAP;
workers assíncronos;
filas e tópicos de eventos;
serviços de documentos;
mecanismos de autenticação;
camada de auditoria;
observabilidade;
MCP Servers;
catálogo de ferramentas;
políticas de autorização.
O objetivo é claro: o agente de IA não precisa conhecer o funcionamento interno do legado. Ele precisa conhecer ferramentas confiáveis, bem descritas e governadas.
Por exemplo, em vez de o agente saber que precisa executar uma procedure Oracle chamada PKG_FATURAMENTO.CONSULTA_STATUS_NF, com parâmetros específicos e retorno em formato interno, ele enxerga uma ferramenta simples: STATUS_NF
Essa ferramenta pode receber um número de nota fiscal e retornar um JSON limpo:
{
"numero_nf": "45721",
"status": "emitida",
"pedido": "aguardando_envio",
"data_emissao": "2026-06-03",
"cliente": "Empresa Exemplo S.A."
}
O agente trabalha com esse JSON. A complexidade da procedure, do banco, das regras fiscais e das integrações antigas fica encapsulada na camada de borda.
Esse é o ponto decisivo: o legado continua funcionando, mas passa a ser consumido por interfaces modernas.
Como agentes de IA enxergam o legado em uma arquitetura moderna
Em uma arquitetura agêntica corporativa, o agente de IA atua como um cliente MCP, ou seja, ele se conecta a um ou mais MCP Servers para descobrir e utilizar ferramentas disponíveis.
Essas ferramentas representam capacidades do negócio. Elas podem consultar informações, iniciar processos, gerar documentos, atualizar registros, abrir chamados, validar dados ou acionar fluxos operacionais.
O agente não precisa saber se, por trás da ferramenta, existe:
uma procedure Oracle;
uma API REST antiga;
um serviço SOAP;
uma fila JMS;
um arquivo CSV;
um job batch;
um mainframe;
uma stored procedure em SQL Server;
um endpoint interno;
uma integração via SFTP;
uma rotina manual parcialmente automatizada.
Ele precisa saber apenas:
qual ferramenta existe;
para que ela serve;
quais parâmetros recebe;
quais permissões exige;
qual formato retorna;
quais restrições possui;
em quais cenários pode ser usada;
quais riscos estão associados à sua execução.
Esse modelo cria uma separação saudável entre inteligência e execução.
O agente interpreta intenção, conduz a conversa, escolhe ferramentas adequadas e monta uma resposta compreensível para o usuário. Os MCP Servers expõem as ferramentas. Os microsserviços executam as integrações. O API Gateway controla acesso, políticas, autenticação e auditoria. O legado continua isolado.
Essa separação evita que a IA se torne um ponto de acesso perigoso para sistemas críticos.
Exemplo prático: consultando o status de uma nota fiscal
Imagine uma empresa com um sistema de faturamento antigo, rodando sobre Oracle, com procedures robustas e regras fiscais complexas. Esse sistema já opera há muitos anos e é essencial para o negócio. Reescrevê-lo do zero seria caro, arriscado e demorado.
O objetivo inicial não é substituir o faturamento. O objetivo é permitir que usuários consultem informações em linguagem natural por meio de um agente de IA.
O usuário pergunta no chat:
“Qual o status da NF 45721?”
O fluxo pode funcionar assim:
O agente interpreta a intenção do usuário.
Ele identifica que se trata de uma consulta de status de nota fiscal.
O agente verifica as ferramentas disponíveis no MCP Server.
Ele escolhe a ferramenta STATUS_NF.
O MCP Server aciona a API do microsserviço de faturamento.
O microsserviço valida permissões, parâmetros e contexto.
O microsserviço executa a procedure Oracle necessária.
O resultado do legado é convertido para um JSON padronizado.
O JSON retorna ao agente.
O agente transforma o retorno técnico em uma resposta natural.
A resposta ao usuário pode ser:
“NF 45721 emitida. O pedido está aguardando envio.”
O valor é imediato. O usuário não precisou acessar uma tela antiga, navegar por menus complexos ou pedir ajuda para alguém do time operacional. O agente traduziu uma intenção simples em uma consulta segura ao legado.
O legado não foi alterado. A operação não foi interrompida. A experiência do usuário melhorou.
O agente pode continuar o fluxo de trabalho
A integração não precisa parar na consulta.
Depois de responder sobre o status da nota fiscal, o agente pode continuar a interação:
“Precisa do DANFE em PDF?”
Se o usuário responder “sim”, um novo fluxo começa:
O agente interpreta a confirmação.
Ele escolhe a ferramenta GERAR_PDF_NF.
O MCP Server aciona a API do serviço de documentos.
O serviço de documentos valida autorização.
O serviço consulta ou aciona o legado conforme necessário.
O PDF é gerado ou recuperado.
Um link seguro é retornado.
O agente entrega o link no chat.
A resposta pode ser:
“O DANFE da NF 45721 está disponível neste link seguro para download.”
Essa continuidade é importante porque o agente deixa de ser apenas uma interface de pergunta e resposta. Ele passa a conduzir jornadas operacionais.
Em vez de o usuário abrir múltiplos sistemas, copiar informações, procurar documentos e acionar áreas diferentes, o agente orquestra o fluxo com base em ferramentas governadas.
Ainda assim, o controle continua preservado. O agente não inventa ações. Ele executa apenas o que está disponível no catálogo de ferramentas, dentro das permissões definidas.
O papel do MCP Server nessa arquitetura
O MCP Server funciona como uma camada de exposição padronizada de ferramentas para agentes de IA.
Ele organiza quais capacidades estão disponíveis, quais entradas são esperadas, quais saídas serão retornadas e quais regras precisam ser respeitadas.
Em um ambiente corporativo, o MCP Server pode expor ferramentas como:
consultar status de nota fiscal;
gerar PDF de documento fiscal;
consultar pedido;
verificar limite de crédito;
abrir chamado interno;
consultar estoque;
validar cliente;
consultar contrato;
buscar histórico de atendimento;
acionar workflow de aprovação;
consultar SLA;
recuperar documento;
iniciar processo de reembolso;
registrar ocorrência;
consultar fatura;
atualizar status de solicitação.
Cada ferramenta precisa ter um contrato claro.
Esse contrato deve definir:
nome da ferramenta;
descrição funcional;
parâmetros obrigatórios;
parâmetros opcionais;
formato de resposta;
permissões necessárias;
escopo de uso;
limites de execução;
riscos envolvidos;
necessidade de aprovação humana;
logs obrigatórios;
métricas coletadas;
dependências técnicas;
SLA esperado;
comportamento em caso de erro.
Sem esse nível de definição, o catálogo de ferramentas pode virar um conjunto perigoso de integrações improvisadas. Com contratos bem definidos, o MCP Server se torna uma camada de governança operacional para agentes corporativos.
O papel dos microsserviços de borda
Os microsserviços de borda são responsáveis por traduzir o mundo moderno para o mundo legado.
Eles recebem chamadas vindas das APIs, aplicam validações, acessam sistemas internos e retornam dados em formatos padronizados.
Esses microsserviços podem executar funções como:
validar parâmetros de entrada;
verificar permissões do usuário;
consultar dados no legado;
executar procedures;
chamar serviços SOAP;
publicar mensagens em filas;
acionar workers;
normalizar respostas;
mascarar dados sensíveis;
enriquecer informações;
tratar erros;
registrar logs;
enviar métricas;
aplicar regras de negócio complementares.
A principal vantagem é o encapsulamento.
O agente não conhece detalhes do legado. O MCP Server não precisa conhecer a implementação interna. O API Gateway não executa lógica de negócio. O microsserviço de borda concentra a tradução técnica e o controle transacional.
Esse desenho reduz acoplamento e facilita evolução.
Com o tempo, partes do legado podem ser substituídas por novos serviços. Desde que o contrato externo seja preservado, o agente e as ferramentas não precisam mudar drasticamente.
Esse é o caminho da modernização contínua.
API Gateway: o ponto de controle corporativo
Nenhuma integração séria entre agentes de IA e legado deveria acontecer sem uma camada forte de API Gateway.
O API Gateway atua como porta de entrada controlada para os serviços corporativos. Ele aplica políticas de acesso, autenticação, autorização, limitação de chamadas, inspeção de tráfego, auditoria, roteamento e proteção.
Em uma arquitetura com agentes de IA, essa camada se torna ainda mais importante.
O Gateway pode controlar:
quais usuários podem acessar determinada API;
quais agentes podem chamar determinada ferramenta;
quais sistemas podem consumir cada endpoint;
limites de chamadas por minuto;
políticas por ambiente;
autenticação via OAuth2, JWT, mTLS ou outro padrão corporativo;
validação de payload;
bloqueio de chamadas suspeitas;
roteamento para versões específicas;
coleta de métricas;
integração com SIEM;
auditoria de chamadas.
Esse controle impede que o agente se torne um atalho inseguro para o legado.
A regra de ouro é simples:
O agente nunca fala diretamente com o banco, com o mainframe, com o SOAP interno ou com o sistema legado. Ele passa por camadas controladas.
Essa regra reduz risco, melhora rastreabilidade e permite que a empresa escale o uso de IA com mais segurança.
Lidando com integrações frágeis
Sistemas legados frequentemente possuem integrações sensíveis. Algumas operações são lentas. Outras falham de forma intermitente. Algumas dependem de janelas de processamento. Outras exigem arquivos, rotinas batch ou sistemas externos com disponibilidade irregular.
Nesses casos, tentar transformar tudo em chamadas síncronas pode gerar instabilidade.
Imagine que o agente precise solicitar a geração de um documento, atualizar um status, iniciar um processo interno ou acionar uma rotina pesada no legado. Se tudo depender de resposta imediata, o usuário pode ficar esperando, a chamada pode expirar e o sistema pode ficar mais frágil.
A solução é introduzir um message broker, como Kafka ou RabbitMQ, para criar fluxos assíncronos mais resilientes.
Nesse modelo:
O agente solicita uma ação.
O MCP Server chama uma API.
O microsserviço valida a requisição.
O microsserviço publica uma mensagem em uma fila ou tópico.
Um worker especializado consome a mensagem.
O worker se comunica com o legado.
O resultado é registrado.
O agente pode consultar o status ou receber uma notificação quando a ação for concluída.
Esse desenho traz vantagens importantes:
desacoplamento entre agente e legado;
maior resiliência;
retry automático;
controle de falhas;
processamento em segundo plano;
redução de timeouts;
melhor absorção de picos;
rastreabilidade por evento;
possibilidade de reprocessamento;
menor impacto sobre sistemas antigos.
O usuário pode receber uma resposta como:
“Solicitação registrada. A geração do documento está em processamento. Avisarei quando estiver disponível.”
Para operações críticas, esse comportamento é muito mais seguro do que forçar uma resposta síncrona a qualquer custo.
Quando usar Kafka e quando usar RabbitMQ
Kafka e RabbitMQ podem apoiar a integração com legados, mas têm características diferentes.
RabbitMQ costuma ser uma boa escolha para filas de trabalho, distribuição de tarefas, processamento assíncrono e cenários em que mensagens precisam ser consumidas por workers específicos. É bastante útil para comandos operacionais, como gerar documento, processar solicitação, enviar arquivo ou executar uma rotina.
Kafka costuma ser mais adequado para arquiteturas orientadas a eventos, streaming de dados, alto volume, retenção de eventos, integração entre múltiplos consumidores e construção de uma base de eventos corporativos. É muito útil quando a empresa quer registrar acontecimentos relevantes do negócio e permitir que diferentes sistemas reajam a esses eventos.
Em uma arquitetura agêntica corporativa, Kafka pode ser usado para expor eventos como:
nota fiscal emitida;
pedido aprovado;
pagamento confirmado;
risco detectado;
cliente atualizado;
estoque crítico;
falha operacional;
contrato vencendo;
anomalia identificada;
SLA próximo do limite.
Agentes de IA podem consumir ou reagir a esses eventos, desde que exista uma camada de governança definindo o que eles podem fazer com cada sinal.
Por exemplo, um agente pode detectar que um pedido importante está parado por falha em uma integração e sugerir uma ação. Em outro cenário, pode abrir um chamado automaticamente. Em fluxos de maior risco, pode solicitar aprovação humana antes de executar qualquer medida.
A escolha entre Kafka e RabbitMQ depende do tipo de fluxo, volume, criticidade, necessidade de retenção, número de consumidores e modelo operacional da empresa.
Segurança: a regra de ouro da integração com IA
A integração entre agentes de IA e legado deve começar pela segurança, não pela interface conversacional.
Um agente que acessa sistemas corporativos precisa operar dentro de limites rigorosos. Ele não pode ter permissão genérica. Ele não pode herdar privilégios amplos. Ele não pode executar ações sem rastreabilidade. Ele não pode acessar dados sensíveis sem justificativa e controle.
Algumas práticas são essenciais:
1. Least privilege
Cada agente deve ter apenas as permissões necessárias para executar sua função.
Um agente de atendimento interno, por exemplo, talvez possa consultar status de pedidos, mas não alterar condições comerciais. Um agente financeiro talvez possa consultar faturas, mas não aprovar pagamentos. Um agente de suporte técnico talvez possa abrir chamados, mas não reiniciar serviços críticos sem aprovação.
2. Autenticação forte
Toda chamada deve estar associada a uma identidade. Isso inclui identidade do usuário, do agente, da aplicação e do serviço.
A empresa precisa saber quem solicitou, qual agente executou, qual ferramenta foi usada e qual sistema foi acionado.
3. Autorização contextual
Não basta saber se o usuário está autenticado. É preciso verificar se ele pode executar aquela ação naquele contexto.
Por exemplo, um gerente regional pode consultar dados de sua região, mas não de toda a empresa. Um analista pode consultar notas fiscais, mas não gerar segunda via para clientes fora de sua carteira.
4. Auditoria ponta a ponta
Cada execução precisa gerar trilha auditável:
usuário solicitante;
agente envolvido;
ferramenta chamada;
parâmetros recebidos;
API acionada;
microsserviço responsável;
sistema legado acessado;
horário;
resultado;
falhas;
aprovações;
dados retornados.
Essa trilha é indispensável para compliance, investigação de incidentes e melhoria contínua.
5. Mascaramento de dados sensíveis
O agente não precisa receber todos os dados retornados pelo legado. Muitas vezes, apenas parte da informação é necessária.
Dados pessoais, documentos, valores sensíveis, informações financeiras e registros protegidos devem ser mascarados ou filtrados conforme o perfil do usuário.
6. Aprovação humana para ações críticas
Nem toda ação deve ser automatizada.
Operações como cancelar pedido, liberar crédito, alterar dados cadastrais, aprovar pagamento, executar ajuste fiscal ou modificar contrato podem exigir aprovação humana.
Nesse caso, o agente prepara a ação, apresenta evidências e solicita aprovação. A execução só acontece após validação de uma pessoa autorizada.
Governança de ferramentas: o catálogo que dá escala
À medida que a empresa cria mais integrações, o número de ferramentas disponíveis para agentes tende a crescer. Sem organização, o ambiente pode ficar caótico.
Por isso, é essencial criar um catálogo corporativo de ferramentas.
Esse catálogo deve registrar:
nome da ferramenta;
domínio de negócio;
responsável técnico;
responsável funcional;
descrição;
versão;
ambiente;
status;
APIs relacionadas;
sistemas legados envolvidos;
nível de risco;
permissões exigidas;
exemplos de uso;
limites operacionais;
dependências;
métricas;
logs;
política de retenção;
histórico de mudanças.
Esse catálogo evita duplicidade, facilita reuso e permite governança distribuída.
Em vez de cada time criar suas próprias integrações de forma isolada, a empresa passa a operar uma plataforma de ferramentas corporativas para agentes de IA.
Esse é um passo importante para transformar iniciativas pontuais em infraestrutura agêntica sustentável.
Classificação de risco para agentes e ferramentas
Nem todo agente tem o mesmo risco. Nem toda ferramenta exige o mesmo nível de controle.
Uma ferramenta que consulta o status de uma nota fiscal possui risco menor do que uma ferramenta que cancela uma nota fiscal. Uma consulta de catálogo possui risco menor do que uma atualização cadastral. Uma recomendação interna possui risco menor do que uma decisão automatizada com impacto financeiro.
A empresa pode classificar ferramentas e agentes por níveis de risco.
Um modelo prático pode considerar:
sensibilidade dos dados;
impacto da ação;
reversibilidade;
criticidade do processo;
exigência regulatória;
necessidade de aprovação;
exposição externa;
volume de uso;
impacto em caso de erro;
dependência de sistemas críticos;
grau de autonomia do agente.
Exemplo de classificação:
Risco baixo
Consultas simples, dados não sensíveis, ações sem impacto operacional direto.
Exemplo: consultar status público de solicitação interna.
Risco moderado
Consultas com dados internos, ações reversíveis ou solicitações operacionais de baixo impacto.
Exemplo: gerar segunda via de documento já autorizado.
Risco alto
Ações que alteram dados, acionam processos críticos ou envolvem informações sensíveis.
Exemplo: alterar cadastro financeiro de cliente.
Risco crítico
Decisões com impacto financeiro, legal, regulatório ou operacional relevante.
Exemplo: aprovar crédito, cancelar contrato, bloquear transação ou liberar pagamento.
Quanto maior o risco, mais forte deve ser a governança: aprovação humana, logs detalhados, testes específicos, limites de execução, monitoramento ativo e mecanismos de interrupção.
Observabilidade: sem visibilidade, não existe confiança
Agentes integrados ao legado precisam ser observáveis.
A empresa deve conseguir acompanhar o que está acontecendo em produção, identificar falhas, medir qualidade, entender comportamento e agir rapidamente em caso de desvio.
A observabilidade deve cobrir:
chamadas ao MCP Server;
uso de ferramentas;
latência por ferramenta;
erros por API;
falhas de autenticação;
rejeições por autorização;
chamadas ao legado;
eventos publicados;
retries;
tempo de processamento;
custo por interação;
volume por usuário;
taxa de sucesso;
taxa de fallback;
uso de aprovação humana;
incidentes;
respostas incompletas;
comportamento inesperado do agente.
Além da observabilidade técnica, é necessário observar o comportamento do agente.
Isso inclui:
ele escolheu a ferramenta correta?
interpretou corretamente a intenção?
respeitou o escopo?
pediu aprovação quando necessário?
apresentou a resposta com clareza?
omitiu informações sensíveis?
evitou executar ação indevida?
explicou limitações quando o dado não estava disponível?
Agentes de IA em produção precisam ser tratados como sistemas críticos. Sem métricas, logs e rastreabilidade, a empresa opera no escuro.
Testes e validação antes de produção
A integração com legado exige uma estratégia de testes mais ampla do que a usada em APIs tradicionais.
Além de testes unitários e de integração, é necessário validar comportamento do agente, escolha de ferramentas, respostas, limites de autonomia e cenários ambíguos.
A esteira de validação deve incluir:
testes de contrato das ferramentas;
testes de autenticação;
testes de autorização;
testes de dados sensíveis;
testes de carga;
testes de fallback;
testes de timeout;
testes de retry;
testes de idempotência;
testes de comportamento do agente;
testes de prompt injection;
testes de uso indevido de ferramentas;
testes com dados sintéticos;
testes de regressão;
avaliação humana em fluxos críticos.
Um agente pode funcionar bem em uma demonstração e falhar em produção quando recebe perguntas ambíguas, dados incompletos ou solicitações fora de escopo.
Exemplo:
“Cancela essa nota aí.”
Essa frase é perigosa. Qual nota? Quem pediu? O usuário tem permissão? O cancelamento ainda é permitido fiscalmente? A operação exige justificativa? Existe aprovação necessária?
Um agente bem governado não deve executar. Ele deve pedir contexto, verificar permissão, consultar regras e, se aplicável, acionar aprovação humana.
Idempotência: essencial para operações com legado
Em integrações com sistemas legados, falhas parciais são comuns.
Uma chamada pode expirar, mas a operação pode ter sido executada. Uma mensagem pode ser processada duas vezes. Um worker pode falhar após acionar o legado, mas antes de registrar sucesso.
Por isso, operações críticas precisam ser idempotentes sempre que possível.
Idempotência significa que repetir a mesma solicitação não deve gerar efeito duplicado.
Por exemplo, se o usuário pede a geração de um PDF de nota fiscal e a chamada é repetida, o sistema não deve criar documentos duplicados desnecessariamente. Ele pode retornar o documento já gerado.
Para isso, a arquitetura pode usar:
correlation ID;
request ID;
chaves de idempotência;
tabela de controle;
estado de processamento;
deduplicação de mensagens;
logs transacionais;
outbox pattern;
saga pattern em fluxos distribuídos.
Esses mecanismos são especialmente importantes quando agentes de IA acionam processos operacionais. A conversa pode parecer simples, mas a execução por trás pode envolver múltiplos sistemas.
Tratamento de erro: o agente precisa saber lidar com limites
Nem sempre o legado estará disponível. Nem toda consulta retornará dados. Nem toda ação poderá ser executada.
Um agente corporativo precisa lidar com falhas de forma transparente e útil.
Exemplos de respostas adequadas:
“Não consegui consultar o status da NF agora porque o serviço de faturamento está indisponível. Posso tentar novamente em alguns minutos ou abrir um chamado para acompanhamento.”
“Encontrei a nota fiscal, mas seu perfil não tem permissão para acessar o DANFE. Posso orientar você sobre quem pode liberar esse acesso.”
“A solicitação foi registrada, mas a geração do PDF ainda está em processamento. O protocolo é DOC-89321.”
O pior comportamento é o agente inventar uma resposta ou esconder a falha.
Para evitar isso, os contratos das ferramentas devem prever códigos de erro claros, mensagens controladas e status operacionais padronizados.
O agente deve saber diferenciar:
dado inexistente;
permissão negada;
sistema indisponível;
timeout;
erro de validação;
regra de negócio impeditiva;
operação em processamento;
ação dependente de aprovação;
falha inesperada.
Essa diferenciação melhora a experiência do usuário e reduz risco operacional.
Modernização incremental: valor agora, evolução contínua
A grande vantagem dessa abordagem é permitir modernização incremental.
A empresa não precisa esperar anos até substituir o legado. Ela pode começar criando uma camada de integração para casos de uso de alto valor e baixo risco.
Um caminho possível:
Fase 1: Consultas assistidas
O agente responde perguntas sobre dados já disponíveis no legado.
Exemplos:
status de nota fiscal;
status de pedido;
dados de cliente;
histórico de atendimento;
saldo de contrato;
disponibilidade de estoque;
andamento de solicitação.
Essa fase gera valor rápido e risco controlado.
Fase 2: Geração de documentos e solicitações
O agente passa a acionar serviços que geram documentos, criam protocolos ou iniciam fluxos.
Exemplos:
gerar DANFE;
emitir segunda via;
abrir chamado;
solicitar análise;
registrar ocorrência;
enviar comprovante;
iniciar workflow interno.
Aqui, a arquitetura já exige mais controle, logs e tratamento assíncrono.
Fase 3: Ações operacionais com aprovação
O agente prepara ações, mas depende de aprovação humana para executar.
Exemplos:
cancelar documento;
alterar dados;
aprovar exceção;
liberar fluxo;
corrigir inconsistência;
acionar rotina crítica.
Essa fase aumenta a capacidade operacional sem remover a responsabilidade humana.
Fase 4: Agentes orientados a eventos
O agente passa a reagir a eventos do negócio.
Exemplos:
detectar pedidos travados;
identificar falhas recorrentes;
sugerir ações de correção;
alertar sobre SLAs;
priorizar exceções;
abrir incidentes automaticamente.
Aqui, a empresa começa a operar em uma lógica mais próxima de arquitetura agêntica em tempo real.
Fase 5: Evolução do legado por domínio
Com o uso da camada de borda, a empresa identifica quais partes do legado geram mais demanda, mais falhas ou mais custo. Essas partes podem ser priorizadas para refatoração, extração de domínio ou substituição gradual.
A modernização deixa de ser uma aposta genérica e passa a ser guiada por dados reais de uso.
Arquitetura de referência para integrar legado com agentes de IA
Uma arquitetura corporativa para esse cenário pode ser organizada em camadas.
1. Camada de experiência
É onde o usuário interage.
Pode ser:
chat corporativo;
portal interno;
Microsoft Teams;
Slack;
aplicativo web;
aplicativo móvel;
interface de atendimento;
painel operacional.
Essa camada coleta a intenção do usuário e apresenta a resposta.
2. Camada do agente
É onde o agente interpreta a solicitação, conversa com o usuário, escolhe ferramentas, solicita contexto adicional e monta a resposta final.
Essa camada deve respeitar:
escopo do agente;
políticas de uso;
limites de autonomia;
perfil do usuário;
contexto da sessão;
regras de segurança.
3. Camada MCP
É onde ficam os MCP Servers e o catálogo de ferramentas.
Essa camada expõe capacidades do negócio de forma padronizada e controlada.
4. Camada de API Gateway
É a porta de controle das APIs.
Aplica autenticação, autorização, rate limiting, auditoria, roteamento e políticas corporativas.
5. Camada de microsserviços de borda
É a camada que traduz chamadas modernas para integrações com o legado.
Aqui ficam adaptadores, validações, normalização de dados, controle transacional e regras complementares.
6. Camada assíncrona
É onde Kafka, RabbitMQ ou outra tecnologia de mensageria apoia fluxos resilientes.
Essa camada é essencial para processamento demorado, integração frágil, eventos de negócio e desacoplamento.
7. Camada legado
É onde estão sistemas existentes:
monólitos;
bancos de dados;
procedures;
SOAP;
mainframe;
arquivos;
filas antigas;
jobs batch;
sistemas on-premise.
O legado fica protegido. Ele não conversa diretamente com agentes.
8. Camada de governança e observabilidade
Essa camada atravessa toda a arquitetura.
Inclui:
logs;
métricas;
traces;
auditoria;
SIEM;
catálogo;
políticas;
avaliação contínua;
controle de custos;
trilhas de decisão;
gestão de risco;
aprovação humana.
Essa arquitetura não serve apenas para “conectar IA ao legado”. Ela cria uma base de operação moderna, auditável e evolutiva.
Exemplo de fluxo completo em linguagem técnica
A seguir, um fluxo mais detalhado para o caso da NF 45721.
Solicitação inicial
Usuário:
“Qual o status da NF 45721?”
Interpretação do agente
O agente identifica:
intenção: consultar status de nota fiscal;
entidade: NF;
identificador: 45721;
ação: consulta;
risco: baixo ou moderado, dependendo dos dados retornados;
ferramenta candidata: STATUS_NF.
Chamada da ferramenta
O agente aciona o MCP Server com os parâmetros necessários.
Validação pelo MCP Server
O MCP Server verifica:
se a ferramenta existe;
se o agente pode usá-la;
se o usuário tem permissão;
se os parâmetros estão completos;
se a chamada respeita o contrato.
Chamada à API
O MCP Server chama a API correspondente, protegida pelo Gateway.
Controle no API Gateway
O Gateway aplica:
autenticação;
autorização;
rate limiting;
validação de token;
registro de auditoria;
roteamento para o serviço correto.
Execução pelo microsserviço
O microsserviço de faturamento:
valida o número da nota;
verifica o contexto do usuário;
consulta a procedure Oracle;
trata erros;
normaliza a resposta;
mascara dados sensíveis, se necessário;
retorna JSON.
Resposta ao agente
O agente recebe uma resposta estruturada.
Resposta ao usuário
O agente responde:
“NF 45721 emitida. O pedido está aguardando envio.”
Continuação do fluxo
Agente:
“Precisa do DANFE em PDF?”
Usuário:
“Sim.”
O agente aciona GERAR_PDF_NF.
O serviço de documentos retorna o link seguro.
Agente:
“O DANFE da NF 45721 está disponível para download neste link.”
Esse fluxo parece simples para o usuário. Essa simplicidade é resultado de uma arquitetura bem desenhada.
O que não fazer
A pressa para colocar IA em produção pode levar a atalhos perigosos.
Alguns erros devem ser evitados:
1. Dar acesso direto ao banco de dados
Agentes não devem consultar tabelas críticas sem mediação. Além de risco de segurança, isso expõe estruturas internas, ignora regras de negócio e dificulta auditoria.
2. Expor procedures diretamente como ferramentas
Uma procedure pode ter parâmetros complexos, efeitos colaterais e regras implícitas. Ela deve ser encapsulada por um serviço, não exposta diretamente ao agente.
3. Criar ferramentas sem contrato
Ferramentas mal descritas aumentam o risco de uso incorreto. Todo recurso exposto ao agente precisa de contrato claro.
4. Ignorar autorização por usuário
Não basta o agente poder chamar uma ferramenta. O usuário por trás da solicitação também precisa ter permissão.
5. Automatizar ações críticas sem aprovação
Agentes podem preparar, sugerir e orquestrar. A execução automática de ações críticas exige maturidade, testes, governança e, muitas vezes, aprovação humana.
6. Não registrar logs completos
Sem logs, a empresa não consegue explicar o que aconteceu. Em ambientes regulados, isso inviabiliza produção.
7. Começar por um caso de uso de alto risco
A melhor estratégia é começar por consultas e jornadas de baixo risco, aprender com o uso real e evoluir gradualmente.
Como escolher o primeiro caso de uso
A escolha do primeiro caso de uso é decisiva.
Um bom piloto deve combinar valor de negócio, viabilidade técnica e risco controlado.
Critérios úteis:
alto volume de solicitações repetitivas;
dependência de telas legadas;
baixo risco operacional;
dados disponíveis;
regras relativamente claras;
dor reconhecida pelos usuários;
ganho perceptível rápido;
integração viável;
facilidade de medir resultado.
Bons candidatos costumam estar em áreas como:
atendimento interno;
faturamento;
financeiro;
operações;
logística;
compras;
suporte de TI;
backoffice;
gestão de pedidos;
consulta documental.
Exemplos de bons primeiros casos:
consultar status de pedido;
consultar status de NF;
recuperar segunda via de documento;
consultar posição de atendimento;
buscar informações contratuais;
consultar SLA;
abrir solicitação interna;
responder dúvidas sobre processos internos;
consolidar informações espalhadas em sistemas diferentes.
O primeiro projeto deve provar a arquitetura, não tentar resolver todos os problemas da empresa.
Roadmap prático de implantação
Um roadmap seguro pode ser dividido em etapas.
1. Assessment do legado
Mapear:
sistemas envolvidos;
integrações existentes;
bancos de dados;
APIs disponíveis;
rotinas críticas;
dependências;
restrições;
riscos;
donos funcionais;
responsáveis técnicos;
incidentes conhecidos.
O objetivo é entender o cenário antes de expor qualquer capacidade para agentes.
2. Priorização de casos de uso
Selecionar casos com base em:
valor para o negócio;
frequência de uso;
impacto operacional;
risco;
complexidade;
dependência técnica;
potencial de reuso.
3. Desenho da arquitetura-alvo
Definir:
canais de acesso;
agentes envolvidos;
MCP Servers;
ferramentas;
APIs;
microsserviços;
integrações com legado;
mensageria;
segurança;
observabilidade;
governança.
4. Definição dos contratos
Criar contratos para:
ferramentas MCP;
APIs;
eventos;
mensagens;
formatos de resposta;
erros;
permissões;
logs.
5. Implementação do piloto
Construir um fluxo real, de ponta a ponta, com escopo controlado.
6. Testes e validação
Validar:
comportamento do agente;
segurança;
autorização;
integração;
falhas;
carga;
respostas;
logs;
aprovação humana, quando necessário.
7. Rollout controlado
Publicar para um grupo restrito de usuários.
Acompanhar métricas, coletar feedback e ajustar.
8. Expansão por domínio
Após validar a arquitetura, expandir para novos fluxos do mesmo domínio ou para domínios relacionados.
9. Evolução contínua
Usar dados de uso, falhas e valor gerado para orientar a modernização gradual do legado.
Métricas para avaliar resultado
A integração de agentes com legado deve ser medida por resultados concretos.
Algumas métricas úteis:
redução de tempo para obter informação;
redução de chamados repetitivos;
volume de consultas atendidas pelo agente;
taxa de sucesso por ferramenta;
tempo médio de resposta;
redução de acessos a telas antigas;
taxa de fallback para atendimento humano;
número de documentos gerados;
redução de erros operacionais;
satisfação dos usuários;
incidentes evitados;
tempo economizado por área;
custo por interação;
estabilidade das integrações;
adoção por domínio;
quantidade de ferramentas reutilizadas.
Essas métricas ajudam a justificar expansão, priorizar melhorias e demonstrar valor para liderança.
Por que essa abordagem reduz risco
A modernização tradicional muitas vezes começa com grandes programas, orçamentos elevados, longos ciclos de análise e alto risco de interrupção. Em muitos casos, a empresa só percebe valor depois de meses ou anos.
A abordagem com camada de borda e agentes de IA muda a lógica.
Ela permite:
preservar o legado;
reduzir interferência em sistemas críticos;
criar valor em semanas, não anos;
expor capacidades por APIs;
medir uso real;
melhorar experiência do usuário;
evoluir por domínio;
substituir partes do legado gradualmente;
manter governança;
criar rastreabilidade;
reduzir dependência de conhecimento informal.
O legado continua existindo, mas deixa de ser uma barreira absoluta para inovação.
A empresa cria uma ponte entre o que já funciona e o que precisa evoluir.
O papel da arquitetura agêntica na modernização
Quando agentes de IA passam a operar sobre ferramentas corporativas, APIs governadas, eventos e microsserviços, a empresa começa a formar uma arquitetura agêntica.
Essa arquitetura não se resume a colocar um chatbot na frente do legado. O valor real está em transformar capacidades corporativas em ferramentas reutilizáveis, seguras e observáveis.
Com o tempo, diferentes agentes podem usar as mesmas ferramentas.
Um agente de atendimento pode consultar pedidos. Um agente financeiro pode consultar faturamento. Um agente de operações pode acompanhar eventos logísticos. Um agente de TI pode monitorar incidentes. Um agente executivo pode consolidar informações de múltiplos domínios.
Todos operam sobre uma base comum:
catálogo de ferramentas;
APIs governadas;
microsserviços de borda;
eventos;
políticas;
trilhas de auditoria;
observabilidade;
segurança.
Essa base é o que permite escala.
Sem ela, cada agente vira uma integração isolada. Com ela, a empresa cria infraestrutura para IA corporativa.
Agentes de IA não substituem a arquitetura
Um ponto importante precisa ser reforçado: agentes de IA não eliminam a necessidade de arquitetura. Eles aumentam a importância dela.
Quanto mais autonomia um agente possui, mais necessários se tornam:
limites claros;
contratos;
permissões;
observabilidade;
governança;
testes;
auditoria;
versionamento;
segurança;
rollback;
aprovação humana;
controle de custo;
avaliação contínua.
IA sem arquitetura vira improviso. Arquitetura sem IA pode continuar lenta. A combinação correta permite gerar valor com controle.
O objetivo não é deixar o agente “fazer qualquer coisa”. O objetivo é permitir que ele execute tarefas úteis dentro de um ambiente seguro, governado e rastreável.
Conclusão: o futuro do legado é a integração inteligente
Sistemas legados não precisam ser tratados como obstáculos absolutos à inovação. Em muitas empresas, eles ainda são o coração da operação. Substituí-los de forma apressada pode gerar mais risco do que valor.
O caminho mais seguro é criar uma camada moderna ao redor do legado. Com Anti-Corruption Layer, APIs, microsserviços de borda, MCP Servers, catálogo de ferramentas, mensageria, observabilidade e governança, a empresa consegue integrar agentes de IA aos sistemas existentes sem expor diretamente o ambiente crítico.
O resultado é uma modernização incremental, pragmática e orientada a valor.
Usuários passam a interagir com sistemas antigos de forma natural. Processos repetitivos ganham fluidez. Consultas deixam de depender de telas complexas. Documentos podem ser gerados por conversa. Fluxos podem ser iniciados com segurança. Eventos do negócio podem acionar agentes. A operação se torna mais inteligente sem exigir uma ruptura imediata.
A grande mudança está na forma de pensar o legado.
Ele não precisa ser descartado para que a empresa avance. Ele precisa ser protegido, encapsulado e exposto por capacidades modernas.
Essa é a base para colocar agentes de IA no centro da operação sem comprometer aquilo que mantém o negócio funcionando.
A modernização mais madura não começa destruindo o passado. Ela cria uma ponte segura entre o legado que sustenta a empresa e a arquitetura agêntica que permitirá sua próxima fase de crescimento.
Aproveita pra assisitir nosso video falando sobre este assunto:
Se você precisar de ajuda em seus projetos, mande um e-mail pra gente.
Comentários