Privacidade, apagamento e exportação

As leis, pelo nome

Apagar

curl -X POST "https://acme-prod.us-east-2.api.niadra.com/v1/forget" \
  -H "Authorization: Bearer $NIADRA_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "target": "handle",
    "handle": {"type": "phone_e164", "value": "+14155550123"}
  }'

import os
import uuid
import httpx

response = httpx.post(
    "https://acme-prod.us-east-2.api.niadra.com/v1/forget",
    headers={
        "Authorization": f"Bearer {os.environ['NIADRA_TOKEN']}",
        "Idempotency-Key": str(uuid.uuid4()),
    },
    json={
        "target": "handle",
        "handle": {"type": "phone_e164", "value": "+14155550123"},
    },
)
erasure = response.json()  # {"request_id": "...", "status": "pending", "target_kind": "handle", ...}

const response = await fetch("https://acme-prod.us-east-2.api.niadra.com/v1/forget", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.NIADRA_TOKEN}`,
    "Idempotency-Key": crypto.randomUUID(),
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    target: "handle",
    handle: { type: "phone_e164", value: "+14155550123" },
  }),
});
const erasure = await response.json();

1. O conteúdo dos eventos (fica uma lápide mínima).
2. As menções e os fatos que ficaram sem evidência, inclusive fatos sobre uma conta de que a pessoa falou.
3. Episódios e pendências.
4. Objetos de negócio cujo dono é o handle.
5. As ações sobre a pessoa, inteiras.
6. Padrões, derivados de novo sem a evidência apagada.
7. Vínculos com contas e parceiros, que são apagados.
8. Linhas da medição, amostras de revisão e conteúdo de disparos de gatilho.
9. Vetores, contexto compilado, arquivos no armazenamento e os pacotes de exportação do titular.
10. Lápides na exportação contínua; os turnos recentes e todo o contexto compilado do perfil saem do cache. Se o cache estiver fora do ar nessa hora, o contexto que ficou lá é recusado na leitura e expira em até 72 horas.
11. Nos espaços com as funcionalidades de agente ligadas: os registros de turno da pessoa, pelo prefixo do hash com chave de cada conversa dela, e os cenários de replay que os guardavam; a memória de trabalho dos escopos dela e a que a nomeia em subject; as interações, os sinais e as inferências dela, com os de todos os beneficiários; os objetos tipados e as observações dela; as reivindicações, o registro de contatos e as transferências da coordenação; e os vínculos de desfecho. A supressão de contato sobrevive, só como hash com chave: um opt-out não sai com a pessoa.

• o conteúdo cru e o texto, os campos e o resultado de ação dos eventos, inclusive os turnos recentes guardados no cache;
• os eventos que já estão no arquivo frio, reescritos na parte do arquivo que os guarda, com o digest da parte refeito no índice do arquivo;
• os fatos, as pendências, os resumos e as resoluções de todas as versões de um episódio, os campos de perfil, os resumos acumulados do perfil e os resultados de extração guardados;
• os valores fixados, que deixam de ser achados pelo valor apagado;
• os resultados das ações de agente;
• os objetos de negócio espelhados de um sistema da sua empresa, no estado e em cada observação de cada fonte, inclusive o valor que uma observação substituiu, e os valores calculados deles (veja abaixo);
• as instruções, as preferências e os traços guardados nos sinais, e as interações que ainda não viraram sinais, no banco e na camada de sessão;
• as notas de trabalho de agente e as propostas de nota, em qualquer estado;
• a memória de trabalho de outros clientes, no banco e nas cópias em cache, inclusive a que estava a caminho do banco quando o apagamento começou;
• os termos dos compromissos e o pacote e o desfecho das transferências da coordenação;
• os registros de turno, em todas as camadas que guardam uma cópia, com o digest de cada valor guardado refeito, e a parte de um turno que espera a junção com ele;
• os lotes de eventos e de turnos guardados depois de falhar (kept_aside): os da pessoa saem, e os de outros ficam com [erased].

Onde cada cópia mora, e por quanto tempo

Exportação sob demanda

Exportação contínua para o seu bucket

• Destino: S3 ou armazenamento compatível com S3, Google Cloud Storage (pela API compatível com S3, com uma chave HMAC) ou Azure Blob (blobs de bloco, com um SAS de contêiner), na região do seu espaço. A configuração recusa, no envio e na aprovação, um agendamento fora da região do espaço, e cada execução confere de novo. O endereço do destino (o endpoint do S3, o host de um SAS do Azure) precisa resolver só para endereços públicos, conferido quando a credencial é registrada e antes de cada execução conectar, como nas entregas de webhook.
• Credencial: uma credencial fornecida por você, só de escrita, gravada pelo Console, ou por PUT /v1/exports/destinations/{schedule_id}/credential, direto no cofre da sua célula; a resposta traz só a nova version. No registro, uma chave de S3 ou de GCS que consegue listar o bucket é recusada, e um SAS com mais permissões que criar, gravar e acrescentar, ou para outro contêiner ou host, também; a exportação escreve por uma porta que só grava.
• Formato: Parquet, um arquivo por tabela e período, com versão de esquema, manifesto JSON e SHA-256 por arquivo.
• Tabelas: eventos, conversas, episódios, fatos e menções, pendências, objetos e eventos de objeto, ações, padrões e evidências, comprovantes e aproveitamento do contexto, e a identidade que liga tudo ao cliente (handles, perfis, vínculos, asserções, registro de uniões).
• Pseudonimizada, se você pedir (pseudonymize): a tabela de handles sai sem o valor de cada telefone, e-mail, documento ou id de sistema e fica com o HMAC dele (value_hmac, com a chave do espaço), então as linhas continuam se ligando entre arquivos e execuções sem nomear a pessoa. As outras tabelas saem como estão.
• Incremental: cada linha sai com op (upsert ou delete); as lápides têm arquivo próprio. Linhas apagadas são puladas e listadas como erased no manifesto, e um arquivo de correção fecha qualquer lacuna. A primeira execução de um agendamento começa do início: os meses que já saíram da janela quente vivem só no arquivo frio, e essa execução os escreve na tabela de eventos antes das linhas vivas, com change_seq 0, e o manifesto lista os meses arquivados que mandou.
• Frequência: a cada quantas horas você definir, no mínimo uma. Cada destino recebe um agendamento só: a configuração recusa, no envio e na aprovação, um segundo agendamento no mesmo tipo, bucket e prefixo.

Acesso negado por padrão, liberado por finalidade

• Um fato de uma categoria que a política nunca declarou não chega a ninguém.
• As categorias que a lei chama de sensíveis são fixadas pelo produto: health, religion, philosophical_belief, political_opinion, union_membership, sexual_life, sexual_orientation, racial_or_ethnic_origin, genetic, biometric e criminal_record. Elas são reconhecidas também por outros nomes (medical, clinical, saude, religiao, genetica, biometria, antecedentes_criminais) e pela família antes do ponto, como health.exam. Uma categoria com um desses nomes é sensível mesmo que a sua política diga o contrário, e sem declaração ela nasce sensível, com mínimo V3.
• Um item sensível só chega a um agente quando a política o libera para uma finalidade que a fonte tem: pelas finalidades da própria categoria ou por uma regra allow que nomeia a finalidade. Uma regra allow sem finalidade não basta.
• Um item sobre uma conversa carrega também a categoria da conversa: a promessa feita numa conversa sobre saúde é dado de saúde.
• Pessoas do Console não leem por finalidade, e sim pela audiência do papel delas: administração e segurança como pessoa, revisão como revisor, análise e integração como analista. Sensibilidade, regras e visibilidade valem igual.

O espelho da política

• em V0: quem ainda não provou nada não ouve nada;
• por um handle que uma afirmação ligou ao perfil e ninguém confirmou: nem para os itens que chegaram por ele, nem para quem lê por ele;
• para uma organização, nem para um item sobre outro contato;
• para um texto que nomeia um assunto sensível (saúde, crença), seja qual for a categoria em que foi arquivado;
• numa categoria sensível: a política ignora a chave, e a configuração recusa o documento que a liga (policy category health is sensitive and cannot mirror).

Finalidade e base legal por item

• Finalidades: cada uma com o nome, a base legal (consent, contract, legal_obligation, legitimate_interest, vital_interest, health_protection, public_task, research, legal_claims, credit_protection ou fraud_prevention, as bases da LGPD, arts. 7 e 11, e do GDPR, art. 6) e, se quiser, a retenção em dias.
• De onde vem a finalidade de um item: a primeira regra que nomeia uma decide. A categoria do fato ou a categoria da conversa (categories), os tipos de evento de sistema que deram origem ao item (event_types, com * no fim para um prefixo), as finalidades declaradas da fonte que colheu, e por fim default. Só contam finalidades declaradas no documento. Um valor fixado segue a conversa em que foi dito.
• Quando: o item recebe as finalidades na mesma transação em que é gravado. O que foi gravado antes do documento existir recebe numa passagem por espaço, em lotes curtos, e o que nenhuma regra nomeou é olhado de novo quando o documento ou as finalidades de uma fonte mudam.

Retenções legais

O perfil revisável

Cartões, códigos de segurança e senhas nunca são gravados

O que a extração nunca guarda

O que fica protegido por desenho

• O papel de banco que atende toda requisição só acrescenta eventos: ele não altera nem apaga uma linha da tabela de eventos, nem na tabela nem em cada partição semanal, e uma restauração aplica a mesma regra de novo. As marcas de um evento (injeção, texto de mídia), o apagamento e o expurgo de um mês arquivado rodam como o papel de sistema.
• Handle, consulta de busca e texto livre só viajam no corpo da requisição, nunca na URL, então não chegam a log de balanceador. Toda leitura que leva um conversation_id tem uma forma POST, com o id no corpo, e o Console e os SDKs usam essa forma; nas formas GET, que continuam, use um id opaco do seu sistema. Veja Limites e convenções.
• Nenhuma linha de log leva dado de cliente. Um erro registrado guarda onde falhou (arquivo, linha e função) e a classe de cada exceção, nunca a mensagem, e um comando de banco que falha não cita os parâmetros. Um teste da suíte do servidor passa um valor canário pela ingestão (um item aceito e um recusado pelo lote), pela extração (uma que dá certo e uma em que o erro do provedor cita o prompt), pela leitura do contexto com consulta e delta e pela busca no histórico, e confere que ele não aparece em nenhuma linha de log, em nenhum nível, pelo formatador de produção.
• O conteúdo é cifrado com AES-256-GCM sob a chave de dados do seu espaço, que só existe embrulhada pela chave mestra de cifra da célula. Essa chave mestra fica no AWS KMS, em HSMs com validação FIPS 140-3, e nunca sai de lá. Sob contrato, a chave que embrulha as chaves de dados do seu espaço pode ser a sua, no serviço de chaves da sua conta na nuvem: a operação da Niadra a nomeia (PUT /v1/spaces/{space_id}/kms-key), a célula passa a gerar a próxima chave de dados do espaço sob ela e continua abrindo o que já foi gravado com a chave que o embrulhou; se você desligar a chave ou retirar a concessão, o espaço para de gravar em vez de voltar à chave da Niadra. Em trânsito, TLS 1.3: a borda e o banco recusam versões anteriores, e os serviços de nuvem e a IA da Niadra, com que a célula fala, negociam 1.3. Numa entrega para um endpoint seu (webhook, SIEM, exportação), vale a versão mais alta que ele aceitar.
• Antes de uma conversa chegar a qualquer modelo de terceiro, o de geração ou o de decisão, regras determinísticas e o modelo de dado pessoal da célula trocam por marcadores o e-mail, o telefone, o cartão (conferido por Luhn), o IBAN, os códigos postais, o endereço, os números de documento de pessoa física e de pessoa jurídica de vários países conferidos pelo dígito verificador ou pela forma escrita (os dois formatos brasileiros, o Social Security Number dos Estados Unidos, o SIN canadense, o National Insurance number britânico, o DNI e o NIE espanhóis, o NIF português, o CURP mexicano, o RUT chileno, o Aadhaar indiano) e, quando vêm junto do nome, o RG, o passaporte, o DNI argentino e a cédula, além da agência e conta bancária e da chave PIX aleatória (bank_account); a versão das regras é pii-rules@3. Um número escrito depois de um código de país (+55 11 91234-567) ou de um DDD entre parênteses ((11) 91234-567) é telefone, em qualquer país, mesmo quando os últimos grupos têm a forma de um CEP: nenhum país escreve código postal assim. Um celular brasileiro de antes do nono dígito, escrito depois do código do país, também é telefone. Parecidos que falham no dígito verificador, conversa em minúsculas e números sem o nome ao lado ficam como estão, e o valor de um fato sensível já guardado nunca vai junto. Quando a resposta do modelo volta, os marcadores de e-mail ou telefone voltam a ser os valores dentro da célula, mas um marcador de documento, cartão ou conta bancária volta como marcador retido, nunca como o valor.
• Os eventos saem do banco vivo quando passam da janela quente e ficam cifrados no arquivo frio. O arquivo frio fica até o seu espaço definir uma retenção para ele; as amostras de revisão e o registro de entregas de webhook têm retenção configurável, e o que vence é apagado de verdade.

Próximos passos