Assistente de IA híbrido – a evolução dos agentes atuais

Escrevi este artigo e, depois, pedi à IA que melhorasse o meu inglês.

Esta é a minha perspetiva pessoal enquanto arquiteto de soluções, a desenvolver software na cloud e plataformas de dados há 20 anos. É mais uma reflexão sobre como vejo o Actor daqui a 1-2 anos.

À medida que os assistentes de IA se tornam mais capazes, a arquitetura subjacente torna-se tão importante como os próprios modelos. Atualmente, a avaliação dos agentes baseia-se nos modelos utilizados, na framework e nos prompts.

Para sistemas como Actor, concebidos para funcionar com e-mails, calendários, documentos e fluxos de trabalho empresariais, uma abordagem exclusivamente baseada na cloud ou exclusivamente local atinge rapidamente os seus limites.

O que começa a surgir, em vez disso, é uma arquitetura híbrida, em que a inteligência e a execução estão distribuídas por dispositivos locais, infraestrutura privada e modelos na cloud.

Isto tem menos a ver com preferências tecnológicas e mais com uma necessidade arquitetónica.

Os limites de um assistente totalmente na nuvem

A maioria dos assistentes de IA atuais funciona sobretudo na cloud. Inicialmente, isso faz sentido: os modelos são grandes, a infraestrutura é centralizada e as atualizações são fáceis. Além disso, a inferência é barata (ou, pelo menos, no caso de alguns modelos).

Mas, quando um assistente passa a estar profundamente integrado nos sistemas de trabalho, surgem alguns problemas estruturais.

Em primeiro lugar, os limites dos dados são importantes.
Os assistentes de trabalho interagem com informações altamente sensíveis: documentos financeiros, e-mails internos, contratos, planos de desenvolvimento de produtos e conversas sobre recursos humanos. Muitas organizações não podem, por motivos legais ou operacionais, transmitir continuamente estes dados para uma infraestrutura externa.

Então a conectividade passa a ser uma dependência.
Um assistente de trabalho que deixa de funcionar num avião, num túnel ferroviário ou durante falhas de rede torna-se pouco fiável nas operações do dia a dia.

A IA na nuvem é poderosa, mas não consegue, na prática, gerir todas as camadas do sistema.

Os limites de um assistente totalmente local

No extremo oposto, executar tudo localmente também implica limitações significativas.

Os modelos de raciocínio mais avançados continuam a exigir uma infraestrutura computacional significativa. Embora o hardware local esteja a evoluir rapidamente — com Apple Silicon, NPUs e chips de IA dedicados —, executar modelos de ponta para raciocínios complexos ou para sintetizar vários documentos continua a ser impraticável na maioria dos dispositivos.

Em segundo lugar, a latência acumula-se nos fluxos de trabalho com agentes.
Um assistente que executa várias etapas — como ler um e-mail, extrair tarefas, consultar o calendário, redigir uma resposta e agendar acompanhamentos — cria uma cadeia de chamadas a modelos e interações com APIs. Até pequenos atrasos se acumulam quando as ações são sequenciais.

Existe também uma desafio de governação.
Gerir modelos em milhares de dispositivos dos colaboradores introduz complexidade operacional: atualizações, correções de segurança, gestão da configuração e monitorização da conformidade.

Por fim, muitos fluxos de trabalho de assistente exigem estado partilhado.
Uma cronologia de projeto, uma base de conhecimento da equipa ou um sistema colaborativo de tarefas não podem estar inteiramente no computador de uma só pessoa.

A inteligência local, por si só, também não consegue fornecer uma visão completa.

Uma direção provável: inteligência distribuída

Uma arquitetura mais natural para assistentes como o Actor é um modelo de inteligência distribuída, em que diferentes camadas do sistema funcionam em ambientes diferentes.

Uma descrição simplificada poderia ser assim:

Camada local (ambiente de execução do dispositivo)
Responsável por conhecer o ambiente do utilizador e executar ações rapidamente.

Responsabilidades típicas:

• aceder a ficheiros, aplicações e notificações locais
• detetar sinais contextuais (documentos ativos, reuniões, e-mails)
• a executar ações rápidas e privadas
• a armazenar em cache conhecimentos usados frequentemente

Infraestrutura privada (nuvem da organização ou do utilizador)
Responsável pelo estado partilhado e pelo tratamento de dados sensíveis.

Responsabilidades típicas:

• bases de conhecimento da empresa
• memória partilhada do agente
• contexto de colaboração da equipa
• processamento de documentos sensíveis

Modelos de nuvem pública
Responsável pelo raciocínio complexo e pelo conhecimento em grande escala.

Responsabilidades típicas:

• tarefas de raciocínio aprofundado
• síntese complexa de vários documentos
• recuperação de grandes volumes de conhecimento
• capacidades linguísticas avançadas

Neste modelo, o ambiente de execução local atua como orquestrador, decidindo onde cada tarefa deve ser executada.

A importância do limite de confiança

Uma das decisões de conceção mais importantes passa a ser definir a fronteira de confiança.

Em termos práticos, isto significa responder a perguntas como:

• Que dados nunca saem do dispositivo?
• Que dados podem ser transferidos para uma infraestrutura privada?
• Que tarefas podem utilizar modelos externos em segurança?
• Como são estas decisões registadas e auditadas?

Esta fronteira é fundamental para a adoção pelas empresas.

As organizações não querem apenas capacidades de IA — querem previsibilidade e controlo sobre o fluxo dos dados.

Porque é provável que esta arquitetura se torne padrão

Várias tendências do setor apontam nessa direção.

A aceleração por hardware está a melhorar rapidamente nos dispositivos locais, permitindo utilizar modelos leves e realizar inferências locais com rapidez.

Ao mesmo tempo, as capacidades dos modelos de ponta continuam a evoluir nos ambientes de nuvem, mantendo uma diferença que torna o raciocínio na nuvem atrativo para tarefas complexas.

As empresas exigem cada vez mais garantias de governação de dados, levando os sistemas de IA a adotar arquiteturas capazes de respeitar os limites internos.

Por fim, as estruturas emergentes de agentes já são concebidas em torno do encaminhamento multimodelo, onde diferentes modelos e ambientes de execução tratam de diferentes tarefas.

As arquiteturas híbridas alinham-se naturalmente com este padrão.

O que isto significa para a Actor

Especificamente no caso do Actor, uma arquitetura híbrida poderia desbloquear várias capacidades:

Um ambiente de execução local poderia compreender continuamente o ambiente, o contexto de e-mail, as reuniões e os documentos do utilizador, sem ter de transmitir tudo para o exterior.

Uma camada de infraestrutura privada do Actor poderia manter a memória do utilizador, os grafos de tarefas e o contexto colaborativo.

Os modelos na nuvem poderiam então ser utilizados seletivamente em tarefas que exigem realmente um raciocínio mais aprofundado.

Em vez de um único ponto de acesso à IA, o Actor torna-se um sistema que coordena a inteligência entre camadas.

Esta arquitetura também permite que os utilizadores e as organizações escolham diferentes estratégias de implementação, consoante as suas necessidades:

• nuvem pessoal
• infraestrutura da empresa
• híbrido local + na nuvem
• implementações totalmente privadas

Por outras palavras, o Actor evolui de um simples assistente para se tornar uma camada cognitiva distribuída para o trabalho.

Olhando para o futuro

O futuro dos assistentes de trabalho provavelmente não será definido por um único modelo ou fornecedor.

Em vez disso, será moldado por como a inteligência é orquestrada em diferentes ambientes.

Os sistemas capazes de combinar privacidade, rapidez de resposta e raciocínio avançado terão uma vantagem estrutural.

As arquiteturas híbridas parecem ser uma das formas mais promissoras de alcançar esse equilíbrio.

P.S.: Estou a reconstruir toda a arquitetura para estar preparada para um modelo híbrido num futuro próximo. É muito trabalho e vai levar algum tempo, mas é a minha paixão.