As suas perguntas têm resposta por uma empresa francesa.
A geração é executada na Mistral, em França, uma empresa sem matriz fora do Espaço Económico Europeu. Os documentos são armazenados na Irlanda e em Nuremberga. Todos os fornecedores, o seu país de constituição e a sua matriz estão listados no nosso registo de subprocessadores.
Isolamento de dados
O isolamento de tenant é aplicado na camada da base de dados através de segurança ao nível da linha. Cada consulta é limitada ao utilizador autenticado. O acesso a dados entre tenants é arquitetonicamente impossível.
Controlo de acesso baseado em funções
Permissões granulares definidas por equipa, tipo de dados e ação. Os administradores controlam quem pode ver os registos de auditoria, gerir membros, eliminar documentos e aceder à faturação.
Registo de auditoria imutável
Cada consulta de IA, acesso a dados e ação administrativa é registado num registo apenas de acréscimo. Quem acedeu a quê, a partir de onde e quando, tudo pesquisável e separado dos dados da aplicação.
Os seus dados permanecem seus.
Os seus dados são usados apenas para servir a sua equipa. Nunca são partilhados, vendidos ou reutilizados. Os seus documentos, consultas e respostas são apenas seus.
Onde é executado e quem pode aceder
Jurisdição, não apenas região
A residência indica onde os dados estão armazenados. A jurisdição indica quem pode exigir acesso aos mesmos. A geração, o armazenamento de documentos e o correio de saída são tratados por empresas constituídas no EEE sem matriz fora do EEE. O nosso caminho de pedido, a cache e a monitorização de erros ainda são executados em fornecedores constituídos nos EUA enquanto migramos para a nossa própria infraestrutura na UE. O nosso registo de subprocessadores assinala cada um por linha, incluindo um fornecedor baseado na UE mas com matriz fora do EEE.
Residência de dados na UE
A geração é executada em França e os *embeddings* em Berlim. Os documentos são armazenados na Irlanda e em Nuremberga. Alguns dos nossos fornecedores estão constituídos fora do Espaço Económico Europeu, pelo que o seu acesso remoto é considerado uma transferência ao abrigo do Capítulo V do RGPD. O nosso registo de subprocessadores identifica cada fornecedor e a base de transferência aplicável.
Quem, na Nordvec, pode ver os seus dados
O produto não tem impersonação, acesso de suporte ou modo de administrador da equipa. Não existe qualquer forma de abrirmos os seus ficheiros ou conversas através da aplicação, e um teste falha a compilação se alguma vez for adicionado. Dois fundadores têm acesso à base de dados a nível de infraestrutura, um acesso permanente que não podemos remover enquanto utilizamos infraestrutura gerida, e que não aparece no seu registo de auditoria. Tudo o que é feito através do produto fica registado, e pode exportar todo o registo como CSV, filtrado por data e ação. O acesso nomeado e com prazo limitado, com notificação para si, chegará com o nosso próprio hardware na UE.
Como é protegido e o que abrange
Encriptado em repouso e em trânsito
Todos os dados são encriptados em repouso (AES‑256) e em trânsito (TLS 1.3). Os tokens OAuth usam uma camada adicional de encriptação ao nível da aplicação.
Custódia das chaves
O nosso fornecedor de plataforma detém atualmente as chaves de encriptação, não nós nem você. Afirmamos isto claramente porque determina o valor da encriptação acima referida: protege um disco desativado ou roubado, não uma credencial comprometida num sistema em funcionamento. Ainda não oferecemos chaves geridas pelo cliente. A custódia das chaves passará a ser nossa quando migrarmos para *hardware* na UE, com uma chave residente na UE e uma política de rotação definida.
Porque é que o índice de pesquisa não é encriptado separadamente
Encriptar individualmente as colunas de texto e vetores quebraria o índice que torna possível a pesquisa vetorial, e numa infraestrutura gerida a chave continuaria a estar com o fornecedor. Preferimos dizer‑lhe onde está o limite do que descrever uma camada de encriptação que não faz o que o nome sugere.
Âmbito das cópias de segurança
As cópias de segurança cobrem a base de dados diariamente, com um ponto de recuperação de 24 horas. Os *blobs* de documentos não estão incluídos, pelo que uma eliminação é definitiva e não pode ser revertida por uma reposição. Qualquer reposição reproduz as eliminações registadas antes de o serviço ser retomado, pelo que não pode recuperar dados que nos pediu para eliminar.
Como o código é testado
Todas as alterações são analisadas antes de serem implementadas: análise estática (*semgrep*) para falhas ao nível do código, auditoria de vulnerabilidades e licenças de dependências, verificação de segredos em cada *commit* e um período de espera de sete dias para a publicação que impede a entrada de pacotes recentemente publicados na compilação. Não realizamos testes de penetração independentes e preferimos dizê‑lo aqui a deixar que uma lista de controlos o sugira.
O que fazemos com os dados
Retenção zero de dados para treino de IA
O Nordvec nunca utiliza os seus dados para treinar, afinar ou melhorar qualquer modelo de IA. Apenas os 5-15 blocos de documentos relevantes para a sua pergunta são enviados por consulta, nunca documentos completos.
Sem partilha de dados com terceiros
Os seus dados nunca são vendidos ou partilhados para fins de terceiros. Os fornecedores de modelos recebem apenas o contexto mínimo necessário para responder à sua consulta, e todos os fornecedores que utilizamos estão identificados no nosso registo de subprocessadores.
Eliminação física imediata
Quando desconectar uma integração, todos os dados sincronizados, embeddings e referências de ficheiros são eliminados permanentemente de imediato. Os blobs de armazenamento são apagados em poucos minutos. Não há eliminações temporárias.
Controlo de acesso em cada camada.
Autenticação na periferia, segurança ao nível da linha na base de dados e um registo de auditoria apenas de adição.
Autenticação na camada de edge
A verificação de JWT acontece na camada de edge antes de os pedidos chegarem aos servidores da aplicação. Tokens inválidos são rejeitados sem qualquer carga no backend.
Controlo de acesso ao nível da base de dados
As políticas de Row‑Level Security (RLS) aplicam o isolamento por tenant diretamente no PostgreSQL. Nem sequer consultas internas conseguem contornar os controlos de acesso.
Registo de auditoria imutável
Cada consulta de IA, acesso a dados e ação administrativa é registado num registo de auditoria apenas de acréscimo, com carimbos temporais precisos.
Limitação de taxa e prevenção de abuso
Os endpoints da API têm limitação de taxa por utilizador e por IP. A prevenção automática de abuso protege contra ataques de credential stuffing e enumeração.
O que temos e o que não temos.
GDPR
Conformidade total com o Regulamento Geral sobre a Proteção de Dados. Direitos dos titulares dos dados em self‑service (Art. 15, 17, 20), proteção de dados desde a conceção (Art. 25), registos imutáveis de tratamento (Art. 30) e segurança do tratamento (Art. 32).
Regulamento Europeu da IA
Registo automático de decisões, controlos de transparência e supervisão humana, mapeados para os Artigos 12-14. Transparência do Artigo 50 através do histórico exportável de interações com IA, com o estado de cada obrigação publicado no painel de confiança.
SOC 2 Tipo II
Não detido. Os Critérios de Serviços de Confiança que a nossa arquitetura já cumpre estão publicados individualmente no painel de confiança, cada um ligado ao código que o implementa. Uma auditoria externa é uma decisão de financiamento, e não a descreveremos como agendada até estar reservada.
ISO 27001
Não detido. Os nossos controlos de segurança da informação estão publicados e verificados na origem, em vez de serem afirmados como alinhamento, e são exportados como OSCAL para que os possa carregar nas suas próprias ferramentas. Preferimos publicar o que pode verificar a uma afirmação que não pode.
Porto seguro
Relate uma vulnerabilidade para security@nordvec.com. Reconhecemos no prazo de 72 horas, atribuímos uma severidade de triagem em 5 dias úteis e mantemo‑lo atualizado até à resolução.
Porto seguro
Não iniciaremos nem apoiaremos ações legais contra investigadores que ajam de boa‑fé, sigam esta política, evitem violações de privacidade e degradação do serviço, e nos deem uma oportunidade razoável de corrigir antes da divulgação. Se não tiver a certeza se uma ação é autorizada, pergunte‑nos primeiro.
Antes de testar
Interaja apenas com contas que lhe pertencem ou para as quais tenha permissão de utilização. Não aceda a dados de outros inquilinos, execute varrimentos que degradem o serviço ou divulgue publicamente uma questão não resolvida. Pedimos uma janela de coordenação de até 90 dias antes da divulgação pública, e damos crédito aos relatores que desejem ser identificados. Se utilizou uma ferramenta de IA generativa em qualquer fase, informe‑nos como; isso ajuda‑nos na triagem e não conta contra o seu relatório.
O nosso processo segue a ISO/IEC 29147 (divulgação) e a ISO/IEC 30111 (tratamento), bem como o dever de divulgação coordenada do Regulamento (UE) 2024/2847 da Lei de Resiliência Cibernética da UE (Art. 13). Os objetivos de correção e o âmbito completo estão publicados no ficheiro SECURITY.md no nosso repositório de código.
Não temos um programa de recompensas por bugs pagas. Reconhecemos os relatórios de boa‑fé com crédito público, não com pagamento.
Entrem em contacto.
Questões de segurança
Dúvidas sobre a nossa arquitetura de segurança, manuseio de dados ou postura de conformidade. Estamos à disposição para fornecer documentação detalhada para a sua análise.
Divulgação responsável
Relate uma vulnerabilidade para security@nordvec.com. Reconhecemos no prazo de 72 horas, atribuímos uma severidade de triagem em 5 dias úteis e mantemo‑lo atualizado até à resolução.