Série sobre Arquitetura de IA – Parte 3

O ponto de estrangulamento nos fluxos de trabalho de investimento não é, muitas vezes, a análise em si, mas sim tudo o que tem de ser feito antes de a análise poder começar: realizar verificações de conformidade, mapear as posições da carteira em relação aos critérios do mandato, classificar um fundo de acordo com uma norma regulamentar, identificar potenciais problemas em todo o universo de investimentos, entre muitas outras tarefas semelhantes.

Não se trata de tarefas analíticas. São tarefas de recuperação e formatação disfarçadas de trabalho analítico. A arquitetura que descrevemos no artigo anterior foi concebida precisamente para resolver este problema.

Nas partes 1 e 2 da série «Arquitetura de IA», explicámos por que razão as escolhas arquitetónicas se acumulam ao longo do tempo e como as quatro camadas (o LLM, os MCP, as competências e os agentes) se articulam em teoria. Neste artigo, passamos à prática, explorando o que cada camada contribui para os fluxos de trabalho reais de investimento, o que um caso de utilização concreto revela sobre as possibilidades atuais e as limitações dos protocolos de contexto do modelo (MCP).

O problema que vale a pena mencionar na análise de investimentos

A disponibilidade de dados já constituiu um obstáculo à análise de investimentos e ao cumprimento normativo. No entanto, à medida que a divulgação de informações pelas empresas amadureceu e as fontes de dados se multiplicaram, esse obstáculo inverteu-se para muitas empresas. A quantidade de dados à sua disposição ultrapassou a sua capacidade de agir com base neles. O resultado é uma espécie de «informação ociosa», definida pela discrepância entre a informação que existe num sistema e a decisão que pode efetivamente ser tomada com base nela.

Imaginemos um analista a verificar a conformidade com os mandatos. Os passos que antecedem a sua análise incluem aceder ao conjunto de dados ou ficheiro correto, selecionar a carteira adequada, localizar o mandato relevante, iniciar a verificação de conformidade, interpretar os resultados ao nível das métricas e identificar as violações e os fatores associados. Nenhum desses passos envolve um julgamento profundo ou pensamento crítico. Trata-se apenas de saber onde clicar e ser capaz de repetir o processo de forma fiável.

Isto não é uma crítica aos sistemas existentes. É uma descrição de como a maioria dos produtos de dados estruturados sempre funcionou: sistemas poderosos que exigem que os utilizadores saibam como os utilizar.

A IA, e mais especificamente a arquitetura em torno da qual esta série de artigos tem vindo a ser desenvolvida, permite-nos repensar este status quo. O raciocínio geral de um LLM, aliado aos dados e metodologias específicos de um MCP especializado, reduz a distância entre a pergunta e a resposta. O trabalho «adicional» que antes consumia a manhã de um analista (a navegação, a filtragem, a exportação, a formatação) desaparece. O que resta é o julgamento; o trabalho diferenciado para o qual o analista foi contratado.

Monitorização de mandatos com recurso à IA: um exemplo prático

Enquanto empresa de tecnologia, a filosofia Clarity AIconsiste em ir ao encontro dos clientes onde eles trabalham, em vez de exigir que sejam eles a vir até nós.

A nossa abordagem centrada na API torna a camada de agentes uma extensão natural desse princípio orientador. O nosso conjunto de MCPs, incluindo um especificamente concebido para monitorizar a conformidade da carteira com os mandatos de investimento, integra os dados e a metodologia Clarity AIdiretamente nas aplicações de IA preferidas ou nos sistemas internos que os nossos clientes já utilizam. Estes MCPs facilitam fluxos de trabalho que decorrem de ponta a ponta com comandos simples em linguagem natural, como «por favor, verifique a conformidade da minha carteira com o meu mandato de investimento».

Uma única frase em linguagem simples dá início a todo um fluxo de trabalho. Na ausência de quaisquer especificações adicionais por parte do utilizador, o Claude analisa os requisitos das instruções e, em resposta, aciona uma série de ferramentas distintas, recolhendo as instruções do utilizador e os ativos da sua carteira, realizando verificações de conformidade ao nível das métricas e compilando os resultados.

Os resultados são apresentados sob a forma de uma tabela estruturada e interativa dentro do chat, incluindo resultados de aprovação/reprovação ao nível das métricas e uma lista das empresas que infringiram as normas. Todos os valores podem ser rastreados através de perguntas de acompanhamento ou de um link direto para a aplicação web Clarity AI, para uma investigação mais aprofundada.

O que antes exigia navegar num portal de dados, localizar a carteira e o mandato certos, interpretar os resultados ao nível das métricas, formatar os resultados e filtrar os casos de incumprimento, agora é resolvido com uma única troca de informações.

Uma aplicação web bem concebida é a ferramenta ideal para explorar dados, nomeadamente no caso de questões abertas, em que o apoio visual ajuda o utilizador a navegar num ambiente repleto de possibilidades. Afinal, muitas das melhores perguntas surgem precisamente da simples exploração de dados. No entanto , o fluxo de trabalho acima descrito não é de natureza exploratória.

O gestor de carteiras conhece a pergunta, a carteira e o mandato, e quer a resposta. Neste tipo de trabalho que exige resultados concretos, mesmo a interface mais bem concebida implica uma etapa de tradução, na qual o utilizador tem de converter uma pergunta em linguagem simples numa sequência de cliques. A arquitetura MCP elimina essa tradução e encurta o caminho entre a pergunta e a resposta. O utilizador faz a pergunta na linguagem que teria usado com um analista, e o sistema apresenta a resposta em segundos.

Essa integração depende de o MCP realizar tarefas que o próprio LLM não consegue realizar sozinho. Modelos de base como o Claude possuem um vasto conhecimento geral, mas carecem dos dados especializados e selecionados, bem como da informação metodologicamente fundamentada, de que os setores regulamentados dependem.

Imaginemos um gestor de carteiras que gere um mandato baseado em valores religiosos com uma carteira de fundos.

Um LLM de uso geral com acesso à Internet teria de identificar as participações de cada fundo (raramente divulgadas publicamente e, na maioria das vezes, desatualizadas em relação ao trimestre anterior), reconciliar convenções de nomenclatura entre PDFs e fichas informativas, localizar vinte valores métricos para cada uma das cerca de cem participações por fundo, decompor métricas compostas relatadas de forma inconsistente entre as empresas, estimar valores para os que não divulgam, normalizar unidades entre normas de reporte e calendários fiscais, e preservar uma pista de auditoria defensável perante o regulador em cada etapa. São 2.000 pontos de dados por fundo, numa carteira que pode conter dezenas, sem uma camada de governança para arbitrar definições e sem maneira de saber quais participações foram silenciosamente ignoradas porque os dados não foram encontrados ou a página não pôde ser carregada.

Essa tarefa é estruturalmente impossível para um modelo que funcione apenas com acesso à Internet. Assim, o MCP especializado funciona como o «impulso» que dota o sistema de raciocínio geral de conhecimentos específicos do domínio, neste caso, relativos aos ativos verificados dos fundos, aos critérios do mandato, ao contexto regulamentar e aos dados codificados pela metodologia que o fluxo de trabalho requer. 

Este é apenas o primeiro passo, ainda rudimentar, rumo a um valor verdadeiramente transformador. Uma vez que este trabalho é agora executado no seio de uma poderosa camada de aplicações repleta de possíveis ligações (agendas, caixas de entrada, CRMs, calendários, etc.), pode ser integrado num fluxo de trabalho automatizado verdadeiramente de ponta a ponta. Uma tarefa agendada no Claude pode executar a mesma verificação todas as manhãs dos dias úteis, sinalizar e comprovar alterações relevantes, redigir um resumo de acordo com as suas diretrizes de voz, alinhar os elementos visuais de alerta com o estilo de design da sua empresa e enviá-lo para a caixa de entrada do gestor de carteiras até às 9h.

Esse fluxo de trabalho, que anteriormente exigia ferramentas específicas ou um esforço manual considerável, pode ser configurado em menos de trinta minutos. É isso que a camada de agentes — a combinação de um LLM, MCPs e competências — torna possível.

Anatomia do fluxo de trabalho de um agente: os quatro elementos básicos

O fluxo de trabalho descrito acima divide-se em quatro elementos básicos. Cada um desempenha uma função específica. Isoladamente, nenhum deles é suficiente; é a combinação que os torna eficazes. A seguir, apresentamos esses elementos aplicados a um fluxo de trabalho de monitorização de mandatos. Cada elemento básico é acompanhado de um exemplo prático que pode experimentar por si mesmo.

O Claude, o LLM, é o motor de raciocínio. Ele interpreta o prompt, decide quais ferramentas utilizar, organiza-as em sequência, lê os resultados e redige a resposta. O utilizador não precisa de especificar nada disto antecipadamente.

Os MCPs gerem o acesso. Por exemplo, um MCP de base de dados recupera a carteira e as participações nos fundos, os dados extrafinanceiros e as metodologias associados, e executa a verificação de conformidade. Um conector do Gmail ou do Outlook envia o alerta. As ferramentas determinam a quais sistemas o LLM pode aceder.

As competências determinam a forma como o sistema deve executar o trabalho. Orientam o LLM para que execute uma tarefa de forma consistente, de acordo com um conjunto específico de critérios, em vez de o fazer de forma ad hoc em cada ocasião. Num exemplo em que o Claude recebe tanto uma competência de redação de e-mails como uma competência de formatação de relatórios, a primeira codifica o tom preferido da empresa; a segunda codifica a forma como a empresa comunica a análise, como a estrutura de um memorando do comité de investimento, a ordem em que os riscos são apresentados e a forma como as recomendações são apresentadas. As competências permitem que os LLMs apliquem efetivamente as formas institucionais de trabalho das empresas.

A programação é o fator determinante. Ela transforma o fluxo de trabalho de reativo (você solicita) para proativo (o sistema age de acordo com a cadência que você definiu). Sem ela, a elaboração do briefing deste exemplo fica parada, à espera que alguém se lembre.

O resultado abaixo é o que essas primitivas geram quando unificadas por um utilizador: um resumo de conformidade com a identidade da marca na caixa de entrada do gestor de carteiras até às 9h, redigido no tom da empresa, formatado de acordo com as suas normas, utilizando dados verificados sobre participações, mandatos e dados extrafinanceiros provenientes do sistema ligado ao MCP, sem que ninguém tenha dado início ao processo.

Consideradas isoladamente, cada uma das componentes básicas tem as suas limitações, mas, quando combinadas, somam-se. Se se eliminar o calendário, o analista ainda tem de se lembrar de acionar o fluxo de trabalho. Sem as competências necessárias, o briefing é genérico, impraticável e aleatório. Se se descartar o MCP, os dados ficam ou totalmente indisponíveis ou completamente pouco fiáveis.

Por que razão a qualidade dos dados é o verdadeiro obstáculo nos fluxos de trabalho baseados em IA

Os MCPs não são mágicos. A qualidade dos resultados que produzem é um reflexo direto da qualidade dos dados na outra extremidade. No exemplo de fluxo de trabalho descrito acima, o que importa é a qualidade dos dados extrafinanceiros e dos dados relativos às participações. Se esses dados forem duvidosos, todo o fluxo de trabalho perde todo o valor.

Cada elemento essencial da qualidade dos dados constitui uma disciplina própria:

• A cobertura de dados requer um enorme poder computacional e operações de investigação primária, a par de competências em aprendizagem automática para a realização de estimativas.
• A atualização dos dados exige operações contínuas e específicas que abranjam a recolha, a validação e os ciclos de atualização em milhares de fontes.
• O rigor metodológico exige um acompanhamento regulamentar, um profundo conhecimento da área e uma gestão disciplinada das versões em milhares de métricas.
• A auditabilidade requer uma infraestrutura que preserve a proveniência ao longo de todas as transformações, de modo a que qualquer valor possa ser rastreado até à sua origem.

Estas disciplinas não decorrem de um modelo mais avançado. Pelo contrário, são desenvolvidas de forma lenta e deliberada, com o tipo de especialização que não se resume a uma janela de contexto. A implicação é de natureza estrutural. À medida que os modelos transformam o raciocínio numa mercadoria, a vantagem competitiva passa para o substrato: os dados.

Para além da arquitetura: quatro perguntas a fazer a qualquer fornecedor de IA

A arquitetura apresentada neste artigo é convergente. Qualquer fornecedor sério irá disponibilizar alguma versão desta arquitetura nos próximos anos. As questões que vale a pena abordar nas conversas com os fornecedores devem, portanto, centrar-se nos elementos que sustentam essa arquitetura.

Siga-nos no LinkedIn ou subscreva a nossa newsletter para receber Clarity AI .