Existe uma premissa embutida na maior parte do design de agentes de IA que raramente é questionada: se um dado é relevante para responder a uma pergunta, o agente deveria poder usá-lo.
Parece razoável, mas está errado.
Para organizações que operam plataformas com vários grupos de participantes — clientes e lojistas, passageiros e motoristas, contratantes e prestadores de serviço —, é exatamente essa premissa que, silenciosamente, transforma implementações de IA em problemas de confiança.
A armadilha da relevância
Um cliente entra em contato com o suporte por causa de uma entrega atrasada. Ele quer saber o que aconteceu e pede reembolso.
As informações mais relevantes incluem os tempos médios de preparo do restaurante, a janela de preparo daquele pedido específico, o histórico de rotas do entregador e quaisquer alertas que surgiram durante o atendimento do pedido. Tudo isso é diretamente útil e gera uma resposta melhor e mais precisa.
Mas também exporia dados de desempenho operacional do restaurante a um cliente que não tem por que vê-los. Responsabilizaria o comportamento de um entregador sem o devido processo. Traçaria uma ligação direta entre o resultado de um lado e os dados do outro, sem o conhecimento ou o consentimento de nenhuma das partes.
O agente não errou — fez exatamente o que foi projetado para fazer: encontrar o que é relevante e usar. O erro foi presumir que relevância e permissão são a mesma coisa.
Por que essa distinção é mais difícil do que parece
Em um produto unilateral, relevância e permissão costumam andar juntas. Quem faz a pergunta é também a pessoa cujos dados estão em jogo. A distância entre o que é útil e o que é permitido é pequena o bastante para que a maioria dos agentes a percorra sem incidentes.
Plataformas multilaterais derrubam essa premissa por completo.
Cada grupo de participantes tem seus próprios dados, fluxos de trabalho, expectativas de privacidade e definições do que é um resultado justo. Quando um agente de IA atua sobre todos eles a partir de uma base de conhecimento compartilhada, ele não está navegando em um único ambiente de dados. Está navegando em vários ao mesmo tempo, sem fronteiras rígidas entre eles.
Três modos de falha aparecem de forma recorrente:
Vazamento de dados entre superfícies. Uma informação relevante em uma superfície pertence a um participante de outra. Um agente de atendimento ao cliente que enxerga o histórico de disputas do lojista, um portal do lojista que exibe detalhes de reclamações de clientes ou uma interface do motorista que faz referência a dados de fiscalização da plataforma.
Ações que geram consequências não revisadas em outro lugar. Um reembolso emitido na superfície do cliente dispara um desconto no repasse na superfície do lojista. Um agente de IA que pode executar a primeira ação, mas não enxerga a segunda consequência, vai tomar decisões aparentemente razoáveis que criam problemas com os quais ele nunca se depara. O ciclo de feedback não se fecha.
Tratamento inconsistente entre grupos de participantes. A mesma pergunta de fundo — por que meu pagamento foi reduzido? — significa algo fundamentalmente diferente dependendo de quem pergunta: um lojista ou um motorista. Os dados elegíveis, a resposta adequada e as ações permitidas são todos diferentes. Um agente sem fronteiras rígidas entre superfícies gera respostas tecnicamente corretas e contextualmente erradas.
Nada disso é culpa do agente de IA — são falhas de arquitetura. Ninguém disse ao agente onde ficavam os limites.
Relevância é ponto de partida, não autorização
Esta é a mudança de perspectiva que importa: a relevância deve orientar o que o agente procura, mas a elegibilidade deve determinar o que ele pode de fato acessar.
São duas perguntas distintas, respondidas em sequência.
A elegibilidade vem primeiro. Antes de o agente recuperar qualquer coisa, a plataforma já precisa ter respondido: de qual superfície vem esta interação? Qual grupo de participantes está autenticado? Quais dados e ações estão no escopo desta superfície, deste papel, deste contexto de política? O que está categoricamente fora dos limites, por mais relevante que seja?
Não são perguntas para o modelo ponderar. São restrições que a plataforma aplica de forma determinística, antes de o agente começar. A relevância passa então a operar dentro dessas restrições, e não no lugar delas.
O efeito prático é significativo. Um agente restrito à superfície do cliente não consegue expor dados do lojista por acidente. Não porque foi instruído a não fazer isso, mas porque esses dados nunca foram elegíveis. Instruções de prompt podem ser contornadas. Restrições de elegibilidade, não.
Essa distinção importa mais do que parece. "Não deveria usar" e "não consegue acessar" não oferecem o mesmo nível de proteção. Em escala, em ambientes complexos, com casos extremos reais, só a segunda se sustenta.
O que isso significa na prática
As plataformas que acertam nisso não criam agentes mais restritivos — elas criam agentes com arquitetura melhor. A capacidade de raciocínio do agente continua a mesma; o que muda é a superfície sobre a qual ele raciocina.
O resultado não é um agente menos capaz. É um agente confiável para todos os grupos de participantes ao mesmo tempo. Em plataformas multilaterais, essa é a capacidade que escala.
A relevância leva você a uma boa resposta. A elegibilidade leva você a uma resposta confiável.
Veja nas suas próprias conversas.
Solicite uma demonstração personalizada gratuita.
