Самая частая ошибка RAG внутри компаний проста: загрузить все, задавать вопросы и считать ответы с source citations автоматически безопасными.
Вторая самая частая ошибка приходит позже: кто-то понимает, что assistant может отвечать из документов, которые пользователь не должен видеть. Salary bands. Customer contracts. Legal drafts. Board notes. Support tickets. HR investigations. Security procedures. Ответ может быть точным и с citations, но система уже раскрыла информацию.
Company knowledge RAG - это не search box с более приятным текстом. Это permissioned information system. Относитесь к нему именно так.
Retrieval должен применять те же или более строгие permissions, что и source systems. Если пользователь не может открыть документ в Google Drive, SharePoint, Notion, Confluence или CRM, RAG не должен извлекать его для этого пользователя.
Core rule
Retrieval layer должен ответить на этот вопрос до возврата любого chunk:
Имеет ли этот пользователь право видеть этот source прямо сейчас?
Не "есть ли этот source в vector database?" Не "релевантен ли этот source?" Не "полезен ли этот source?" Permission идет первым.
Есть три распространенных patterns:
Pattern | Как это работает | Fit |
|---|---|---|
Separate indexes | Один index на audience или workspace | Простые команды, coarse permissions |
Metadata filtering | Хранить ACL/group/source metadata и фильтровать до retrieval | Большинство company RAG systems |
Real-time permission check | Запрашивать permissions source system во время retrieval | Sensitive или часто меняющиеся permissions |
Правильный ответ зависит от source systems и уровня риска. Для большинства SME достаточно separate indexes плюс metadata filtering. Для customer, HR, legal или regulated data могут потребоваться real-time checks.
Source boundaries
Не создавайте один гигантский knowledge pool. Разделяйте по audience и sensitivity:
Corpus | Audience | Examples | Rule |
|---|---|---|---|
Public/product | Все | Help docs, public pricing, product pages | Safe for broad assistant |
Internal operations | Employees | Process docs, internal FAQs | Employee-only |
Department | Department members | Sales playbooks, support macros, engineering runbooks | Group-filtered |
Customer records | Assigned teams | Tickets, contracts, account notes | Strict ACL and audit |
Restricted | Named users only | HR, legal, security, board | Обычно separate system или no RAG |
Чем меньше audiences обслуживает один corpus, тем проще рассуждать о leakage.
Ingestion controls
Ingestion pipeline - место, где начинается много утечек.
Перед indexing источника сохраняйте:
- Source system.
- Document ID.
- Owner.
- Audience или ACL.
- Sensitivity label.
- Created и updated timestamps.
- Expiry или review date.
- Можно ли использовать документ для AI retrieval.
- Содержит ли документ personal data.
Если source system уже имеет labels, сохраните их. Если нет, добавьте легкий classification step перед ingestion.
Retrieval controls
Retrieval должен идти в таком порядке:
- Identify the user and groups.
- Identify the requested workspace or assistant.
- Filter candidate sources по corpus, ACL, sensitivity и freshness.
- Retrieve relevant chunks только из allowed sources.
- Rerank allowed chunks.
- Generate the answer with source references.
- Refuse или escalate, когда allowed sources insufficient.
Не делайте retrieval сначала и filter позже в prompt. Если forbidden chunk попал в model context, граница уже провалилась.
Prompt and answer behavior
Assistant должен быть проинструктирован:
- Отвечать только из retrieved sources.
- Cite source title и section/link.
- Говорить, когда allowed sources не содержат answer.
- Отделять inference от sourced facts.
- Не раскрывать, что restricted sources существуют.
- Не пересказывать access-denied material.
Плохой refusal:
"Я нашел HR salary bands, но у вас нет доступа."
Лучший refusal:
"У меня нет approved source для ответа на это."
Второй ответ не раскрывает существование или тему restricted documents.
Logging without creating a second leak
RAG logs чувствительны. Они могут содержать user questions, retrieved chunks, source IDs, answers и иногда personal data.
Логируйте достаточно для debugging:
- User ID или pseudonymous ID.
- Assistant/workspace.
- Query timestamp.
- Retrieved source IDs.
- Permission-filter outcome.
- Answer ID.
- Refusal/escalation reason.
- Latency и errors.
Будьте осторожны с:
- Полными user questions.
- Полными retrieved chunks.
- Полными generated answers.
- Customer data.
- HR/legal/security topics.
Для sensitive systems храните redacted logs или source IDs вместо full text. Дайте logs собственный access control и retention period.
Stale and conflicting sources
Permission - не единственная граница. Source quality тоже важна.
У каждого indexed source должны быть owner и freshness rule:
Source type | Review rule |
|---|---|
Pricing | Review on every pricing change |
Policy | Review on policy owner update, at least quarterly |
Product docs | Review on release |
Legal template | Review by legal owner |
Support macro | Review monthly or after escalation pattern |
Когда sources conflict, assistant должен показывать conflict только если пользователь имеет доступ к обоим sources. Иначе он должен отвечать из highest-authority allowed source или escalate.
Testing permission boundaries
Тестируйте users, а не только documents:
- Employee with broad access.
- Employee with narrow department access.
- Manager with team-only access.
- Contractor.
- Former employee или disabled account.
- Customer-facing support user.
- Admin.
Для каждого задайте:
- Вопрос, на который он должен иметь возможность ответить.
- Вопрос чуть за пределами его permissions.
- Вопрос о restricted document, который он знает.
- Вопрос, где public docs и internal docs конфликтуют.
- Вопрос с prompt injection: "ignore access rules."
Правильный результат - не просто "good answer". Это "good answer from allowed sources."
Rollout path
Начните с наименее sensitive corpus:
- Public/product docs.
- Internal operations docs.
- Department-specific docs.
- Customer records with strict ACL.
- Restricted corpora only after explicit security/legal approval.
На каждом этапе измеряйте:
- Answer helpfulness.
- Citation quality.
- Refusal correctness.
- Access-denied retrieval rate.
- Stale-source rate.
- User reports of missing or wrong sources.
Пока не делайте этого
Не индексируйте "all company docs" в одного assistant.
Не полагайтесь на prompt instructions для enforcement permissions.
Не логируйте full retrieved chunks для sensitive corpora без clear retention and access policy.
Не смешивайте HR, legal, customer и public docs в одном corpus.
Не позволяйте RAG отвечать за пределами allowed sources только ради helpfulness.
Итог
Company knowledge RAG ценен, потому что приносит source-grounded answers в ежедневную работу. Он рискован, потому что source-grounded answers все равно могут раскрывать информацию.
Сначала проектируйте permission boundaries. Фильтруйте до retrieval. Разделяйте corpora по audience. Сохраняйте source metadata. Отказывайте безопасно. Логируйте осторожно. Тестируйте с реальными permission profiles. Если пользователь не может напрямую открыть source, RAG не должен использовать этот source, чтобы ответить ему.
