Agentes de IA dedicados vs multi-tenant: o que é isolamento de verdade

Um agente de IA dedicado roda com memória, credenciais, configuração e ambiente de execução próprios, para uma única empresa. Um agente multi-tenant compartilha parte dessa infraestrutura com outros clientes e depende de regras de software para manter os dados de cada cliente separados. Nenhum dos modelos é automaticamente seguro ou inseguro. O que importa é quais camadas são compartilhadas, como a separação é garantida e se o fornecedor consegue mostrar evidências de que ela se sustenta.

Principais pontos

• Isolamento não é um interruptor único. Ele se aplica separadamente a memória, credenciais, computação, logs, modelos e configuração, e um fornecedor pode ser forte em uma camada e fraco em outra.
• A hospedagem multi-tenant pode ser uma escolha razoável para funções restritas e de baixo risco. Estruturas dedicadas compensam o custo quando o agente acessa registros sensíveis, muitas ferramentas internas ou dados regulados.
• As falhas mais danosas são as silenciosas: memória compartilhada, credenciais compartilhadas e logs compartilhados, mais do que invasões dramáticas.
• Peça ao fornecedor que demonstre o isolamento, não que o descreva. Evidências, resultados de testes e um processo claro de incidentes valem mais do que um diagrama.
• Qualquer que seja o modelo, sua empresa deve controlar permissões, aprovações e a possibilidade de exportar ou apagar o que o agente sabe.

O que significam dedicado e multi-tenant para um agente de IA?

Os termos vêm da hospedagem de software. Em um sistema multi-tenant, vários clientes (tenants) usam a mesma aplicação em execução, e o código do fornecedor decide quem vê o quê. Em um sistema dedicado, o cliente recebe a própria instância, e há menos estrutura compartilhada entre os seus dados e os de qualquer outra empresa.

Com agentes de IA, essa pergunta pesa mais do que em um software comum, porque um agente não é só uma aplicação com banco de dados. Ele tem identidade, guarda informações, lê documentos, chama ferramentas e age nas suas contas. Cada uma dessas capacidades é um ponto em que o contexto da sua empresa pode se misturar ao de outra, ou em que o erro de um cliente pode alcançar outro.

Também ajuda separar duas ideias que os fornecedores costumam confundir:

• Isolamento lógico é a separação garantida por software: identificadores de tenant, regras de acesso e filtros dentro de sistemas compartilhados.
• Isolamento físico ou de execução é a separação por construção: processos separados, armazenamento separado, contas separadas e, às vezes, infraestrutura separada.

O isolamento lógico pode ser bem feito. Mas ele depende de cada consulta, cada cache e cada chamada de ferramenta aplicar a regra certa, sempre. O isolamento dedicado de execução reduz em quantos lugares essa regra precisa se sustentar, e essa é a sua principal vantagem.

Quais camadas podem ser compartilhadas e quais não devem?

Uma boa forma de avaliar a resposta de qualquer fornecedor é ir camada por camada. As sete camadas da infraestrutura de IA empresarial funcionam como um mapa geral. Para fins de isolamento, estas são as que mais importam.

• Memória e conhecimento: as anotações, os documentos, o histórico de conversas e o contexto recuperado que o agente usa. Isso nunca deve ser compartilhado entre empresas. Se a memória fica em um índice comum, pergunte exatamente como as consultas são delimitadas.
• Credenciais e identidade: as contas e os tokens que o agente usa para acessar e-mail, agenda, armazenamento e sistemas do negócio. Eles devem pertencer à sua empresa ou a uma identidade criada só para o seu agente. Veja por que o agente de IA da empresa precisa de identidade e contas próprias.
• Ferramentas e integrações: os conectores que o agente pode chamar. Código de conector compartilhado é comum e aceitável se cada chamada rodar com as suas credenciais e as suas permissões, e não com uma conta de serviço agrupada.
• Execução e computação: onde a lógica do agente é de fato executada. Compartilhar computação é o motivo econômico usual do multi-tenant e costuma ser aceitável quando os processos estão bem separados.
• Acesso ao modelo: o modelo de linguagem que o agente chama. A maioria dos agentes usa um modelo hospedado por terceiros, então algum compartilhamento aqui é normal. A pergunta é se os seus dados são retidos, usados em treinamento ou mantidos em cache entre clientes.
• Logs e rastros: os registros do que o agente fez. Os logs costumam conter os textos mais sensíveis do sistema e, com frequência, são a parte menos isolada.
• Configuração e prompts: as instruções que definem a função do agente. São propriedade intelectual sua e não devem vazar para ambientes de outros tenants nem ser editadas por administradores compartilhados sem registro.

Uma regra prática: compartilhar computação genérica é uma decisão de custo, enquanto compartilhar memória, credenciais ou logs é uma decisão de risco. Trate as duas de forma diferente.

O que dá errado quando o isolamento é fraco?

As falhas costumam ser banais. Raramente se parecem com uma invasão de filme. Parecem um pequeno erro que não encontra nenhuma barreira natural para pará-lo.

A recuperação entre tenants é o caso clássico. Um agente consulta um índice de conhecimento compartilhado, e a falta de um filtro devolve um trecho que pertence a outro cliente. Ninguém atacou nada. Uma regra de delimitação foi esquecida em um caminho de consulta.

Credenciais agrupadas são o segundo caso. Se um fornecedor se conecta aos sistemas de vários clientes com uma única conta de serviço compartilhada, qualquer falha ou comprometimento dessa conta tem um raio de impacto amplo, e a sua trilha de auditoria não consegue dizer quais ações foram realmente suas.

A injeção de prompt é o terceiro. Um agente que lê conteúdo externo (e-mails, páginas da web, arquivos enviados) pode receber desse conteúdo uma instrução indevida. Em um ambiente compartilhado, a pergunta passa a ser o que o agente consegue alcançar quando é enganado. O OWASP Top 10 for LLM Applications trata isso como risco central, e a resposta prática é a mesma em qualquer caso: permissões estreitas, para que um agente manipulado não consiga fazer muito.

Logs, caches e ferramentas de depuração são o quarto. A equipe de suporte pode ver rastros de vários clientes, um cache pode entregar uma resposta guardada à parte errada, ou um relatório de erro pode incluir um trecho de documento. É nesses pontos que bons diagramas de arquitetura falham em silêncio.

O fio condutor: quanto menos o seu agente alcança, e quanto menos sistemas ele divide com outros, menor a consequência de qualquer erro isolado.

Quando cada modelo faz sentido?

Nenhuma opção vence em todos os critérios. Plataformas multi-tenant costumam ser mais rápidas de começar e mais simples de contratar. Estruturas dedicadas exigem mais esforço para projetar e operar, mas oferecem limites mais claros, auditorias mais fáceis e mais controle sobre mudanças. O mesmo dilema aparece na decisão entre agentes de IA em nuvem ou hospedagem própria, e as questões de localização se cruzam com a residência de dados em IA.

Use este guia de decisão como ponto de partida.

• Incline-se para multi-tenant quando a função for restrita, os dados tiverem baixa sensibilidade, o agente tiver acesso somente de leitura a poucas ferramentas e um erro for fácil de notar e reverter.
• Incline-se para dedicado quando o agente lê registros de clientes, financeiros, jurídicos ou de pessoal, ou quando ele pode enviar mensagens, alterar registros ou disparar pagamentos em seu nome.
• Incline-se para dedicado quando contratos ou órgãos reguladores exigirem que você mostre onde os dados ficam, quem pode acessá-los e como são apagados.
• Incline-se para dedicado quando você pretende dar ao agente várias integrações ao longo do tempo, já que cada nova ferramenta amplia o que um ambiente compartilhado precisa manter separado.
• Incline-se para multi-tenant, com condições rígidas, quando estiver em um teste inicial. O teste deve provar que a função é útil antes de você investir em infraestrutura mais pesada. Veja o que cada etapa de prova de conceito, piloto e produção deve provar.
• Mantenha a flexibilidade quando houver dúvida. Pergunte se é possível migrar do compartilhado para o dedicado depois, levando junto memória, configuração e logs.

O último ponto pesa mais do que parece. Um ambiente compartilhado do qual você não consegue sair nem exportar nada é um risco diferente de um ambiente compartilhado que você consegue deixar.

O que perguntar ao fornecedor sobre isolamento?

Uma boa conversa sobre isolamento é específica. Estas perguntas foram pensadas para gerar respostas verificáveis, na mesma postura de uma avaliação de segurança de fornecedor de IA.

• Quais componentes são compartilhados entre clientes e quais são criados por cliente? Peça uma resposta camada por camada, cobrindo memória, credenciais, execução, logs e configuração.
• Como a recuperação de informações é delimitada? O conhecimento de cada cliente fica em um índice ou repositório separado, ou em um compartilhado com filtros? Se houver filtros, onde são aplicados e como são testados?
• De quem são as credenciais que o agente usa? São contas nossas, de uma identidade dedicada ao agente ou de uma conta agrupada do fornecedor?
• O que o agente pode fazer por padrão e quem aprova mudanças nisso? Peça para ver a lista de permissões, em linguagem simples, e como ela é revisada.
• Quem, dentro do fornecedor, pode ver nossos dados, logs ou conversas? Em que condições, com qual aprovação e com que registro de acesso?
• Como logs e rastros são separados, retidos e apagados? Eles contêm prompts, documentos ou dados pessoais?
• O que é enviado ao provedor do modelo, e algo disso é retido, mantido em cache entre clientes ou usado em treinamento?
• Como vocês testam o isolamento? Peça o método (por exemplo, tentativas deliberadas de acesso entre tenants) e a frequência, não uma promessa genérica.
• O que acontece quando algo dá errado? Pergunte como vamos ser avisados, quem conduz a resposta e o que poderemos ver depois.
• Como saímos? Pergunte o que podemos exportar (memória, configuração, logs) e como a exclusão é confirmada. Isso se liga diretamente a quem é dono dos prompts e dados na IA da empresa.

Trate respostas vagas como informação. Um fornecedor que explica um desenho com clareza e admite seus limites costuma ser mais seguro do que um que responde a tudo com a palavra seguro.

Um cenário ilustrativo: duas formas de hospedar uma mesma função

Este cenário é ilustrativo, não um caso real.

Uma empresa regional de serviços quer um agente para ajudar a equipe de operações a preparar resumos semanais a partir de anotações internas e de uma pasta compartilhada. No primeiro desenho, o agente roda em uma plataforma multi-tenant. O conhecimento fica em um índice compartilhado com filtros por tenant, e a conexão com a pasta é feita por uma conta de integração agrupada. No segundo desenho, o agente tem identidade própria no ambiente de trabalho da empresa, um repositório de conhecimento próprio e acesso somente de leitura a uma única pasta.

Os dois desenhos produzem o resumo em um dia normal. A diferença aparece em um dia anormal. Suponha que um documento da pasta contenha um texto oculto mandando o agente encaminhar o conteúdo para outro lugar. No primeiro desenho, o alcance do agente depende da conta agrupada, e a trilha de auditoria não separa com facilidade as ações desta empresa das de outras. No segundo, o agente não tem canal de saída e só uma pasta para ler, então o raio de impacto é pequeno e o log mostra exatamente o que aconteceu.

A empresa ainda pode escolher o primeiro desenho para um teste com anotações não sensíveis. O ponto é escolher com consciência e impor condições: uma pasta limitada, nenhuma ação de saída e um plano para migrar ao segundo desenho antes de a função crescer.

Como a Be Human trata o isolamento

A Be Human projeta cada agente em torno da identidade, da memória, dos canais, das ferramentas e das permissões de uma única empresa, com limites de aprovação definidos no primeiro ciclo de trabalho. A operação gerenciada inclui monitoramento, revisão de permissões, manutenção de integrações e resposta a incidentes, de modo que o isolamento é verificado como prática contínua e não resolvido uma vez só na configuração. A empresa mantém o controle sobre o que o agente pode alcançar e o que deve lembrar. Na escolha de um fornecedor, os guias sobre perguntas para fornecedor de agentes de IA antes de assinar e como verificar as promessas de um fornecedor de IA valem para a Be Human tanto quanto para qualquer outro.

Perguntas frequentes

Um agente de IA dedicado é sempre mais seguro do que um multi-tenant? Não. Um agente dedicado com permissões amplas, aprovações fracas e monitoramento ruim pode ser mais arriscado do que um compartilhado bem operado. Estruturas dedicadas reduzem o que é compartilhado, mas a segurança continua dependendo de permissões estreitas, acessos revisados e controles testados.

Multi-tenant significa que meus dados ficam misturados com os de outras empresas? Não necessariamente. Em um sistema multi-tenant bem construído, os dados são armazenados e recuperados sob regras específicas de cada tenant, ficando separados mesmo com a infraestrutura compartilhada. O risco é que essas regras precisam se sustentar em todos os pontos, e por isso vale perguntar como a delimitação é aplicada e testada.

Posso começar em hospedagem compartilhada e migrar para dedicada depois? Muitas vezes sim, se isso for planejado. Pergunte antes de assinar se memória, configuração e logs podem ser exportados em formato utilizável, e se a identidade e as integrações do agente podem ser recriadas sob as suas próprias contas. A migração fica muito mais difícil quando essas peças estão presas dentro da plataforma do fornecedor.

Qual é a pergunta de isolamento mais útil? Pergunte de quem são as credenciais que o agente usa e o que exatamente ele alcança com elas. A resposta revela o limite real: uma identidade dedicada, com permissões estreitas e revisadas, reduz o dano de quase qualquer outra falha, inclusive erros em sistemas compartilhados.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.