Fet a la UE, i on són les teves dades

On es fa Nessie, on són les teves dades i què controles quan l’allotges tu mateix.

Qui el construeix i sota quina llei

Nessie el construeix UnlikeOtherAI s.r.o., una empresa registrada a la República Txeca i que opera sota la legislació txeca.

Aquesta pàgina descriu com es construeix el programari i on s’executa. No és una declaració de compliment: Nessie no té cap certificació de seguretat i res del que hi ha aquí s’ha d’entendre com a tal. Quines dades personals es tracten i amb quina base és matèria de la política de privadesa, que és una pàgina a part.

On s’executa el producte allotjat

Nessie Cloud s’executa en proveïdors d’allotjament europeus —Scaleway, Hetzner i altres—. Triem el millor servei que ofereix cada proveïdor, de manera que diferents parts del producte poden funcionar amb proveïdors diferents, tots a Europa.

Qualsevol dada més precisa que aquesta —un emplaçament, una ciutat o un centre de dades concret— no s’indica aquí de manera deliberada, perquè quedaria desactualitzada sense que ningú se n’adonés.

L’autoallotjament et deixa la decisió a les mans

On s’executa una instància autoallotjada és un paràmetre de desplegament, no un paràmetre del producte. El camí d’una sola màquina és una pila de Docker Compose que col·loques en una màquina que tries tu. A l’arbre de Terraform per a un núvol gestionat, la regió és una entrada sense cap valor per defecte: res d’allà es pot endevinar, de manera que res no té valor per defecte, i la base de dades, el dipòsit d’emmagatzematge d’objectes i els serveis segueixen tots la regió que indiquis.

Hi ha dos detalls estructurals que compten per a la mateixa qüestió. La cua i el transport en temps real són tots dos PostgreSQL: no hi ha Redis ni cap intermediari de missatges pel mig, de manera que no hi ha un tercer sistema que cal ubicar. I l’emmagatzematge d’objectes és compatible amb S3 en lloc d’estar lligat a un sol proveïdor; el desplegament de referència executa MinIO en un contenidor, en una xarxa privada i sense cap entrada pròpia. Les parts que han de viure en algun lloc són la base de dades, el magatzem d’objectes i els dos serveis Node, i totes viuen allà on les posis. Com s’aixeca tot plegat ho trobaràs a la pàgina d’instal·lació.

Què guarda Nessie, i què no guarda deliberadament

La identitat no es copia

Amb l’inici de sessió d’UnlikeOtherAI, el proveïdor d’identitat gestiona i guarda la identitat de les persones: els factors d’autenticació, els perfils, la pertinença a organitzacions i equips, i les invitacions. Nessie és una part confiant, no un segon sistema d’identitat. És una decisió sobre dades tant com d’arquitectura: una identitat que Nessie no guarda mai és una que no pot filtrar, perdre ni deixar d’esborrar.

El que la taula users guarda realment és l’identificador estable d’usuari del proveïdor —la clau a través de la qual es resol tota la resta—, l’adreça electrònica, un mirall no autoritatiu del nom visible i de l’avatar, i camps propis del producte (preferències, pronoms, una versió de token que serveix per revocar sessions). El mirall només hi és perquè es pugui mostrar un nom i una imatge sense una petició per cada fila, i es torna a sincronitzar a partir de les declaracions verificades del proveïdor a l’inici de sessió, en canviar d’equip i en renovar la sessió. Res no fabrica cap valor: una persona a qui el proveïdor no ha donat nom porta la seva adreça electrònica fins que ho faci. Només hi ha un hash de contrasenya per al propietari d’arrencada d’una instal·lació que no té cap proveïdor d’identitat.

El mateix val per a l’estructura. Una organització del proveïdor és una organització de Nessie, vinculada per l’identificador d’organització del proveïdor; un equip sense enllaç amunt respon 404 TEAM_NOT_LINKED en lloc de recórrer a una suposició local, i una lectura en directe de la llista de membres va al proveïdor d’identitat i no en conserva res.

Encara hi ha dos miralls que no hem eliminat, i seria deshonest suggerir el contrari. Els noms de l’organització i de l’equip encara es guarden localment al costat dels identificadors de vinculació, i les files locals de pertinença encara autoritzen les peticions ordinàries entre sincronitzacions. Eliminar totes dues coses és feina oberta i registrada al repositori, no pas una cosa ja acabada.

Res de comercial

El servei central de facturació gestiona els pagaments. Nessie no guarda cap client, subscripció, factura, preu, saldo de crèdit, política de recàrrega, consentiment de pagament, extracte ni estat de cancel·lació d’un proveïdor de pagaments, i no calcula tarifes. Llegeix valors ja preparats per mostrar i els mostra.

Secrets

Cal tenir una caixa forta configurada per poder guardar cap secret. Deliberadament no hi ha cap alternativa a la base de dades ni cap camí en text pla: sense caixa forta, desar, rotar i revocar un secret retornen un error en lloc de degradar-se a una cosa menys segura. Els registres propis de Nessie sobre un secret no contenen cap valor, cap text xifrat, cap clau ni cap token de la caixa forta, només una referència opaca i les seves metadades, i els camins de la caixa forta es construeixen només a partir d’identificadors estructurals, mai amb el nom d’una organització, un equip, un projecte o una persona.

Les credencials que Nessie ha de conservar ell mateix per actuar com a client d’OAuth —credencials de connectors i de bústies, secrets de webhooks, material de renovació de sessió, càrregues de l’executor— es segellen en sobres AES-256-GCM lligats a un propòsit, sota un anell de claus versionat que és una arrel independent del secret de signatura de sessió, amb un procediment de rotació documentat.

També hi ha una regla sobre els models: es pot saber que un secret existeix i es pot autoritzar el seu ús, però el material del secret no ha d’entrar mai al context del model, als prompts, als arguments d’eines, als resultats d’eines, a la memòria, als embeddings, a la cerca, als registres ni als missatges. A un agent se li pot concedir la capacitat d’usar un secret. Mai no se li pot concedir la de revelar-ne cap.

Que els discos subjacents estiguin xifrats és una propietat de la màquina on s’executa un desplegament. El repositori no estableix el xifratge a nivell de volum per als volums de la base de dades i de l’emmagatzematge d’objectes, de manera que aquesta pàgina no ho afirma.

Aïllament entre inquilins

Nessie és multiinquilí per disseny: una sola base de dades en què cada fila pertany exactament a una organització i cada taula filla porta un organization_id. L’aïllament s’aplica en dos llocs: la clàusula d’abast que porta cada consulta, i unes claus foranes reals sobre aquesta columna, que es van afegir en quaranta-dues restriccions després que una auditoria interna trobés que la columna hi era però sense restricció en desenes de taules.

Un conjunt de proves de conformitat manté aquesta invariant fixada a la frontera HTTP. Hi sembra un atacant amb el màxim de privilegis —propietari complet de la seva pròpia organització— i comprova que cada lectura canònica de recursos d’una altra organització respongui 403, 404 o buit, i que cada mutació canònica sigui rebutjada deixant intacta la fila de l’altra organització. Cobreix canals, aprovacions, el registre d’auditoria, activadors, agents i els seus vincles, execucions, projectes, tasques, fils, connexions, instal·lacions de fluxos de treball, instàncies MCP, la base de coneixement i les alertes.

Sent precisos sobre el mecanisme: això és aplicació a nivell d’aplicació més claus foranes, no seguretat a nivell de fila de PostgreSQL. No hi ha cap política RLS ni cap suport al costat de la base de dades, i el conjunt de proves s’executa contra un magatzem fidel en memòria i no contra una base de dades real, de manera que demostra les clàusules d’abast que escriu el codi, no l’SQL que executa un servidor. El repositori ho diu a la documentació del mateix conjunt de proves, i aquesta pàgina també.

El registre d’auditoria

Es registra cada acció amb conseqüències: qui ha actuat i com —una persona, un agent, un servei—, què ha fet, sobre quin recurs, en quina organització, projecte, equip o canal, si ha tingut èxit o s’ha denegat, per què, i l’identificador de petició, l’adreça i l’agent d’usuari amb què ha arribat.

El registre és només d’addició per disseny i no hi ha cap manera d’escriure-hi des de fora: POST /api/audit-log no existeix, i és deliberat. Les entrades estan encadenades —cadascuna porta un resum SHA-256 dels seus propis camps canònics més el resum de l’entrada anterior d’aquella organització—, de manera que una fila modificada o suprimida trenca la cadena i es pot detectar. Un propietari o administrador de l’organització pot recórrer aquesta cadena quan vulgui i se li diu on es va trencar per primera vegada, si es va trencar.

Dues matisacions honestes. La cadena fa que el registre sigui evident davant de manipulacions, no immune a la manipulació: al darrere no hi ha cap revocació d’escriptura a nivell de base de dades ni cap emmagatzematge d’escriptura única, de manera que la garantia és la detecció, no la prevenció. I les entrades es conserven indefinidament per defecte: la retenció configurable amb exportació abans d’esborrar està dissenyada, no construïda. A més, les entrades tenen prohibit portar secrets o cossos complets de petició, i un conjunt fix de noms de camps de metadades sensibles s’oculta en entrar.

El llibre de costos

Cada invocació d’un model es registra contra l’organització i contra l’usuari, l’equip, el projecte, el canal, l’agent i l’execució d’on ve, amb els tokens que ha consumit i amb el cost informat pel proveïdor i l’estimació de Nessie guardats un al costat de l’altre. Una mètrica que un proveïdor no informa es guarda com a nul·la en lloc d’endevinar-la. Els informes els pot llegir un propietari o administrador de l’organització.

Aquest llibre és telemetria operativa: què ha gastat una organització i per compte de qui. No és una factura ni una autoritat de facturació.

Tercers, quan fas servir el producte allotjat

Un desplegament allotjat parla amb un conjunt reduït i fix de serveis. El trànsit de models i la cerca web no van directament als proveïdors: tots dos surten per una única passarel·la operada per UnlikeOtherAI, que és on hi ha els proveïdors de models i de cerca. L’inici de sessió i la facturació van a l’autenticador d’UnlikeOtherAI. La caixa forta de secrets està autoallotjada al costat de l’aplicació. Els enllaços de videotrucada generats pel servidor fan servir per defecte el servei públic de Jitsi.

Gairebé tota la resta està desactivada fins que un operador la configura, i ho diu en lloc de fallar en silenci: comptes connectats de Google, Microsoft i Slack; el correu dels agents mitjançant Amazon SES, que cada desplegament executa al seu propi compte sense cap intermediari; notificacions push mòbils i del navegador; connectors de recerca i de fonts de tauler; navegadors al núvol. Val la pena dir dos detalls perquè canvien on van les dades:

• Les bústies connectades es queden amb el teu proveïdor. El correu es llegeix en directe del teu proveïdor, per IMAP i SMTP o amb l’inici de sessió propi del proveïdor; Nessie en guarda la credencial segellada i res més del compte. Una bústia que connectes a la safata d’entrada de Clients és l’excepció: demanes que les converses es guardin amb cada client, de manera que se’n fa una còpia.
• Les trucades de veu a l’aplicació no passen per Nessie. L’API fa de corredor d’una credencial i el client obre ell mateix la connexió d’àudio. El dictat i les trucades telefòniques són diferents: el seu àudio passa per Nessie cap als proveïdors de veu i de models que el tracten.

Un detall d’inferència segueix el mateix principi: les capçaleres signades d’identitat del sol·licitant només s’envien al servidor de xat configurat, de manera que apuntar els embeddings a un altre endpoint no li lliura mai una asserció de delegació sobre la persona el text de la qual s’està incrustant.

El producte allotjat fa servir diversos proveïdors d’inferència i tria entre ells segons el cost i la qualitat. Una organització podrà triar a l’administració quins proveïdors poden fer servir els seus agents: només occidentals, només europeus, només xinesos, o sense preferència —el proveïdor més eficient per a cada feina—. Una instància autoallotjada tria els seus.

Si l’executes tu mateix, tot això canvia

Cada tercer de la llista anterior és una opció de configuració en una instància autoallotjada. La inferència es pot dirigir a qualsevol endpoint compatible amb OpenAI, també un al teu propi maquinari. Els connectors estan desactivats tret que els activis. L’inici de sessió d’UnlikeOtherAI és el camí compatible, i un desplegament sense cap proveïdor d’identitat s’executa com una sola organització no vinculada amb un propietari d’arrencada.

Aquest és tot el sentit de l’arranjament: el programari és el mateix, i les decisions sobre on s’executa i fins on pot arribar corresponen a qui l’executa. La pàgina d’instal·lació explica com.