Saltar para o conteúdo principal
Quando um auditor ou um regime de privacidade pergunta “onde essa evidência reside?”, eles querem dizer o artefato — o PDF, CSV ou JSON assinado em que seu relatório de compliance renderiza. A configuração de residência de dados de IA do OrcaRouter responde exatamente essa pergunta: ela declara a região sob a qual seus relatórios de compliance assinados são armazenados e servidos, carimba cada relatório que você gera com ela, e retém qualquer relatório cuja região carimbada não mais corresponda. Esta é uma propriedade do artefato de relatório, não uma afirmação sobre onde a inferência roda. Se você veio aqui procurando fixar o tráfego de modelo a uma região, isso é uma decisão de roteamento upstream e vive em outro lugar — leia a seção 4 antes de confiar nisso.

​
1. O que a residência de dados de IA controla

Um workspace declara uma região. A partir desse ponto:
  • cada relatório de compliance que você gera é carimbado com a região declarada;
  • o artefato renderizado é armazenado particionado por região;
  • uma leitura cross-region é retida — um relatório carimbado eu não baixará enquanto o workspace declara us;
  • a divulgação de fluxos de dados do relatório afirma claramente que os provedores de modelo upstream (subprocessadores) processam os dados de requisição em suas próprias regiões.
A região é um entre seis códigos:
CódigoRegião
usEstados Unidos
euUnião Europeia (EEE)
ukReino Unido
apÁsia-Pacífico
cnChina
globalGlobal / sem restrição
Deixar a residência não definida também é válido — um relatório não carimbado não carrega afirmação de residência e é servido sem uma checagem de região.
Ler a região atual é aberto a qualquer Member do workspace (faz parte da superfície de compliance gratuita e somente-navegação). Alterá-la exige Admin do workspace — diferente de instalar um pack ou ir ao ar, definir a residência não é separadamente paywalled. Veja Plan gating.

​
2. Defina a região (um fluxo concreto)

Defina a residência a partir do console em Compliance → Settings, logado como Admin do workspace. O console conduz a rota de gerenciamento por você usando a sua sessão — esta é uma rota UserAuth, nunca uma chave de relay (sk-orca-…): 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
A resposta ecoa a região que você definiu. Para ler o valor atual e as opções selecionáveis (para um dropdown de configurações), a rota de leitura correspondente é aberta a Members: 
GET /api/compliance/residency
Authorization: Bearer <your console session>

{
  "region": "eu",
  "options": [
    { "code": "us", "label": "United States" },
    { "code": "eu", "label": "European Union (EEA)" },
    { "code": "uk", "label": "United Kingdom" },
    { "code": "ap", "label": "Asia-Pacific" },
    { "code": "cn", "label": "China" },
    { "code": "global", "label": "Global / no restriction" }
  ]
}
Defina a residência uma vez, de antemão, antes de gerar os relatórios em que seu auditor vai confiar. A região que um relatório carrega é fixada no momento da geração — veja a próxima seção para o que acontece quando você a altera depois.

​
3. Alterando a região depois que relatórios existem

A residência é aplicada no momento do download contra a região atual declarada do workspace. Um relatório carimbado sob a região que estava declarada quando ele foi gerado só será servido enquanto o workspace ainda declarar essa mesma região. Então se você gera relatórios sob us, depois troca o workspace para eu, esses relatórios anteriores carimbados us param de baixar — o gateway os retém em vez de servir um artefato sob uma afirmação de residência que ele não pode mais satisfazer. A correção é regenerar o relatório sob a nova região.
Alterar a residência não re-carimba retroativamente relatórios existentes. Após uma mudança de região, regenere qualquer relatório que você ainda precise baixar. Isso é intencional: um artefato nunca é re-rotulado com uma região sob a qual não foi produzido. A página dedicada Leituras cross-region cobre programas multi-região em profundidade.

​
4. O que a residência NÃO é

Esta é a distinção que a maioria das equipes erra, então ela ganha sua própria seção.
Definir region: eu não roteia seu tráfego de modelo através de infraestrutura da UE. Ela governa onde o artefato de evidência reside, não onde o modelo roda. Os provedores upstream processam os dados de requisição em suas próprias regiões; o relatório divulga esse fluxo em vez de constrangê-lo.
A residência carimba relatórios de compliance. O armazenamento e a retenção de logs de requisição são governados separadamente — veja Retenção para o padrão de 30 dias e o máximo de 180 dias server-clamped.
Uma região declarada mais a divulgação de subprocessador do relatório é evidência que você pode entregar a um auditor — não é um acordo legal de processamento de dados. Combine-a com seus próprios controles contratuais.
Se uma regulação genuinamente exige que a inferência permaneça na região, isso é uma decisão de roteamento upstream distinta de onde sua evidência é armazenada. Seja preciso com os auditores sobre qual garantia você está fazendo.

​
5. Onde isto se encaixa

A residência é um botão no fluxo de compliance mais amplo — instale um pack, observe-o, vá ao ar, gere um relatório assinado e armazene esse relatório sob uma região declarada.

Visão geral de compliance

O loop completo — instale, observe, aplique e entregue evidência assinada.

Leituras cross-region

Por que um relatório carimbado com uma região não serve sob outra, e como rodar um programa multi-região.

Relatório assinado

Como cada relatório obtém seu hash SHA-256 e sua assinatura Ed25519.

Plan gating

Quais ações de compliance são gratuitas para ler e quais precisam de um Admin pago.
Para a fronteira entre o que o gateway garante e o que continua sendo seu, o mapa de Responsabilidade compartilhada coloca a residência em contexto: o gateway controla seus próprios artefatos de evidência; suas decisões de subprocessador e infraestrutura continuam sendo suas.