LLM local cu Ollama în 2026: privacy, self-hosting și GDPR

Când apelezi un model de limbaj, unde ajung datele tale și cine le mai poate vedea? Pentru un side-project, întrebarea e teoretică. Pentru o bancă, un spital sau o instituție publică, e o problemă de conformitate la care trebuie să răspunzi. Un LLM local cu Ollama răstoarnă logica: modelul rulează pe infrastructura ta, iar datele nu mai părăsesc perimetrul pe care îl controlezi. Acest ghid explică, pe surse reale, când are sens self-hosting-ul, cum îl pui în practică și ce obligații GDPR rămân chiar și atunci.

O clarificare din start: rularea locală nu e „bună” iar cloudul „rău”. Sunt două profiluri diferite de risc și de cost. Cloudul rămâne excelent pentru sarcini publice, spike-uri de trafic și raționament de vârf. Localul câștigă acolo unde datele sunt sensibile, volumul e constant sau ai nevoie să funcționezi offline. Articolul îți dă criteriile ca să alegi în cunoștință de cauză.

Inferență locală vs API cloud: diferența fundamentală

Când folosești un API cloud (un endpoint de tip OpenAI, Anthropic sau Google), fluxul e simplu și, tocmai de aceea, ușor de subestimat ca risc: promptul, documentele atașate, istoricul conversației — toate pleacă de pe infrastructura ta, traversează internetul, ajung pe serverele furnizorului, sunt procesate acolo, iar răspunsul se întoarce. Pe acest traseu, datele tale au părăsit perimetrul pe care îl controlezi.

Inferența locală inversează logica: modelul (greutățile lui — milioanele sau miliardele de parametri numerici) e descărcat o singură dată pe infrastructura ta, iar procesarea promptului se face acolo unde sunt și datele. Cu Ollama, asta înseamnă un proces care încarcă modelul în memorie și expune un endpoint local. Datele rămân pe mașina ta, în rețeaua ta.

De ce contează: privacy by design și GDPR Art. 25

Conceptul de privacy by design and by default nu e o metaforă de marketing. E o obligație juridică, codificată în GDPR la Articolul 25 — „Protecția datelor începând cu momentul conceperii și în mod implicit”. Articolul cere operatorului să implementeze măsuri tehnice și organizatorice adecvate încă din faza de proiectare, nu ca un strat adăugat ulterior. Două principii sunt direct 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ă e, prin construcție, o aplicare directă a acestui principiu: dacă datele nu părăsesc perimetrul, suprafața de risc privind transmiterea către terți scade structural. Atenție însă — și revenim la asta — privacy by design nu e un comutator pe care îl activezi rulând local. E o disciplină. Rularea locală îți dă fundamentul tehnic; restul ține de măsuri organizatorice.

Sectoarele reglementate au o problemă reală cu apelul cloud

• Bancar. Băncile operează sub secret bancar și sub reguli stricte de externalizare și risc IT. Trimiterea unei analize de credit sau a unei conversații cu un client către un endpoint extern poate intra în coliziune cu aceste cerințe.
• Sănătate. Datele de sănătate sunt o categorie specială de date (GDPR Art. 9), cu regim de protecție întărit. Procesarea locală mută discuția de la „cum securizez transferul” la „nu există transfer”.
• Sector public. Administrația gestionează adesea date care necesită control național. Direcția generală — control intern pentru date sensibile, soluții on-premises — e reală și documentată de ani buni în presa de specialitate.

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

Open-weight ≠ open-source (și de ce contează licența)

Un model pe care îl rulezi cu Ollama e, de regulă, open-weight, nu neapărat open-source. Distincția nu e pedanterie:

• Open-weight înseamnă că greutățile modelului sunt disponibile pentru descărcare și rulare. Le poți încărca local, le poți folosi pentru inferență, uneori le poți ajusta. Asta îți permite self-hosting-ul.
• Open-source, în sens strict, 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 numite colocvial „open-source” sunt, în realitate, open-weight cu licență custom — un detaliu cu consecințe juridice directe asupra utilizării comerciale.

Ollama în practică: instalare, primul model și API-ul OpenAI-compatible

Partea bună e că, tehnic, intrarea e foarte joasă. Instalezi Ollama, descarci un model și îl rulezi:

# descarci un model open-weight (variante permisive, Apache 2.0)
ollama pull qwen3:8b

# verifici că daemonul răspunde și pui o întrebare
ollama list
ollama run qwen3:8b "Spune-mi în două propoziții ce este self-hosting."

Detaliul care face adopția nedureroasă: Ollama expune un endpoint REST OpenAI-compatible. Dacă ai deja cod scris pe SDK-ul OpenAI, nu-l rescrii — îl repointezi:

from openai import OpenAI

# singurele modificări față de un setup OpenAI normal:
client = OpenAI(
    base_url="http://localhost:11434/v1",  # Ollama local
    api_key="ollama",                       # cerut de SDK, dar ignorat local
)

resp = client.chat.completions.create(
    model="qwen3:8b",
    messages=[{"role": "user", "content": "Explică RAG într-o propoziție."}],
)
print(resp.choices[0].message.content)

Aceeași chat.completions.create, aceeași formă de răspuns — dar rulează pe localhost și nu face niciun apel extern. Ollama acoperă endpoint-urile uzuale (/v1/chat/completions, /v1/embeddings, /v1/models), exact cele de care ai nevoie pentru o aplicație reală. Migrarea unei aplicații existente devine: schimbi base_url, schimbi model, gata.

Construirea curată a aplicațiilor pe aceste SDK-uri — și abstractizarea peste mai mulți furnizori — e o disciplină în sine, acoperită în cursul de construire de aplicații AI cu Python și SDK-uri. Iar pentru /v1/embeddings și RAG complet local (vector store pe infrastructura ta, fără DB extern), fundamentele sunt în cursul de RAG — Retrieval-Augmented Generation.

Cum alegi modelul: capabilitate ȘI licență

În 2026, ecosistemul open-weight e matur și divers. Nu există „cel mai bun model” în absolut — performanța relativă depinde de sarcină, de hardware și de varianta cuantizată. Dar cele două pârghii reale sunt capabilitatea și licența, iar a doua e cea pe care echipele o uită cel mai des.

• Qwen3 (Alibaba) — variante distribuite sub Apache 2.0, permisivă, cu uz comercial curat. Cel mai „sigur” default când vrei o suprafață juridică mică.
• DeepSeek — raport calitate/cost notabil la rulare locală; verifică varianta și licența exactă (frecvent permisivă).
• Llama 4 (Meta) — licență custom a Meta (community license), cu condiții: un prag legat de utilizatorii activi lunari (de ordinul a ~700M MAU pentru organizațiile foarte mari), o cerință de atribuire de tip „Built with Llama” și o politică de utilizare acceptabilă.
• Gemma (Google) — familie eficientă, gândită pentru hardware modest, livrată istoric sub termenii proprii Google (custom). Tocmai Gemma e exemplul perfect pentru regula de mai jos: termenii s-au schimbat între versiuni.

Regula de aur: verifică întotdeauna licența CURENTĂ din model card-ul oficial înainte de orice utilizare comercială. Licențele se schimbă în timp — ce era custom poate deveni permisiv (sau invers), iar un blog (inclusiv acesta) nu e sursa ta juridică. Model card-ul oficial este.

Dacă vrei o metodă structurată de a pune modelele în balanță pentru cazul tău, cursul de comparație a modelelor AI tratează exact acest tip de decizie, cu benchmark-uri prezentate ca intervale cu metodologie, nu ca numere absolute scoase din context.

Cuantizare GGUF și hardware: q4_K_M vs q8_0

Ollama servește modele în format GGUF, cuantizat ca să reducă consumul de memorie cu pierdere minimă de calitate. Nivelul de cuantizare e pârghia ta principală de RAM/VRAM:

• q4_K_M — echilibrul implicit. Aproximativ 4 biți; un model 7-8B intră în câțiva GB și rulează pe majoritatea mașinilor moderne. Începe de aici.
• q8_0 — cvasi-fără pierderi, cam dublul amprentei față de q4. Folosește-l când ai memorie și vrei fidelitate maximă.
• fp16 — jumătate de precizie, complet; cel mai mare consum, rar necesar pentru RAG sau uz local.

Reguli de deget, nu garanții: un model 7-8B la q4_K_M e confortabil pe o mașină cu ~8 GB de RAM/VRAM liberi; treci la 13-14B și vei vrea vizibil mai mult. Tratează aceste cifre ca puncte de plecare și urmărește utilizarea reală — lungimea contextului și concurența contează la fel de mult.

Un avantaj practic deloc minor: pentru că răspunsul în RAG e ancorat în context recuperat, un model bine ales de 7-8B egalează adesea unul mult mai mare la Q&A factual, rulând confortabil pe hardware modest. Bigger nu e automat better la self-hosting.

Self-hosting reduce, dar NU elimină obligațiile GDPR

Aici e capcana în care cad echipele entuziaste: presupun că „rulăm local, deci suntem conformi”. Greșit. Rularea locală reduce o categorie de risc (transferul către terți), dar transferă către tine o serie de responsabilități.

Ce reduci: transferul datelor către un procesator extern, întrebarea „unde au ajuns datele?”, dependența de versiunea altcuiva, factura per-token și lock-in-ul. Dacă nu există transfer, nu mai trebuie să securizezi un transfer inexistent.

Ce rămâne în sarcina ta:

• DPIA (evaluarea impactului asupra protecției datelor) pentru procesările cu risc ridicat — o faci înainte de lansare, nu după un incident.
• Audit trail și jurnalizare — decizi conștient ce loghezi; dacă loghezi prompturi, le tratezi ca date sensibile.
• Minimizarea datelor efectiv procesate — nu indexa tot share-ul doar pentru că poți.
• Controlul accesului la serverul local — „intern” trebuie să însemne cu adevărat intern, în spatele autentificării și al restricțiilor de rețea.
• Hardening și mentenanță — actualizări de securitate, gestionarea versiunilor, configurație.

Capcana „Ollama Cloud”. Atenție la granița perimetrului: dacă rutezi inferența printr-un serviciu cloud (inclusiv variante găzduite ale ecosistemului), datele ies din perimetru — și ai revenit, din punct de vedere al conformității, exact în scenariul cloud pe care voiai să-l eviți. Argumentul „rulăm local” se aplică doar cât timp procesarea chiar rămâne în perimetrul tău.

Cadrul complet — DPIA, audit trail, hardening și harta responsabilităților — e tratat în profunzime, alături de un capstone de deployment privat end-to-end, în cursul LLM-uri Locale cu Ollama. Iar pentru postura de securitate a unui sistem AI intern (amenințări, controale, guvernanță), cursul de AI Security & Ethics completează natural partea de governance.

Când depășești Ollama: vLLM și SGLang la scară

Ollama e excelent pentru dezvoltare, prototipare și sarcini cu concurență moderată. Când treci la servire la scară — mulți utilizatori simultani, throughput ridicat — intră în scenă motoare de inferență dedicate precum vLLM și SGLang. Ele aduc tehnici ca PagedAttention (gestionarea eficientă a memoriei pentru atenție) și continuous batching (gruparea dinamică a cererilor), care cresc semnificativ debitul pe același GPU. Și ele expun, convenabil, un server OpenAI-compatible — deci modelul tău de integrare rămâne același; schimbi doar motorul din spate.

Heuristica sănătoasă: Ollama pentru dezvoltare și volume moderate; vLLM/SGLang când concurența și throughput-ul devin constrângerea reală. Nu sări la infrastructură complexă înainte să ai nevoie de ea.

Măsoară înainte să treci în producție

Un ultim principiu, valabil indiferent de model sau motor: măsoară. Construiește un set mic de evaluare cu perechi întrebare/răspuns-așteptat și notează calitatea retrieval-ului și a răspunsului înainte și după orice schimbare (alt model, altă cuantizare, alt chunk size). „A mers bine în demo” e felul în care ajung regresiile în producție. O abordare riguroasă a evaluării e subiectul cursului de evals LLM pentru producție.

Cum te ajută cursul LLM-uri Locale cu Ollama

Tot ce ai citit aici e harta. Cursul LLM-uri Locale cu Ollama: Privacy, Self-Hosting și Inferență Offline este traseul complet de practician, ancorat exclusiv în surse oficiale (docs.ollama.com, model cards Hugging Face, llama.cpp/GGUF, documentația vLLM și SGLang):

• De ce LLM local: privacy by design, data residency, EU AI Act și GPAI când hostezi local.
• Ollama în profunzime: instalare, API REST OpenAI-compatible, operare locală (logs, keep-alive, concurență, variabile OLLAMA_*).
• Alegerea modelului: taxonomia open-weight (dense vs MoE), profiluri comparate prin model cards, matrice de decizie.
• Cuantizare și hardware: GGUF, q4_K_M vs q8_0, dimensionare realistă VRAM/RAM.
• Modelfile și personalizare: modele custom cu FROM, PARAMETER, SYSTEM, TEMPLATE; import GGUF/safetensors.
• De la cloud la local: înlocuirea apelurilor API, embeddings, RAG local offline.
• Scaling on-premise: vLLM, SGLang, PagedAttention, continuous batching.
• Licențiere și guvernanță: citirea corectă a model cards, Apache 2.0 vs licențe custom, DPIA, audit trail, minimizare.
• Capstone: deployment privat end-to-end cu API intern și checklist GDPR.

Lecțiile sunt interactive și ai un profesor AI integrat în fiecare temă, deci înveți aplicat, pe propriile tale scenarii — nu doar teoretic.

Concluzie

Un LLM local cu Ollama nu mai este o curiozitate de pasionat: e o decizie de arhitectură cu efect direct asupra conformității, costului și controlului. Pentru date sensibile, sarcini constante sau medii offline, „datele nu părăsesc niciodată infrastructura noastră” e cea mai curată poveste de conformitate pe care o poți spune.

Dar nu e magie. Rularea locală îți dă fundamentul; restul e disciplină — alegi modelul cu licența potrivită, dimensionezi corect cuantizarea și hardware-ul, păstrezi obligațiile GDPR care rămân în sarcina ta și măsori înainte să treci în producție. Începe mic: descarcă un model, repointează un singur base_url și pune-i o întrebare pe care doar datele tale o pot răspunde. Primul răspuns corect, complet offline, e un sentiment bun — și începutul unei arhitecturi pe care chiar o controlezi.

Surse

1. Ollama — OpenAI compatibility (documentație oficială)
2. Ollama — documentație și API
3. GDPR — Articolul 25, „Data protection by design and by default” (EUR-Lex)
4. Qwen — model cards și licențiere (Hugging Face)
5. Meta — Llama: licențe și politică de utilizare
6. vLLM — documentație oficială (PagedAttention, OpenAI-compatible server)