Company knowledge RAG: права доступа, утечки и границы источников

Самая частая ошибка 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 должен идти в таком порядке:

1. Identify the user and groups.
2. Identify the requested workspace or assistant.
3. Filter candidate sources по corpus, ACL, sensitivity и freshness.
4. Retrieve relevant chunks только из allowed sources.
5. Rerank allowed chunks.
6. Generate the answer with source references.
7. 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:

1. Public/product docs.
2. Internal operations docs.
3. Department-specific docs.
4. Customer records with strict ACL.
5. 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, чтобы ответить ему.