Журнал аудита ИИ-запросов к 1С: кто спросил, к какой базе и что было заблокировано

Когда к базе 1С подключают ИИ-ассистента, в системе появляется новый канал доступа, который штатный Журнал регистрации почти не описывает. На типовом случае видно, почему нативный журнал не отвечает на вопрос «кто спросил, к какой базе и что заблокировано», и что вместо него должен фиксировать отдельный аудит ИИ-запросов к 1С.

Случай, который повторяется чаще, чем кажется

Оптовая компания, около 120 человек, три рабочие базы: УТ для торговли, Бухгалтерия предприятия для учёта и ЗУП для расчёта зарплаты. Чтобы аналитики быстрее собирали отчёты, а ведущий разработчик не копался вручную в метаданных, к контуру подключили ИИ-ассистента через MCP-сервер. Подключение сделали быстро: одна техническая учётная запись (назовём её mcp_svc) с широкими правами, чтобы просто заработало.

Через месяц на доработку СКД-отчётов пришёл внешний подрядчик. Ему на время дали доступ к тому же ассистенту. Не разбираясь в границах, подрядчик попросил: «собери сводку по сотрудникам с окладами и премиями за квартал». Ассистент честно обратился к ЗУП, выполнил несколько запросов к регистрам расчёта и вернул ФИО, оклады и суммы премий. Ни блокировки, ни предупреждения: обычная выборка, каких за день проходят десятки.

Спустя две недели финансовый директор спросил, откуда у подрядчика цифры по фонду оплаты труда. Вопрос был простой: кто именно, когда и к какой базе обратился, что запросил и что система в ответ отдала. Специалист по безопасности открыл Журнал регистрации 1С и увидел ровно одно: учётная запись mcp_svc в 14:32 выполнила серию запросов. Ни человека за этими запросами, ни исходного вопроса, ни отметки о том, что хоть что-то было ограничено. Расследование упёрлось в тупик на первом же шаге.

Почему нативный Журнал регистрации не видит ИИ-канал

Причина первая: ассистент ходит в базы под одной технической учёткой. Журнал регистрации фиксирует именно её, поэтому действия десятков людей, которые в разное время что-то спрашивали у ИИ, сливаются в один обезличенный поток. Ответа на вопрос «кто спросил» там нет по устройству.

Причина вторая: нативный журнал пишет на уровне сеансов и объектов (какой справочник, какой документ, какой регистр сведений или накопления затронут), но не на уровне смысла. Один вопрос на естественном языке модель раскладывает на серию запросов к данным и несколько вызовов инструментов, а исходную формулировку и контекст журнал не хранит. Восстановить по постфактум-следам, что на самом деле спрашивали, почти невозможно.

Причина третья, и она ключевая для нашей темы: нативный журнал в принципе не умеет писать «заблокировано» для ИИ. Ролевые права и RLS ограничивают интерактивные сессии людей в интерфейсе. Но обращения ассистента идут под сервисной учёткой с её правами, и отказов по политике ИИ там не возникает: их просто некому породить. Нет управляющего слоя перед базой, значит, нет и события «запрос отклонён».

Здесь стоит развести два понятия. Ограничение прав (роли, RLS) и учёт обращений решают разные задачи: первое сужает то, что доступно, второе фиксирует, кто, что и с каким результатом сделал. Одно не заменяет другое. Пока перед базой нет отдельного слоя, логирование обращений нейросети к базе сводится к безликому потоку операций, в котором не видно ни автора, ни отклонённых попыток.

Что на самом деле должен фиксировать журнал ИИ-запросов

Отдельный аудит запросов ИИ к 1С отвечает на три вопроса из заголовка: кто, куда и с каким результатом. По опыту, полезный журнал ИИ содержит:

• Инициатор. Реальный человек или именованное рабочее место, а не общая сервисная учётка. Это то, что превращает «серию запросов от mcp_svc» в «запрос конкретного сотрудника».
• База и её среда. К какой инфобазе шло обращение (УТ, Бухгалтерия, ЗУП) и в каком она статусе: прод, тест или разработка. Обращение к боевой ЗУП и к её тестовой копии несут разный вес.
• Инструмент и параметры. Какой инструмент или запрос был вызван и с какими ключевыми параметрами, чтобы по записи читалась суть операции, а не только сам факт.
• Вердикт и причина. Разрешено, ограничено или заблокировано, и почему: попытка записи в прод, обращение вне роли, превышение квоты на базу.
• Время и возможность выгрузки. Метка времени плюс экспорт (например, CSV или JSONL), чтобы передать выборку в SIEM или приложить к материалам по инциденту.
• Хранение. Настраиваемый срок, отдельно от Журнала регистрации, чтобы аудит ИИ-канала не размывался в общем потоке платформенных событий.

Ключевой пункт здесь последний. Журнал ИИ ценен не тем, что перечисляет успешные обращения, а тем, что фиксирует отклонённые: заблокированная запись в боевую бухгалтерию, отклонённый выход за контур роли, упёршийся в квоту массовый обход справочника. Это и есть материал для расследования и для предметного разговора со службой ИБ.

Управляемый шлюз: откуда берутся и аудит, и блокировки

Все три вопроса закрываются, если между ИИ-ассистентом и базами стоит управляемый шлюз, через который проходит каждое обращение. Точка, где ИИ встречается с данными, становится единственной и контролируемой. Как локальная граница удерживает данные в контуре компании, подробно разобрано в отдельной статье про ИИ для 1С на своём контуре; здесь важнее другое: то же место, где шлюз принимает решение, оно же пишет журнал.

Кто спросил. Доступ выдаётся по рабочим местам, поэтому каждое действие привязано к конкретному человеку, а не к общей учётке. В нашем сценарии подрядчик был бы отдельным местом с ограниченным профилем, и его запрос к ЗУП не растворился бы в потоке mcp_svc.

К какой базе. Шлюз маршрутизирует обращения по нескольким инфобазам и знает статус каждой. Прод, тест и разработка различаются на уровне политики, а не на честном слове администратора.

Что заблокировано. Здесь появляются события, которых нативный журнал дать не мог. Жёсткий read-only на боевых базах (fail-closed) отклоняет любую попытку записи в прод и фиксирует отказ. Ролевые профили на уровне шлюза ограничивают, к каким базам и операциям допущен каждый: профиль с доступом только к торговым данным не получит выгрузку из ЗУП, обращение вне роли будет отклонено. Важно, что эти профили задаются на самом шлюзе, отдельным слоем, а не наследуются из прав 1С. Квоты на каждую базу отсекают аномальные всплески запросов. Даже запрос, спровоцированный подменой инструкции (prompt injection), который пытается выйти за рамки роли или записать в прод, осядет в журнале как заблокированная попытка, а не как тихо выполненная операция.

Здесь же проходит граница с более простыми подходами. Сырой MCP-сервер без governance-слоя даёт ассистенту прямой доступ к базе и в лучшем случае пишет тот же безликий поток, что и платформа. Токен-маскировщики, которые прячут отдельные значения, но не дают ни ролей, ни вердиктов, не отвечают ни на «кто спросил», ни на «что заблокировано». Governance и аудит начинаются там, где перед базой стоит слой, который имеет право сказать «нет» и записать это «нет».

Что до сокращения объёма данных, который видит модель: маскирование ПДн на выходе шлюза для Корпоративной редакции сейчас в разработке, и обещать его как готовую функцию было бы нечестно. Но и без маскирования отдельный журнал ИИ уже отвечает на главный вопрос расследования: кто, к какой базе и что именно система ему разрешила или запретила.

152-ФЗ, требования по защите персональных данных и 24 часа на ответ

Это не академический интерес. Справочник Контрагенты, документы с контактами, а тем более ЗУП, это персональные данные, то есть ИСПДн. И закон ждёт от оператора не только защиты, но и учёта доступа. Требования по защите персональных данных относят к обязательным мерам защиты ИСПДн регистрацию событий безопасности: сбор, запись и хранение сведений о значимых для защиты событиях с возможностью их последующего анализа. Учёт того, кто и к каким данным обращался, здесь не пожелание, а ожидаемая мера. ИИ-ассистент открывает новый путь к тем же данным, и если этот путь нигде не журналируется, в системе учёта появляется пробел ровно там, где регулятор ждёт полноты.

Дальше идёт фон ответственности. С 30 мая 2025 года поправки к статье 13.11 КоАП (Федеральный закон №420-ФЗ от 30.11.2024) заметно подняли ставки. Фиксированные штрафы зависят от масштаба: утечка данных от 1 до 10 тысяч субъектов обойдётся организации в сумму от 3 до 5 млн рублей, а при утечке более чем 100 тысяч записей штраф доходит до 15 млн. За повторную утечку в течение года введены оборотные штрафы: от 1 до 3 процентов совокупной годовой выручки, но не менее 20 млн рублей. Отдельно закон обязывает уведомить Роскомнадзор об инциденте в течение 24 часов, а результаты внутреннего расследования донести в течение следующих 72 часов.

Эти сутки и есть практический смысл аудита. Когда возникает подозрение на утечку, нужно быстро ответить, чьи данные и через какой канал были затронуты и что удалось предотвратить. Отдельный журнал ИИ-запросов даёт этот ответ за минуты, а не за недели разбора платформенных логов. И при разборе инцидента возможность показать, что ИИ-канал был под контролем, а события фиксировались, работает в вашу пользу гораздо надёжнее, чем объяснения задним числом.

Оговорка без преувеличений: локальный контур и отдельный аудит сами по себе не делают компанию «соответствующей 152-ФЗ» и не заменяют аттестацию. Соответствие определяется вашими процессами и оценкой регулятора, а не наличием одной галочки. Но держать данные в своём контуре и сокращать объём того, что вообще уходит в модель, объективно снижает и поверхность риска, и цену возможной ошибки.

Короткий чеклист

Перед тем как открывать ИИ-ассистенту доступ к боевым базам, проверьте несколько вещей.

• Под какой учётной записью ассистент реально ходит в базу и сможете ли вы по журналу отличить одного человека от другого.
• Фиксируются ли где-нибудь отклонённые обращения. Если блокировка нигде не остаётся, расследовать инцидент будет нечем.
• Разведены ли ограничение (права, RLS) и учёт. Первое не заменяет второе.
• Остаются ли журнал и данные в вашем периметре, особенно если база относится к ИСПДн.
• Есть ли выгрузка событий в SIEM или в архив под нужный срок хранения.

Если коротко

Feenlace MCP-1C, это управляемый MCP-шлюз для 1С:Предприятие, который ставится в ваш контур одним автономным бинарём. Он соединяет ИИ-ассистентов (Claude, ChatGPT и другие) с инфобазами через слой политик. Бесплатная Открытая редакция с открытым исходным кодом даёт попробовать связку ИИ и 1С у себя. Полноценный управляемый шлюз с ролевыми профилями, аудитом ИИ-запросов, жёстким read-only на проде и квотами по базам, это Корпоративная редакция: тот самый отдельный журнал, где видно, кто спросил, к какой базе и что было заблокировано. Посмотреть редакции и развернуть у себя можно на feenlace.ru.