Saltar para o conteúdo principal
Você declarou a residência do seu workspace como eu, gerou um relatório SOC 2 sob ela, e depois trocou o workspace para us. O que acontece com o antigo relatório eu? O OrcaRouter o retém. Um relatório de compliance assinado é carimbado por região no momento da geração, e ele só é servido enquanto a região atual declarada do seu workspace ainda corresponder a esse carimbo. Uma leitura cross-region é negada — o artefato nunca é entregue sob uma afirmação de residência que ele não pode mais satisfazer. Esta página cobre essa única regra: a restrição de leitura. Para declarar e alterar a própria região, veja Residência de dados; para o que há dentro do artefato, veja Relatório assinado.

1. Por que uma restrição de relatório de residência de dados existe

Um relatório assinado carrega uma afirmação de residência. Quando você o gera sob eu, a divulgação do relatório afirma que o artefato de evidência é carimbado para a União Europeia e armazenado particionado por região. Se o gateway então servisse esse mesmo artefato depois que você moveu o workspace para us, a cópia servida estaria fazendo uma afirmação de residência que ela não mais sustenta.
A restrição é sobre o artefato de evidência, não sobre seu tráfego de inferência. Declarar uma região carimba e particiona por localidade os relatórios de compliance que o gateway produz. É uma divulgação honesta + controle de localidade de artefato — ela não geo-fixa em qual região um provedor de modelo upstream processa seus prompts. Os provedores upstream (subprocessadores) processam os dados de requisição em suas próprias regiões, e o relatório divulga exatamente isso.
Então, em vez de servir silenciosamente um artefato agora incompatível, o OrcaRouter o retém e diz para você regenerá-lo sob a região atual.

2. A regra de correspondência

A regra é uma única comparação no momento do download, entre a região carimbada no relatório e a região atual declarada do seu workspace.
O artefato é retornado normalmente, em qualquer formato (PDF, JSON ou CSV) sob o qual ele foi gerado.
O download é negado. O artefato nunca é servido sob uma residência que ele não pode satisfazer. Você regenera o relatório sob a região atual para obter um artefato novo e corretamente carimbado.
Um relatório gerado enquanto o workspace não tinha residência declarada não carrega afirmação de residência, então não há nada para divergir — ele é servido sob qualquer região. Declarar uma região só carimba relatórios gerados após a declaração.
As regiões declaráveis são o conjunto fechado us, eu, uk, ap, cn e global (mais o estado não-definido / sem-restrição).

3. Um passo a passo concreto

Um workspace que trocou de região no meio do trimestre:
1

Declare eu e gere

Como Admin do workspace, defina a residência para eu e gere o relatório SOC 2 do trimestre. O artefato é carimbado eu e armazenado sob a partição da UE.
2

Troque o workspace para us

Mais tarde, um Admin altera a região declarada para us. A mudança é registrada na trilha de auditoria do workspace.
3

Tente baixar o antigo relatório eu

O download é retido com:
this report's data-residency region no longer matches the workspace — regenerate it
4

Regenere sob us

Gere um relatório novo; ele é carimbado us e baixa normalmente. O antigo artefato eu permanece registrado sob sua região mas não é servido enquanto o workspace está declarado us.
Se você só precisa ler um relatório antigo depois de uma troca de região, troque a região declarada de volta para aquela sob a qual o relatório foi carimbado (Admin), baixe, depois troque de volta. O carimbo no artefato nunca muda — o gate é puramente a comparação atual-vs-carimbado.

4. Quem pode mudar o quê

Ler a configuração de residência e navegar pelos relatórios é aberto a todo membro do workspace. As ações que movem a região — e, portanto, o que é retido — são só de Admin e gated no servidor.
AçãoRotaPapel
Ler região declaradaGET /api/compliance/residencyMember
Alterar região declaradaPUT /api/compliance/residencyAdmin
Baixar um relatório (region-checked)GET /api/compliance/reports/:id/downloadAdmin
Todos estes rodam contra as rotas /api/compliance/* sob a sua sessão de console. Nenhuma chave de relay (sk-orca-…) está envolvida — a residência é uma configuração de superfície de compliance, não algo que uma requisição /v1/* carrega.
Alterar a região declarada é consequente: ela imediatamente retém cada relatório previamente gerado carimbado sob uma região diferente. Coordene mudanças de região com quem estiver no meio de uma auditoria, e regenere os relatórios de que eles precisam sob a nova região.
Um link de compartilhamento para auditor somente-leitura serve o mesmo artefato carimbado por região para o qual foi cunhado. O link não contorna o carimbo de residência no relatório subjacente — é uma visão tokenizada de um artefato que já carrega sua afirmação de região. Cunhe links de compartilhamento depois de ter resolvido a região declarada do workspace, para que um auditor não receba um link para um relatório que você depois tenha que regenerar.

6. Onde isto se encaixa

A restrição cross-region é a garantia do lado da leitura que torna um relatório carimbado por região confiável. As peças ao seu redor:

Residência de dados

Declare e altere a região sob a qual seus relatórios são carimbados e armazenados.

Relatório assinado

Gere o próprio pack de evidência assinado com Ed25519 e carimbado por região.

Exporte evidência

Links de compartilhamento para auditor e os formatos CSV / JSON / PDF.

Plan gating

Quais ações de compliance são gratuitas vs. pagas, e quem pode rodá-las.
Para a fronteira entre o que o gateway atesta e o que continua sendo seu — incluindo a residência como um controle de divulgação em vez de geo-fixação de inferência — veja Responsabilidade compartilhada.