Skip to main content
A sua empresa é a controladora dos dados; a Niadra atua como operadora, com DPA assinado. Todo direito do titular tem API: acesso e portabilidade pelo export, correção pelo feedback, eliminação pelo forget e oposição ao perfilamento pelo desligamento de padrões. O apagamento segue a linhagem, percorre tudo o que derivou do dado e termina com comprovante. Os seus dados nunca treinam modelos, nem os nossos, nem os de terceiros.

As leis, pelo nome

O mesmo desenho cobre o núcleo comum da LGPD, do GDPR e do UK GDPR, da CCPA/CPRA e das leis estaduais dos Estados Unidos, da PDPA, da APPI, da DPDP e da PIPA: residência dos dados numa região só, papéis de controlador e operador, direitos por API, retenção configurável, apagamento com comprovante, nenhum treino com os seus dados e lista pública de suboperadores. Para outros países, a lei aplicável entra no anexo do contrato. Regimes setoriais, a DORA para entidades financeiras na União Europeia, a HIPAA para saúde nos Estados Unidos e o EU AI Act para quem opera agentes na União Europeia, também ficam no anexo do contrato. Os dados de cada espaço ficam na região dele. O plano de controle não guarda conteúdo de cliente, e os provedores de IA são chamados só na mesma região.

Apagar

POST /v1/forget recebe um target (profile, handle ou conversation) e o profile_id, o handle ou o conversation_id correspondente. Pede uma pessoa do Console com o papel security, ou uma chave de escopo admin, e exige o Idempotency-Key: o mesmo pedido mandado duas vezes começa um apagamento só.
A resposta é 202, com um request_id e status: "pending". Acompanhe por GET /v1/forget/{request_id} (pending, running, completed ou failed, com o que foi apagado em erased e quando terminou em completed_at), ou liste todos os apagamentos do espaço por GET /v1/forget, filtrando por status. O apagamento percorre a linhagem inteira, nesta ordem:
  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. O conteúdo pessoal das ações. Operação, valor e horário ficam só se você declarar obrigação legal de guarda.
  6. Padrões, derivados de novo sem a evidência apagada.
  7. Vínculos com contas e parceiros, que são encerrados.
  8. Linhas da medição, amostras de revisão e conteúdo de disparos de gatilho.
  9. Vetores, contexto compilado e arquivos no armazenamento.
  10. Lápides na exportação contínua e caches purgados.
No fim vem o comprovante de apagamento (o hash dele volta em receipt_hash), que lista também, em export_run_ids, as execuções de exportação que já continham o dado, e o webhook erasure.completed, para você limpar o seu próprio lago de dados. A Niadra nunca entra no seu bucket para apagar. Comprovantes de leitura antigos guardam só hashes: provam que a leitura aconteceu sem reter o conteúdo. Esquecer uma pessoa nunca apaga a conta a que ela estava ligada, e esquecer uma conta nunca apaga a memória pessoal dos contatos. Veja Contas e parceiros.

Onde cada cópia mora, e por quanto tempo

Exportação sob demanda

POST /v1/export reúne os dados de um titular para acesso e portabilidade, por profile_id ou handle: eventos, fatos, episódios, pendências, objetos, ações, padrões com as evidências e vínculos. A resposta é 201, com o run_id, a lista de files, o sha256 deles e uma download_url de vida curta (até download_expires_at). GET /v1/exports/{run_id}/download serve o arquivo de novo, com a mesma autorização. As duas são rotas do papel security, e cada download fica registrado.

Exportação contínua para o seu bucket

Além da exportação sob demanda, o seu espaço pode agendar uma exportação contínua que escreve a memória, de forma incremental, no seu próprio bucket. Os dados são seus; a Niadra não é o seu lago de dados.
  • Destinos: S3, GCS ou Azure Blob, na região do seu espaço, conferida no cadastro e a cada execução.
  • Credencial: só de escrita, fornecida por você (papel assumido ou chave 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. Nunca credencial de leitura.
  • 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).
  • 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.
  • Frequência: por hora ou por dia, um agendamento por destino, com intervalo mínimo de uma hora.
O conteúdo sai decifrado apenas no caminho até o seu bucket, que o cifra com a sua chave. Existe a opção de exportar pseudonimizado, para análise. Cada execução, agendada ou sob demanda, aparece com a faixa de sequência, o estado e o manifesto em GET /v1/exports/runs.

O que fica protegido por desenho

  • Dado pessoal nunca vai na URL: telefone, e-mail, número de documento e texto livre só viajam no corpo da requisição, então nunca chegam a log de balanceador nem a rastros.
  • O conteúdo é cifrado com AES-256-GCM sob uma chave exclusiva da sua empresa, guardada em HSM com validação FIPS 140-3, além do TLS 1.3 em trânsito.
  • Dado sensível é mascarado antes de chegar a qualquer modelo de IA que processa as conversas; o seu agente só o recebe depois da verificação que a sua política exige.
  • A retenção é configurável por classe de dado, e o dado vencido é apagado de verdade.

Próximos passos

Comprovantes e auditoria

a trilha que cada apagamento e cada leitura deixam.

Apagar

o endpoint em detalhe.

Padrões

oposição ao perfilamento e retirada de padrão.

Segurança e privacidade no site

as seis camadas que protegem os dados.