Създадено в ЕС и къде се съхраняват данните ви

Къде се създава Nessie, къде се съхраняват данните ви и какво контролирате, когато Nessie работи на ваша собствена инфраструктура.

Кой го изгражда и по кое право

Nessie се изгражда от UnlikeOtherAI s.r.o. – дружество, регистрирано в Чехия и действащо по чешското право.

Тази страница описва как е изграден софтуерът и къде работи. Тя не е декларация за съответствие: Nessie не притежава сертификат за сигурност и нищо тук не бива да се чете като такъв. Какви лични данни се обработват и на какво основание е предмет на политиката за поверителност, която е отделна страница.

Къде работи хостваният продукт

Nessie Cloud работи при европейски доставчици на хостинг – Scaleway, Hetzner и други. Избираме най-добрата услуга на всеки доставчик, така че различни части от продукта може да работят при различни доставчици, всички в Европа.

Нищо по-конкретно от това – определена площадка, град или център за данни – не се посочва нарочно, защото информацията би остаряла, без никой да забележи.

Самостоятелното хостване оставя избора във ваши ръце

Къде работи самостоятелно хостваната инсталация, е настройка на внедряването, а не на продукта. Пътят за една машина е стек с Docker Compose, който поставяте на машина по ваш избор. В дървото на Terraform за управлявано облачно решение регионът е входен параметър изобщо без стойност по подразбиране: нищо там не може да се налучква, затова нищо там няма стойност по подразбиране, а базата данни, хранилището за обекти и услугите следват региона, който сте посочили.

Два структурни детайла са важни за същия въпрос. Опашката и транспортът в реално време са и двете PostgreSQL – по пътя няма Redis и няма брокер на съобщения, така че няма трета система, която да се поставя някъде. А хранилището за обекти е съвместимо със S3 и не е вързано за един доставчик; референтното внедряване пуска MinIO в контейнер в частна мрежа без собствен входящ достъп. Частите, които трябва да живеят някъде, са базата данни, хранилището за обекти и двете услуги на Node, и всички те живеят там, където ги поставите. Как се прави това, е описано на страницата за инсталация.

Какво съхранява Nessie – и какво нарочно не съхранява

Самоличността не се копира

При вход през UnlikeOtherAI доставчикът на самоличност управлява и съхранява човешката самоличност – факторите за удостоверяване, профилите, членството в организации и екипи и поканите. Nessie е доверяваща се страна, а не втора система за самоличност. Това е решение за данните не по-малко, отколкото архитектурно: самоличност, която Nessie никога не съхранява, е самоличност, която не може да изтече, да бъде загубена или да остане неизтрита.

В таблицата users всъщност се пази стабилният идентификатор на потребителя от доставчика – ключът, през който се разрешава всичко останало, – имейл адресът, неавторитетно огледало на показваното име и аватара и локални за продукта полета (предпочитания, местоимения, версия на токена, използвана за отмяна на сесии). Огледалото съществува само за да може да се покаже име и снимка без заявка за всеки ред и се синхронизира отново от проверените твърдения на доставчика при вход, при смяна на екип и при подновяване на сесията. Нищо не измисля стойност: човек, когото доставчикът не е назовал, носи своя имейл адрес, докато това не стане. Хеш на парола има само за първоначалния собственик на инсталация изобщо без доставчик на самоличност.

Същото важи и за структурата. Една организация при доставчика е една организация в Nessie, свързана чрез идентификатора на организацията при доставчика; екип без връзка към доставчика отговаря с 404 TEAM_NOT_LINKED, вместо да се връща към локална догадка, а актуалното четене на състава отива при доставчика на самоличност и нищо не съхранява.

Две огледала още не са премахнати и би било нечестно да внушаваме обратното. Имената на организациите и екипите все още се съхраняват локално до идентификаторите на връзките, а локалните редове за членство все още оправомощават обикновените заявки между синхронизациите. Премахването и на двете е проследявана, отворена работа в хранилището на кода, а не нещо вече завършено.

Нищо търговско

Плащанията се управляват от централната услуга за таксуване. Nessie не съхранява клиент, абонамент, фактура, цена, кредитно салдо, политика за презареждане, съгласие за плащане, извлечение или състояние на отказ при платежния доставчик и не изчислява тарифи. Тя чете готови за показване стойности и ги показва.

Тайни

За да се съхрани каквато и да е тайна, е необходим настроен трезор. Нарочно няма резервен вариант в базата данни и няма път с обикновен текст: без трезор запазването, ротирането и отнемането на тайна връщат грешка, вместо да се влошат до нещо по-малко сигурно. Собствените записи на Nessie за дадена тайна не съдържат стойност, шифротекст, ключ или токен на трезора – само непрозрачна препратка и нейните метаданни, – а пътищата в трезора се изграждат само от структурни идентификатори, никога от името на организация, екип, проект или човек.

Идентификационните данни, които Nessie трябва да държи сама, за да действа като клиент на OAuth – данни за конектори и пощенски кутии, тайни на уебкуки, материал за подновяване на сесии, полезни товари на изпълнители – се запечатват в целево обвързани пликове AES-256-GCM под версиониран набор от ключове, който е отделен корен от тайната за подписване на сесиите, с документирана процедура за ротация.

Има и правило за моделите: може да се знае, че една тайна съществува, и да е разрешено използването ѝ, но материалът на тайната не бива да попада в контекста на модела, в подканите, аргументите на инструментите, резултатите от инструментите, паметта, векторните представяния, търсенето, дневниците или съобщенията. На агент може да се даде възможност да използва тайна. Никога не може да му се даде възможност да я разкрие.

Дали дисковете отдолу са шифровани, е свойство на машината, на която работи внедряването. Хранилището на кода не установява шифроване на ниво том за базата данни и за томовете с хранилището за обекти, затова тази страница не твърди такова.

Изолация на наемателите

Nessie е многонаемателна по замисъл: една база данни, в която всеки ред принадлежи на точно една организация и всяка подчинена таблица носи колона organization_id. Изолацията се прилага на две места – в клаузата за обхват, която носи всяка заявка, и в истински външни ключове върху тази колона, добавени чрез четиридесет и две ограничения, след като вътрешен одит установи, че колоната присъства, но не е ограничена в десетки таблици.

Набор от тестове за съответствие държи този инвариант на място на границата на HTTP. Той създава максимално привилегирован нападател – пълноправен собственик на своя организация – и проверява, че всяко канонично четене на ресурси на друга организация отговаря с 403, 404 или празно, а всяка канонична промяна се отхвърля, без редът на другата организация да бъде докоснат. Покрива канали, одобрения, одитния дневник, тригери, агенти и техните връзки, изпълнения, проекти, задачи, нишки, връзки, инсталации на работни процеси, инстанции на MCP, базата знания и известията.

За да сме точни относно механизма: това е прилагане на ниво приложение плюс външни ключове, а не защита на ниво ред в PostgreSQL (row-level security). Няма политика RLS и няма подкрепа от страна на базата данни, а наборът тестове работи срещу вярно изградено хранилище в паметта, а не срещу жива база данни, така че доказва клаузите за обхват, които пише кодът, а не SQL, който изпълнява сървърът. Хранилището на кода го казва в собствената документация на набора тестове, както го казва и тази страница.

Одитната следа

Записва се всяко значимо действие: кой е действал и в какво качество – човек, агент, услуга, – какво е направил, върху кой ресурс, в коя организация, проект, екип или канал, дали е успял или е бил отказан, защо, както и идентификаторът на заявката, адресът и потребителският агент, с които е пристигнало.

Дневникът е само за добавяне по замисъл и няма начин да се пише в него отвън: POST /api/audit-log не съществува и това е нарочно. Записите са верижно свързани – всеки носи SHA-256 дайджест на собствените си канонични полета плюс дайджеста на предишния запис за същата организация, – така че променен или премахнат ред прекъсва веригата и това може да се открие. Собственик или администратор на организацията може по всяко време да обходи веригата и му се казва къде за първи път е прекъсната, ако е била.

Две честни уговорки. Веригата прави дневника очевиден при подправяне, а не защитен от подправяне: зад него няма отнемане на правата за запис на ниво база данни, нито хранилище със запис еднократно, така че гаранцията е откриване, а не предотвратяване. И записите по подразбиране се пазят безсрочно – конфигурируемо съхранение с експорт преди изтриване е проектирано, но не е изградено. Записите също не могат да съдържат тайни или пълни тела на заявки, а фиксиран набор от имена на чувствителни метаданни се скрива при приемането.

Счетоводната книга на разходите

Всяко извикване на модел се записва към организацията и към потребителя, екипа, проекта, канала, агента и изпълнението, от които идва, заедно с изразходваните токени, като както отчетената от доставчика цена, така и собствената оценка на Nessie се пазят една до друга. Показател, който доставчикът не отчита, се съхранява като null, а не се налучква. Отчетите могат да се четат от собственик или администратор на организацията.

Тази книга е оперативна телеметрия – колко е похарчила една организация и от чие име. Тя не е фактура и не е авторитет по таксуването.

Трети страни, когато използвате хостван продукт

Хостваното внедряване комуникира с малък, фиксиран набор от услуги. Трафикът към модели и уеб търсенето не отиват директно към доставчици: и двете излизат през един шлюз, управляван от UnlikeOtherAI, зад който стоят доставчиците на модели и търсене. Входът и таксуването отиват към удостоверителя на UnlikeOtherAI. Трезорът за тайни се хоства самостоятелно заедно с приложението. Генерираните от сървъра връзки за видеообаждания по подразбиране използват публичната услуга Jitsi.

Почти всичко останало е изключено, докато оператор не го настрои, и го заявява, вместо да се проваля тихо: свързани акаунти в Google, Microsoft и Slack; имейл на агентите през Amazon SES, който внедряването пуска в собствения си акаунт без посредник; мобилни и браузърни известия; конектори за проучвания и източници на табла; облачни браузъри. Две подробности заслужава да се споменат, защото променят къде отиват данните:

• Свързаните пощенски кутии остават при вашия доставчик. Пощата се чете на живо от вашия доставчик – през IMAP и SMTP или през собствения вход на доставчика; Nessie съхранява запечатаните данни за вход и нищо друго за акаунта. Пощенската кутия, която свързвате към входящата поща на Клиенти, е изключение: вие искате разговорите ѝ да се пазят при всеки клиент, затова те се копират.
• Гласовите обаждания в приложението не минават през Nessie. API-то посредничи за идентификационни данни, а клиентът сам отваря аудиовръзката. Диктуването и телефонните обаждания са друго: звукът им минава през Nessie към доставчиците на реч и модели, които го обработват.

Една подробност при извеждането на заключения следва същия принцип: подписаните заглавки за самоличност на извикващия се изпращат само към настроения чат хост, така че насочването на векторните представяния към друга крайна точка никога не предава на тази точка твърдение за делегиране за човека, чийто текст се представя.

Хостваният продукт използва няколко доставчика за извеждане на заключения и избира между тях според цената и качеството. Организацията ще може да избира в администрацията кои доставчици да използват нейните агенти: само западни, само европейски, само китайски или без предпочитание – най-ефективният доставчик за всяка задача. Самостоятелно хостваната инсталация избира сама.

Ако го пуснете сами, всичко това се променя

Всяка трета страна по-горе е конфигурационен избор на самостоятелно хостваната инсталация. Извеждането на заключения може да се насочи към всяка крайна точка, съвместима с OpenAI, включително такава на собствен хардуер. Конекторите са изключени, освен ако не ги включите. Входът през UnlikeOtherAI е поддържаният път, а внедряване изобщо без доставчик на самоличност работи като една несвързана организация с първоначален собственик.

Именно това е смисълът на подредбата: софтуерът е един и същ, а решенията къде работи и до какво може да достига принадлежат на този, който го управлява. Как – описва страницата за инсталация.