Desenvolvida na UE e onde estão os seus dados

Onde é desenvolvido o Nessie, onde estão os seus dados e o que controla quando a aloja na sua própria infraestrutura.

Quem a desenvolve e ao abrigo de que lei

O Nessie é desenvolvido pela UnlikeOtherAI s.r.o., uma empresa registada na República Checa e que opera ao abrigo da lei checa.

Esta página descreve como o software é construído e onde funciona. Não é uma declaração de conformidade: o Nessie não possui qualquer certificação de segurança, e nada aqui deve ser lido como tal. Que dados pessoais são tratados e com que fundamento é matéria da política de privacidade, que é uma página à parte.

Onde funciona o produto alojado

O Nessie Cloud funciona em fornecedores de alojamento europeus — a Scaleway, a Hetzner e outros. Escolhemos o melhor serviço de cada fornecedor, pelo que diferentes partes do produto podem funcionar em fornecedores diferentes, todos na Europa.

Qualquer indicação mais precisa do que esta — um local, uma cidade ou um centro de dados em concreto — não é deliberadamente indicada aqui, porque ficaria desatualizada sem que ninguém reparasse.

Com o alojamento próprio, a escolha é sua

O local onde uma instância de alojamento próprio funciona é uma definição de implementação, não uma definição do produto. O caminho de uma única máquina é uma stack Docker Compose que coloca numa máquina à sua escolha. Na árvore Terraform para uma cloud gerida, a região é um parâmetro sem qualquer valor predefinido: nada ali pode ser adivinhado, por isso nada ali tem um valor predefinido, e a base de dados, o bucket de armazenamento de objetos e os serviços seguem todos a região que indicar.

Há dois pormenores estruturais que importam para a mesma questão. A fila e o transporte em tempo real são ambos PostgreSQL — não há Redis nem broker de mensagens no caminho, pelo que não há um terceiro sistema para colocar. E o armazenamento de objetos é compatível com S3, em vez de estar preso a um único fornecedor; a implementação de referência executa o MinIO num contentor, numa rede privada e sem entrada própria. As partes que têm de estar algures são a base de dados, o armazenamento de objetos e os dois serviços Node, e todas elas ficam onde as colocar. Como montar tudo isto está na página de instalação.

O que o Nessie guarda — e o que deliberadamente não guarda

A identidade não é copiada

Com o início de sessão UnlikeOtherAI, o fornecedor de identidade gere e armazena a identidade das pessoas — fatores de autenticação, perfis, pertença a organizações e equipas, e convites. O Nessie é uma parte dependente (relying party), não um segundo sistema de identidade. É uma decisão sobre dados tanto como sobre arquitetura: uma identidade que o Nessie nunca armazena é uma identidade que não pode divulgar, perder nem deixar de eliminar.

O que a tabela users realmente guarda é o identificador estável do utilizador atribuído pelo fornecedor — a chave através da qual tudo o resto é resolvido —, o endereço de email, um espelho não autoritativo do nome de apresentação e do avatar, e campos locais do produto (preferências, pronomes, uma versão de token usada para revogar sessões). O espelho existe apenas para que um nome e uma imagem possam ser apresentados sem um pedido por linha, e é ressincronizado a partir das declarações verificadas do fornecedor no início de sessão, na mudança de equipa e na renovação da sessão. Nada fabrica um valor: uma pessoa a quem o fornecedor não atribuiu nome fica com o seu endereço de email até que o atribua. Só existe um hash de palavra-passe para o proprietário inicial de uma instalação sem qualquer fornecedor de identidade.

O mesmo vale para a estrutura. Uma organização do fornecedor é uma organização do Nessie, ligada pelo identificador de organização do fornecedor; uma equipa sem ligação a montante responde 404 TEAM_NOT_LINKED em vez de recorrer a um palpite local, e uma leitura em direto da lista de membros vai ao fornecedor de identidade e não persiste nada.

Ainda faltam eliminar dois espelhos, e seria desonesto insinuar o contrário. Os nomes das organizações e das equipas continuam armazenados localmente junto dos identificadores de ligação, e as linhas locais de pertença continuam a autorizar os pedidos comuns entre sincronizações. Eliminar ambos é trabalho em aberto, registado no repositório, e não algo já concluído.

Nada comercial

O serviço central de faturação gere os pagamentos. O Nessie não armazena clientes, subscrições, faturas, preços, saldos de crédito, políticas de carregamento, consentimentos de pagamento, extratos nem estados de cancelamento de um fornecedor de pagamentos, e não calcula tarifas. Lê valores prontos a apresentar e mostra-os.

Segredos

É necessário um cofre configurado para armazenar um segredo, seja ele qual for. Deliberadamente, não há recurso à base de dados nem caminho em texto simples: sem cofre, guardar, rodar e revogar um segredo devolvem um erro em vez de recuarem para algo menos seguro. Os registos do próprio Nessie sobre um segredo não contêm valor, texto cifrado, chave nem token do cofre — apenas uma referência opaca e os seus metadados — e os caminhos do cofre são construídos apenas com identificadores estruturais, nunca com o nome de uma organização, equipa, projeto ou pessoa.

As credenciais que o Nessie tem de guardar para atuar como cliente OAuth — credenciais de conectores e de caixas de correio, segredos de webhooks, material de renovação de sessão, cargas do executor — são seladas em envelopes AES-256-GCM com finalidade específica, sob um conjunto de chaves com versões que é uma raiz distinta do segredo de assinatura das sessões, com um procedimento de rotação documentado.

Há ainda uma regra sobre os modelos: pode saber-se que um segredo existe e pode autorizar-se a sua utilização, mas o material secreto não pode entrar no contexto do modelo, nos prompts, nos argumentos ou resultados de ferramentas, na memória, nos embeddings, na pesquisa, nos registos nem nas mensagens. Um agente pode receber a capacidade de usar um segredo. Nunca pode receber a capacidade de o revelar.

Saber se os discos subjacentes estão cifrados é uma propriedade da máquina onde a implementação corre. O repositório não estabelece cifragem ao nível do volume para os volumes da base de dados e do armazenamento de objetos, pelo que esta página não a afirma.

Isolamento entre inquilinos

O Nessie é multi-inquilino por conceção: uma única base de dados, em que cada linha pertence a exatamente uma organização e cada tabela subordinada tem um campo organization_id. O isolamento é imposto em dois pontos — a cláusula de âmbito que cada consulta inclui, e chaves estrangeiras reais nessa coluna, acrescentadas em quarenta e duas restrições depois de uma auditoria interna ter verificado que a coluna existia, mas sem restrições, em dezenas de tabelas.

Uma bateria de conformidade mantém esse invariante na fronteira HTTP. Cria um atacante com privilégios máximos — proprietário pleno da sua própria organização — e verifica que cada leitura canónica de recursos de outra organização responde 403, 404 ou vazio, e que cada mutação canónica é rejeitada, com a linha da outra organização intacta. Abrange canais, aprovações, o registo de auditoria, gatilhos, agentes e as suas associações, execuções, projetos, tarefas, conversas, ligações, instalações de fluxos de trabalho, instâncias MCP, a base de conhecimento e alertas.

Sendo precisos quanto ao mecanismo: isto é imposição ao nível da aplicação mais chaves estrangeiras, não segurança ao nível da linha do PostgreSQL (row-level security). Não existe qualquer política RLS nem salvaguarda do lado da base de dados, e a bateria de conformidade corre contra um armazém fiel em memória e não contra uma base de dados real, pelo que demonstra as cláusulas de âmbito que o código escreve, e não o SQL que um servidor executa. O repositório di-lo na própria documentação da bateria, e esta página também.

O registo de auditoria

Cada ação com consequências fica registada: quem agiu e na qualidade de quê — uma pessoa, um agente, um serviço —, o que fez, a que recurso, em que organização, projeto, equipa ou canal, se teve êxito ou foi recusada, porquê, e o identificador do pedido, o endereço e o user agent com que chegou.

O registo é só de acréscimo por conceção e não há forma de lhe escrever a partir do exterior: POST /api/audit-log não existe, e isso é deliberado. As entradas estão encadeadas — cada uma contém um resumo SHA-256 dos seus próprios campos canónicos e o resumo da entrada anterior dessa organização —, pelo que uma linha alterada ou removida quebra a cadeia e é detetável. O proprietário ou administrador de uma organização pode percorrer essa cadeia quando quiser e é-lhe indicado onde se quebrou pela primeira vez, se tal tiver acontecido.

Duas ressalvas honestas. A cadeia torna o registo evidente em caso de adulteração, não imune a ela: não há por trás revogação de escrita ao nível da base de dados nem armazenamento de escrita única, pelo que a garantia é a deteção e não a prevenção. E, por predefinição, as entradas são conservadas indefinidamente — a retenção configurável com exportação antes de eliminar está concebida, não construída. As entradas também estão impedidas de conter segredos ou corpos completos de pedidos, e um conjunto fixo de nomes de campos de metadados sensíveis é ocultado à entrada.

O registo de custos

Cada invocação de um modelo é registada na organização, e no utilizador, equipa, projeto, canal, agente e execução de que veio, com os tokens consumidos e, lado a lado, o custo comunicado pelo fornecedor e a estimativa do próprio Nessie. Uma métrica que o fornecedor não comunica é guardada como nula e não adivinhada. Os relatórios podem ser lidos pelo proprietário ou administrador da organização.

Este registo é telemetria operacional — o que uma organização gastou e em nome de quem. Não é uma fatura nem uma autoridade de faturação.

Terceiros, quando usa o produto alojado

Uma implementação alojada comunica com um conjunto pequeno e fixo de serviços. O tráfego dos modelos e a pesquisa na web não vão diretamente para os fornecedores: ambos saem por um único gateway operado pela UnlikeOtherAI, onde se encontram os fornecedores de modelos e de pesquisa a montante. O início de sessão e a faturação vão para o autenticador da UnlikeOtherAI. O cofre de segredos é alojado por nós, junto da aplicação. As ligações de videochamada geradas pelo servidor usam por predefinição o serviço público Jitsi.

Quase tudo o resto está desativado até um operador o configurar, e di-lo em vez de falhar em silêncio: contas Google, Microsoft e Slack ligadas; email de agentes através do Amazon SES, que cada implementação executa na sua própria conta, sem intermediários; notificações push móveis e de navegador; conectores de investigação e de fontes de quadros; navegadores na cloud. Dois pormenores merecem ser referidos, porque mudam o destino dos dados:

As caixas de correio ligadas ficam junto do seu fornecedor. O correio é lido em direto junto do fornecedor, através de IMAP e SMTP ou do início de sessão do próprio fornecedor; o Nessie guarda a credencial selada e mais nada sobre a conta. Uma caixa de correio que ligue à caixa de entrada de Clientes é a exceção: está a pedir que as conversas fiquem guardadas junto de cada cliente, pelo que são copiadas para o Nessie.
As chamadas de voz na aplicação não passam pelo Nessie. A API intermedeia uma credencial e o cliente abre ele próprio a ligação de áudio. O ditado e as chamadas telefónicas são diferentes: o áudio passa pelo Nessie até aos fornecedores de voz e de modelos que o processam.

Um pormenor de inferência segue o mesmo princípio: os cabeçalhos assinados de identidade do autor do pedido só são enviados para o anfitrião de chat configurado, pelo que apontar os embeddings para outro endpoint nunca entrega a esse endpoint uma declaração de delegação sobre a pessoa cujo texto está a ser convertido em embeddings.

O produto alojado usa vários fornecedores de inferência e escolhe entre eles por custo e qualidade. Uma organização poderá escolher na admin quais os fornecedores que os seus agentes podem usar: só ocidentais, só europeus, só chineses ou sem preferência — o fornecedor mais eficiente para cada trabalho. Uma instância de alojamento próprio escolhe os seus.

Se o executar por si, tudo isto muda

Cada terceiro acima referido é uma escolha de configuração numa instância de alojamento próprio. A inferência pode ser apontada a qualquer endpoint compatível com OpenAI, incluindo um no seu próprio hardware. Os conectores estão desativados, a menos que os ative. O início de sessão UnlikeOtherAI é o caminho suportado, e uma implementação sem qualquer fornecedor de identidade funciona como uma única organização sem ligação, com um proprietário inicial.

É esse o ponto central da solução: o software é o mesmo, e as decisões sobre onde corre e a que pode aceder pertencem a quem o executa. A página de instalação explica como.