Securitate și date, așa cum sunt astăzi.

Niciun furnizor AI nu vă citește documentele în mod implicit.

O organizație nouă nu permite niciunul. Prima încercare de a citi un document eșuează și indică organizația și modelul. Autorizarea este o comandă a unui operator, care înregistrează cine a decis, când și pe ce temei declarat. Nu există trecere automată la un al doilea furnizor dacă primul este refuzat, iar o configurație pur și simplu absentă nu devine niciodată consimțământ. Gemini API și Vertex AI sunt doi subprocesatori, iar fiecare este autorizat separat.

În demo, textul documentelor este trimis către Gemini API de la Google, prin HTTPS. Faptul că acest trafic intră sub termeni care exclud antrenarea depinde de serviciul Google și de contractul de care ține credențialul API. Nimic din sistemul nostru nu stabilește și nu impune acest lucru. Demo-ul are un singur credențial și un singur endpoint.

Este o lacună în propria noastră verificare. Nu este o constatare despre Google. Remedierea înseamnă să obținem termenii furnizorului pentru serviciul precis pe care îl folosim, să îi înregistrăm și să facem ca mediul de rulare să dovedească faptul că rulează pe acel serviciu. Se află pe lista de condiții de mai jos și nu este opțională înainte de documentele reale.

Unde rulează modelul

Endpointul Gemini API folosit de demo nu garantează prelucrarea în UE. O regiune europeană de inferență cere o altă integrare. Pentru pilot, integrarea aceea este acum construită: API-ul unui pilot citește prin endpointul UE al Vertex AI și refuză să pornească pe orice alt serviciu AI. Niciun document al unui client nu i-a fost trimis; în testele noastre a primit doar documente publice.

Nu vom afirma că documentele unui client sunt prelucrate în UE înainte ca vreunul să fi fost prelucrat.

Furnizorul AI al pilotului: Vertex AI în UE, așa cum a fost verificat pe 20 octombrie 2026

Ce spune această secțiune despre Google este documentația Google așa cum am citit-o pe 20 octombrie 2026. Ce spune despre ELARID descrie codul nostru la acea dată. Nu presupunem că ceva rămâne valabil: o pagină, starea unui model sau termenii se pot schimba după acea dată.

• Un subprocesator de sine stătător. Vertex AI și Gemini API oferă aceleași modele Gemini sub termeni diferiți. Gemini API se află sub propriii Termeni suplimentari de utilizare (Additional Terms of Service). Vertex AI este un serviciu Google Cloud, sub termenii Google Cloud. ELARID le listează ca doi subprocesatori și îl autorizează pe fiecare separat. Din 22 aprilie 2026, Google documentează Vertex AI sub un nume nou, Gemini Enterprise Agent Platform.
• Endpointul UE, niciodată cel global. Fiecare apel merge la endpointul multi-regiune UE al Google. Este singura adresă Vertex AI pe care o poate construi integrarea, iar nicio setare nu indică alta. Documentația Google spune că acest endpoint acoperă strict rezidența datelor în interiorul statelor membre UE și că o cerere trimisă unui endpoint global poate fi prelucrată în orice locație Google Cloud din lume.
• Modelul, așa cum a fost verificat. Integrarea numește un singur model, gemini-3.7-flash, pe care Google îl listează ca suportat pentru prelucrare de învățare automată în multi-regiunea UE. Google indică retragerea lui la 28 ianuarie 2027, cu gemini-3.8-flash ca înlocuitor, listat și el pentru multi-regiunea UE. După data retragerii, un apel către model eșuează. Trecerea la înlocuitor este o schimbare deliberată în codul nostru, niciodată una pe tăcute.
• Ce nu folosim. Google garantează prelucrarea în UE doar pentru ce listează. ELARID face un singur fel de apel: un prompt, cu întregul PDF atașat atunci când documentul are pagini scanate, și forma JSON pe care trebuie să o ia răspunsul. Nu folosește nicio capacitate, funcție sau opțiune de consum pe care pagina Google o marchează ca nesuportată acolo. Nu folosește grounding, apelare de funcții, execuție de cod, ajustare fină (tuning), inferență în lot sau Live API și nu creează un cache de context propriu. Consola Google se află în afara limitei jurisdicționale și nu este folosită niciodată cu documente ale clienților.
• Ce nu lămurește pagina Google. Ea listează capacități și nu menționează felurile de intrare. Nu spune nimic, într-un sens sau altul, despre un PDF trimis odată cu cererea, iar așa se transcrie o pagină scanată.
• Ce înregistrează fiecare apel. Înregistrarea fiecărui apel AI indică furnizorul, unde s-a promis prelucrarea (UE sau „negarantat” pentru un serviciu care nu promite nimic), modelul cerut și versiunea modelului care a răspuns, înregistrată doar atunci când răspunsul o declară. Versiunea nu este dedusă niciodată din numele modelului. Baza de date refuză un rând care declară UE pentru orice furnizor în afară de Vertex AI.
• Încă nu. Ce spune contractul Google despre antrenare și păstrare se înregistrează atunci când contractul există. Nu va fi luat doar dintr-o pagină web și nu se înregistrează înainte de acel moment.

Paginile Google din spatele acestei secțiuni

Fiecare dată este cea pe care o poartă pagina însăși.

• Data residency. Multi-regiunea UE, modelele listate pentru prelucrare în UE și endpointul global. Datată 15 octombrie 2026.
• Supported capabilities. Ce este și ce nu este acoperit pe endpointurile multi-regiune. Datată 15 octombrie 2026.
• Locations. Endpointul UE și locația lui. Datată 19 octombrie 2026.
• Model versions. Lansare, retragere și înlocuitor. Datată 19 octombrie 2026.
• Release notes. Noul nume, din 22 aprilie 2026. Datată 15 octombrie 2026.
• Gemini API Additional Terms of Service. Termenii Gemini API. Datată 28 aprilie 2026.
• Google Cloud Service Specific Terms. Termenii pentru Vertex AI ca serviciu Google Cloud. Datată 12 octombrie 2026.

În pilot, accesul este restrâns prin separarea stocării administrate de resursele de calcul.

Citirile sunt înregistrate înainte de a fi servite

Produsul înregistrează de fiecare dată când servește unei persoane unul dintre documentele dumneavoastră, un pasaj citat din el sau ce s-a citit din el: constatările, urma dovezilor, poziția privind garanția, o evaluare, un document citit din nou. Înregistrarea spune cine, ce, când și la ce cerere. Este scrisă înainte ca răspunsul să plece. O citire care nu poate fi înregistrată nu este servită.

Dacă ne întrebați cine de la ELARID s-a uitat la fișierul dumneavoastră, răspundem din acea înregistrare. Ea se află în jurnalul de audit, la care aplicația poate adăuga, dar pe care nu îl poate modifica sau șterge. Supraviețuiește unei ștergeri, pentru că tocmai atunci este nevoie de ea.

Ea înregistrează ce a fost servit, ceea ce înseamnă mai mult decât ce a fost privit, și niciodată mai puțin. Pagina de portofoliu citește constatările fiecărui proiect pentru a spune ce așteaptă și unde, deci deschiderea ei înregistrează fiecare proiect ca servit. O pagină afișată din nou sau reîmprospătată înregistrează din nou.

Ce nu conține

Listele proiectelor dumneavoastră. Listele documentelor pe care le conține un proiect, cu numele lor și cu emitentul, numărul și data citite din fiecare. Listele etapelor de procesare ale unui document. Răspunsul la o încărcare, care îi returnează fișierul persoanei care tocmai l-a furnizat (cine l-a furnizat este înregistrat pe fișierul însuși). O citire făcută în afara produsului, de un operator la un prompt al bazei de date sau de copia de siguranță nocturnă, nu este o persoană în fața unui ecran și nu apare în înregistrare.

Criptarea în repaus pentru baza de date se află încă pe lista de condiții. Preferăm ca această secțiune să sune prost acum decât să descoperiți dumneavoastră mai târziu.

Ștergerea

Ștergerea este o comandă a unui operator. Nu există un job în fundal și nici un buton de autoservire. Rulează sub un rol al bazei de date care există doar pentru a șterge. Acel rol poate vedea și distruge datele clienților și nu are nicio putere de a schimba schema. Sunt două autorități diferite și le ținem separate.

Comanda primește identificatorul organizației tastat din nou, manual, șterge întâi obiectele stocate și verifică din nou fiecare cheie pentru a confirma că a dispărut. Abia apoi înregistrează ce a șters. Dacă măcar un obiect supraviețuiește, execuția nu raportează succes. Rularea ei de două ori este sigură. Refuză să pornească pe un bucket de stocare care păstrează versiuni anterioare ale unui obiect, pentru că acolo o cheie pare dispărută în timp ce o copie este încă stocată. Bucketurile noastre urmează să fie create fără versionare, iar comanda verifică acest lucru înainte să pornească.

Rămâne apoi o dovadă de ștergere: numărul de rânduri șterse din fiecare tabelă, cine a cerut ștergerea, cine a rulat-o și când. Nu conține niciun conținut.

Ce supraviețuiește unei ștergeri astăzi

• Fișierele stocate: nimic. Până la 23 septembrie 2026, promptul trimis modelului, care conține textul documentului dumneavoastră, era stocat ca un obiect pe care ștergerea nu îl putea atinge. L-am găsit printr-o verificare și este remediat: înregistrarea fiecărui apel către model indică acum versiunea documentului citit, așa că ștergerea urmează acea legătură, elimină obiectul și îi verifică din nou cheia, ca pe oricare altul. Un al doilea astfel de câmp a fost găsit de verificarea construită ulterior, înainte ca ceva să fi scris în el, și a fost închis la fel.
• Fișierele respinse de scanerul antimalware. Când se șterge un singur proiect, ele sunt păstrate doar pentru organizație și după hash-ul conținutului, deci nu pot fi deosebite pe proiecte. Încheierea angajamentului le șterge.
• Dovada de ștergere și înregistrarea de audit ale ștergerii înseși. Este deliberat. Ștergerea înregistrării unei ștergeri este felul în care o ștergere devine nedemonstrabilă.

Fereastra completă de ștergere

Nu putem încă enunța în zile întreaga fereastră de ștergere. Propoziția cinstită are patru părți, iar într-un pilot ultimele trei sunt planificate și încă nu rulează.

Sisteme active

Eliminate în clipa în care comanda raportează succes: imediat.

Istoricul furnizorului bazei de date

Păstrat până la 7 zile. Este o setare a noastră, iar valoarea implicită a furnizorului este o zi. Până atunci, un rând șters poate fi încă restaurat de noi.

Copiile aflate sub controlul nostru

Șterse în cel mult 30 de zile. Copia de siguranță zilnică a unui pilot poate fi restaurată timp de 20 de zile, iar fiecare copie a ei dispare în aproximativ 28 de zile, adică în cel mult 30 chiar dacă eșuează copiile din două nopți.

Copia nocturnă este cea care șterge copiile vechi. Dacă s-ar opri, nimic nu le-ar șterge până ar rula din nou, iar oprirea ei este ceea ce raportează alerta. Mecanismul este construit și a rulat doar pe simulări locale. Planul propriu de instantanee (snapshot) al stocării pentru copii, pe care se bazează acest număr, nu a rulat încă.

O ramură pe care o restaurare a bazei de date o lasă în urmă este ștearsă de mână după ce restaurarea este acceptată. Dacă restaurăm o copie mai veche, ștergerile înregistrate în cea mai nouă copie sunt listate și rulate din nou. O ștergere făcută după cea mai nouă copie, dacă baza de date activă se pierde chiar atunci, nu se află în nicio copie. Comanda care o rulează din nou o păstrăm în afara serverului și o rulăm de mână.

Încă neprecizat

Cât timp persistă copiile interne ale furnizorului bazei de date după fereastra sa de istoric, acolo unde propriile lui documente se contrazic. Cât timp păstrează furnizorul AI textul paginilor pe care i-l trimitem. Vom pune ambele întrebări în scris când se semnează contractele pilotului și vom publica răspunsurile așa cum le dau furnizorii.

Copii de siguranță și restaurare

Astăzi nimic nu a fost restaurat pe infrastructură reală, iar produsul nu este găzduit. După găzduire, copia de siguranță a demo-ului ar fi un instantaneu (snapshot) al întregului server. Acesta este un singur domeniu de defectare: aplicația, baza de date, documentele și coada, la un loc. Punctul de recuperare ar fi de până la aproximativ o zi. Un instantaneu al unei baze de date aflate în funcțiune este consistent doar ca după o oprire bruscă (crash-consistent). Nu este o copie de siguranță curată.

Construit pentru pilot și exersat doar pe simulări locale, la 11 octombrie 2026: o copie de siguranță zilnică a bazei de date și a documentelor într-un Storage Box dintr-un alt oraș, criptată, restaurabilă timp de 20 de zile și ștearsă în cel mult 30.

Cât timp serverul rulează și ajunge la furnizorul nostru de e-mail, o copie eșuată sau lipsă trimite o alertă unei persoane. Nimic nu verifică încă din afara serverului.

O restaurare scriptată readuce o copie într-o bază de date temporară și într-o stocare temporară. Verifică numărul de rânduri al fiecărei tabele și dimensiunea și suma de control a fiecărui document față de ce s-a copiat. Deschide fiecare document cu cheia și îl compară cu amprenta SHA-256 pe care o înregistrează baza de date. Listează ștergerile de rulat din nou. Pe calculatorul nostru, pe simulări locale, a durat câteva secunde. Pe infrastructură reală nu a rulat.

Înainte să fie acceptat orice document real, pilotul aduce patru lucruri: o bază de date administrată cu restaurare la un moment anterior ales, stocare de obiecte într-un domeniu de defectare separat, o copie de siguranță automată a bazei de date și a documentelor, ținută în afara serverului, și o restaurare exersată. O restaurare exersată este una pe care am efectuat-o și am cronometrat-o efectiv. O restaurare doar configurată nu contează. O instanță de pilot refuză să pornească până când data acelui exercițiu nu este înregistrată.

Când se încheie un pilot

Documentele dumneavoastră și tot ce derivă din ele sunt șterse la cerere sau la încheierea angajamentului, printr-o singură comandă care rulează ștergerea de mai sus pentru fiecare proiect și face și altele în plus. Primiți dovada de ștergere.

Ce rămâne după aceea este spus aici pentru că nu ar trebui să fie nevoie să întrebați. Încheierea unui angajament șterge datele și revocă accesul tuturor. Organizația dumneavoastră rămâne ca înregistrare administrativă: un identificator, un nume, o dată de creare și nimic altceva.

Este păstrată pentru că dovada de ștergere și jurnalul de audit trimit amândouă la ea, iar o înregistrare care dovedește că o ștergere s-a petrecut nu poate supraviețui lucrului la care trimite, dacă acel lucru este eliminat. Alegerea este deci între a păstra un nume și a pierde dovada, iar noi păstrăm dovada. Odată cu ea rămân înregistrările care trimit la ea și nu conțin nimic din conținutul dumneavoastră: calitățile de membru, marcate ca revocate; jurnalul de audit, citirile incluse; deciziile noastre înregistrate despre ce furnizori pot prelucra datele dumneavoastră; și dovezile de ștergere.

O singură comandă acoperă tot angajamentul, cu o singură dovadă care spune toate cele trei lucruri: datele șterse, accesul revocat, înregistrarea administrativă păstrată. Accesul se încheie primul, așa că nimic nu poate fi încărcat cât timp se șterg fișierele. Apoi dispare tot ce este stocat sub organizația dumneavoastră: fișierele fiecărui proiect, fișierele refuzate de scaner și orice a lăsat o încărcare întreruptă, fiecare verificat din nou pentru a confirma că a dispărut. Apoi dispar înregistrările fiecărui proiect, într-o singură tranzacție care verifică, înainte de a se confirma, că nu a rămas nimic din organizația dumneavoastră.

Revocarea accesului unei persoane are efect la următoarea ei cerere. Calitatea de membru este citită din baza de date la fiecare apel, deci o revocare nu așteaptă să expire ceva. Calitatea de membru este revocată și păstrată, așa că cine a avut acces și până când rămâne o întrebare la care se poate răspunde și după aceea.

Aceasta încheie accesul persoanei la organizația dumneavoastră. Nu îi încheie sesiunea: rămâne autentificată, ca persoană care nu mai este membră a vreunei organizații. Încheierea directă a sesiunilor este o acțiune separată a unui operator, și ea există. Sesiunile unei persoane, sau toate sesiunile din mediu, pot fi încheiate deodată, cu un motiv declarat, care este înregistrat și nu poate fi lăsat necompletat. Este răspunsul la întrebarea ce facem dacă se scurge un token. Nu dezactivează contul. Oprirea cuiva de a se autentifica din nou este o altă autoritate, și le ținem separate pentru ca un răspuns la incident să nu blocheze o persoană pe tăcute.