Alessandro Cotrufo diz que o contexto é o maior desafio da IA empresarial

Alessandro Cotrufo questionou o modelo de IA empresarial centrado nos modelos, e uma manchete do Google News resumiu sua posição em um conflito direto. Modelos melhores não são a principal limitação. O problema mais difícil é fornecer à IA um contexto empresarial atualizado, relevante e governado quando ela precisa responder ou agir.

A manchete, atribuída ao Carroll County Mirror-Democrat, oferece poucos detalhes que possam ser verificados de forma independente sobre as declarações de Cotrufo. No entanto, sua atividade pública o conecta à Redis e reforça repetidamente o mesmo argumento de priorizar o contexto. A Redis também incorporou essa posição à sua estratégia recente de produtos para agentes de IA em produção.

Essa distinção importa porque as empresas passaram anos comparando modelos da OpenAI, Google, Anthropic, Meta e outros fornecedores. O argumento de Cotrufo desloca o escrutínio das pontuações de benchmark para os sistemas que cercam esses modelos. Se ele estiver certo, trocar o modelo não corrigirá registros ausentes, políticas desatualizadas, permissões quebradas ou decisões não documentadas.

Isso não significa que os modelos deixaram de importar. A qualidade do modelo ainda afeta o raciocínio, o seguimento de instruções, o uso de ferramentas e a precisão das respostas. A inversão é que a escolha do modelo parece cada vez mais um componente dentro de um problema de confiabilidade muito maior.

A manchete do Google News aponta para uma estratégia mais ampla da Redis

O desenvolvimento mais importante não é um novo modelo de base. É o esforço crescente para transformar o contexto empresarial em uma categoria definida de infraestrutura.

A listagem original do Google News apresentou a visão de Cotrufo como um desafio direto às prioridades convencionais da IA empresarial. Contudo, é difícil verificar o artigo subjacente para além de sua manchete sindicada. Portanto, os leitores devem tratar a atribuição precisa com cautela, especialmente quaisquer detalhes que não sejam reproduzidos por uma fonte primária acessível.

As publicações públicas de Cotrufo fornecem evidências mais sólidas para a posição mais ampla. Sua atividade descreve os agentes como tendo um problema de contexto, e não um problema de inteligência. Ele também argumentou que a IA em produção depende de manter dados, recursos e decisões consistentes em tempo real.

Essa linguagem corresponde de perto à direção atual dos produtos da Redis. Em maio de 2026, a empresa apresentou o Redis Iris como um sistema de contexto e memória destinado a conectar agentes a dados empresariais fragmentados. A Redis descreve um mecanismo de contexto como a camada entre um agente e as informações de que ele precisa para agir.

A documentação do mecanismo de contexto da empresa lista quatro serviços gerenciados. LangCache reutiliza respostas para prompts semanticamente semelhantes. Agent Memory mantém informações de curto e longo prazo. Context Retriever oferece aos agentes acesso estruturado a dados empresariais. Data Integration sincroniza alterações de bancos de dados relacionais.

Essa arquitetura transforma o argumento de Cotrufo em uma tese comercial concreta. Um modelo só pode raciocinar sobre as informações disponíveis durante uma etapa específica de inferência. Se uma política atual de reembolso permanece presa em um sistema inacessível, um raciocínio melhor não consegue recuperá-la por mágica.

A mesma limitação se aplica quando um agente encontra registros conflitantes. Um banco de dados de clientes pode mostrar um titular de conta, enquanto uma plataforma de suporte mostra outro. Uma troca de e-mails pode conter a exceção mais recente, mas nenhum sistema formal a registra.

Um modelo pode produzir linguagem fluente sobre essas contradições. Ele não consegue determinar de forma independente qual sistema tem autoridade, a menos que a arquitetura ao redor forneça essa regra. Portanto, contexto inclui significado, propriedade, permissões, tempo e proveniência, e não apenas texto adicional.

Isso cria a tensão central do artigo. Fornecedores de modelos continuam aprimorando a capacidade geral, enquanto implantações empresariais encontram falhas enraizadas em condições operacionais privadas. Essas condições diferem entre empresas e, muitas vezes, mudam mais rapidamente do que um ciclo de treinamento de modelos.

O Google News deu ao argumento uma manchete concisa, mas a Redis forneceu o sinal mais relevante. A empresa está posicionando o tratamento de contexto como uma camada coordenada de produção, e não como um conjunto de integrações personalizadas.

Esse enquadramento também atende aos interesses da Redis. A empresa vende infraestrutura que armazena estado, recupera informações e movimenta dados rapidamente. Seu diagnóstico não deve ser confundido com uma prova neutra de que uma plataforma resolve todas as falhas de contexto.

Ainda assim, o problema subjacente vai além de um único fornecedor. O Google Cloud agora define a engenharia de contexto de IA como o projeto do ambiente de dados e da memória usados por um sistema de IA. Esse alinhamento independente sugere que a categoria está se tornando parte da arquitetura empresarial predominante.

A notícia, portanto, é uma mudança de ênfase. As empresas estão deixando de perguntar qual modelo é mais inteligente para perguntar quais informações chegam ao modelo, sob quais regras e em que momento.

Por que atualizações de modelos não conseguem reparar conhecimento empresarial ausente

Um modelo mais forte pode raciocinar melhor, mas não pode raciocinar a partir de fatos privados que a empresa nunca disponibilizou.

Modelos de base aprendem padrões amplos a partir de grandes coleções de treinamento. Isso os torna úteis para redação geral, programação, sumarização e análise. Não lhes dá conhecimento automático dos contratos atuais de uma empresa, APIs internas, regras de aprovação ou histórico de clientes.

Considere um agente de suporte que lida com uma solicitação de reembolso. O modelo pode conhecer práticas comuns do varejo e produzir uma resposta persuasiva. Sua utilidade depende de receber a política aplicável, o registro de compra, a categoria do produto, o status do cliente e qualquer exceção aprovada.

Um documento de política ausente cria um tipo de falha. Uma cópia desatualizada cria outro. A recuperação excessiva também pode ocultar o parágrafo decisivo sob material irrelevante, tornando uma janela de contexto maior menos útil do que o esperado.

A engenharia de contexto aborda esse problema de seleção. É o processo de reunir as instruções, registros, memórias, descrições de ferramentas e estado operacional que um modelo recebe durante a inferência. O objetivo não é fornecer tudo. É fornecer o menor conjunto confiável que sustente a próxima decisão.

Esse requisito se torna mais difícil quando um sistema de IA atua em várias etapas. Um chatbot convencional pode responder a uma pergunta isolada. Um agente pode inspecionar uma conta, comparar políticas, solicitar autorização, atualizar um ticket e notificar um cliente.

Cada etapa altera o estado relevante. O agente precisa se lembrar do que já verificou, reconhecer novos dados e evitar repetir uma ação. Também deve preservar a fronteira entre as informações que pode ler e as operações que pode executar.

Um modelo maior não elimina essas obrigações de engenharia. Ele pode se recuperar com mais elegância de uma instrução ambígua, mas ainda precisa de credenciais válidas e de um registro confiável das ações concluídas.

Isso explica por que contexto é mais amplo do que geração aumentada por recuperação, ou RAG. RAG pesquisa uma fonte de conhecimento e adiciona material relevante a um prompt antes da geração. Ela pode fundamentar uma resposta, mas a recuperação por si só não gerencia todas as partes do ambiente de trabalho de um agente.

Uma camada de contexto em produção também pode incluir memória de sessão, preferências do usuário, esquemas de banco de dados, eventos em tempo real, controles de acesso, resultados de ferramentas e estado de fluxo de trabalho. Ela precisa decidir o que reter, o que descartar e o que atualizar.

O Stack Overflow ilustrou essa lacuna usando o desenvolvimento de software específico de empresas. Sua análise do problema de contexto empresarial observa que um assistente genérico pode conhecer bibliotecas públicas, mas não a arquitetura privada ou decisões técnicas anteriores de uma organização.

O artigo descreve o Genie da Uber, um assistente interno usado em canais do Slack. Segundo o Stack Overflow, o Genie combina um repositório interno de conhecimento validado por humanos com modelos da OpenAI. Engenheiros podem inspecionar as fontes em vez de aceitar uma resposta sem respaldo.

Esse exemplo não prova que todos os agentes contextuais terão sucesso. Ele mostra por que a inteligência do modelo e o conhecimento institucional desempenham funções diferentes. O modelo fornece capacidades linguísticas e de raciocínio. A camada de conhecimento fornece restrições e evidências específicas da empresa.

O conhecimento institucional também inclui explicações que raramente aparecem em bancos de dados estruturados. Uma equipe pode ter abandonado uma biblioteca porque ela falhou durante uma migração anterior. Outro serviço pode exigir uma aprovação incomum devido a um antigo compromisso de conformidade.

Esses fatos frequentemente sobrevivem em notas de reuniões, conversas de chat, arquivos locais e na memória dos funcionários. Portanto, construir uma camada de contexto utilizável começa como um problema organizacional antes de se tornar um problema de recuperação.

Uma base de conhecimento pesquisável pode tornar materiais dispersos mais acessíveis. No entanto, a qualidade da busca não pode compensar a ausência de propriedade, políticas pouco claras ou documentos que ninguém mantém.

A posição de Cotrufo é mais forte neste ponto. As empresas não podem resolver operações não documentadas simplesmente escolhendo o modelo mais recente. Elas precisam tornar sua realidade interna legível para as máquinas.

A verdadeira disputa é entre trocar modelos e investir em contexto

A disputa principal é entre a substituição repetida de modelos e o investimento contínuo em dados, memória e governança ao redor de cada modelo.

Uma equipe focada em modelos responde a resultados fracos testando outro fornecedor, ampliando prompts ou selecionando uma janela de contexto maior. Esses experimentos podem ajudar quando a falha original envolve qualidade de raciocínio ou seguimento de instruções.

Eles conseguem menos quando o registro de origem está errado. Se um agente de vendas recebe o catálogo de produtos do último trimestre, nenhum líder de benchmark consegue inferir todas as mudanças de forma confiável. Se faltam permissões, o modelo não consegue obter com segurança um contrato restrito.

Uma equipe focada em contexto começa pela decisão que o sistema precisa tomar. Ela identifica fontes autoritativas, atualização necessária, permissões do usuário, estado histórico e incerteza aceitável. O modelo é então avaliado dentro desse ambiente operacional.

Essa abordagem muda as perguntas de aquisição. Os compradores ainda precisam comparar precisão, latência, segurança e compatibilidade dos modelos. Eles também precisam testar se a aplicação ao redor recupera as evidências corretas e respeita os limites de acesso.

As buscas do Google News tendem a destacar lançamentos visíveis de modelos porque as versões produzem eventos claros e nomes reconhecíveis. O trabalho de contexto é menos visível. Ele aparece em contratos de dados, suítes de avaliação, pipelines de recuperação, sistemas de identidade e procedimentos de manutenção.

Ainda assim, esses componentes menos visíveis determinam se um agente pode passar de uma demonstração para um fluxo de trabalho recorrente. Uma demonstração refinada frequentemente usa documentos cuidadosamente selecionados e perguntas previsíveis. A produção expõe entradas conflitantes, mudanças de permissão, campos ausentes e casos incomuns.

O argumento de priorizar o contexto também afeta a dependência de fornecedores. Quando o significado empresarial reside nos prompts de um único fornecedor de modelos ou em um sistema proprietário de memória, a migração se torna cara. Uma camada de contexto governada separadamente pode preservar o conhecimento institucional enquanto os modelos mudam.

Esse benefício não é automático. Armazenamentos de contexto e produtos de orquestração podem criar suas próprias dependências. Formatos de dados, índices vetoriais, esquemas de ferramentas, históricos de avaliação e políticas de acesso ainda podem vincular uma empresa a uma única arquitetura.

Por isso, as empresas devem separar ativos duráveis de componentes substituíveis. Ativos duráveis incluem propriedade das fontes, definições de negócio, regras de aprovação, casos de avaliação e registros rastreáveis. Modelos, algoritmos de recuperação e frameworks de orquestração devem permanecer testáveis em relação a esses ativos.

A estratégia da Redis reflete essa divisão. Seu anúncio do Redis Iris descreve uma camada que fornece memória, dados estruturados, busca, cache e informações operacionais atualizadas para agentes. O modelo fica acima dessa camada e, em teoria, pode ser trocado.

A empresa afirma que seu Context Retriever gera ferramentas controladas a partir de entidades de negócio definidas. Essa abordagem importa porque o acesso irrestrito a bancos de dados exporia agentes a dados que eles nem compreendem nem têm permissão para usar.

Uma ferramenta pode restringir a ação disponível. Em vez de permitir consultas arbitrárias, um agente pode receber uma função aprovada para recuperar um pedido por identificador de cliente. A função pode aplicar acesso no nível de linha e retornar um esquema previsível.

Isso é contexto como política executável, e não apenas um documento anexado a um prompt. Ele expressa o que o agente pode solicitar, quais dados pode ver e como esses dados devem ser interpretados.

O CEO da RelationalAI, Molham Aref, apresentou um argumento relacionado a partir de outra área do mercado. Em uma discussão de junho de 2026 sobre a camada de contexto empresarial, ele afirmou que documentos por si só não capturam as relações e a lógica de negócio por trás das decisões operacionais.

Essa distinção é importante para cadeias de suprimentos, precificação, risco e análise de fraude. Esses domínios dependem de transações estruturadas e de relações em mudança, não apenas de texto corrido. Um sistema de IA precisa entender como os registros se conectam e quais cálculos definem um conceito de negócio.

Portanto, os concorrentes não são simplesmente Redis contra outra empresa de banco de dados. A disputa mais profunda é arquitetural. Um caminho trata o modelo como o centro do produto e conecta dados quando necessário. O outro trata o modelo como um componente de raciocínio dentro de um sistema de informação governado.

A afirmação de Cotrufo favorece o segundo caminho. Seu apelo cresce à medida que os modelos fundacionais se tornam mais fáceis de substituir e os dados empresariais continuam difíceis de organizar.

Um Contexto Melhor Introduz Seus Próprios Riscos de Precisão e Segurança

O contexto pode reduzir respostas sem suporte, mas um contexto mal governado pode fazer um sistema de IA errar com confiança e acessar informações mais sensíveis.

Este é o desafio mais forte ao argumento de Cotrufo. Chamar o contexto de maior problema pode fazer a solução parecer simples: conectar mais dados, adicionar memória e recuperar os registros certos.

Cada uma dessas operações introduz riscos. Um serviço de memória pode preservar uma suposição incorreta de uma conversa anterior. A recuperação pode trazer à tona uma política substituída. Um pipeline de sincronização pode propagar mais rapidamente um erro do sistema de origem.

Mais contexto também pode aumentar a exposição. Um agente conectado a registros de clientes, mensagens internas e sistemas operacionais se torna um alvo mais valioso. Uma instrução maliciosa dentro de um documento recuperado pode tentar redirecionar o agente ou extrair informações restritas.

O controle de acesso deve, portanto, acompanhar o usuário e a tarefa. Um funcionário que pode visualizar uma conta regional não deve obter acesso global porque o índice compartilhado de um agente contém ambas. Relevância de busca não estabelece autorização.

A procedência importa pelo mesmo motivo. Cada resposta importante deve revelar quais registros a sustentaram, quando esses registros foram alterados e qual sistema é responsável por eles. Sem essa trilha, o contexto produz confiança sem responsabilização.

A memória cria outra questão de governança. Algumas informações devem persistir entre sessões, como uma preferência de usuário confirmada. Outras devem expirar, incluindo instruções temporárias ou suposições que nunca foram validadas.

As equipes precisam de regras de retenção que diferenciem o histórico de conversas de fatos duráveis. Também precisam de caminhos de correção. Quando um usuário corrige um erro, o sistema deve atualizar ou invalidar a memória antiga, em vez de recuperar ambas as versões posteriormente.

O cache semântico apresenta uma troca semelhante. Reutilizar uma resposta anterior pode reduzir a latência e evitar chamadas desnecessárias ao modelo. Também pode retornar uma resposta obsoleta se a política subjacente mudar antes de o cache expirar.

Portanto, um cache seguro precisa de mais do que correspondência por similaridade. Ele precisa de regras de expiração, consciência da versão da fonte e exclusões para decisões que exigem dados atuais. Uma explicação em cache pode ser aceitável, enquanto um saldo de conta em cache não é.

A avaliação continua sendo a proteção final. As equipes devem testar a aplicação completa, não apenas o modelo. Testes úteis medem precisão de recuperação, atualização das fontes, aplicação de permissões, conclusão de ferramentas e comportamento quando faltam evidências necessárias.

O sistema deve ser capaz de recusar ou encaminhar o caso. Um agente que sempre produz uma resposta preencherá lacunas de contexto com linguagem plausível. A confiabilidade em produção depende, em parte, de reconhecer quando as evidências disponíveis não justificam uma ação.

O perfil de IA generativa do National Institute of Standards and Technology enfatiza a gestão de riscos no design, na implantação, no monitoramento e na governança. Essa visão de ciclo de vida se encaixa na engenharia de contexto porque a qualidade das informações e as permissões mudam após o lançamento.

As alegações dos fornecedores também exigem verificação nos ambientes dos clientes. A Redis afirma que seus serviços podem fornecer memória persistente, acesso governado e sincronização quase em tempo real. Essas capacidades não garantem decisões de negócio corretas sem dados de origem precisos e regras configuradas adequadamente.

Nem a tese ampla do contexto prova que as diferenças entre modelos se tornaram irrelevantes. Algumas tarefas exigem melhor raciocínio, desempenho multilíngue mais forte ou seleção de ferramentas mais confiável. Um modelo fraco pode usar mal um contexto excelente.

A posição prática é menos absoluta do que a manchete do Google News. A confiabilidade empresarial resulta da interação entre a capacidade do modelo e a qualidade do contexto. A correção útil de Cotrufo é que os compradores frequentemente examinaram a primeira enquanto investiam pouco na segunda.

A Engenharia de Contexto Pressiona Todos os Fornecedores de IA Empresarial

A mudança para o contexto pressiona provedores de modelos, plataformas de dados, fornecedores de aplicações e compradores empresariais a comprovar confiabilidade em todo um fluxo de trabalho.

Empresas de modelos fundacionais enfrentam pressão para tornar seus modelos mais fáceis de conectar, governar, avaliar e substituir. A capacidade bruta continua importante, mas os compradores empresariais precisam cada vez mais de uso previsível de ferramentas e controles claros.

Plataformas de nuvem enfrentam um desafio diferente. Elas já gerenciam dados, identidade e infraestrutura de aplicações. Sua oportunidade é integrar esses ativos em plataformas de agentes sem forçar todos os clientes a usar um único modelo ou formato de dados.

Empresas de banco de dados e busca veem o contexto como um mercado em expansão. A Redis enfatiza estado e memória em tempo real. Outros fornecedores se concentram em recuperação vetorial, grafos de conhecimento, camadas semânticas ou data warehouses. Cada um descreve sua força existente como a camada empresarial ausente.

Fornecedores de aplicações também têm uma vantagem. Seus produtos já contêm regras de fluxo de trabalho e permissões de usuários. Uma plataforma de atendimento ao cliente entende tickets, enquanto uma plataforma de vendas entende contas e oportunidades.

No entanto, o contexto específico de cada aplicação pode aprofundar a fragmentação. Um agente que opera entre sistemas de vendas, faturamento, suporte e produto precisa reconciliar identidades e definições diferentes. Nenhuma aplicação isolada representa automaticamente o negócio completo.

Consultorias e equipes internas de plataforma enfrentarão pressão para integrar esses sistemas. Seu valor deixa de estar na criação de demonstrações isoladas e passa a definir serviços de contexto reutilizáveis, padrões de avaliação e controles de governança.

Os compradores empresariais têm a responsabilidade mais difícil. Os fornecedores podem disponibilizar conectores e sistemas de memória, mas apenas a empresa pode decidir qual fonte é autoritativa. Ela deve definir o que realmente significa “cliente ativo”, “desconto aprovado” ou “incidente resolvido”.

Esse trabalho frequentemente revela divergências anteriores à IA. Dois departamentos podem usar o mesmo nome de métrica com cálculos diferentes. Um agente não cria esse conflito, mas pode expô-lo e amplificá-lo.

Trabalhadores do conhecimento também devem se importar, pois o design de contexto afeta quais julgamentos são codificados. Se apenas documentos formais entrarem no sistema, exceções úteis e experiência prática podem desaparecer. Se toda conversa informal entrar, os riscos de privacidade e qualidade crescem.

Um segundo cérebro bem elaborado pode ajudar indivíduos a preservar decisões e materiais de apoio. Sistemas empresariais precisam de controles adicionais para propriedade compartilhada, permissões, retenção e auditabilidade.

Desenvolvedores precisarão tratar pipelines de contexto como software de produção. Prompts de recuperação, analisadores de documentos, regras de classificação, políticas de memória e esquemas de ferramentas exigem versionamento e testes. Uma alteração em qualquer camada pode modificar o comportamento de um agente.

Gerentes de produto precisarão de métricas além do uso. Um assistente usado com frequência ainda pode fornecer orientações de baixa qualidade. Sinais melhores incluem conclusão verificada de tarefas, taxas de correção, padrões de escalonamento, cobertura de fontes e tempo economizado em fluxos de trabalho definidos.

As equipes de segurança se tornarão participantes centrais, e não revisoras finais. As permissões dos agentes devem corresponder à identidade do usuário, ao escopo da tarefa e à política vigente. Os registros devem mostrar tanto o acesso às informações quanto as ações realizadas.

O enquadramento de Cotrufo, portanto, redistribui a atenção por toda a organização. O programa de IA empresarial deixa de ser principalmente um projeto de integração de modelos. Ele se torna um esforço contínuo para estruturar conhecimento, autoridade, memória e feedback.

Essa é uma mensagem mais exigente do que “instale um modelo mais inteligente”. Ela também explica por que o contexto pode ser o diferencial duradouro. Concorrentes podem licenciar modelos semelhantes, mas não compartilham o mesmo conhecimento institucional nem a mesma disciplina operacional.

O Que os Leitores do Google News Devem Observar em Seguida

A tese que prioriza o contexto será validada por evidências de produção, não por outra rodada de anúncios de categoria.

O primeiro sinal é o desempenho mensurável do fluxo de trabalho. As empresas devem informar se agentes conscientes do contexto concluem tarefas definidas com precisão, e não apenas se os funcionários abrem um chatbot. Taxas de correção, escalonamentos, validade das fontes e ações bem-sucedidas de ferramentas revelarão mais do que totais de adoção.

Se essas métricas melhorarem enquanto as empresas mantêm o mesmo modelo fundacional, o argumento de Cotrufo se fortalece. Se atualizações de modelos produzirem ganhos maiores do que mudanças de contexto, a hierarquia da manchete se torna mais difícil de defender.

O segundo sinal é a portabilidade de modelos. Os fornecedores afirmam cada vez mais que as empresas podem preservar sua camada de contexto ao trocar de modelo. Os compradores devem testar essa promessa executando tarefas, evidências, permissões e avaliações idênticas entre vários provedores.

Uma troca bem-sucedida mostraria que o contexto institucional está se tornando o ativo durável. Reescritas caras ou grandes mudanças de comportamento revelariam dependências ocultas dentro de sistemas supostamente neutros em relação a modelos.

O terceiro sinal é a governança em condições reais. Plataformas de contexto devem mostrar que conseguem lidar com permissões revogadas, políticas alteradas, registros excluídos e conteúdo contaminado sem vazar dados ou reciclar respostas desatualizadas.

Um sistema que funciona bem em uma demonstração estática, mas falha após uma atualização de política, não resolveu o problema empresarial. Atualização, rastreabilidade e correção precisam funcionar continuamente.

A manchete do Google News merece atenção porque captura uma mudança real nas prioridades de IA empresarial. Ela não deve ser interpretada como prova de que a Cotrufo, a Redis ou qualquer outro fornecedor já resolveu o problema do contexto.

Para desenvolvedores e compradores corporativos, a ação imediata é clara: auditar um fluxo de trabalho de produção, do registro de origem à decisão final. Identifique o que o modelo vê, o que deixa de ver, quem controla cada fato e como os erros são corrigidos.

Em seguida, teste se mudar o modelo resolve as falhas observadas. Caso não resolva, o gargalo provavelmente está em outro lugar. A alegação da Cotrufo só conquistará relevância duradoura quando os investimentos em contexto gerarem um trabalho mais seguro e preciso sob pressão empresarial real.