Доступы и безопасность для корпоративного ИИ-ассистента

Корпоративный ИИ-ассистент безопасен не потому, что работает “внутри компании”, а потому что у него ограничены источники, действия и права. На старте лучше давать read-only доступ к выбранным документам и явно запрещать секреты, production-системы, персональные данные без политики и действия без подтверждения.

Каждое расширение доступа должно отвечать на вопрос: какую задачу это улучшает, кто видит результат, что может пойти не так и где человек подтверждает действие.

Для первого контура подходят источники с понятным владельцем и правами доступа: база знаний, регламенты, инструкции, wiki, тикеты, документы проекта, внутренние FAQ. Не стоит сразу подключать весь файловый архив, почту, CRM, production-логи и документы с персональными данными.

• обычный сотрудник: видит только общие документы и свои рабочие материалы;
• руководитель процесса: видит расширенный набор источников своего подразделения;
• администратор знаний: управляет источниками и актуальностью документов;
• security/IT owner: утверждает доступы, журналы и исключения;
• сервисный аккаунт ассистента: имеет минимальные технические права.

Действия ассистента лучше разделить на уровни. Read-only ответы и ссылки на источники можно проверять раньше. Запись комментариев, создание задач, изменение статусов, отправка писем, запуск процессов и работа с внешними API требуют approval gates и отдельного журнала.

• перед доступом к новому источнику данных;
• перед записью или изменением объекта во внешней системе;
• перед отправкой сообщения от имени пользователя или компании;
• перед использованием персональных данных;
• перед запуском процесса, который влияет на клиента, деньги, договор или production;
• перед расширением роли сервисного аккаунта.

Нужно логировать запрос, пользователя или роль, источники, найденные документы, действие ассистента, approval и результат. Логи нужны не для тотального контроля сотрудников, а для расследования ошибок, улучшения качества и доказательства, что ассистент не вышел за разрешенный контур.

Секреты, токены, приватные ключи, пароли, vault и production-credentials не должны попадать в контекст ассистента. Персональные данные требуют отдельной политики: какие данные нужны, где основание обработки, кто видит ответ, как хранится журнал и как удаляются данные.

• юридически значимые решения;
• платежи и финансовые операции;
• массовые изменения данных;
• увольнения, найм и оценка сотрудников;
• изменение прав доступа;
• deploy, release и production-операции;
• ответы клиентам без проверки в чувствительных сценариях.

Если ассистент работает в developer workflow, применяются похожие правила: MCP-интеграции нужно рассматривать как дизайн доступов, а не как список удобных подключений. Для coding agents используйте отдельные материалы про MCP-интеграции и пилот AI coding agents.

Общую рамку внедрения описывает материал про ИИ в бизнесе. Если нужно выбрать первый сценарий, начните с карты пилота ИИ. Для базы знаний используйте RAG-чек-лист. Для проектной реализации смотрите разработку и внедрение RAG-систем.