Agentes de IA expõem o problema de dados que as empresas arrastam há anos, mostra debate da Inc42 com a Oracle

Empresas vêm acumulando dados há anos. Torná-los utilizáveis para IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → está se mostrando bem mais difícil do que guardar os dados em si. Esse foi o ponto de partida de um roundtable promovido pela Inc42 em parceria com a Oracle↳Oracle22 conteúdosOracle lança Java 26 para aumentar produtividade de desenvolvedoresDev (Back & Front) · mar 2026Oracle oferece o primeiro cluster de computação em nuvem em escala ZettaDevSecOps · jan 2025Oracle abre inscrições para o ONE, programa gratuito de formação em tecnologia e inteligência artificialData · dez 2024Ver tudo em Data → durante o CTO Summit 2026, na Índia, reunindo CTOs e fundadores para discutir como construir a base de dados que sustenta agentes de IA em produção.

O problema não é novo, mas a IA agentic o deixou impossível de ignorar. Sistemas construídos para times, funções e casos de uso diferentes deixaram informação espalhada entre bancos de dados, aplicações e fluxos de trabalho. Um agente que precisa raciocinar sobre a organização inteira não se contenta em encontrar o dado em algum lugar: ele precisa entender o que aquele dado significa e usá-lo no contexto certo.

O tamanho do gargalo

Uma pesquisa da Dun & Bradstreet citada no evento dá a dimensão do problema: 73% das empresas indianas pesquisadas relatam algum retorno mensurável de investimentos em IA, mas apenas 4% afirmam que seus dados corporativos estão totalmente prontos para sustentar IA em escala. É um gap grande entre “já funciona em algum lugar” e “funciona de forma confiável e ampla”.

Fechar essa distância significa lidar com anos de dívida de dados acumulada: identidades de cliente fragmentadas entre sistemas, dados operacionais isolados em silos, informação organizada para relatório que não serve para um agente que precisa recuperá-la e agir sobre ela. Para quem trabalha com pipeline de dados no Brasil, o cenário é familiar: datasets de CRM, ERP e produto que nunca foram desenhados para conversar entre si.

Outcome primeiro, arquitetura depois

O consenso mais forte do debate foi que a decisão de arquitetura não deveria vir antes da pergunta de negócio. Dhruv Gupta, cofundador da Orchard Healthcare, descreveu assim a lógica que seguiu ao construir a plataforma de dados de cliente da empresa, um projeto de seis meses:

O jeito que a gente pensa é de trás para frente. Qual é o problema a resolver?

The way we think about it is backwards. What is the problem to be solved?Dhruv Gupta, cofundador da Orchard Healthcare

Syed Mohd Bilal, head de data science da Perfios, reforçou a mesma ordem de prioridade: primeiro o resultado desejado, só depois a escolha de ferramentas.

Comece com foco no resultado e depois descubra o que construir, em vez de pensar primeiro nas ferramentas.

Start from an outcome focus and then figure out what to build rather than, you know, thinking about tools first.Syed Mohd Bilal, head de data science da Perfios

Definido o outcome, sobra ainda uma escolha arquitetural real: construir para aquele caso de uso específico ou investir numa plataforma que sustente múltiplas aplicações. Bilal resumiu o trade-off: desenvolvimento orientado a caso de uso resolve a necessidade imediata, enquanto a abordagem platform-first cria uma base mais ampla para aplicações futuras.

Vinay Murthy, diretor sênior de produto da Zeta, argumentou que a IA está tornando essa base ampla cada vez mais difícil de adiar, porque funcionários e sistemas começam a criar agentes por conta própria, fora do controle central de TI.

O que a IA traz de novo é que os casos de uso deixam de estar sob seu controle.

What AI gets in is that the use cases are no longer in your control.Vinay Murthy, diretor sênior de produto da Zeta

Isso impõe uma exigência extra à plataforma subjacente: ela precisa atender aplicações já conhecidas e, ao mesmo tempo, permitir que novos agentes encontrem e interpretem dados para necessidades que a empresa ainda nem definiu.

A camada semântica vira pré-requisito

Conectar um agente diretamente a um banco de dados não resolve o problema sozinho. Palanivel Saravanan, head de infraestrutura e cloud engineering da Oracle, citou o cenário comum de informação espalhada entre Oracle, MySQL, PostgreSQL, MongoDB e conhecimento não estruturado: ligar o agente direto a esses sistemas esbarra no fato de que ele pode não entender o schema do banco nem gerar queries que o banco execute com eficiência.

A saída discutida no painel é uma camada intermediária entre o agente e o dado, responsável por interpretar estrutura e significado antes de planejar a recuperação da informação. Em sistemas tradicionais, era um humano que conectava dado operacional a decisão de negócio; com agentes autônomos, parte desse raciocínio precisa ser codificado na própria camada de dados.

A camada semântica só agora está se tornando obrigatória para sustentar o raciocínio do agente.

The semantic layer is only required or is becoming mandatory to support the reasoning for the agent.Palanivel Saravanan, head de infraestrutura cloud engineering da Oracle

Para quem constrói pipelines, isso tem um paralelo direto com o que já se vê em arquiteturas de RAG e em protocolos como o MCP: sem um catálogo semântico consistente (nomes de campo, relações de negócio, regras de qualidade), o agente ou alucina joins impossíveis ou devolve resultado tecnicamente correto e semanticamente errado. Bilal, da Perfios, acrescentou que a semântica também ajuda a reduzir o espaço de busca do modelo, deixando a recuperação mais focada em vez de varrer a base inteira.

Quem está mais perto do dado, segundo Bilal, é quem deveria definir seu significado, e essa definição precisa ser consistente entre ferramentas e plataformas, não documentada só na cabeça de um analista.

Quem pode acessar o quê

Tornar a informação compreensível não resolve a questão de quem pode usá-la. Abhimanyu Saxena, cofundador da InterviewBit e da Scaler, ilustrou o dilema com uma pergunta direta: se um modelo aprende com o dado do Banco A, esse conhecimento pode ser reaproveitado para o Banco B? Usar dado corporativo para treinar ou melhorar um sistema de IA carrega implicações legais e técnicas que vão além do contrato de uso original.

O mesmo problema aparece dentro de uma única empresa, quando funcionários usam modelos de fronteira (frontier models) para trabalhar com dado interno sem controle centralizado. Himanshu Garg, CTO da Kapture CX, foi direto:

Como você constrói governança em torno disso? Essa é a coisa mais crítica.

So how do you build governance around this right? That is the most critical thing.Himanshu Garg, CTO da Kapture CX

Na Kapture, isso significa aplicar controle de acesso diretamente sobre os grafos de conhecimento e contexto que os agentes consultam, além de construir harnesses de teste para automatizar avaliação de comportamento do agente antes de liberar em produção. Para times de plataforma e segurança no Brasil, é o mesmo tipo de disciplina de IAM e políticas de acesso que já existe para APIs internas, só que agora aplicada a um agente que decide sozinho quais chamadas fazer.

Nem todo agente precisa de modelo de fronteira

A última peça discutida foi puramente financeira. Naveen Dachuri, CTO da Yulu, separou dois cenários: ferramentas internas de IA, onde a empresa define orçamento, e IA embutida em produto voltado ao cliente final, onde uso e custo são muito mais difíceis de prever. No caso de reparo de bicicletas da Yulu, a conta é mais direta: dá para pesar a redução de toques manuais e tempo de resposta contra o custo de rodar o agente.

O equilíbrio entre valor e custo. Isso é o mais importante.

So the value versus cost balance. It is most important.Naveen Dachuri, CTO da Yulu

Manter esse equilíbrio também passa por escolher o modelo certo para cada tarefa. A Kapture usa modelos menores para tarefas previsíveis, como consulta de status de pedido, em vez de acionar um modelo de fronteira para toda interação. Saravanan, da Oracle, observou que as empresas estão deixando de lado a abordagem de modelo único para tudo, e que modelos open-weight vêm oferecendo uma estrutura de custo mais previsível para parte dessas cargas de trabalho.

O que fica para quem constrói

O recado do roundtable para quem projeta arquitetura de dados é concreto: camada semântica, controle de acesso granular por agente e roteamento de modelo por tarefa deixaram de ser otimização futura e viraram pré-requisito de produção. Nenhum desses três elementos aparece pronto numa plataforma de IA comprada de prateleira; eles exigem trabalho de modelagem de dados, governança e observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → que cabe ao time de engenharia, não ao fornecedor do modelo.

O que ainda fica em aberto, inclusive para quem participou do debate, é como padronizar esse trabalho entre organizações: não existe ainda um framework comum para decidir até onde vai um grafo de contexto, nem uma resposta fechada sobre reuso de dado treinado entre clientes diferentes de um mesmo fornecedor de IA.

Fonte: Inc42 (Índia)