Uso de dados

A sua empresa é a controladora dos dados dos seus clientes; a Niadra os trata em nome dela, como operadora, para uma finalidade só: dar aos seus agentes a memória de cada cliente. Esta página diz o que decorre disso, em termos que o seu jurídico e o seu time de segurança podem conferir, e aponta, para cada afirmação, o código ou a configuração que a sustenta em 30/09/2026.

​

As três afirmações

Os dados nunca são vendidos, alugados ou compartilhados para outro fim. Nada no código da Niadra envia dado de cliente a alguém que não esteja na lista de subprocessadores, e cada um deles o recebe para a finalidade da sua empresa: hospedar (AWS), extrair a memória de uma conversa e decidir sobre ela (os modelos de IA pelo OpenRouter). Nenhum destino de marketing, de análise de mercado ou de “parceiro” existe no servidor. Toda saída HTTP para fora da célula passa por um único adaptador, niadra-back/src/niadra/adapters/outbound/egress.py, que só entrega a endpoints que a sua empresa configurou (webhooks, SIEM, bucket de exportação); os demais destinos são os da AWS e o OpenRouter, nomeados no código. Os dados são usados só para a finalidade da controladora. O que a Niadra grava, extrai, compila e entrega serve à memória dos seus agentes e às ferramentas de governança da sua empresa (apagamento, exportação, auditoria, medição). A política do espaço decide quem lê o quê (Acesso negado por padrão), e cada item guarda as finalidades e a base legal com que foi colhido (Finalidade e base legal por item). A Niadra não lê o conteúdo para nenhum fim próprio: os logs não levam conteúdo (teste niadra-back/tests/unit/flow/test_log_canary.py), as métricas não levam id de espaço ou de cliente, e a cobrança conta conversas e tarefas, não lê o que dizem. Os dados nunca treinam modelos, nem os da Niadra, nem os de terceiros. A Niadra não treina modelo nenhum: os modelos que rodam dentro da célula (o detector de dado pessoal, o de busca por significado, o leitor de documentos) são modelos publicados, fixados por versão na imagem (niadra-back/models/src/niadra_models/onnx/pinned.py), e não há nenhum código de treino ou de ajuste fino nos repositórios. Para os modelos de terceiros, cada pedido ao OpenRouter leva provider: {"data_collection": "deny", "zdr": true} (niadra-back/src/niadra/adapters/outbound/llm/openrouter.py, função _body, e jev.py): data_collection: deny diz ao roteador que o provedor final não pode guardar o pedido para treino ou melhoria de produto, e zdr: true restringe a chamada a rotas com retenção zero. Uma rota que não ofereça as duas coisas não recebe o pedido.

​

O que sai da célula, e para onde

Nada mais. Não há SDK de análise, pixel ou serviço de terceiro no Console ou no site que receba dado de cliente: a Content Security Policy do site e do Console só permite scripts da própria origem (niadra-frontend/deploy/Caddyfile), e as visitas ao site são contadas pela própria Niadra, sem terceiro.

​

O que a operação da Niadra vê

• Por padrão, ids, hashes e contagens. Os logs, as métricas, os alertas e os painéis não levam conteúdo de cliente. Os comprovantes dizem quem leu o quê por id, nunca o texto.
• Acesso operacional existe e deixa rastro. Para restaurar um espaço, conferir uma cópia ou apagar um espaço, o fundador roda os runbooks do niadra-back/README.md na máquina, pelo Systems Manager, que o CloudTrail da conta registra. Um acesso pelo Console a um espaço deixa comprovante admin, que a sua empresa vê. Esse acesso não é usado para ler conteúdo de cliente; não há segundo aprovador para ele, e isso está dito no modelo de ameaças.
• Testes e medidas usam dados sintéticos. A verificação de ponta a ponta de cada implantação roda num tenant sintético da própria Niadra; os testes do CI e as medições publicadas usam conversas inventadas.

​

O que a sua empresa controla

• Retenção, por classe de dado e por finalidade, e o apagamento com comprovante (Privacidade).
• Quem lê o quê, pela política, com simulação antes de mudar (POST /v1/policy/simulate).
• Exportação sob demanda e contínua: os dados são seus e saem quando você pedir, no seu bucket.
• Os subprocessadores: a lista vai no contrato, e uma mudança nela é avisada no prazo do contrato, com direito de objeção.
• A saída da região. Se a sua empresa não aceitar que texto mascarado vá aos modelos fora da região, isso é uma condição de contrato; hoje a plataforma não tem um modo sem modelo de terceiro, e não está prometido.

​

Compromisso contratual

O que esta página descreve é o comportamento do código de hoje. As três afirmações entram como cláusulas no contrato de tratamento de dados (DPA) da sua empresa com a Niadra, com a lista de subprocessadores como anexo. O contrato é o que obriga; esta página é como conferir que o código faz o que o contrato diz.

​

Próximos passos