As estruturas de agentes prontas a usar são insuficientes para o setor bancário. Sim, é por aí que eu começaria, e não, uma estratégia de prompts mais clara ou um gateway de API mais rigoroso não alteram essa realidade.
Uma pilha padrão com o LangChain, ferramentas, uma base de dados vetorial e um gateway de API pode tornar um agente funcional. Este pode encaminhar uma intenção, obter o contexto, chamar uma ferramenta e devolver uma resposta bem elaborada. Tudo bem. Mas o setor bancário não falha ao nível de “será que consegue chamar a API?”. O setor bancário falha ao nível de “esta chamada foi autorizada, abrangida pelo âmbito, verificada, registada e é seguro mostrá-la a este cliente?”. Isso é um problema de arquitetura diferente.
Existem três razões pelas quais não colocaria uma pilha de agentes genérica junto aos fluxos de trabalho bancários de produção sem adicionar uma camada de confiança dedicada.
Em primeiro lugar, os dados financeiros são dados relativos ao passivo. Uma resposta errada num chatbot de retalho é embaraçosa. Um saldo, um estado de transação, uma explicação sobre comissões ou uma decisão de crédito errados podem constituir um risco jurídico. Ao abrigo da Dever da FCA para com o Consumidor, por exemplo, a instituição tem de demonstrar que os clientes recebem um apoio justo, compreensível e adequado. Se o modelo criar uma opção de reembolso ou explicar um produto de forma incorreta, não se pode encolher os ombros e culpar “a IA”. O banco é responsável pelo resultado. Por isso, a arquitetura tem de tratar cada afirmação factual como algo a verificar junto de um sistema de referência.
Em segundo lugar, a multilocação não é apenas uma escolha de conceção do produto. Se prestar serviços a vários clientes bancários, comerciantes, unidades de negócio ou regiões a partir de uma única plataforma, o isolamento entre inquilinos tem de existir em todas as camadas: solicitações, memória, índices vetoriais, permissões de ferramentas, registos, chaves Redis, linhas de base de dados, segredos e exportações de auditoria. Uma única fuga de dados entre inquilinos não é um ticket de bug. Pode ser um incidente passível de comunicação. É por isso que não gosto de arquiteturas em que o agente tem acesso alargado e a camada da aplicação “se lembra” de filtrar as coisas mais tarde. Filtrar mais tarde é a forma como ocorrem as fugas de dados.
Em terceiro lugar, o LLM é o componente menos fiável da cadeia. Pode parecer severo, mas é a suposição correta. O modelo é probabilístico. Pode seguir instruções maliciosas, confiar excessivamente no contexto recuperado ou expor dados pessoais identificáveis (PII) num resumo. Pode gerar uma chamada de ferramenta que pareça válida até se verificarem os parâmetros. Por isso, nunca deixaria o modelo interagir diretamente com as APIs bancárias principais.
A abordagem mais segura consiste em deixar o modelo raciocinar, mas manter a aplicação das regras em sistemas determinísticos. O raciocínio pertence à camada do agente. A aplicação das regras pertence aos validadores de esquemas, às verificações de políticas, às permissões no âmbito do utilizador, aos mecanismos de aprovação e aos registos de auditoria. Assim que se faz essa separação, a arquitetura deixa de ser uma cadeia de chamadas de API orientadas por modelos e torna-se um sistema de confiança controlado, em que o LLM é tratado como um componente de raciocínio útil, mas não fiável.
Uma abordagem facilita a aplicação dessa divisão. Quando analiso um agente bancário, a questão que me interessa é quanta autoridade ele detém e até que ponto essa autoridade se afasta da pessoa que a concedeu. A capacidade indica a qualidade da demonstração. A autoridade determina o nível de controlo que o sistema está autorizado a exercer. Um modelo brilhante ligado a ferramentas de leitura exclusiva é um assistente simples. Um modelo pouco sofisticado que detém uma chave permanente capaz de movimentar fundos é um problema diferente e necessita de todas as camadas subjacentes. Divido esse eixo de autoridade em quatro classes — assistente, orquestrador, operador e agente económico — no artigo Nem todos os agentes são agentes económicos.
Contrate-nos
Sobre nós