Há um pressuposto enraizado na conceção da maioria dos agentes de IA que raramente é questionado: se os dados são relevantes para responder a uma pergunta, o agente deve poder utilizá-los.
Parece razoável, mas está errado.
Para as organizações que gerem plataformas com vários grupos de participantes — clientes e comerciantes, passageiros e motoristas, clientes e prestadores de serviços —, é esse pressuposto que, discretamente, transforma implementações de IA em problemas de confiança.
A armadilha da relevância
Um cliente contacta o apoio ao cliente por causa de uma entrega atrasada. Quer saber o que aconteceu e pede um reembolso.
A informação mais relevante inclui os tempos médios de preparação do restaurante, o tempo de preparação específico dessa encomenda, o histórico de trajetos do motorista e quaisquer alertas que tenham surgido durante a execução. Tudo isto é diretamente útil e permite uma resposta melhor e mais precisa.
Mas também exporia dados de desempenho operacional do restaurante a um cliente que não tem qualquer motivo para os ver. Implicaria o comportamento de um motorista sem qualquer processo justo. Estabeleceria uma ligação direta entre o resultado de uma das partes e os dados de outra, sem o conhecimento nem o consentimento de nenhuma delas.
O agente não cometeu um erro — fez exatamente aquilo para que foi concebido: encontrar o que é relevante e utilizá-lo. O erro foi assumir que relevância e permissão são a mesma coisa.
Porque é que esta distinção é mais difícil do que parece
Num produto unilateral, relevância e permissão coincidem quase sempre. O utilizador que faz a pergunta é também a pessoa cujos dados estão em causa. A distância entre o que é útil e o que é permitido é suficientemente pequena para que a maioria dos agentes a percorra sem incidentes.
As plataformas multilaterais anulam por completo esse pressuposto.
Cada grupo de participantes tem os seus próprios dados, fluxos de trabalho, expectativas de privacidade e definições do que é um resultado justo. Quando um agente de IA opera sobre todos eles a partir de uma base de conhecimento partilhada, não está a navegar num único ambiente de dados. Está a navegar em vários em simultâneo, sem fronteiras rígidas entre eles.
Surgem, de forma consistente, 3 modos de falha:
Fuga de dados entre superfícies. A informação relevante numa superfície pertence a um participante de outra. Um agente de cliente que consegue ver o histórico de litígios de um comerciante, um portal de comerciante que mostra detalhes das reclamações de clientes ou uma interface de motorista que faz referência a dados de fiscalização ao nível da plataforma.
Ações com consequências não revistas noutros pontos. Um reembolso emitido na superfície do cliente desencadeia uma dedução no pagamento na superfície do comerciante. Um agente de IA que pode executar a primeira ação, mas não vê a segunda consequência, tomará decisões aparentemente razoáveis que criam problemas com os quais nunca se depara. O ciclo de feedback nunca se fecha.
Tratamento inconsistente consoante o grupo de participantes. A mesma pergunta de fundo — porque é que o meu pagamento foi reduzido? — tem um significado radicalmente diferente consoante seja um comerciante ou um motorista a fazê-la. 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, mas erradas no contexto.
Nada disto é culpa do agente de IA — são falhas de arquitetura. Nunca ninguém disse ao agente onde estavam os limites.
A relevância é um ponto de partida, não uma autorização
Eis a mudança de perspetiva que importa: a relevância deve orientar aquilo que o agente procura, mas é a elegibilidade que deve determinar aquilo a que pode efetivamente aceder.
São 2 questões distintas, respondidas por ordem.
A elegibilidade vem primeiro. Antes de o agente obter qualquer informação, a plataforma já tem de ter respondido: de que superfície vem esta interação? Que grupo de participantes está autenticado? Que dados e ações estão no âmbito desta superfície, desta função, deste contexto de políticas? O que está categoricamente vedado, por mais relevante que possa ser?
Não são questões sobre as quais o modelo deva raciocinar. São restrições que a plataforma aplica de forma determinística, antes de o agente começar. A relevância opera depois dentro dessas restrições, e não em vez delas.
O efeito prático é significativo. Um agente limitado à superfície do cliente não pode expor acidentalmente dados de comerciantes. Não porque tenha recebido instruções nesse sentido, mas porque esses dados nunca foram elegíveis. As instruções de um prompt podem ser contornadas pelo raciocínio. As restrições de elegibilidade não.
Esta distinção é mais importante do que pode parecer. «Não deve utilizar» e «não consegue aceder» não oferecem o mesmo nível de proteção. À escala, em ambientes complexos e com casos-limite reais, só a segunda se mantém.
O que isto significa na prática
As plataformas que acertam nisto não criam agentes mais restritivos — criam agentes com melhor arquitetura. A capacidade de raciocínio do agente mantém-se; o que muda é a base sobre a qual raciocina.
O resultado não é um agente menos capaz. É um agente em que todos os grupos de participantes podem confiar em simultâneo. Em plataformas multilaterais, é essa a capacidade que escala.
A relevância leva a uma boa resposta. A elegibilidade leva a uma resposta fiável.
Veja-o nas suas próprias conversas.
Peça uma demonstração personalizada gratuita.
