La data de 04-08-2026, tot mai multe aplicații SaaS adaugă funcții AI: căutare semantică în documente, chatbot pentru suport, rezumate automate, asistenți interni sau analiză de contracte. Pentru antreprenori, freelanceri și mici firme din România, tentația este clară: un singur produs, mai mulți clienți, costuri ținute sub control. Dar când AI-ul lucrează cu datele mai multor organizații, arhitectura multi-tenant devine o problemă de securitate, nu doar una de eficiență.
Multi-tenant înseamnă că aceeași platformă deservește mai mulți clienți, numiți „tenants”. Riscul apare când separarea dintre ei este tratată superficial. Într-o aplicație clasică, problema poate fi o interogare SQL fără filtru corect pe tenant_id. Într-o aplicație AI, suprafața se extinde: documente încărcate pentru RAG, embeddings, indexuri vectoriale, cache-uri de prompturi, rezultate generate, loguri de conversație și jurnale de audit. O scurgere nu trebuie să fie spectaculoasă ca să fie gravă; este suficient ca un chatbot să răspundă unui client folosind fragmente din documentele altui client.
Prima decizie este nivelul de izolare. Pentru clienți mici, un model comun cu separare strictă prin identificator de tenant poate fi acceptabil dacă există controale solide, teste și monitorizare. Pentru clienți reglementați sau date sensibile, merită analizată izolarea mai puternică: baze de date separate, containere de stocare separate, indexuri separate sau chiar instanțe dedicate. Microsoft descrie în documentația Azure AI Search modele precum index pentru fiecare tenant sau documente combinate într-un index comun, cu compromisuri între cost, scalare și izolare. Alegerea nu este doar tehnică; este și comercială, pentru că un plan enterprise poate justifica infrastructură dedicată.
Indexurile vectoriale cer atenție specială. Embeddingurile nu sunt text brut, dar pot păstra semnale despre conținut și pot duce la recuperarea unor fragmente greșite dacă sunt amestecate fără control. Furnizori precum Pinecone recomandă folosirea namespace-urilor pentru izolarea datelor fiecărui tenant într-un index serverless, iar operațiunile de citire și scriere trebuie să țintească namespace-ul corect. Dacă folosiți metadate pentru filtrare, filtrul trebuie aplicat server-side, impus de backend, nu lăsat la alegerea interfeței sau a modelului AI.
Regula practică este simplă: modelul AI nu trebuie să decidă niciodată ce date are voie să vadă. Aplicația trebuie să stabilească identitatea utilizatorului, tenantul, rolul și permisiunile înainte de a trimite context către model. Principiul Zero Trust, documentat de NIST, rămâne relevant: accesul se acordă explicit, pe baza identității și politicilor, nu pentru că cererea vine „din interiorul aplicației”. Pentru un SaaS românesc, asta înseamnă autentificare solidă, roluri clare, verificări pe fiecare request și teste automate care încearcă să acceseze datele altui tenant.
Jurnalele sunt adesea uitate. În proiectele AI, logurile pot conține prompturi, răspunsuri, nume de fișiere, ID-uri de documente sau fragmente din datele clienților. OWASP recomandă ca logarea să sprijine auditul și detectarea incidentelor, dar și să evite datele care nu trebuie colectate. Practic, fiecare eveniment important ar trebui să includă tenant_id, user_id, acțiunea, resursa și rezultatul, însă fără a salva inutil conținut sensibil. Accesul la loguri trebuie separat pe roluri, iar exporturile pentru suport nu trebuie să amestece clienți diferiți.
Pentru firmele care vând SaaS cu AI, o listă minimă de control ar trebui să includă: inventarul datelor procesate de AI, schema de izolare pentru fiecare tenant, politica pentru embeddings și indexuri vectoriale, retenția logurilor, criptarea în tranzit și în repaus, testele de autorizare, procedura de offboarding și ștergerea completă a datelor clientului. Dacă un client pleacă, nu este suficient să îi dezactivați contul; trebuie șterse sau arhivate conform contractului documentele, vectorii, cache-urile și jurnalele asociate.
Există și o dimensiune legală. Regulamentul european AI Act introduce obligații mai stricte pentru anumite sisteme AI, inclusiv cerințe privind managementul riscului, documentarea și, pentru sistemele cu risc ridicat, înregistrarea automată a evenimentelor prin loguri. Nu orice chatbot SaaS va fi sistem cu risc ridicat, dar arhitectura trebuie gândită astfel încât să poată demonstra controale, nu doar să promită că „datele sunt separate”.
Concluzia pentru antreprenori este pragmatică: AI multi-tenant poate reduce costurile și accelera produsul, dar doar dacă izolarea este proiectată de la început. Datele, vectorii și jurnalele trebuie tratate ca trei suprafețe diferite de risc. Dacă sunt puse în aceeași găleată, problema va apărea mai târziu, când produsul are deja clienți, contracte și obligații. Cel mai ieftin moment pentru separare corectă este înainte de lansare.
Surse
- Microsoft Learn — „Multitenancy and Content Isolation – Azure AI Search”
- Microsoft Learn — „Data, Privacy, and Built-in Protections – Azure AI Search”
- Pinecone Docs — „Implement multitenancy”
- OWASP Cheat Sheet Series — „Logging Cheat Sheet”
- NIST — „Zero Trust Architecture”
- EUR-Lex — Regulation (EU) 2024/1689, Artificial Intelligence Act
