Журнал "Information Security/ Информационная безопасность" #2, 2026

ционно-распорядительного документа, проводит финальную экспертную дора- ботку и готовит документы для утвер- ждения руководителем (иным уполно- моченным лицом). 2. Средний уровень (рекомендуется для организаций, имеющих небольшие подразделения ИБ, порядка 3–7 спе- циалистов). Регулярные автоматизиро- ванные проверки изменений законода- тельства: создается внутреннее храни- лище неконфиденциальных документов, используется RAG. По-прежнему может использоваться внешняя LLM, инфор- мация в которую передается через API. Автоматически формируются отчеты о соответствии. В рамках рассмотрения автоматизации на данном уровне следует коснуться вопросов работы RAG и внешних LLM с точки зрения того, насколько описанный выше алгоритм приемлем для безопас- ности данных. RAG работает следующим образом: сначала ретривер (поисковый движок) извлекает наиболее релевантные фраг- менты из внутренней базы знаний орга- низации (регламенты, приказы, преды- дущие аудиторские заключения, акту- альные тексты законов и т. п.), затем формируется запрос, содержащий сфор- мулированную пользователем инструк- цию и фрагменты внутренней базы зна- ний, после чего передается в LLM- модель (в рамках рассматриваемого подхода – через API), которая формирует ответ уже на основе этого запроса. Такой подход резко снижает риск гал- люцинаций (когда модель выдает прав- доподобную, но неверную информацию) и гарантирует, что все рекомендации и тексты основаны именно на имеющихся в организации внутренних материалах и текущей нормативке. Однако при этом следует иметь в виду, что: l отдельные куски внутренней инфор- мации передаются во внешний сервис и могут сохраняться в журналах (логах) этого внешнего сервиса; l вовне уходит не вся внутренняя доку- ментация, а лишь отдельные части отдельных документов; l сама LLM не сохраняет переданную в запросе информацию непосредственно у себя внутри, информация сохраняется только в журналах программного обес- печения организующего взаимодействие пользователя с моделью. Эта информа- ция может использоваться (а часто дей- ствительно используется) владельцем сервиса для последующего обучения модели: журналы преобразуются в понятный для обучения модели набор данных (датасет) и затем отдельно запус- кается процесс обучения копии (или новой) LLM, которая в последующем заменяет работающую. Указанные выше моменты необходимо учитывать с точки зрения принятия реше- ния о целесообразности выстраивания процесса в рамках описанного выше подхода. По мнению автора, подобным образом можно организовать автомати- зацию в двух ситуациях: l обрабатываются документы, не содер- жащие критическую информацию; l провайдер сервиса внешней LLM- модели отечественный и с ним имеется соглашение о невключении данных в обучающие датасеты. 3. Продвинутый уровень (целевой ори- ентир для зрелых служб ИБ). Создание внутреннего ИИ-ассистента ИБ на базе локальных моделей и RAG. Ассистент работает 24/7, обеспечивает непрерывный мониторинг ключевых регламентов, авто- матически выявляет несоответствия при выходе новых нормативных актов, форми- рует доказательную базу по любому запро- су аудитора и даже предлагает готовые корректирующие меры с расчетом влияния на деловые процессы организации. В целом развернуть локальную LLM и сделать ИИ-ассистента – задача доста- точно простая и доступная, причем даже для небольших организаций. Основной проблемой является необходимость мощностей для функционирования ИИ- ассистента. Подводные камни Автоматизация на базе LLM и RAG – мощный инструмент, однако было бы ошибкой представлять его как универ- сальное решение без оговорок. Практика показывает, что именно здесь многие организации допускают критические про- счеты. Первое и главное: юридическая ответ- ственность за содержание организа- ционно-распорядительных документов при таком подходе никуда не перекла- дывается. Документ подписывает чело- век – он же и несет ответственность. Это означает, что любой сгенерирован- ный текст должен проходить обязатель- ную экспертную проверку квалифици- рованным специалистом. Второе – проблема актуальности базы знаний в RAG-контуре. Система хороша ровно настолько, насколько актуальны загруженные в нее документы. Если нормативный акт вступил в силу, а соот- ветствующий текст не был своевременно добавлен в хранилище, модель будет формировать рекомендации на основе устаревших данных – причем делать это уверенно и без каких-либо пред- упреждений. Регулярное обновление базы знаний должно быть закреплено как отдельный, регламентированный процесс с назначенным ответственным и четко определенной периодичностью. Третье – так называемый дрейф моде- ли. При использовании внешних LLM- сервисов владелец сервиса периодиче- ски обновляет модель, и ее поведение может изменяться: меняется стиль фор- мулировок, интерпретация отдельных требований, структура генерируемых документов. То, что работало корректно в марте, в сентябре может давать иные результаты. Это требует периодического тестирования и валидации на контроль- ных примерах – особенно перед началом нового цикла актуализации документов. Указанное характерно и для смены локальных моделей (например, в случае, когда увеличили мощности и решили использовать LLM с большим, чем было ранее, количеством параметров). Четвертое – внедрение LLM/RAG- решения неизбежно ставит вопросы, которые находятся за пределами техни- ческой плоскости. Кто в подразделении ИБ является владельцем базы знаний и несет ответственность за ее актуаль- ность? Кто верифицирует выходные документы перед передачей на согла- сование? Как выстроен процесс контро- ля качества генерируемых текстов? Эти вопросы критически важны, поскольку в противном случае автома- тизация рискует воспроизвести ту самую проблему, с которой она призвана бороться. Вспомним ситуацию из начала статьи: один специалист ушел в отпуск – процесс остановился. Если знания о том, как функционирует RAG-система, как обновляется база и как проверяются результаты, сосредоточены в одном человеке, организация получает новую точку единого отказа вместо старой. Решение – документирование процесса работы с системой на уровне внутреннего регламента и распределение ключевых функций между несколькими специали- стами. Владелец базы знаний, специалист по верификации выходных документов и администратор интеграции – это могут быть разные роли, совмещенные в рам- ках небольшого подразделения, но при этом четко разграниченные и задубли- рованы (имеется запасной специалист), а также зафиксированы в организацион- но-распорядительных документах. Только в этом случае автоматизация действи- тельно повышает операционную устой- чивость, а не создает новые сложности. В заключение Автоматизация регламентов и соот- ветствия требованиям – не самоцель и не дань моде на искусственный интел- лект. Это управленческое решение, про- диктованное объективной реальностью: нормативная среда усложняется быстрее, чем растут штаты подразделе- ний ИБ, а цена ошибки в документах становится все выше. LLM-решения с технологией RAG сего- дня предоставляют реальную возмож- ность выйти из этого противоречия без многомиллионных бюджетов и много- летних внедрений. Однако их ценность определяется не самой технологией, а тем, насколько грамотно выстроен процесс вокруг нее. l • 73 УПРАВЛЕНИЕ www.itsec.ru Ваше мнение и вопросы присылайте по адресу is@groteck.ru