Для обычного чат-бота ACL может быть простым: кто может писать боту и кто видит историю. Для ИИ-агента правила сложнее, потому что агент может читать базу знаний, искать по документам, создавать задачи, писать в CRM, отправлять сообщения в Slack, Telegram или Teams и вызывать внешние API.
Хороший Chat ACL отвечает на несколько вопросов: какие источники данных доступны этому пользователю, какие команды можно выполнить, какие tool calls разрешены, можно ли писать от имени бота, нужен ли approval и что логировать. Без ACL агент может случайно показать коммерческие данные не той команде или выполнить действие по чужой команде.
Chat ACL особенно важен в RAG-сценариях. Если пользователь не имеет доступа к документу в Google Drive, Confluence, CRM или внутренней базе знаний, агент не должен использовать этот документ в ответе, даже если embeddings технически нашли подходящий фрагмент.
ACL не заменяет guardrails и moderation, но дополняет их. Guardrails проверяют содержание и поведение, а ACL отвечает за право доступа: можно ли этому пользователю видеть, спрашивать, вызывать и менять именно эти данные.
Примеры
- Сотрудник отдела продаж может спрашивать агента о своих сделках, но не видит финансовые документы компании.
- ИИ-агент в Slack отвечает только в разрешенных каналах и не читает приватные каналы без доступа пользователя.
- В чат-виджете клиент может смотреть только свои обращения, а оператор поддержки видит историю обращения и внутренние заметки.
- Агент нашел релевантный документ в базе знаний, но не использует его, потому что у пользователя нет прав на этот раздел.
- Команда "создать задачу в CRM" доступна менеджеру, а команда "изменить владельца сделки" требует approval руководителя.
- В Telegram-боте админ может публиковать посты в канал, а обычный редактор только отправляет черновик на согласование.
Где используется
- ограничение доступа к диалогам и истории чата
- разделение прав пользователей, операторов и администраторов
- контроль источников RAG по правам пользователя
- запрет tool calls для неавторизованных пользователей
- безопасная работа чат-агента в Slack, Teams и Telegram
- разграничение данных CRM, сделок и клиентских обращений
- approval для рискованных команд и внешних сообщений
- логирование доступа к чувствительным данным
- защита от prompt injection через проверку прав
- подключение корпоративной базы знаний к чат-боту
Связанные термины
Частые вопросы
Chat ACL - это то же самое, что роли пользователей?
Роли часто используются внутри ACL, но ACL шире. Он может учитывать пользователя, канал, команду, документ, тип действия, источник данных, workspace и состояние approval.
Зачем ACL нужен ИИ-агенту, если есть системный prompt?
Prompt можно обойти или неправильно интерпретировать. ACL должен проверяться на уровне приложения и API: если права нет, агент технически не должен получить данные или выполнить действие.
Как ACL работает с RAG?
Перед тем как вернуть найденный фрагмент, система проверяет, имеет ли пользователь доступ к исходному документу или разделу. Иначе агент должен пропустить этот источник.
Что будет, если не настроить Chat ACL?
Агент может показать чужие данные, прочитать закрытый канал, выполнить команду от неавторизованного пользователя или смешать контекст разных клиентов.
Где хранить правила Chat ACL?
Обычно в backend, базе данных, корпоративном IAM, CRM, workspace-настройках или связке ролей и permissions. Не стоит хранить критичные права только в prompt.
Как проверить, что ACL работает?
Нужны тестовые пользователи с разными ролями, negative tests, audit log, проверка RAG-источников и сценарии, где пользователь пытается запросить чужие данные или запрещенное действие.
