Saltar para o conteúdo principal
Se sua app de LLM processa dados pessoais da UE, três obrigações do GDPR caem no próprio caminho da requisição: mantenha os dados pessoais no mínimo que o modelo precisa (Art. 5), evidencie para onde o egress de ferramenta os envia (Art. 44), e honre o direito ao apagamento de um titular de dados (Art. 17). O pack GDPR transforma essas em controles aplicados que você instala em uma chamada — sem autorar política do zero. Esta página é o ponto de partida de gdpr llm: o que instalar o pack de fato materializa, um fluxo de instalação concreto, e como o apagamento funciona de ponta a ponta. Para a referência completa das camadas de conteúdo e ação, siga os links em vez de relê-las aqui.

​
1. O que o pack GDPR instala

Navegar pelo catálogo é gratuito para qualquer Member do workspace; instalar é uma ação de Admin do workspace em plano pago (o mesmo gate que ir ao ar — veja Plan gating). Uma instalação materializa linhas reais e editáveis de Guardrail e Firewall mapeadas para artigos do GDPR:
Um guardrail de PII que bloqueia a requisição quando identificadores da UE (IBAN, número NHS do Reino Unido, Steuer-ID alemão, NIR francês) são detectados, de modo que dados regulados nunca cheguem ao provedor upstream. Ele roda no stage de input. Veja Guardrails para a lista de entidades e os overrides de ação por entidade — você pode trocar uma entidade coberta de block para mask depois da instalação.
Um guardrail de PII mais amplo que rejeita totalmente requisições contendo emails, números de telefone, SSNs, números de cartão de crédito ou IPs, de modo que dados de categoria especial e dados pessoais comuns sejam capturados juntos.
Um guardrail de logging que registra cada decisão de guardrail como evidência de processamento — alimentando o relatório assinado que seu auditor lê.
Uma regra de egress de firewall que audita os destinos outbound que suas ferramentas reportam ao gateway, de modo que uma avaliação de transferência tenha uma trilha real de para onde os dados foram. Veja Firewall para correspondência de egress.
O pack é um ponto de partida que você possui, não uma caixa-preta. Cada regra que ele escreve é uma linha comum de guardrail ou firewall que você pode editar, reordenar ou desabilitar no console depois.

​
2. Instale o pack GDPR (um fluxo concreto)

Instale a partir do console em Compliance → Packs, logado como Admin do workspace em um plano pago. 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-…): 
POST /api/compliance/packs/gdpr/install
Authorization: Bearer <your console session>
Antes de se comprometer, o catálogo te diz exatamente para qual framework você está mapeando — abra-o como Member primeiro: 
GET /api/compliance/catalog
Authorization: Bearer <your console session>

{
  "key": "gdpr",
  "name": "GDPR",
  "framework": "EU General Data Protection Regulation",
  "jurisdiction": "EU/EEA"
}
Instale em observe primeiro. A regra de egress de firewall materializada pode rodar apenas-audit para que você observe destinos reais de transferência por uma semana antes que qualquer um deles seja negado — veja Observe vs enforce.

​
3. Controles de PII na requisição

A minimização de dados é o controle load-bearing do GDPR, e no gateway ela é um guardrail de PII. Por padrão o pack bloqueia a requisição no stage de input quando dados pessoais da UE são detectados — a requisição é rejeitada antes que o modelo a veja, de modo que dados regulados nunca cheguem ao provedor upstream. Além das entidades da UE incluídas, você pode ajustar o guardrail que o pack instalou: escolha exatamente quais entidades cobrir, troque uma entidade coberta de block para mask, e adicione seus próprios padrões de entidade customizados. A lista completa de entidades, os overrides de ação por entidade e as opções de entidade customizada vivem na referência de Guardrails.
Se você troca uma entidade para mask, esse mascaramento é ao vivo no stage de input mas sandbox-avaliado no stage de output — o mascaramento ao vivo de respostas de modelo está no roadmap. Um block de output é aplicado tanto em respostas streaming quanto não-streaming. Planeje sua minimização em torno do stage de input, onde tanto block quanto mask estão totalmente ao vivo.

​
4. Residência para sua evidência gdpr llm

Os auditores de GDPR perguntam onde a evidência reside. A configuração de residência de dados do OrcaRouter carimba cada relatório de compliance assinado com uma região (us / eu / uk / ap / cn / global) e retém qualquer relatório cuja região carimbada não mais corresponda ao workspace. Para um programa da UE, declare eu antes de gerar os relatórios em que seu auditor vai confiar: 
PUT /api/compliance/residency
Authorization: Bearer <your console session>
Content-Type: application/json

{ "region": "eu" }
A residência governa o artefato de relatório, não onde a inferência roda. Não é geo-fixação de tráfego de modelo. A página dedicada Residência de dados cobre a distinção e o que acontece quando você altera a região depois que relatórios existem.

​
5. Direito ao apagamento (Art. 17)

Uma app GDPR real precisa de um caminho de apagamento real, não uma promessa. No OrcaRouter, a autoexclusão de conta roda um fluxo de carência-depois-scrub:
PassoO que acontece
RequisiçãoConta com soft-delete imediato; login bloqueado.
CarênciaUma janela cancelável de 30 dias antes do scrub irreversível.
ScrubPII apagada; purga em cascade de logs de requisição, correspondências de guardrail e eventos de firewall.
A janela de carência é cancelável — e um usuário ainda pode exportar seus dados durante ela antes que o scrub dispare (portabilidade de dados, Art. 20). Após a janela, o scrub é irreversível e cascateia pelos registros que carregam identificadores diretos.
Os logs de requisição são governados separadamente do apagamento: a retenção padrão é de 30 dias, server-clamped a um máximo de 180 dias. Reduzi-la encolhe a janela em que qualquer dado pessoal fica em logs — veja Retenção.

​
6. Prove com um relatório assinado

Uma vez que o pack esteja ao ar, gere um relatório de compliance: ele é hasheado com SHA-256 e assinado com Ed25519, de modo que um auditor possa verificar que ele foi produzido pelo OrcaRouter e não foi alterado — publicamente, sem um login. 
POST /api/compliance/reports
Authorization: Bearer <your console session>
Content-Type: application/json

{ "framework": "gdpr" }
Qualquer pessoa pode verificar a assinatura contra a chave pública, e você pode entregar a um auditor um link de compartilhamento com escopo e tempo limitado. A mecânica vive em Relatório assinado e Verifique um relatório.

​
7. Onde isto se encaixa

O GDPR é um framework no loop de compliance mais amplo — instale um pack, observe-o, aplique, declare a residência, depois entregue evidência assinada.

Direito ao apagamento

O fluxo de carência-depois-scrub e a purga em cascade por completo.

Residência de dados

Evidência carimbada por região, e por que não é geo-fixação de inferência.

Visão geral de compliance

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

Guardrails

A referência da camada de conteúdo — entidades de PII, mascaramento e overrides.
Para a fronteira entre o que o gateway garante e o que continua sendo seu sob o GDPR — declarar a residência, classificar seus dados, disparar exclusões — o mapa de Responsabilidade compartilhada coloca o pack GDPR em contexto.