Документация / Возможности / Обработка запроса и защита данных

Обработка запроса и защита данных

Редакция 23 сентября 2026

Для службы безопасностиДля администратораДо выбора платформы и перед работой на реальных данных

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

Путь вопроса от пользователя до языковой модели и обратно

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

1. Единый конвейер обработки запроса

Этапы защиты, обязательные в каждой задаче

Проверка прав, маскирование и запись в журнал аудита обращений к языковой модели и отказов в доступе есть в каждой задаче, и отключить или ослабить их автор задачи не может. Если правила задачи разрешают передать данные сервису языковых моделей, текст запроса всегда проходит маскирование. Если маскирование недоступно, запрос не уходит. По трассе можно разобрать каждый этап любого запроса.

Как конвейер собирает запрос и проверяет ответ

• В один запрос к языковой модели платформа собирает вопрос, фрагменты документов, текст приложенных файлов и историю разговора.
• Маскирование проходит весь текст запроса (вопрос, фрагменты документов, текст из приложенных файлов, историю разговора, результаты действий ИИ-агента во внешних системах и замечания проверки качества, с которыми языковая модель переписывает ответ).
• Если автор задачи требует ссылок на источники, ответ без ссылок или со ссылками на документы, которые не нашлись для этого вопроса, проверку не проходит, и пользователь его не получает.
• Фильтры ответа (правила, которые задает автор задачи) ищут в ответе персональные данные заданных категорий, запрещенные формулировки и сведения заданных классов данных. Что делать с найденным, выбирает автор задачи. Если он не выбрал другое, ответ с такими сведениями не выдается вовсе. Кроме того, фильтр может вырезать найденное из ответа или только отметить находку в трассе, и тогда ответ выдается без изменений.
• Если автор задачи включил проверку качества ответа, языковая модель-оценщик ставит ответу оценку по показателю, который выбрал автор задачи (например, насколько ответ опирается на найденные документы). Если оценка ниже порога, заданного автором задачи, языковая модель пишет ответ заново с замечаниями оценщика. Если и после заданного числа повторов оценка ниже порога, дело передается на разбор сотруднику.
• Перед каждым действием ИИ-агента во внешней системе (например, перед чтением карточки клиента) платформа отдельно проверяет права того, от чьего имени работает ИИ-агент.

Что автор задачи задает в конвейере

Для каждого шага автор задачи указывает класс языковой модели и классы данных, которые шаг передает языковой модели. Значения «данные не чувствительны» по умолчанию нет, поэтому классы данных указывают явно. В правилах задачи автор задает, какие классы данных уходят к языковой модели только после маскирования, а какие не уходят вовсе. Там же задаются фильтры ответа и проверка качества ответа (показатель, порог и число повторов).

От чего конвейер не защищает

• Маскирование работает только с текстом. Изображение уходит к сервису языковых моделей, только если автор задачи отнес его к открытым или внутренним данным и правила задачи разрешают такую передачу. Есть ли в изображении персональные данные, платформа не проверяет и полагается на класс данных, который указал автор задачи.
• Проверка качества ответа не работает, когда пользователь видит ответ по частям, пока языковая модель его пишет.
• Текст документа может содержать команды для языковой модели (например, «не учитывай прежние инструкции»). Конвейер такие команды не распознает, и они могут изменить ответ языковой модели. Права пользователя и маскирование при этом продолжают действовать, потому что их проверяет сама платформа до и после обращения к языковой модели.

Какие этапы видны в трассе каждого запроса, разобрано на странице «Наблюдение за состоянием».

2. Разграничение доступа по ролям и атрибутам

Сотрудник видит и делает только то, что ему разрешено

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

Как платформа проверяет права

Права складываются из следующих слоев правил:

• Общие правила платформы. Первое из них запрещает все, что не разрешено явно.
• Роли, которые задает автор задачи.
• Дополнительные запреты задачи. Они могут только сузить права, расширить их нельзя.

Кроме роли, платформа проверяет признаки дела и сотрудника. У дела это владелец и очередь (список дел, из которого сотрудники берут работу), у сотрудника это подразделение и очереди, в которых он работает. Если право роли ограничено своими делами или делами своей очереди, а у дела не указан владелец или очередь, в доступе отказано.

Роли и признаки, которые пришли внутри самого запроса как данные, платформа не учитывает. Поэтому присвоить себе роль, вписав ее в запрос, нельзя. Действия, на которые выдаются права, перечислены закрытым списком (например, чтение, поиск, подтверждение решения по делу и изменение настроек). Каждый отказ в доступе записывается в журнал аудита.

Как устроен единый вход

Единый вход - это вход во все рабочие программы с одной корпоративной учетной записью. Сотрудники входят на платформу через ее службу входа (программу в составе платформы, которая проверяет учетные записи). Корпоративную систему входа компании администратор подключает к службе входа платформы в настройках службы входа, без программирования. Для подключения служат стандартные протоколы единого входа OpenID Connect и SAML 2.0. Другие программы компании, которые обращаются к платформе (например, учетная система), получают свои служебные учетные записи.

Что администратор настраивает в доступе

Какую роль получает сотрудник, решает привязка групп сотрудников к ролям задачи (группы ведутся в службе входа платформы). Порядок привязки групп к ролям разобран на странице «Доступ и роли», там же объяснено, почему сотрудник может не видеть дело или документ.

Чего разграничение доступа не делает

• Права на документы задаются на весь корпус задачи сразу (корпус - это набор документов, по которому ищет задача). Отдельных прав у каждого документа нет, поэтому документы с разным доступом автор задачи раскладывает по разным корпусам.
• Отозванное право перестает действовать, когда истечет пропуск, который служба входа выдает сотруднику при входе. По умолчанию пропуск действует до пяти минут, и больше пятнадцати минут его срок не бывает.
• Назначить роль на время (например, на время отпуска коллеги) нельзя. Роль назначают и снимают вручную.

3. Выявление и маскирование персональных данных

Маскирование персональных данных перед отправкой языковой модели

Платформа заменяет найденные персональные данные метками перед отправкой текста сервису языковых моделей, и в трассы и журнал аудита эти данные тоже попадают замаскированными. Языковая модель при этом понимает текст. Фразу «⟦PERSON-NAME:9f3a…⟧ подал заявку» она читает как «человек подал заявку». Если платформа не уверена, персональные данные перед ней или нет, она заменяет значение меткой.

Как платформа находит персональные данные

Для поиска персональных данных в русском тексте платформа применяет следующие способы:

• Разбор форм слов (например, «Иванову» и «Иванов» платформа считает одной фамилией).
• Словари имен, фамилий, отчеств, улиц и городов.
• Проверку контрольных сумм у СНИЛС, ИНН, ОГРН, полиса ОМС и номера карты.
• Модели машинного обучения, которые находят имена и адреса в тексте.

Разные формы одного имени (например, «Иванову Ивану Ивановичу» и «Иванов И. И.») платформа считает одним человеком, и один человек получает одну метку на весь разговор. Платформа находит следующие виды персональных данных:

• ФИО.
• Паспорт РФ и загранпаспорт.
• СНИЛС, ИНН и полис ОМС.
• Телефон и адрес электронной почты.
• Адрес места жительства и дату рождения.
• Банковский счет и номер карты.
• Госномер автомобиля и водительское удостоверение.

Полный перечень приведен на странице «Персональные данные».

Исходные данные платформа ставит на место меток сразу после ответа языковой модели по таблице соответствия меток и исходных данных, а затем проверяет ответ и выдает его пользователю или записывает в дело. Таблица соответствия хранится в зашифрованном виде. Если маскирование недоступно или завершилось ошибкой, запрос к сервису языковых моделей не уходит. Режима «пропустить без маскирования» нет.

Что задают в маскировании

• Автор задачи может добавить свои категории сведений, которые ищет маскирование, свои словари и шаблоны и выбрать для категории сведений более строгое действие (например, заменить значение без возврата в ответ или отказаться обрабатывать текст целиком). Ослабить защиту, которая действует без настройки, автор задачи не может.
• Поиск персональных данных работает в одном из двух режимов. Тщательный режим добавляет к распознаванию имен и адресов еще одну модель машинного обучения и поэтому работает дольше быстрого.
• Таблица соответствия меток и исходных данных одного разговора хранится, пока в разговоре не будет перерыва дольше заданного срока (по умолчанию четырнадцать суток), и в любом случае не дольше 90 суток.

Чего маскирование не делает

• Особые категории персональных данных (например, сведения о здоровье и убеждениях) маскирование не распознает. От их передачи языковой модели защищает только отметка класса данных «особые персональные данные», которую автор задачи ставит шагу.
• Сами файлы, изображения и звук маскирование не обрабатывает. Текст, извлеченный из файлов, маскируется, как любой другой текст запроса.
• При обратной подстановке значение возвращается в той форме, в которой встретилось первым, поэтому падеж может не совпасть с остальным текстом.
• Маскирование находит не все персональные данные, и часть значений может уйти к сервису языковых моделей без замены. Какую долю персональных данных маскирование находит на документах компании, показывает оценка качества на эталонном наборе (примерах документов компании с заранее отмеченными персональными данными, подробнее на странице «Самостоятельная настройка»).

12. Аудит и прослеживаемость

Что аудит дает службе безопасности и проверяющим

Служба безопасности и проверяющие (например, внутренний аудит компании) получают следующее:

• Журнал аудита, в который можно только дописывать, с проверкой целостности.
• Трассы каждого запроса к задаче, по которым видно, как получено решение по делу.
• Выгрузку событий безопасности в систему мониторинга безопасности компании.

Журнал аудита, в который можно только дописывать

• Каждая запись журнала аудита содержит контрольную сумму, которая вычисляется из самой записи и из контрольной суммы предыдущей записи. Так записи складываются в цепочку, и правка или удаление любой записи эту цепочку разрывает.
• Журнал ведется несколькими цепочками (цепочки делятся по периодам времени). Раз в заданный срок (по умолчанию раз в час) платформа записывает последние контрольные суммы всех цепочек в отдельное хранилище, где записанное нельзя изменить или удалить.
• Проверка целостности пересчитывает цепочки и выдает отчет. Если запись подменили, отчет называет место в цепочке, где она разорвана. Пропуск в нумерации событий платформа записывает отдельным событием.
• В журнал аудита записывается только текст после маскирования, и снять маскирование в журнале нельзя. Выгрузку журнала проверяющие могут проверить на целостность (что записи не подменены) отдельно от платформы, без доступа к ней.

Трасса каждого решения по делу и ее просмотр

Трасса пишется для каждого запроса к задаче без исключений, поэтому трасса есть у каждого решения по делу. В трассе видны следующие сведения:

• Версии языковой модели, текстов инструкций и задачи.
• Шаги поиска и найденные фрагменты документов.
• Действия ИИ-агента во внешних системах.
• Места, где маршрут дела разветвлялся, и выбранный путь.

Трассы находят по номеру дела, не зная внутреннего номера трассы. На экране просмотра видны этапы запроса на шкале времени, путь дела по маршруту с исходами согласований и разбор отдельного шага (от собранного запроса к языковой модели до сработавших проверок). Паспорт запуска (описание запроса с версиями задачи, языковых моделей и исходами согласований) выдается файлом, чтобы передать его аудитору.

Выгрузка событий безопасности в систему мониторинга

События безопасности платформа передает в систему мониторинга безопасности компании. События делятся на следующие классы:

• Вход и права (в том числе отказ во входе и смена роли).
• Доступ к данным (в том числе выгрузка данных и журнала).
• Изменение работы платформы (например, выпуск новой версии задачи или правка настроек).
• Внешние вызовы (обращение к сервису языковых моделей и действие ИИ-агента во внешней системе).
• Срабатывание защит (например, маскирования, фильтра ответа или отказа в доступе).

Каждое событие безопасности платформа записывает в журнал аудита, и эту запись нельзя выключить в настройках. В систему мониторинга уходит тот же замаскированный текст, что и в журнал аудита. Пока система мониторинга недоступна, события ждут в очереди доставки и не теряются. Способ передачи и формат событий подбирают при внедрении под требования системы мониторинга, и формат утверждает служба безопасности компании.

Сроки хранения по классам данных

• Срок хранения задается для сочетания вида записей (например, история разговоров, журнал аудита, трассы или результаты задач) и класса данных.
• Наименьший допустимый срок записан в договоре с компанией, а действующий срок задает администратор в настройках платформы. Если действующий срок меньше наименьшего или у данных не указан класс или срок, платформа не запускается.
• Когда срок истек, данные удаляются, и удаление записывается в журнал удалений вместе с правилом и правовым основанием. Если удаление разорвало бы цепочку журнала аудита, платформа данные не удаляет и оставляет решение об их удалении человеку.
• Журнал аудита по умолчанию не удаляется. Трассы хранятся в течение срока, заданного в настройках.

Чего аудит не делает

• Проверка целостности обнаруживает правку или удаление записи после приема события. Подделку события до приема она не обнаруживает, и электронной подписи у записей журнала нет.
• Проверка целостности не обнаружит, что последние записи журнала согласованно переписал тот, у кого есть права на запись в журнал, если он сделал это до того, как платформа отправила их контрольные суммы в отдельное хранилище (по умолчанию это происходит раз в час). Не обнаружит она и полную переделку журнала вместе с этим хранилищем и резервными копиями, которую сделал администратор.
• По трассе видно, как получено решение по делу. Повторить по трассе тот же ответ нельзя, потому что повторный вызов языковой модели может дать другой ответ.
• Трасса доступна, пока не истек срок ее хранения.

Экран журнала описан на странице «Экраны кабинета» (кабинет - это веб-интерфейс платформы для сотрудников и администратора), записи хода запусков на странице «Наблюдение за состоянием», а сроки хранения по видам записей на странице «Персональные данные».