Stworzone w UE i miejsce przechowywania twoich danych

Gdzie powstaje Nessie, gdzie znajdują się twoje dane i co kontrolujesz, gdy hostujesz Nessie samodzielnie.

Kto to buduje i według jakiego prawa

Nessie tworzy UnlikeOtherAI s.r.o. — spółka zarejestrowana w Czechach i działająca według prawa czeskiego.

Ta strona opisuje, jak oprogramowanie jest zbudowane i gdzie działa. Nie jest oświadczeniem o zgodności: Nessie nie posiada żadnego certyfikatu bezpieczeństwa i nic tutaj nie należy za taki uznawać. To, jakie dane osobowe są przetwarzane i na jakiej podstawie, opisuje polityka prywatności — to osobna strona.

Gdzie działa wersja hostowana

Nessie Cloud działa u europejskich dostawców hostingu — Scaleway, Hetznera i innych. Wybieramy najlepszą usługę każdego z nich, więc różne części produktu mogą działać u różnych dostawców, wszyscy w Europie.

Nic dokładniejszego — konkretnej lokalizacji, miasta czy centrum danych — celowo tu nie podajemy, bo taka informacja zdezaktualizowałaby się niezauważenie.

Samodzielny hosting oddaje wybór w twoje ręce

To, gdzie działa instancja hostowana samodzielnie, jest ustawieniem wdrożenia, a nie ustawieniem produktu. Wariant jednomaszynowy to stos Docker Compose, który uruchamiasz na wybranej maszynie. W drzewie Terraform dla zarządzanej chmury region jest parametrem bez żadnej wartości domyślnej: niczego nie da się tam zgadnąć, więc niczego tam nie ustawiono domyślnie, a baza danych, bucket magazynu obiektów i usługi podążają za regionem, który wskażesz.

W tej samej kwestii liczą się jeszcze dwa szczegóły architektury. Kolejka i transport czasu rzeczywistego to w obu przypadkach PostgreSQL — na ścieżce nie ma Redisa ani brokera wiadomości, więc nie ma trzeciego systemu, który trzeba gdzieś umieścić. Magazyn obiektów jest zgodny z S3 i nie jest przywiązany do jednego dostawcy; we wdrożeniu referencyjnym działa MinIO w kontenerze w sieci prywatnej, bez własnego wejścia z zewnątrz. Elementy, które muszą gdzieś działać — baza danych, magazyn obiektów i dwie usługi Node — działają tam, gdzie je postawisz. Jak to uruchomić, opisuje strona instalacji.

Co Nessie przechowuje, a czego celowo nie

Tożsamość nie jest kopiowana

Przy logowaniu przez UnlikeOtherAI dostawca tożsamości zarządza tożsamością ludzi i ją przechowuje — czynniki uwierzytelniania, profile, członkostwo w organizacjach i zespołach oraz zaproszenia. Nessie jest stroną ufającą (relying party), a nie drugim systemem tożsamości. To decyzja tyle samo dotycząca danych, co architektury: tożsamości, której Nessie nigdy nie przechowuje, nie może wyciec, zgubić ani zapomnieć usunąć.

Tabela users przechowuje w rzeczywistości stały identyfikator użytkownika nadany przez dostawcę — klucz, przez który rozwiązywane jest wszystko inne — adres e-mail, niewiążące odbicie nazwy wyświetlanej i awatara oraz pola lokalne produktu (preferencje, zaimki, wersję tokenu służącą do unieważniania sesji). Odbicie istnieje wyłącznie po to, by można było wyświetlić imię i zdjęcie bez osobnego zapytania dla każdego wiersza; jest odświeżane ze zweryfikowanych oświadczeń dostawcy przy logowaniu, przy zmianie zespołu i przy odświeżeniu sesji. Żadna wartość nie jest wymyślana: osoba, której dostawca nie nazwał, ma w miejscu nazwy swój adres e-mail, dopóki nie zostanie nazwana. Hash hasła istnieje tylko dla pierwszego właściciela instalacji, która w ogóle nie ma dostawcy tożsamości.

To samo dotyczy struktury. Jedna organizacja u dostawcy to jedna organizacja w Nessie, powiązana identyfikatorem organizacji nadanym przez dostawcę; zespół bez powiązania nadrzędnego zwraca 404 TEAM_NOT_LINKED zamiast cofać się do lokalnego domysłu, a odczyt aktualnej listy członków trafia do dostawcy tożsamości i niczego nie zapisuje.

Dwa odbicia jeszcze nie zniknęły i nieuczciwie byłoby sugerować inaczej. Nazwy organizacji i zespołów są nadal przechowywane lokalnie obok identyfikatorów powiązania, a lokalne wiersze członkostwa nadal autoryzują zwykłe żądania między synchronizacjami. Usunięcie obu to otwarta, śledzona praca w repozytorium, a nie coś, co już zostało zakończone.

Nic handlowego

Płatnościami zarządza centralna usługa rozliczeń. Nessie nie przechowuje klienta, subskrypcji, faktury, ceny, salda kredytów, zasad doładowań, zgody płatniczej, zestawienia ani stanu anulowania po stronie operatora płatności i nie oblicza taryf. Odczytuje gotowe do wyświetlenia wartości i je pokazuje.

Sekrety

Do zapisania jakiegokolwiek sekretu wymagany jest skonfigurowany sejf. Celowo nie ma zapasowej ścieżki przez bazę danych ani zapisu jawnym tekstem: bez sejfu zapisanie, rotacja i unieważnienie sekretu kończą się błędem, a nie przejściem na coś mniej bezpiecznego. Własne rekordy Nessie o sekrecie nie zawierają wartości, szyfrogramu, klucza ani tokenu sejfu — tylko nieprzezroczyste odwołanie i jego metadane — a ścieżki w sejfie budowane są wyłącznie ze strukturalnych identyfikatorów, nigdy z nazwy organizacji, zespołu, projektu czy osoby.

Poświadczenia, które Nessie musi przechowywać samo, by działać jako klient OAuth — poświadczenia konektorów i skrzynek pocztowych, sekrety webhooków, materiał do odświeżania sesji, ładunki executora — są zapieczętowane w kopertach AES-256-GCM przypisanych do celu, pod wersjonowanym zestawem kluczy, który jest odrębnym korzeniem od sekretu podpisującego sesje i ma udokumentowaną procedurę rotacji.

Obowiązuje też reguła dotycząca modeli: o sekrecie można wiedzieć, że istnieje, i można zezwolić na jego użycie, ale materiał sekretu nie może trafić do kontekstu modelu, promptów, argumentów narzędzi, wyników narzędzi, pamięci, embeddingów, wyszukiwania, logów ani wiadomości. Agent może dostać możliwość użycia sekretu. Nigdy nie dostanie możliwości jego ujawnienia.

To, czy dyski są szyfrowane, jest cechą maszyny, na której działa wdrożenie. Repozytorium nie ustanawia szyfrowania na poziomie woluminów dla bazy danych i magazynu obiektów, dlatego ta strona tego nie twierdzi.

Izolacja najemców

Nessie jest z założenia wielonajemcze: jedna baza danych, w której każdy wiersz należy do dokładnie jednej organizacji, a każda tabela podrzędna ma kolumnę organization_id. Izolacja jest wymuszana w dwóch miejscach — w klauzuli zakresu, którą niesie każde zapytanie, oraz w prawdziwych kluczach obcych na tej kolumnie, dodanych w czterdziestu dwóch ograniczeniach, gdy wewnętrzny audyt wykazał, że kolumna jest obecna, ale w dziesiątkach tabel pozbawiona ograniczeń.

Zestaw testów zgodności pilnuje tego niezmiennika na granicy HTTP. Zasiewa maksymalnie uprzywilejowanego atakującego — pełnego właściciela własnej organizacji — i sprawdza, że każdy kanoniczny odczyt zasobów innej organizacji kończy się odpowiedzią 403, 404 lub pustą, a każda kanoniczna mutacja zostaje odrzucona, przy czym wiersz drugiej organizacji pozostaje nietknięty. Obejmuje kanały, zatwierdzenia, dziennik audytu, wyzwalacze, agentów i ich powiązania, uruchomienia, projekty, zadania, wątki, połączenia, instalacje przepływów pracy, instancje MCP, bazę wiedzy i alerty.

Precyzyjnie o mechanizmie: jest to wymuszanie na poziomie aplikacji plus klucze obce, a nie zabezpieczenia na poziomie wierszy (row-level security) w PostgreSQL. Nie ma polityki RLS ani zabezpieczenia po stronie bazy danych, a zestaw testów zgodności działa na wiernym magazynie w pamięci, a nie na prawdziwej bazie, więc dowodzi tego, co zapisują klauzule zakresu w kodzie, a nie SQL wykonywanego przez serwer. Mówi o tym dokumentacja samego zestawu w repozytorium i mówi o tym ta strona.

Ślad audytowy

Każde istotne działanie jest zapisywane: kto działał i w jakiej roli — osoba, agent, usługa — co zrobił, na jakim zasobie, w której organizacji, projekcie, zespole lub kanale, czy się udało, czy zostało odrzucone, dlaczego, a także identyfikator żądania, adres i user agent, z którymi przyszło.

Dziennik jest z założenia tylko do dopisywania i nie ma sposobu, by zapisać do niego z zewnątrz: POST /api/audit-log nie istnieje i jest to celowe. Wpisy są powiązane w łańcuch — każdy niesie skrót SHA-256 własnych pól kanonicznych oraz skrót poprzedniego wpisu tej organizacji — więc zmieniony lub usunięty wiersz przerywa łańcuch i da się to wykryć. Właściciel lub administrator organizacji może przejść ten łańcuch na żądanie i dowiaduje się, gdzie się po raz pierwszy przerwał, jeśli tak się stało.

Dwa uczciwe zastrzeżenia. Łańcuch sprawia, że dziennik ujawnia manipulacje, ale nie czyni ich niemożliwymi: nie stoi za nim odebranie praw zapisu na poziomie bazy ani magazyn jednokrotnego zapisu, więc gwarancją jest wykrycie, a nie zapobieganie. Po drugie, wpisy są domyślnie przechowywane bezterminowo — konfigurowalne przechowywanie z eksportem przed usunięciem jest zaprojektowane, ale niezbudowane. Wpisy nie mogą też zawierać sekretów ani pełnych treści żądań, a stały zestaw nazw wrażliwych pól metadanych jest zamazywany przy zapisie.

Rejestr kosztów

Każde wywołanie modelu jest zapisywane przy organizacji oraz przy użytkowniku, zespole, projekcie, kanale, agencie i uruchomieniu, z których pochodzi, razem ze zużytymi tokenami; koszt podany przez dostawcę i własne oszacowanie Nessie są przechowywane obok siebie. Miara, której dostawca nie podaje, jest zapisywana jako null, a nie zgadywana. Raporty może odczytać właściciel lub administrator organizacji.

Ten rejestr to telemetria operacyjna — ile organizacja wydała i na czyje polecenie. Nie jest fakturą ani organem rozliczeniowym.

Podmioty trzecie przy korzystaniu z wersji hostowanej

Wdrożenie hostowane komunikuje się z małym, stałym zbiorem usług. Ruch do modeli i wyszukiwanie w sieci nie trafiają bezpośrednio do dostawców: oba wychodzą przez jedną bramę prowadzoną przez UnlikeOtherAI, za którą stoją dostawcy modeli i wyszukiwania. Logowanie i rozliczenia trafiają do uwierzytelniacza UnlikeOtherAI. Sejf sekretów jest hostowany samodzielnie obok aplikacji. Linki do rozmów wideo tworzone przez serwer domyślnie wskazują publiczną usługę Jitsi.

Prawie wszystko inne jest wyłączone, dopóki operator tego nie skonfiguruje, i mówi o tym wprost, zamiast zawodzić po cichu: połączone konta Google, Microsoft i Slack; poczta agentów przez Amazon SES, którą wdrożenie prowadzi na własnym koncie, bez pośrednika; powiadomienia push w aplikacji mobilnej i przeglądarce; konektory badań i źródeł tablic; przeglądarki w chmurze. Dwa szczegóły warto wymienić, bo zmieniają to, dokąd trafiają dane:

• Połączone skrzynki pocztowe zostają u twojego dostawcy. Poczta jest odczytywana na żywo od twojego dostawcy, przez IMAP i SMTP albo logowanie samego dostawcy; Nessie przechowuje zapieczętowane poświadczenie i nic więcej o koncie. Wyjątkiem jest skrzynka, którą podłączasz do skrzynki odbiorczej Klientów: prosisz wtedy, by jej rozmowy były przechowywane przy każdym kliencie, więc są kopiowane.
• Rozmowy głosowe w aplikacji nie przechodzą przez Nessie. API pośredniczy w wydaniu poświadczenia, a klient sam otwiera połączenie audio. Dyktowanie i rozmowy telefoniczne działają inaczej: ich dźwięk przechodzi przez Nessie do dostawców mowy i modeli, którzy go przetwarzają.

Jeden szczegół dotyczący wnioskowania opiera się na tej samej zasadzie: podpisane nagłówki tożsamości wywołującego są wysyłane wyłącznie do skonfigurowanego hosta czatu, więc skierowanie embeddingów na inny punkt końcowy nigdy nie przekaże temu punktowi asercji delegowania dotyczącej osoby, której tekst jest osadzany.

Wersja hostowana korzysta z kilku dostawców wnioskowania i wybiera między nimi pod kątem kosztu i jakości. Organizacja będzie mogła wybrać w panelu administracyjnym, których dostawców mogą używać jej agenci: tylko zachodnich, tylko europejskich, tylko chińskich albo bez preferencji — wtedy najbardziej efektywnego dostawcę do każdego zadania. Instancja hostowana samodzielnie wybiera własnych.

Samodzielny hosting zmienia to wszystko

Każdy z powyższych podmiotów trzecich jest w instancji hostowanej samodzielnie kwestią konfiguracji. Wnioskowanie można skierować na dowolny punkt końcowy zgodny z OpenAI, także na twoim własnym sprzęcie. Konektory są wyłączone, dopóki ich nie włączysz. Logowanie przez UnlikeOtherAI jest wspieraną ścieżką, a wdrożenie bez żadnego dostawcy tożsamości działa jako pojedyncza niepowiązana organizacja z pierwszym właścicielem.

Na tym polega całe założenie: oprogramowanie jest to samo, a decyzje o tym, gdzie działa i do czego może sięgać, należą do tego, kto je uruchamia. Jak to zrobić, opisuje strona instalacji.