Multi-tenant
Arquitetura em que cada organização ou área opera em um espaço isolado (organização), com dados, chaves, budgets e permissões que não se misturam.
Por que importa
Multi-tenant é a arquitetura em que uma mesma plataforma atende várias organizações, mantendo cada uma num espaço isolado: dados, chaves, orçamentos e permissões de uma organização não tocam os da outra. Importa porque, sem esse isolamento, compartilhar infraestrutura vira risco de contaminação — o dado de um cliente aparecendo para outro, o gasto de uma área caindo no orçamento da vizinha, uma permissão vazando entre fronteiras que deveriam ser estanques.
No contexto de governança de IA, o isolamento é a base sobre a qual todo o resto se apoia. Allowlist de modelos por organização, budget por centro de custo, trilha de auditoria por identidade — nada disso faz sentido se as fronteiras entre organizações não forem reais. A pergunta que define uma boa arquitetura multi-tenant é simples e implacável: é possível, de dentro de uma organização, alcançar o dado de outra? A resposta tem que ser não, e tem que ser comprovável.
Como funciona
Cada chamada carrega a identidade da organização à qual pertence, e essa identidade acompanha a requisição por toda a camada. As consultas a dados são filtradas por essa marca de organização, de modo que uma leitura nunca devolve o que é de outra. Chaves, orçamentos e permissões são igualmente escopados: a chave virtual de um time só alcança os recursos daquele time, o orçamento é contabilizado dentro da organização, e uma permissão concedida numa não tem efeito na outra.
O ponto delicado é o escopo na borda: a identidade da organização não pode ser forjada pelo cliente. Por isso ela é injetada por um ponto confiável — o gateway — que sobrescreve qualquer tentativa do cliente de se passar por outra organização. Sem isso, o isolamento seria só uma convenção; com isso, é uma fronteira que o cliente não controla.
Como a Horse Labs trata
Na Horse Labs, cada organização opera numa organização isolada: as consultas do BFF são filtradas pela identidade da organização, que vem assinada do gateway e não pode ser forjada pelo cliente. Allowlist, budgets e secrets são escopados por organização, e a tentativa de alcançar recursos de outra resulta em recusa, não em vazamento. O isolamento não fica só na intenção — é coberto por testes de integração que verificam, caso a caso, que uma organização não enxerga o que pertence a outra.
Erros comuns
O erro mais comum é confiar no filtro de organização vindo do cliente: deixar a aplicação aceitar a identidade que a requisição declara em vez de injetá-la num ponto confiável. Aí basta um cliente mal-intencionado mudar um cabeçalho para cruzar a fronteira. O segundo erro é tratar o isolamento como verdade não testada — assumir que o filtro está em toda consulta sem provar. Em arquitetura multi-tenant, isolamento não comprovado por teste é isolamento que ainda não existe: a única garantia é a que se verifica.