Artificial Intelligence & IT
RAG (Chat sa internim dokumentima): kako firme prave “interni AI” bez curenja podataka

Većini firmi ne treba AI koji piše pesme. Treba im AI koji može da odgovori na vrlo konkretno pitanje u 09:12 u ponedeljak: „Koja je naša standardna procedura za onboarding klijenta?“, „Gde je poslednja VPN politika?“, ili „Šta SLA kaže o vremenu reakcije na incident?“
To znanje već postoji—razbacano po SharePoint folderima, PDF-ovima, internim wiki stranicama, email thread-ovima, tiketing sistemu i starim Word dokumentima. Problem nije nedostatak informacija. Problem je pronalaženje prave informacije brzo, dosledno i bezbedno.
Tu RAG (Retrieval-Augmented Generation) postaje praktičan šablon. Umesto da „trenirate“ model na privatnim podacima, RAG u trenutku upita pronalazi relevantne delove interne dokumentacije i koristi ih kao kontekst. Kada je urađeno kako treba, dobijate visoku tačnost bez toga da privatni dokumenti postanu trajna „memorija“ modela.
Šta je RAG (i šta nije)
RAG je način dizajna sistema. Kada korisnik postavi pitanje, sistem pretražuje internu bazu znanja, pronalazi najrelevantnije pasuse i šalje ih modelu da iz njih formira odgovor.
- To nije fine-tuning modela na internim podacima
- To nije magična pretraga—kvalitet zavisi od dokumenata i strukture
- To nije bezbedno samo po sebi—bezbednost mora biti dizajnirana
RAG može da radi sa cloud modelima, privatnim (on-prem) modelima, ili hibridno. Rizik nije u nazivu tehnologije, nego u detaljima: kontrola pristupa, granice podataka i audit.
Najčešći RAG use-case-ovi u firmama
RAG najbolje radi kada je znanje relativno stabilno, a pitanja se ponavljaju. Najčešći use-case-ovi sa brzim povratom ulaganja su:
- Interna baza znanja: politike, SOP, onboarding, HR procedure
- Ugovori i klauzule: brzo pronalaženje obaveza i izuzetaka
- Tiketi i support: sažeci, predlozi koraka, linkovi ka runbook-ovima
- IT dokumentacija: arhitektura, konfiguracije, troubleshooting vodiči
- Compliance i audit: pronalaženje evidencija, procedura i dokaza
Pravi bezbednosni problem: „Ko sme šta da vidi?“
Najveći rizik internog AI-a nije da pogreši. Najveći rizik je da tačno odgovori—pogrešnoj osobi.
Ako neko iz Sales-a može da pita: „Pokaži mi sve ugovore sa posebnim popustima“, bezbednosni problem nije AI—problem je autorizacija.
Produkcioni RAG mora da primeni dozvole u trenutku pretrage (retrieval). To znači: sistem sme da vrati samo dokumente koje korisnik realno sme da otvori. Ako retrieval sloj ne zna za dozvole, pre ili kasnije doći će do curenja.
Arhitektura: siguran RAG u 7 blokova
Siguran RAG nije jedan alat. To je pipeline. U praksi izgleda ovako:
- Ingestion: povezivanje izvora (Drive/SharePoint, wiki, tiketing, file server)
- Normalizacija: pretvaranje u tekst + metapodatke (owner, tim, tagovi)
- Chunking: deljenje dokumenta na smislene segmente (ne predugačke)
- Indexing: embeddings + metapodaci u vektorsku bazu ili search indeks
- Retrieval: povlačenje segmenata UZ filtriranje po dozvolama
- Generation: model odgovara striktno na osnovu konteksta
- Observability: audit logovi, monitoring i evaluacija kvaliteta
Model dozvola: uslov bez kojeg se ne ide u produkciju
Najjednostavniji robustan pristup je da svaki chunk nosi ACL metapodatke i da se oni primenjuju tokom pretrage. Sistem mora da zna identitet korisnika (SSO/OAuth) i da mapira dozvole.
- Identitet: SSO (Microsoft/Google/Okta) ili interni auth
- Role: IT, HR, Finansije, Menadžment, Eksterni partner
- ACL: ko ima read pristup kom folderu/izvoru
- Chunk-level primena: chunk nasledjuje ACL dokumenta
Ako korisnik ne može normalno da otvori dokument, RAG sistem ne sme da ga povuče. AI nije nova vrata do podataka—treba da bude brži interfejs za ono što već smete da vidite.
Audit logovi: najbolja odbrana kad nešto krene loše
Interni AI postaje poslovni sistem. To znači da vam treba trag. Minimum koji treba logovati:
- Ko je pitao (user ID, rola, tenant, IP)
- Koji dokumenti/chunk-ovi su povučeni (ID, naziv, timestamp)
- Koji model i koja prompt šema je korišćena
- Da li odgovor sadrži citate/linkove ka izvorima
- Blokade i neuspešne pretrage zbog nedostatka dozvole
Ovo nije samo za incident response. Ovo je i način da dokazujete usklađenost i da vremenom podižete kvalitet odgovora.
Data minimization: ne šaljite modelu više nego što mora
Bezbednost je i smanjenje izloženosti. I uz ispravne dozvole, treba minimizovati količinu konteksta:
- Vraćajte samo top relevantne chunk-ove (ne ceo dokument)
- Redakcija tajni (API key, lozinke) tokom ingestion-a
- Isključite ultra-osetljive izvore (npr. payroll) dok stvarno ne zatreba
- Kratak životni vek promptova i oprezno čuvanje razgovora
Tabela: „dobar“ vs „rizičan“ RAG dizajn
| Oblast | Bezbedniji pristup | Rizičan pristup |
|---|---|---|
| Dozvole | Primena u retrieval fazi | Samo UI ograničenja |
| Kontekst | Samo relevantni chunk-ovi | Slanje celih dokumenata modelu |
| Tajne | Redakcija na ingestion-u | Nada da niko neće pitati |
| Logovi | Trag upita + retrieval-a | Nema traceability |
| Ažuriranje | Re-index + tracking promena | Jednom indeksirano zauvek |
| Odgovori | Citati + „ne znam“ bez konteksta | Ulepšavanje i halucinacije |
Kako krenuti za 2–4 nedelje bez prekomplikovanja
Ne treba vam savršena platforma prvog dana. Bezbedan MVP je moguć ako pametno suzite scope:
- Krenite sa 1–2 izvora: wiki + tiketing sa sažecima
- Ograničite korisnike: prvo IT i menadžment
- Obavezni citati: svaki odgovor mora da pokaže izvor
- „Ne znam“ ponašanje: bez konteksta sistem odbija odgovor
- Merite uspeh: ušteda vremena, brže rešavanje tiketa, manje ponavljanja
Zaključak: interni AI je bezbednosni projekat, ne chatbot projekat
RAG može dramatično da ubrza pristup znanju, ali samo ako su bezbednost i governance ugrađeni od starta. Cilj nije da zvuči pametno. Cilj je da interne informacije postanu pretražive, proverljive i dostupne samo onima koji imaju pravo.
Ako RAG tretirate kao infrastrukturu—identitet, dozvole, logovi i monitoring—možete uvesti interni AI bez curenja podataka.

