Standard
Polityki dostępu do wiedzy: ABAC/RBAC dla RAG i GraphRAG
To, co jest dowodem w odpowiedzi, jest jednocześnie udostępnieniem informacji. Dlatego polityka dostępu musi być częścią retrieval i cytowań — bez wyjątków, poza wyjątkami formalnie rejestrowanymi.
Dlaczego polityki dostępu są częścią RAG
W systemach opartych o retrieval „wyciek” nie musi być bezpośredni. Wystarczy, że model dostanie fragment, którego użytkownik nie powinien zobaczyć, a potem zsyntetyzuje odpowiedź. Dlatego polityki dostępu muszą działać przed rerankiem i przed generacją.
RBAC vs ABAC (praktyczna różnica)
- RBAC: role użytkownika decydują o dostępie do całych kolekcji (prościej, szybciej).
- ABAC: reguły oparte o atrybuty (dział, kraj, typ klienta, poziom umowy) – dokładniejsze.
- Hybryda: RBAC na kolekcji, ABAC na dokumencie/chunku.
GraphRAG: polityki na węzłach i krawędziach
W GraphRAG wrażliwe mogą być nie tylko dokumenty, ale i relacje. Praktyka: oznaczaj ACL na węzłach (encje) oraz na krawędziach (relacje), a następnie filtruj subgraf przed „walkiem” lub zapytaniem.
Uwaga operacyjna: cache jest częstym źródłem wycieków. Cache musi być „policy-aware”
(klucz zawiera zestaw uprawnień albo ich skrót) oraz mieć jawne TTL.
Checklista wdrożeniowa
- Filtr ACL przed retrieval i przed rerankiem (nie po).
- Doc@ver i metadane w odpowiedzi (dowodowość i audyt).
- Testy: scenariusze „deny” w golden set (użytkownik bez uprawnień).
- Rejestr wyjątków: każde obejście polityki musi mieć ownera i termin wygaśnięcia.
Minimum bezpieczeństwa
- Deny‑by‑default na każdym PEP.
- Jedna polityka dla retrieval i cytowań.
- Audit trail: trace_id + powody odrzuceń.
- Wyjątki tylko czasowe i jawne.
