Безопасность ИИ в СЭД: что проверять при выборе системы
Когда компании оценивают СЭД с ИИ-функциональностью, вопросы безопасности обычно откладывают напоследок. Сначала смотрят на автоматизацию, поиск, генерацию документов. С появлением ИИ в СЭД появились новые риски, которых раньше не было. Заказчики все чаще спрашивают, кто контролирует действия ИИ-агентов, куда передаются данные и можно ли через чат-бот получить доступ к закрытым документам.
Разобраться с этими вопросами лучше еще на этапе выбора системы. Ранее мы разбирали векторный поиск и критерии оценки ИИ-функциональности, которые можно проверить прямо на демонстрации.
Что беспокоит заказчиков в первую очередь
ИИ-инструменты работают с корпоративными документами, нередко с персональными данными или конфиденциальной информацией. В обсуждениях ИИ-функциональности чаще всего повторяются три темы:
- Куда передаются данные. ИИ должен обрабатывать документы внутри инфраструктуры организации, без передачи содержимого во внешние сервисы. Особенно это важно для СЭД в государственных учреждениях.
- Доступ к закрытым данным через ИИ-ассистент. Когда сотрудник задает вопрос чат-боту, тот должен формировать ответ только на основе документов, к которым у этого сотрудника есть права.
- Контроль над действиями ИИ-агентов. Автоматизация, работающая в фоне, принимает решения и выполняет действия без участия пользователя. Организации нужно понимать, что именно делает агент и на каком основании, и иметь возможность проверить это.
Четыре критерия безопасности ИИ, которые нужно проверить на демо
1. Логирование действий ИИ-автоматизации
ИИ-агент в фоновом режиме анализирует документы, извлекает данные, запускает процессы, изменяет атрибуты. На практике именно журнал событий обычно становится первым источником информации, когда нужно разобраться в причинах ошибки или спорного решения ИИ.
Проверить это можно за несколько минут: выполните тестовый запрос и откройте журнал. Там должны быть время выполнения, входные данные, результат и список выполненных действий. Если лог показывает только факт запуска без детализации, то это неполное логирование. Детальное логирование полезно не только для безопасности, но и для аудита процессов.
2. Логирование запросов к LLM
Здесь речь идет уже не о действиях агента, а о взаимодействии системы с языковой моделью. Хорошей практикой считается фиксация обращений к LLM: был ли запрос к языковой модели, когда и в рамках какого процесса.
Проверить можно так: выполните несколько запросов к модели и убедитесь, что факт взаимодействия попал в журнал. Отдельно уточните: логируется ли содержимое промптов или только метаданные.
3. Управление доступами к ИИ-автоматизации
Система электронного документооборота с ИИ должна разграничивать права доступа: кто из сотрудников может запускать какие сценарии, к каким данным имеет доступ автоматизация, какие операции ей разрешены.
Практический пример: можно ли запретить ИИ-агенту удалять документы или изменять критичные атрибуты карточки? Можно ли создать отдельную роль для автоматизации с ограниченным набором прав, как для обычного пользователя?
Если управление правами для ИИ-сценариев не предусмотрено, автоматизация работает с полномочиями того, кто ее запустил.
Чтобы это проверить, запросите демонстрацию настройки прав для ИИ-автоматизации. Уточните, можно ли ограничить доступ к конфиденциальным данным, определить список разрешенных операций, создать отдельную роль для агента.
4. Шифрование данных при запросах к LLM
Если система взаимодействует с языковыми моделями через внешний API или облако, содержимое документов передается за пределы инфраструктуры. Вопрос в том, как именно и что происходит с промежуточными результатами.
Обычно заказчики начинают проверку со следующих вопросов: TLS/SSL при передаче запросов, безопасное хранение эмбеддингов и кэша, соответствие требованиям ФЗ-152 при обработке персональных данных.
На демонстрации системы уточните, шифруются ли запросы к LLM при передаче. Как хранятся эмбеддинги и кэш. Есть ли документация по соответствию регуляторным требованиям. Если в системе есть интеллектуальный поиск, отдельно стоит оценить как устроены векторный поиск и RAG в СЭД.
Куда уходят данные из документов
За рамками четырех критериев есть более широкий вопрос, который стоит задавать любому вендору: ИИ обрабатывает документы внутри контура или данные уходят во внешние сервисы?
Если ИИ работает через внешние облачные модели, содержимое корпоративных документов фактически покидает организацию. Несколько конкретных вещей, на которые стоит обратить внимание:
- Поддержка локальных моделей. В некоторых компаниях внутренние политики безопасности или требования регуляторов запрещают передачу данных за пределы корпоративного контура. Для них важна поддержка локально развернутых LLM, например, через Ollama или llama.cpp, которые работают на собственном оборудовании без подключения к интернету.
- Выбор модели на стороне заказчика. Во многих случаях заказчики предпочитают самостоятельно выбирать модель, исходя из требований своей службы безопасности. Это могут быть российские облачные решения (YandexGPT, GigaChat), локальные модели или другие варианты.
- Где хранятся промпты. Настройки ИИ-операций должны храниться внутри системы заказчика, а не на серверах разработчика. Именно такой подход стоит проверять на демонстрации, например, в Модуле искусственного интеллекта в СЭД ТЕЗИС.
- Разграничение прав в чат-боте и RAG. Когда сотрудник задает вопрос ИИ-ассистенту, тот должен работать только с теми документами, к которым у этого сотрудника есть доступ. Важно убедиться, что семантический поиск учитывает те же права доступа, что и сама СЭД.
Как проверить безопасность ИИ в системе на демонстрации
| Что проверять | Что должно быть |
|---|---|
| Логирование действий ИИ-агента | Детальный лог: время, входные данные, результат, выполненные действия |
| Логирование запросов к LLM | Фиксируется факт взаимодействия, содержимое не логируется |
| Управление доступами к ИИ-сценариям | Отдельные роли для автоматизации, ограничение операций и доступа к данным |
| Шифрование при передаче данных | TLS/SSL для запросов к LLM, безопасное хранение промежуточных данных |
| Место обработки данных | Поддержка локальных моделей, данные не уходят во внешние сервисы |
| Хранение промптов | Внутри системы заказчика, не на серверах вендора |
| Выбор LLM | Заказчик выбирает модель самостоятельно |
| Разграничение доступа в чат-боте | RAG-поиск работает в рамках прав текущего пользователя |
Безопасность ИИ — это не отдельная функциональность
При выборе ИИ-функциональности важно оценивать не только качество ответов модели или удобство интерфейса. Не меньшее значение имеют логирование, разграничение доступа, работа с данными и возможность контролировать действия автоматизации. Именно эти вопросы чаще всего возникают у заказчиков на этапе пилотирования и согласования требований безопасности.
Команда СЭД ТЕЗИС разработала структурированный чек-лист критериев оценки ИИ-функциональности в корпоративных системах. В нем не только безопасность, но и автоматизация, поиск, интеграция с языковыми моделями, голосовое управление и ряд других параметров. Каждый критерий содержит описание и конкретный сценарий проверки на демонстрации.
FAQ
Какие требования к безопасности ИИ предъявляет ФЗ-152?
Если ИИ-инструменты работают с персональными данными, на них распространяются те же требования ФЗ-152, что и на другие информационные системы. Важно понимать, где обрабатываются данные, кто имеет к ним доступ и как организована их передача.
При использовании внешних языковых моделей стоит отдельно уточнить, покидают ли данные инфраструктуру организации. Для многих компаний это один из ключевых вопросов безопасности. Поэтому заказчики все чаще выбирают локальные модели или решения, которые позволяют контролировать передачу данных и разграничивать доступ к ИИ-функциям.
Можно ли использовать локальные языковые модели вместо облачных?
Да. Главное отличие заключается в том, где происходит обработка данных. Облачные модели работают на инфраструктуре провайдера, а локальные разворачиваются на серверах организации.
Для компаний с повышенными требованиями к безопасности локальный вариант часто оказывается предпочтительным, поскольку данные остаются внутри корпоративного контура. Для этого могут использоваться решения на базе Ollama, llama.cpp и других инструментов для запуска открытых моделей.
Может ли ИИ-агент в СЭД случайно изменить или удалить документ?
Такая ситуация возможна, если для автоматизации не настроены отдельные права доступа. Поэтому при внедрении ИИ важно заранее определить, какие действия агенту разрешены. На практике для ИИ-автоматизации обычно создают отдельные роли с ограниченным набором полномочий. Например, агент может анализировать документы и извлекать данные, но не иметь права изменять или удалять информацию.
Можно ли использовать ИИ в СЭД в государственных организациях?
Да, но требования к безопасности и обработке данных в государственном секторе обычно выше. Во многих случаях предпочтение отдается локально развернутым моделям или российским сервисам, которые соответствуют внутренним требованиям организации. Также стоит учитывать требования к использованию отечественного программного обеспечения. Для части государственных заказчиков наличие решения в реестре Минцифры является обязательным условием при выборе системы.
На каком этапе внедрения СЭД стоит проверять безопасность ИИ?
Лучше делать это еще на этапе выбора системы. Многие вопросы можно проверить во время демонстрации продукта: как ведется логирование, каким образом разграничиваются права доступа, где обрабатываются данные и какие языковые модели поддерживаются. Если такие требования обсудить заранее, будет проще избежать доработок и дополнительных затрат после внедрения системы.
