De Ce Rulezi Modelul Local: Privacy by Design și Costul Real al Apelului Cloud

Când apeși enter pe un prompt, textul tău — documentele atașate, istoricul conversației, poate un extras de cont sau un fragment de fișă medicală — pleacă de pe infrastructura ta, traversează internetul și ajunge pe serverele altcuiva. Întrebarea „unde au ajuns aceste date și cine le mai poate vedea?” pare pur tehnică, dar este, în realitate, strategică și juridică — iar pentru sectoare întregi, precum cel bancar, sănătatea sau administrația publică, poate fi diferența dintre conformitate și incident. Inferența locală, prin Ollama, inversează complet acest flux: procesarea se face acolo unde sunt și datele, iar ele nu mai părăsesc niciodată perimetrul pe care îl controlezi. De ce contează asta — și ce preiei tu pe umeri în schimb — este miza de la care pornește tot ce urmează.

Inferență Locală vs API Cloud: Diferența Fundamentală

Când folosești un API cloud (un endpoint de tip OpenAI, Anthropic sau Google), fluxul este simplu de descris și, tocmai de aceea, ușor de subestimat din punct de vedere al riscului: textul tău — promptul, documentele atașate, istoricul conversației — pleacă de pe infrastructura ta, traversează internetul, ajunge pe serverele furnizorului, este procesat acolo, iar răspunsul se întoarce. Pe acest traseu, datele tale au părăsit perimetrul pe care îl controlezi.

Inferența locală inversează această logică. Modelul (greutățile lui, adică milioanele sau miliardele de parametri numerici) este descărcat o singură dată pe infrastructura ta, iar procesarea promptului se face acolo unde sunt și datele. Cu Ollama, lucrul acesta se reduce la a rula un proces care încarcă modelul în memorie și expune un endpoint local. Datele nu mai traversează un perimetru extern: ele rămân pe mașina ta, în rețeaua ta, sub controlul tău.

Această diferență nu înseamnă că API-ul cloud este „rău” și localul „bun”. Înseamnă că cele două au profiluri de risc și de cost diferite, iar alegerea corectă depinde de natura datelor și de cadrul în care operezi.

Privacy by Design: Ce Spune GDPR Art. 25

Conceptul de privacy by design and by default nu este o metaforă de marketing. Este o obligație juridică, codificată în Regulamentul General privind Protecția Datelor (GDPR), la Articolul 25 — „Protecția datelor începând cu momentul conceperii și în mod implicit” (engl. data protection by design and by default).

Articolul 25 cere operatorului de date să implementeze măsuri tehnice și organizatorice adecvate încă din faza de proiectare a unui sistem, nu ca un strat adăugat ulterior. Două principii operaționalizate de acest articol sunt deosebit de relevante pentru alegerea local vs cloud:

• Minimizarea expunerii: prelucrezi și transmiți doar datele strict necesare. Dacă poți procesa un document confidențial fără să-l trimiți nicăieri, atunci by design nu îl trimiți.
• Protecția implicită (by default): configurația cea mai protectivă trebuie să fie cea predefinită, nu o opțiune pe care utilizatorul trebuie să o activeze conștient.

Inferența locală este, prin construcție, o aplicare directă a acestui principiu: dacă datele nu părăsesc niciodată perimetrul, suprafața de risc privind transmiterea către terți se reduce structural. Atenție însă — și acesta este un punct pe care îl vom relua de mai multe ori în curs — privacy by design nu este un comutator pe care îl activezi rulând local. Este o disciplină. Rularea locală îți oferă fundamentul tehnic, dar trebuie completată cu măsuri organizatorice (controlul accesului, jurnalizare, minimizarea datelor efectiv procesate).

Notă importantă: această lecție este informativă și nu constituie consultanță juridică. Pentru obligațiile concrete aplicabile organizației tale, consultă un specialist și textul oficial al GDPR.

De Ce Sectoarele Reglementate Au o Problemă cu Apelul Cloud

Pentru anumite sectoare, transferul de date personale către un procesator extern nu este doar o chestiune de preferință, ci ridică întrebări de conformitate dificile. Trei verticale ilustrează bine acest lucru:

Sectorul bancar

Băncile operează sub secret bancar și sub reglementări sectoriale stricte privind externalizarea (outsourcing) și gestionarea riscului IT. Trimiterea conținutului unei conversații cu un client, a unui extras de cont sau a unei analize de credit către un endpoint extern poate intra în coliziune cu aceste cerințe. Posibilitatea de a procesa local elimină întrebarea „unde au ajuns aceste date și cine le mai poate accesa?”.

Sănătatea

Datele de sănătate sunt o categorie specială de date în sensul Art. 9 GDPR, supuse unui regim de protecție întărit. Un sistem care ar trimite fragmente de fișe medicale către un procesator extern trebuie să justifice solid temeiul juridic și garanțiile. Procesarea locală mută discuția de la „cum securizez transferul” la „nu există transfer”.

Sectorul public

Administrația publică gestionează adesea date care necesită control național și care nu pot fi expuse, prin politică internă sau prin reglementare, unor infrastructuri din afara controlului direct. În spațiul public românesc există de ani buni o discuție, reflectată în presa de specialitate (de exemplu materiale publicate de AGERPRES și Ziarul Financiar), despre nevoia de capacități de cloud guvernamental și soluții on-premises pentru sarcini sensibile. Nu intrăm aici în cifre sau proiecte specifice; reținem doar că direcția generală — control intern pentru date sensibile — este reală și documentată în presă.

Open-Weight vs Open-Source: O Distincție Care Contează

Un model pe care îl rulezi cu Ollama este, de regulă, un model open-weight, nu neapărat open-source. Diferența nu este pedanterie:

• Open-weight înseamnă că greutățile modelului (parametrii antrenați) sunt disponibile pentru descărcare și rulare. Le poți încărca local, le poți folosi pentru inferență, uneori le poți și ajusta. Asta îți permite self-hosting-ul.
• Open-source, în accepțiunea strictă a licențelor de software liber, ar presupune mult mai mult: codul de antrenare, datele de antrenament, libertatea deplină de redistribuire. Foarte puține modele mari îndeplinesc complet acest standard.

Multe modele descrise colocvial drept „open-source” sunt, în realitate, open-weight cu licență custom. Acest detaliu are consecințe juridice directe asupra utilizării comerciale, pe care le vom aprofunda în lecțiile despre licențiere. Pe scurt, drept regulă de aur a întregului curs:

Verifică întotdeauna licența CURENTĂ din model card-ul oficial înainte de orice utilizare comercială. Licențele se schimbă în timp.

Peisajul Modelelor Open-Weight în 2026

În 2026, ecosistemul modelelor open-weight rulabile local este matur și divers. La nivel general — fără cifre de adopție, pe care le-am considera nesigure — câteva familii domină discuția:

• Llama 4 (Meta): familie de modele cu licență custom a Meta, care include condiții specifice (printre care un plafon legat de utilizatorii activi lunari pentru organizațiile foarte mari, o cerință de atribuire de tipul „Built with Llama” și o politică de utilizare acceptabilă).
• Gemma 3 (Google): familie de modele eficiente, gândite pentru rulare pe hardware modest.
• Qwen3 (Alibaba): familie cu variante distribuite sub licență Apache 2.0, ceea ce o face atrăgătoare pentru utilizare comercială curată.
• DeepSeek: modele cu performanță notabilă, frecvent menționate în discuțiile despre raportul calitate/cost al rulării locale.

Nu vom declara niciun model „cel mai bun”. Performanța relativă depinde de sarcină, de hardware-ul disponibil și de varianta cuantizată folosită. Vom reveni pe larg, în modulele tehnice, la cum alegi modelul potrivit pentru contextul tău, cu benchmark-uri prezentate ca intervale cu metodologie, nu ca numere absolute scoase din context.

Ce Câștigi Rulând Local

Tabloul beneficiilor, dincolo de confidențialitate, include:

1. Control complet asupra perimetrului: datele nu pleacă, versiunea modelului este fixată de tine, comportamentul este reproductibil în timp.
2. Funcționare offline: odată descărcat modelul, inferența nu mai depinde de conectivitate. Pentru medii izolate (air-gapped) sau cu rețea instabilă, acesta este uneori singurul mod viabil.
3. Latență predictibilă: nu depinzi de încărcarea unui serviciu extern partajat sau de fluctuațiile rețelei. Latența ta depinde de hardware-ul tău, pe care îl cunoști.
4. Fără per-token billing extern: nu plătești pe fiecare token procesat către un terț. Costul tău este în hardware și operare, ceea ce schimbă complet calculul la volume mari.

Ce Pierzi sau Preiei pe Umerii Tăi

Onestitatea intelectuală cere să spunem clar și partea cealaltă a balanței. Rularea locală transferă o serie de responsabilități de la furnizor la tine:

• Operarea: actualizări, monitorizare, disponibilitate. Nu mai există un SRE al furnizorului care veghează în locul tău.
• Hardware-ul: ai nevoie de capacitate de calcul (GPU sau, pentru modele mici, CPU/RAM suficient). Acesta este un cost de capital și de întreținere real.
• Mentenanța: gestionarea versiunilor de model, a actualizărilor de securitate, a configurației.
• Performanța de vârf: cele mai mari și mai capabile modele frontier rulate de marii furnizori în cloud pot depăși ce poți rula rezonabil pe hardware local. Pentru multe sarcini de business diferența nu contează; pentru altele, contează.

Costul Real al Apelului Cloud: Mai Mult Decât Factura

Când compari costuri, factura per-token este doar partea vizibilă. „Costul real” al apelului cloud include și componente care nu apar pe factură:

• Costul de conformitate: efortul de a documenta, justifica și audita transferurile de date către un procesator extern.
• Costul de dependență (lock-in): dacă logica ta de business depinde de un model și o versiune care se pot schimbă sau retrage, ai un risc operațional.
• Costul de imprevizibilitate: latența și disponibilitatea unui serviciu partajat nu sunt sub controlul tău.

La volume mici și pentru date ne-sensibile, apelul cloud rămâne adesea cea mai pragmatică alegere. La volume mari, pentru date reglementate sau în medii unde controlul perimetrului este o cerință, balanța înclină spre local. Acest curs te înarmează să faci această alegere informat și să o implementezi corect cu Ollama.

Un Cadru de Decizie: Când Înclină Balanța Spre Local

Pentru a transforma toate cele de mai sus într-un instrument practic, propun un cadru de decizie pe care îl vei recunoaște în multe forme de-a lungul cursului. Întreabă-te, pentru fiecare flux de lucru în care intenționezi să folosești un LLM:

1. Cât de sensibile sunt datele care intră în prompt? Date publice sau anonimizate? Date interne ne-personale? Date personale? Categorii speciale (sănătate, date biometrice)? Cu cât urci pe această scară, cu atât crește atracția spre local.
2. Care este volumul așteptat? Câteva apeluri pe zi sau zeci de mii? La volume mari, per-token billing-ul extern devine o linie de cost dominantă, iar amortizarea hardware-ului local devine atractivă.
3. Ai cerințe de control al perimetrului? Reglementare sectorială, politică internă, cerință contractuală cu un client care impune ca datele să nu părăsească infrastructura ta?
4. Ai capacitatea operațională? Ai sau poți construi competența de a opera, monitoriza și întreține infrastructura de inferență?

Răspunsurile nu produc un verdict mecanic, dar conturează clar profilul. Un caz tipic în care localul câștigă: date personale sau reglementate, volum mediu-mare, cerință de control al perimetrului, capacitate operațională existentă. Un caz tipic în care cloudul rămâne rezonabil: date ne-sensibile, volum mic, fără cerințe de localizare, echipă fără apetit pentru operare de infrastructură. Multe organizații ajung la o arhitectură hibridă: cloud pentru sarcini generale ne-sensibile, local pentru fluxurile care ating date reglementate. Ollama se integrează firesc în această abordare hibridă, oferind un endpoint compatibil cu ecosistemul existent.

Despre Cuantizare: o Privire Anticipată

Una dintre întrebările care apar imediat când oamenii descoperă inferența locală este: „cum încape un model de miliarde de parametri pe hardware-ul meu?”. Răspunsul tehnic, pe care îl vom dezvolta în modulele dedicate, ține de cuantizare — reprezentarea parametrilor cu o precizie numerică mai mică (de exemplu, întregi pe 4 biți în loc de numere în virgulă mobilă pe 16 biți), ceea ce reduce dramatic amprenta de memorie cu o pierdere de calitate adesea acceptabilă. Formatul GGUF, folosit de ecosistemul llama.cpp pe care se sprijină Ollama, este standardul de facto pentru distribuirea modelelor cuantizate rulabile local. Nu intrăm acum în detalii; reține doar că tocmai cuantizarea face self-hosting-ul accesibil pe hardware rezonabil, nu doar pe clustere de centru de date. Vom prezenta întotdeauna efectele cuantizării asupra performanței ca intervale cu metodologie, nu ca numere fixe, pentru că depind de model, de sarcină și de nivelul de cuantizare ales.

Ce Urmează în Acest Curs

Modulul de față stabilește de ce-ul: motivația de privacy, data residency și cadru legal. Lecțiile următoare aprofundează localizarea datelor și suveranitatea (Lecția 1) și intersecția cu EU AI Act (Lecția 2). Ai acum harta deciziei — dar o hartă nu pune încă niciun model în funcțiune pe mașina ta. Detaliile de instalare și configurare a Ollama vin în Modulul 1, iar guvernanța operațională detaliată (DPIA, audit trail, politici) este tratată în Modulul 8. Reține arhitectura cursului: aici clădim fundația conceptuală și juridică, iar de la lecția următoare începem, pas cu pas, să punem mâinile pe tastatură.

Disclaimer final: conținutul are scop educațional și informativ. Nu înlocuiește consultanța juridică de specialitate. Pentru deciziile de conformitate ale organizației tale, consultă textul oficial al reglementărilor și un consilier juridic.