Residência de Dados no TrueFoundry AI Gateway

Introdução

Os sistemas de IA já não são ferramentas passivas. Estão cada vez mais agênticos – operando autonomamente em fluxos de trabalho, APIs e dados empresariais sensíveis. Em sistemas tradicionais, a residência de dados era definida pelo local onde os dados eram armazenados. Uma vez que as bases de dados e o armazenamento residissem em regiões aprovadas, a conformidade era considerada resolvida.

A IA agêntica quebra esse modelo. Cada interação gera novas superfícies de dados – prompts, memória do agente, registos, rastreios e dados de inferência transitórios, que são processados e observados em tempo de execução, muitas vezes em várias regiões, mesmo quando nada é persistido.

Como resultado, a residência de dados já não é um mero item de conformidade. É uma questão fundamental de infraestrutura agora discutida ao nível da administração. A pergunta que as empresas devem responder é simples: Para onde se movem os dados gerados por IA em tempo de execução e quem controla esses caminhos?

Na TrueFoundry, a residência de dados é aplicada no Gateway de IA, onde a inferência, os agentes e as ferramentas convergem. A residência é tratada como uma propriedade do sistema, aplicada em condições de operação normal, falhas e escala. Este blogue explica como a residência de dados é definida, aplicada e verificada no Gateway de IA da TrueFoundry.

Por que a Residência de Dados é Mais Difícil em Sistemas de IA

A residência de dados era mais simples quando as aplicações tinham caminhos de dados previsíveis. As requisições fluíam dos usuários para os serviços e para os bancos de dados, geralmente dentro de uma única região, e os controles de conformidade eram em grande parte estáticos.

Sistemas de IA quebram este modelo em tempo de execução.

Em arquiteturas de IA modernas, o movimento de dados é dinâmico e orientado por decisões, não fixo. Uma única requisição de usuário pode acionar múltiplos caminhos de execução, todos orquestrados pelo AI Gateway. É aqui que a residência de dados se torna frágil.

Em tempo de execução, um AI Gateway pode:

• Selecionar um modelo com base na disponibilidade, latência ou política
• Retentar uma requisição se um endpoint de modelo atingir o tempo limite
• Fazer failover para um endpoint alternativo durante interrupções parciais
• Invocar ferramentas a jusante ou servidores MCP como parte dos fluxos de trabalho do agente
• Emitir prompts, respostas e rastreamentos para pipelines de observabilidade

Cada uma dessas decisões pode introduzir movimento de dados implícito, muitas vezes sem que a aplicação tenha conhecimento disso.

As falhas mais comuns de residência de dados em sistemas de IA ocorrem:

• Durante failover, quando o tráfego é silenciosamente roteado para outra região
• Durante roteamento multimodelos, quando apenas alguns modelos têm escopo regional
• Através de invocação de ferramentas orientada por agente, onde as ferramentas residem em diferentes regiões
• Através de logs e telemetria, que são frequentemente exportados por padrão

Crucialmente, essas falhas ocorrem mesmo quando:

• A aplicação é implantada na região
• O modelo principal está hospedado localmente
• Os sistemas de armazenamento são restritos à região

Por que o Gateway de IA se Torna o Ponto de Aplicação

Todas essas falhas têm uma coisa em comum: elas ocorrem em tempo de execução, impulsionadas por roteamento, novas tentativas, execução de agente e comportamento de registro.

O Gateway de IA é a única camada que:

• Vê cada requisição antes da execução
• Controla a seleção de modelos, novas tentativas e failover
• Intermedia a invocação de agentes e ferramentas
• Emite dados de observabilidade

É por isso que a residência de dados em sistemas de IA não pode ser garantida apenas pela configuração de implantação. Ela deve ser imposta no Gateway de IA, onde os caminhos de execução são decididos em tempo real.

Em plataformas como TrueFoundry, a residência é tratada como um restrição rígida de tempo de execução, não uma preferência de melhor esforço, garantindo que nenhum caminho de execução, incluindo cenários de falha, possa violar os limites regionais.

A Nova Responsabilidade de Dados de IA: Prompts, Logs e Dados Transitórios

Sistemas de IA Agentes não apenas usam dados, eles geram continuamente novas superfícies de dados em tempo de execução. Essas superfícies não existiam em aplicações tradicionais, e elas mudam fundamentalmente o que a residência de dados deve considerar.

Em sistemas de IA, a residência de dados não se limita mais a dados em repouso. Ela se estende a cada dado criado, processado ou observado durante a inferência e a execução do agente, mesmo que esses dados existam apenas brevemente.

Os mais importantes dessas novas responsabilidades de dados são frequentemente os menos visíveis.

Prompts e Estado do Agente

Solicitações de inferência transportam prompts e respostas através do AI Gateway, frequentemente contendo lógica proprietária, dados de clientes ou contexto interno sensível. Ao contrário das APIs tradicionais, esses dados são de formato livre e não higienizados, tornando-os particularmente de alto risco.

Fluxos de trabalho agentivos introduzem contexto e memória persistentes entre interações. Se esse estado for processado ou reproduzido fora das regiões aprovadas, a residência é violada, mesmo quando as chamadas de inferência individuais parecem conformes.

Logs, Telemetria e Dados Transitórios

Sistemas de IA também geram logs, rastreamentos, embeddings e metadados de execução que podem codificar informações sensíveis. Se os pipelines de observabilidade exportarem esses dados entre regiões, violações ocorrem silenciosamente.

Crucialmente, os dados não precisam ser armazenados para serem não conformes. Dados de inferência transitórios, processados apenas em memória por milissegundos, ainda se enquadram nos requisitos de residência se cruzarem um limite jurisdicional.

Por que isso muda a aplicação da residência

Os controles de residência tradicionais foram projetados para sistemas estáticos, não para roteamento dinâmico, novas tentativas, failover e execução orientada por agentes. Em sistemas de IA, a residência deve ser aplicada em tempo de execução, onde esses caminhos de dados são criados.

Em plataformas como TrueFoundry, essa aplicação acontece no Gateway de IA, onde prompts, contexto do agente, novas tentativas e telemetria convergem, tornando a residência uma propriedade do sistema em vez de uma suposição.

Arquitetura TrueFoundry: Onde a Residência de Dados é Aplicada

Garantir a residência de dados em sistemas de IA exige mais do que uma implantação regional. Exige clara separação de responsabilidades em toda a pilha de IA, para que os caminhos de execução, controle e dados possam ser governados independentemente.

TrueFoundry é projetado em torno de uma arquitetura de plano dividido que que torna isso possível.

Em um nível superior, a plataforma é composta por três planos distintos:

1. Plano de Controle
2. Plano de Gateway
3. Plano de Computação

Essa separação é fundamental para como a residência de dados é aplicada de forma confiável em tempo de execução.

Plano de Controle: Configuração e Orquestração

O plano de controle é a camada de orquestração da plataforma TrueFoundry. É responsável por:

• Gerenciar a configuração e as políticas da plataforma
• Definir regras de roteamento, residência e acesso
• Coordenar implantações de gateway entre regiões
• Gerenciar metadados, estado da configuração e configurações de governança

Crucialmente, o plano de controle não processa tráfego de inferência e não executa cargas de trabalho. Ele define o que deve acontecer, não onde os dados fluem em tempo de execução.

Para empresas com requisitos rigorosos de conformidade, o TrueFoundry suporta ambos:

• Implantações de plano de controle hospedadas
• Implantações de plano de controle auto-hospedadas (opção empresarial)

Isso permite que as organizações escolham o equilíbrio adequado entre simplicidade operacional e requisitos de soberania, sem alterar como a aplicação da residência funciona a jusante.

Plano de Gateway: Camada de Aplicação em Tempo de Execução

‍

O plano de gateway é onde a residência de dados é ativamente aplicada.

Os Gateways de IA da TrueFoundry ficam entre as aplicações e todos os fornecedores de modelos, atuando como:

• Um controlador de tráfego, decidindo para onde as requisições são roteadas
• Um firewall de conformidade, impedindo caminhos de execução não conformes
• Um ponto de aplicação de políticas, aplicando regras de residência em tempo de execução

Cada requisição de inferência, nova tentativa, failover, invocação de agente e evento de observabilidade passa pelo gateway. Isso lhe confere visibilidade total sobre:

• Seleção de modelo
• Decisões de roteamento e fallback
• Execução de ferramentas de agente e MCP
• Prompts, respostas e telemetria

Devido a isso, o plano de gateway é o única camada capaz de impor a residência de dados como uma restrição rígida.

Se uma solicitação não puder ser atendida dentro dos limites de residência configurados, o gateway rejeita a solicitação, fechando o acesso em vez de roteá-la silenciosamente para uma região não-conforme.

Esta é a principal diferença entre imposição em tempo de execução e configuração de melhor esforço.

Plano de Computação: Ambiente de Execução de Propriedade do Cliente

O plano de computação é onde aplicativos, agentes e cargas de trabalho realmente são executados.

Na TrueFoundry, o plano de computação:

• Sempre é executado dentro da infraestrutura de propriedade do cliente
• É tipicamente um ou mais clusters Kubernetes (EKS, GKE, AKS, OpenShift ou on-premise)
• Nunca é operado ou acessado diretamente pela TrueFoundry

Este design garante que:

• O código do aplicativo nunca sai do ambiente do cliente
• As solicitações de inferência se originam da infraestrutura controlada pelo cliente
• Garantias de residência de dados não são comprometidas por ambientes de execução compartilhados

A TrueFoundry não executa cargas de trabalho de clientes em computação compartilhada. Em vez disso, ela se integra aos clusters existentes do cliente ou ajuda a provisionar novos, mantendo a execução firmemente dentro do limite de confiança da organização.

Por que esta arquitetura é importante para a residência de dados

Esta separação de planos permite à TrueFoundry impor a residência de dados sem comprometer:

• Plano de controle define a política de residência
• Plano de gateway a impõe em tempo de execução
• Plano de computação garante que a execução permaneça dentro dos limites do cliente

Como a imposição ocorre no gateway — onde roteamento, novas tentativas, agentes e logs convergem —, a residência de dados se mantém mesmo sob:

• Falhas e novas tentativas
• Roteamento multimodelos
• Fluxos de trabalho com agentes
• Observabilidade de alto volume

É isso que permite que a residência de dados se torne uma propriedade do sistema, não uma suposição ligada a diagramas de implantação.

Como a TrueFoundry Garante a Residência de Dados

A residência de dados em sistemas de IA não é uma configuração simples — ela deve ser garantida em execução, roteamento e armazenamento. Na TrueFoundry, isso é alcançado através de três modos de aplicação complementares que, juntos, cobrem todo o ciclo de vida dos dados de IA.

Cada modo aborda uma classe diferente de risco de residência e pode ser usado de forma independente ou em combinação, dependendo dos requisitos da empresa.

1. Os Dados Nunca Saem do Seu Ambiente

Para organizações com as mais rigorosas necessidades de residência e conformidade, a TrueFoundry permite um modelo de implantação onde os dados nunca saem do ambiente do cliente.

Neste modo:

• Todas as cargas de trabalho da aplicação são executadas dentro de clusters Kubernetes de propriedade do cliente
• Modelos, artefatos e tráfego de inferência permanecem dentro da conta de nuvem do cliente ou ambiente on-premise
• Nenhum dado do cliente é processado em computação compartilhada de propriedade da TrueFoundry
• A saída de dados para sistemas externos pode ser totalmente eliminada

Isso se aplica a ambos:

• Implantações de plano de controle auto-hospedadas
• Implantações de plano de controle gerenciado, onde os clientes ainda mantêm controle sobre a região de gateway, armazenamento e limites de execução

Ao garantir que os caminhos de execução e de dados permaneçam inteiramente dentro da infraestrutura controlada pelo cliente, este modo oferece as mais fortes garantias de residência possíveis e simplifica as auditorias regulatórias.

2. Dados Restritos a um País ou Região Específica

Muitas empresas precisam operar globalmente, garantindo que os dados de uma determinada geografia nunca ultrapassem as fronteiras jurisdicionais.

A TrueFoundry impõe isso através de implantações de AI Gateway específicas para cada região:

• Os endpoints do Gateway são implantados em regiões ou países específicos
• As solicitações roteadas através de um determinado endpoint do gateway são processadas apenas dentro dessa região
• O roteamento, as tentativas e os caminhos de failover são restritos à infraestrutura local da região

As aplicações escolhem explicitamente qual endpoint de gateway regional usar. Isso torna a residência de dados:

• Explícita, não implícita
• Configurável por carga de trabalho ou ambiente
• Aplicável em tempo de execução, não apenas na implantação

Se não existir um caminho de execução compatível com a residência para uma solicitação, o gateway fecha a solicitação com falha em vez de roteá-la para outra região. Isso garante que os mecanismos de disponibilidade nunca anulem a intenção de conformidade.

3. Armazenamento Específico da Região por Carga de Trabalho

A inferência e a execução são apenas parte do panorama da residência de dados. Logs, rastreamentos, prompts e telemetria frequentemente contêm informações igualmente sensíveis e devem seguir as mesmas regras de residência.

O TrueFoundry permite que as empresas imponham a residência na camada de armazenamento ao:

• Usando projetos de rastreamento e registro específicos da região
• Oferecendo suporte a buckets de armazenamento gerenciados pelo cliente implantados em regiões específicas
• Garantindo que os dados de observabilidade sejam gravados apenas em armazenamento regional aprovado

Isso torna possível:

• Armazenar dados europeus exclusivamente em regiões da UE
• Manter cargas de trabalho regulamentadas (por exemplo, ITAR, financeiras, de saúde) restritas a limites nacionais
• Isolar dados entre regiões, mesmo dentro da mesma implantação global

Como essas escolhas de armazenamento estão integradas diretamente na configuração do AI Gateway e do SDK, os dados de observabilidade seguem as mesmas garantias de residência que o tráfego de inferência.

Por Que Esses Três Modos São Importantes Juntos

Cada modo de imposição resolve um problema diferente:

• Isolamento em nível de ambiente impede a saída de dados não controlada
• Gateways de nível regional restringem os caminhos de execução em tempo de execução
• Armazenamento específico da região fecha lacunas de observabilidade e registro

Juntos, eles garantem que a residência de dados seja aplicada:

• Em inferência, agentes e ferramentas
• Em cenários de execução normal e falha
• Em dados em repouso e dados em movimento

Essa abordagem em camadas é o que permite à TrueFoundry transformar a residência de dados de uma configuração de melhor esforço em uma propriedade de sistema verificável e imposta em tempo de execução.

Na TrueFoundry, a residência de dados é aplicada através de múltiplas camadas explícitas dentro do AI Gateway, cada um abordando uma classe diferente de risco em tempo de execução.

Essas camadas trabalham juntas para garantir que as garantias de residência sejam mantidas em condições do mundo real.

Como a Residência de Dados é Aplicada em Tempo de Execução no Gateway de IA da TrueFoundry

Em sistemas de IA, as garantias de residência de dados só são válidas se forem aplicadas em tempo de execução, em cada caminho de execução, não apenas durante a operação em estado estável. Na TrueFoundry, o Gateway de IA é o ponto de aplicação onde decisões de roteamento, novas tentativas, execução de agentes e observabilidade convergem.

Os seguintes mecanismos explicam como a residência de dados é aplicada de forma determinística dentro do Gateway de IA da TrueFoundry.

Roteamento de Inferência e Residência de Modelo

Os modelos na TrueFoundry são registrados com afinidade de região explícita. O Gateway de IA avalia as restrições de residência antes de rotear qualquer solicitação e seleciona apenas endpoints de modelo que são elegíveis para a região permitida da carga de trabalho.

Isso evita:

• Uso acidental de modelos hospedados globalmente ou não residentes
• Roteamento entre regiões durante o balanceamento de carga
• Desvio de residência à medida que novos modelos são adicionados ou modelos existentes são atualizados

Como a residência é tratada como uma restrição de roteamento rígida, não uma preferência, modelos não conformes nunca são considerados — mesmo que estejam disponíveis ou sejam mais rápidos.

Controles de Retentativa, Failover e Alta Disponibilidade

Retentativas e caminhos de failover são a fonte mais comum de violações silenciosas de residência de dados em sistemas de IA.

O AI Gateway da TrueFoundry impõe:

• Pools de retentativa bloqueados por região, garantindo que as retentativas nunca saiam da região permitida
• Failover com reconhecimento de residência, onde os alvos de fallback são restritos à mesma jurisdição
• Comportamento de falha fechada, onde as solicitações são rejeitadas se não houver um caminho de execução em conformidade com a residência

Isso garante que os mecanismos de disponibilidade nunca anulem a intenção de conformidade. Se um caminho em conformidade não estiver disponível, o sistema falha explicitamente em vez de rotear dados entre regiões.

Execução de Ferramentas de Agente e MCP

Para cargas de trabalho agentivas, a residência de dados deve permanecer consistente em inferência de modelo e invocação de ferramentas a jusante.

A TrueFoundry garante:

• Ambientes de execução de agente restritos à região
• Prevenção da invocação de ferramentas MCP entre regiões
• Políticas de residência consistentes em fluxos de trabalho de agente de várias etapas

Isso elimina um modo de falha comum onde a inferência permanece em conformidade, mas os agentes vazam dados indiretamente através de ferramentas ou servidores MCP implantados em outras regiões.

Observabilidade, Logs e Telemetria

Os pipelines de observabilidade são frequentemente negligenciados em projetos de residência de dados, apesar de frequentemente conterem dados altamente sensíveis.

O AI Gateway da TrueFoundry garante que:

• Prompts, respostas e rastreamentos podem ser armazenados na região
• A exportação de telemetria respeita as mesmas restrições de residência que a inferência
• Caminhos de depuração e monitoramento não vazam dados através de limites regionais

Isso fecha uma das lacunas de residência mais persistentes em sistemas de IA, onde a inferência está em conformidade, mas os logs e rastreamentos não estão.

Por que a Aplicação em Tempo de Execução Importa

Esses mecanismos de aplicação se aplicam uniformemente em:

• Caminhos de execução normais
• Retentativas e falhas parciais
• Roteamento multimodelos
• Fluxos de trabalho orientados a agentes e a ferramentas

Como a aplicação ocorre antes da execução, a residência de dados torna-se uma propriedade verificável do sistema, e não uma configuração de melhor esforço vinculada à alocação da infraestrutura.

Cenários Comuns de Falha na Residência de Dados e Como a TrueFoundry os Evita

A maioria das violações de residência de dados em sistemas de IA não são causadas por configurações incorretas óbvias. Elas surgem de casos de borda e caminhos de exceção que raramente são testados até que algo dê errado.

A seguir, estão os cenários de falha mais comuns que as empresas enfrentam e como o TrueFoundry AI Gateway foi projetado para evitá-los.

Cenário de Falha 1: Failover entre Regiões Durante Interrupções

‍O que acontece em muitos sistemas
Um endpoint de modelo regional torna-se indisponível. O AI Gateway tenta novamente automaticamente ou faz failover para o próximo endpoint disponível, muitas vezes em outra região.

Do ponto de vista da disponibilidade, isso parece um sucesso.
Do ponto de vista da conformidade, é uma violação silenciosa.

Como a TrueFoundry evita isso

• Alvos de failover estão restritos à mesma região
• Pools de repetição são restritos por região
• Se nenhum endpoint compatível existir, a solicitação é bloqueada

Isso garante que mecanismos de disponibilidade nunca substituam a política de residência.

Cenário de Falha 2: Residência Parcial em Configurações Multi-Modelo

O que acontece em muitos sistemas
Alguns modelos são implantados na região, enquanto outros (muitas vezes backups ou modelos mais recentes) são hospedados globalmente. As políticas de roteamento selecionam, sem intenção, modelos não residentes.

Como a TrueFoundry evita isso

• Os modelos são registrados com afinidade de região explícita
• A residência é imposta como uma restrição de roteamento rígida
• Modelos não compatíveis nunca são elegíveis para seleção

Isso torna as garantias de residência resilientes à rotatividade de modelos e à experimentação.

Cenário de Falha 3: Invocação de Ferramenta Entre Regiões Acionada por Agente

O que acontece em muitos sistemas
A inferência é executada localmente, mas os agentes invocam ferramentas ou servidores MCP implantados em outras regiões, criando movimentação indireta de dados.

Como a TrueFoundry evita isso

• A execução do agente e o acesso às ferramentas MCP têm escopo regional
• A invocação de ferramentas entre regiões é bloqueada no gateway
• As políticas de residência aplicam-se uniformemente em fluxos de trabalho de várias etapas

Isso mantém a residência consistente durante a inferência e execução a jusante.

Cenário de Falha 4: Vazamento de Observabilidade e Telemetria

O que acontece em muitos sistemas
Prompts, respostas e rastreamentos são exportados para serviços centralizados de registro ou monitoramento fora da região, muitas vezes por padrão.

Como a TrueFoundry evita isso

• Pipelines de observabilidade são cientes da residência
• A exportação de telemetria é explicitamente configurada e restrita
• Caminhos de depuração respeitam as mesmas regras de residência que a inferência

Isso fecha uma das lacunas de conformidade mais frequentemente negligenciadas em sistemas de IA.

Como as Empresas Podem Verificar a Residência de Dados na TrueFoundry

As garantias de residência só são significativas se puderem ser verificadas e demonstradas. A TrueFoundry permite que as empresas validem a residência de dados através de visibilidade e auditabilidade em tempo de execução, e não por suposições a posteriori.

Visibilidade da Aplicação em Tempo de Execução

O Gateway de IA fornece visibilidade sobre:

• Qual endpoint do modelo processou uma solicitação
• Em que região a execução ocorreu
• Se algum caminho de nova tentativa ou de fallback foi acionado

Isso permite que as equipes confirmem que cada caminho de execução permaneceu em conformidade.

Logs e Rastreamentos Prontos para Auditoria

Para revisões de conformidade e segurança, a TrueFoundry apresenta:

• Logs estruturados mostrando decisões de roteamento e execução
• Metadados de região associados a inferência e ações de agente
• Evidência de que caminhos não conformes foram bloqueados

Isso torna possível comprovar a residência durante auditorias, em vez de depender apenas de diagramas arquitetônicos.

Testando a Residência Sob Condições de Falha

Uma vantagem fundamental da aplicação ao nível do gateway é a testabilidade.

As empresas podem:

• Simular interrupções regionais
• Observar o comportamento de failover
• Validar que as solicitações falham de forma segura em vez de serem redirecionadas entre regiões

Isso transforma a residência de um requisito estático em uma propriedade de sistema continuamente verificável.

Conclusão

Em sistemas de IA modernos, a residência de dados não pode ser garantida apenas por escolhas de implantação. O roteamento dinâmico, as novas tentativas, os fluxos de trabalho de agentes e os pipelines de observabilidade introduzem caminhos de execução onde os dados podem cruzar silenciosamente as fronteiras regionais.

O AI Gateway é a única camada com contexto suficiente para evitar isso. Ele vê cada solicitação de inferência, cada nova tentativa, cada ação de agente e cada rastro emitido pelo sistema. Se a residência não for imposta aqui, ela não poderá ser imposta de forma consistente em nenhum outro lugar.

Na TrueFoundry, a residência de dados é tratada como uma propriedade de sistema em tempo de execução. Os caminhos de execução são restritos por design, os casos de exceção falham de forma segura e a aplicação é observável e auditável. Isso torna as garantias de residência resilientes não apenas em estado estável, mas também em caso de falha, escala e mudança.

Para empresas que implementam IA em ambientes regulamentados ou multirregionais, essa distinção importa. A residência de dados não é mais um item a ser marcado; é um compromisso arquitetônico. E o AI Gateway é onde esse compromisso se torna realidade.