Integração de sistemas legados: por que o dado — não o modelo — trava seu projeto de IA
O sucesso da IA depende de entregar o dado certo ao processo, mesmo quando ele está preso em sistemas legados.
Conheça o Orcheon.
Por Gustavo Valadares, Vorch · LinkedIn · Atualizado em agosto de 2026
Fluxos, agentes e protocolos como o MCP evoluíram rápido. Mas há um limite que nenhum deles remove sozinho: o dado que continua preso em sistemas que não o entregam.
O maior limitador de um projeto de IA raramente é o modelo — é o dado. De nada adianta fluxos sofisticados e agentes conectados por protocolos como o MCP se os sistemas onde a informação vive não a expõem de forma acessível. Em processos críticos, o acesso ao dado no legado costuma ser o verdadeiro gargalo.
Por que o dado é o gargalo — e não o modelo
Os últimos avanços da IA aplicada ao negócio deslocaram o gargalo. Modelos ficaram acessíveis, fluxos ficaram sofisticados e protocolos como o MCP passaram a conectar agentes a ferramentas e fontes com poucas linhas. O efeito colateral é que a parte difícil migrou de lugar: não é mais “como o agente raciocina”, e sim “a que dado ele consegue chegar”. Um fluxo bem desenhado que não alcança o dado certo entrega uma decisão pela metade.
Mesmo com orquestração de IA madura, o resultado é limitado pela informação que o fluxo consegue tocar. A inteligência da automação não compensa a ausência do dado — ela apenas expõe a lacuna mais rápido, e de forma mais cara.
Na prática, em toda operação enterprise a integração e o acesso ao dado estão entre os maiores obstáculos para colocar IA para trabalhar — mais do que a escolha do modelo. E essa barreira tem um nome concreto: o sistema onde o dado mora não foi feito para entregá-lo.
Nem todo sistema expõe seus dados via API REST
A suposição silenciosa de muitos projetos é que todo sistema oferece uma API REST limpa, documentada e pronta para uso. Na realidade de uma operação enterprise — especialmente em setores regulados — o acesso ao dado assume formas bem mais ásperas:
· Sistemas sem API. Core bancário, ERPs antigos e mainframes que nunca foram pensados para expor dados a terceiros.
· APIs parciais. Existe uma API, mas ela cobre só uma fatia do dado — ou não expõe justamente o campo de que o processo precisa.
· Dados presos em telas e relatórios. A informação existe, mas só aparece numa interface, num PDF ou num relatório — nunca num endpoint.
· Integrações em lote. O dado só circula em arquivos batch noturnos, com uma latência que não serve a um processo em tempo real.
· Bancos de dados fechados. O acesso direto ao banco é bloqueado por política de segurança — e com razão, em ambiente regulado.
· Formatos não estruturados. Contratos, e-mails e documentos digitalizados: dado que existe, mas não em formato consultável.
Cada uma dessas formas é um ponto onde um projeto de IA trava — não por falta de modelo, mas por falta de acesso.
Como resolver: uma camada de conectividade, não um novo ETL
A resposta não é copiar todo o dado para um data lake antes de começar — isso recria o problema clássico do ETL: caro, lento e desatualizado no dia seguinte. A saída é uma camada de conectividade que encontra o dado onde ele já está, na forma que ele já tem, e o entrega ao processo sob demanda.
1. Conectar pelo caminho que existe. APIs REST e webhooks quando há; adaptadores especializados quando o sistema é legado e não expõe endpoint.
2. Ler o dado não-estruturado. Extrair informação de documentos, telas e relatórios com agentes de IA, quando não existe uma via estruturada.
3. Unificar em contexto, sem ETL. Consolidar o que vem de cada fonte numa memória contextual em grafo — atores, eventos e relações do processo —, em vez de uma cópia bruta num warehouse.
4. Servir o dado ao processo. O fluxo puxa, a cada passo, apenas o dado de que aquele passo precisa — não tudo, o tempo todo.
É a mesma lógica que permite integrar sistemas legados sem ETL: em vez de mover e duplicar o dado, dá-se contexto a ele onde ele está.
Dois caminhos: quando há API e quando não há
Na prática, todo sistema-fonte cai em um de dois caminhos — e a plataforma precisa dar conta dos dois.
Quando já há API. Se o sistema expõe uma API REST, conectá-lo é questão de configuração, não de desenvolvimento. A plataforma consome a fonte em poucos cliques, sem escrever código e sem abrir um projeto de integração — quem liga o sistema ao processo é o próprio time de negócio. É o caminho rápido: a fonte entra no fluxo praticamente no mesmo dia.
Quando não há API. Se o sistema não expõe nada, o caminho é construir o acesso — e é aqui que o serviço entra. A Vorch atua de forma consultiva para abrir a fonte com segurança: adaptadores para o legado, extração assistida por IA de telas e documentos, e o desenho da ponte entre o sistema e o processo. É trabalho especializado, e é onde a experiência em processos críticos regulados pesa — a integração se faz uma vez e passa a servir o processo continuamente.
O dado certo, na hora certa — o papel do processo
Aqui entra a diferença de uma abordagem process-first. Quando o fluxo comanda a execução, ele sabe exatamente qual dado é necessário em cada etapa — e busca só aquele. Isso muda a natureza da integração: em vez de um projeto de dados gigante que precisa terminar antes de a IA começar, a conectividade cresce processo a processo, guiada pelo que cada passo exige. O acesso ao dado deixa de ser um pré-requisito monolítico e passa a fazer parte do próprio processo — governado e auditável, com trilha de rastreabilidade de cada consulta a cada sistema.
O que a área de TI precisa repensar agora
A virada não é só de quem opera o processo — é de quem cuida dos sistemas. Para a área de TI, a pergunta deixou de ser “temos os dados?” e passou a ser “conseguimos entregá-los, de forma segura e no momento certo, a um processo que os consome?”. Preparar-se para IA, hoje, é em boa parte preparar o acesso ao dado.
Na prática, alguns movimentos ajudam a chegar pronto:
· Mapear onde o dado crítico vive. Saber quais sistemas guardam o dado de cada processo — e como, ou se, ele é exposto hoje.
· Preferir API a raspagem de tela. Um endpoint governado é mais seguro, estável e auditável do que extrair da interface; onde faltar API, planejar como abri-la.
· Tratar acesso ao dado como produto. Documentado, versionado, com controle de acesso por papel e trilha de auditoria — não um favor pontual entre equipes.
· Definir a política de segurança antes de abrir a fonte. Quem lê o quê, com qual credencial e com qual rastro — decidido antes, não depois.
A conta é simples: se o processo não bebe do dado certo na hora certa, ele opera sem contexto. E um agente sem contexto é o pior dos mundos — você paga os tokens do melhor modelo disponível e não recebe o retorno, porque a decisão nasce cega. Contexto não é detalhe de infraestrutura: é o que transforma token gasto em resultado útil.
Perguntas frequentes
O MCP resolve o problema de acesso a dados?
Protocolos como o MCP padronizam como um agente conversa com ferramentas e fontes, o que reduz o atrito de conexão. Mas o MCP não cria acesso onde ele não existe: se o sistema-fonte não expõe o dado, não há o que consumir. O MCP é a tomada — ainda é preciso haver energia do outro lado.
Preciso de um data warehouse pronto antes de usar IA num processo?
Não necessariamente. Montar um warehouse completo antes de começar recria o custo e a lentidão do ETL. Uma abordagem por processo conecta apenas as fontes que aquele processo usa e unifica o contexto conforme avança — entregando valor sem esperar um projeto de dados inteiro terminar.
E se o meu sistema não tem API?
A ausência de API não impede a integração. Adaptadores especializados, leitura de telas e extração de documentos com IA permitem acessar o dado mesmo quando não há endpoint — respeitando as políticas de segurança do ambiente.
Isso é um projeto de ETL?
Não. ETL move e copia o dado para outro lugar antes de usá-lo. A proposta aqui é dar contexto ao dado onde ele está, consolidando atores e relações numa memória em grafo — sem a cópia bruta e a defasagem típicas do ETL.
Quanto tempo leva integrar um sistema legado?
Varia conforme o tipo de acesso disponível: conexões via API são rápidas, enquanto legados sem endpoint exigem adaptadores ou extração assistida por IA. O ponto prático é que a integração acompanha o processo — não precisa estar 100% concluída para o primeiro processo entrar em produção.
Sobre o autor
Co-fundador da Vorch, empresa por trás do Orcheon — plataforma de automação agêntica process-first para processos críticos. Com mais de 20 anos no setor de tecnologia e forte atuação em transformação digital no mercado financeiro, é especialista em desenvolvimento de produtos e Product Market Fit. Ocupou posições de liderança na Sinqia, SAP, Datasul-Totvs e Infor, e é co-fundador da Simply e do Grupo Mult, onde liderou projetos de automação de processos, IA e gestão de inovação. Tem MBA em Governança Financeira (FGV), especialização em Gestão de Custos (PUC Minas) e programa de Gestão da Inovação em Stanford (via Endeavor).
Na prática, resolver o limite do dado é o que separa um piloto de IA de uma operação em produção. É esse o trabalho da camada de conectividade e da memória contextual em grafo do Orcheon: dar aos processos críticos o dado certo, na hora certa — sem depender de que todo sistema tenha uma API pronta.