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

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

Редакция 24 сентября 2026, дополнена 9 ноября 2026

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Платформа передает события безопасности в систему мониторинга безопасности компании, когда указан адрес этой системы. Такую систему часто называют SIEM (Security Information and Event Management, управление информацией и событиями безопасности): в ней служба безопасности собирает и разбирает такие события. Передается закрытый перечень из шестнадцати видов событий. Состав перечня задан платформой, и выключить отдельный вид настройкой нельзя. Виды делятся на шесть групп:

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

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

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

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

По умолчанию передача выключена. Адрес системы мониторинга называет служба безопасности компании.

Каждое событие уходит отдельным сообщением syslog (стандартный протокол передачи журналов, в версии по стандарту интернета RFC 5424), а тело сообщения записано в формате CEF (Common Event Format, общий формат записи событий безопасности) в кодировке UTF-8. Передача идет только по TCP (протоколу с установкой соединения). UDP (передача без подтверждения) не поддерживается, потому что он теряет сообщения без следа. Само соединение платформа не шифрует.

В заголовке CEF указаны производитель и продукт (Svaya), версия установки, название вида события и его важность. В расширении передаются:

• Время события (rt) и его идентификатор (externalId).
• Псевдоним сотрудника или службы (suser). Имени в событии нет.
• Результат (act и outcome), код причины (reason), если он есть, и группа события (cat).
• Класс субъекта, идентификатор установки, цепочка журнала аудита и позиция в ней (chain и chainPos), тип события (eventType), контрольная сумма записи (eventHash).
• Номер трассы (traceId), если он есть.
• Поля содержимого, заданные для вида (payload).
• Признак anchored, который равен yes, если позиция уже покрыта контрольной суммой, записанной в отдельное хранилище, где ее нельзя изменить (по умолчанию это происходит раз в час), и равен no, если еще нет.

Для каждого вида платформа передает только заранее названные поля содержимого. Например, для отказа во входе это код причины и канал. Остальные поля события остаются в журнале аудита. Текст, который человек вводит свободной формой, например причина выпуска автоматизации, в выгрузку не входит. Значение длиннее 1024 знаков обрезается, в конце ставится пометка «…[усечено]».

Платформа читает журнал аудита по отметке: для каждой цепочки запоминает, до какой позиции передача дошла. Если отправка не удалась, отметка стоит на месте, и те же события уходят при следующей попытке. У передачи по syslog через TCP нет подтверждения приема каждого сообщения системой мониторинга, поэтому доставки ровно один раз она не дает. После обрыва соединения платформа отправляет заново последние пачки (по умолчанию две), а после перезапуска сервиса сбора телеметрии повторы возможны по той же причине. Система мониторинга может получить одно событие дважды. Дубль узнают по идентификатору события (externalId).

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

Если маскирование текста события не подтверждено, само событие в систему мониторинга не уходит. Вместо него приходит служебная запись «Событие удержано: маскирование не подтверждено». В ней указаны тип удержанного события, позиция в цепочке и причина, а текста события нет. Причина бывает одной из трех:

• При записи в журнал маскирование заменило значения метками вместо отказа обрабатывать текст целиком, как требовало правило.
• Распознаватель персональных данных не ответил вовремя.
• Условие аудита не вычислилось.

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

Показателя состояния передачи в метриках платформы нет.

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

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

Что платформа очищает по сроку и как это видно

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

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

• Удалить запись.
• Заменить значения выбранных полей хешем (кодом, который вычисляется из значения).
• Заменить значения выбранных полей маской (каждый знак, кроме промежутков между словами, становится звездочкой, форма значения остается видна).
• Записать в выбранные поля пустое значение.

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

Если автоматизацию собрала сама компания, в разделе «Правила автоматизации» срок хранения задается числом суток, и такое правило только удаляет. Срок в нем считается от даты создания, а у файлов от времени последней записи. Если у записей набора данных нет поля с такой датой, правило по этому набору платформа пропускает, и данные остаются. Обезличивание задают правила в части автоматизаций, которые собирает БизнесМатика.

Что остается после очистки:

• Итог каждого прохода записывается в рабочий журнал платформы, в том числе когда удалять было нечего. Так видно, что очистка работала.
• По каждому исполненному правилу платформа добавляет строку в журнал удалений. В строке записаны правило, цель, действие, примененный срок, число затронутых записей, итог и правовое основание, если автор правила его записал. Журнал удалений ведется в основной базе платформы. Отдельного экрана для него в кабинете нет, и сама очистка этот журнал не затрагивает.
• В журнал аудита платформа записывает событие «Выполнена очистка по сроку хранения» по каждому исполненному правилу, в том числе когда ничего не удалено. Его видно на экране «Журнал аудита».

Правило, которое платформа исполнить не может, она пропускает, и данные по нему остаются. Причины бывают разные, например в записях нет поля, от даты которого считается срок. Такое правило в журнал удалений не попадает. Его видно на экране настройки автоматизации: на вкладке «Правила» в блоке «Правила платформы» стоит строка «Еще N правил хранения записаны в автоматизации, но пока не действуют». Для действующих правил в том же блоке написан срок, который применяется на деле, например «срок хранения 5 лет» или «обезличивание через 1 год». Если автор автоматизации вынес срок в пороги, рядом со строкой стоит кнопка «Изменить».

Что администратор записывает в описателе

Сроки хранения администратор записывает в своем слое описателя в разделе installation, подразделе retention. Срок задается для вида данных, а внутри вида можно задать срок для класса данных. Пример записи:

installation:
  assist:
    dataClasses: [internal, pdn]
  retention:
    kinds:
      task-results:
        days: 1825
        contractMinimumDays: 1825
        byDataClass:
          pdn: 365
      masking-map:
        days: 7

Числа в примере условные. Вид task-results - результаты автоматизаций, days - срок вида в сутках, contractMinimumDays - договорный минимум, который администратор записывает сам, byDataClass - срок для данных класса pdn. Класс из byDataClass должен быть назван в списке assist.dataClasses, об этом ниже. Вид masking-map - таблица соответствия меток и исходных данных. Класс записывается одним из шести значений: public (открытые), internal (внутренние), pdn (персональные данные), pdn-special (особые персональные данные), bank-secret (банковская тайна), trade-secret (коммерческая тайна). Класс данных берется из объявления набора данных или файлов в автоматизации. Если класс там не указан, действует срок вида.

Как читается срок:

• Для результатов автоматизаций и истории разговоров срок из описателя сам ничего не удаляет. Он действует только там, где в автоматизации уже есть правило очистки.
• Для этих же видов срок из описателя только продлевает срок правила автоматизации и сократить его не может. Если правило удаляет или обезличивает раньше, платформа ждет срока из описателя. Если правило ждет дольше, действует срок правила. Применяется больший из двух. Поэтому записью в описателе нельзя заставить платформу удалить или обезличить данные раньше, чем сказано в правиле автоматизации.
• Срок пары «вид и класс» заменяет срок вида для данных этого класса, поэтому может быть короче срока вида. Он нужен, чтобы долгий срок вида не удерживал данные класса, которые автоматизация обезличивает раньше. Данные других классов остаются на сроке вида. Договорным минимумом срок пары не проверяется.
• Значение days: null означает, что для вида описатель своего срока не задает. Правила автоматизаций действуют, как в них записано.

Срок применяется к трем видам:

• task-results - результаты автоматизаций, то есть наборы данных и файлы автоматизаций, кроме диалоговой памяти.
• dialog-history - история разговоров, то есть набор данных диалоговой памяти автоматизации.
• masking-map - таблица соответствия меток и исходных данных (на странице «Персональные данные» она названа картой замен). Для нее срок является верхней границей: таблица не хранится дольше срока из описателя. Он сокращает перерыв в разговоре и предельный срок жизни таблицы, о которых сказано выше в разделе о маскировании. Если срок из описателя длиннее этих пределов, они не продлеваются. Срок любого класса, кроме public, тоже сокращает срок таблицы целиком, действует самый короткий из заданных.

Описатель принимает сроки и для других видов данных. Для четырех из них срок очистку не включает: audit-journal (журнал аудита), traces (трассы), backups (резервные копии) и usage-journal (журнал расхода). Сроки этих данных задаются в других местах, они перечислены ниже.

Что происходит при ошибках в сроках:

• Раздела retention нет. Платформа запускается, пишет в рабочий журнал предупреждение и очищает данные автоматизаций по срокам из правил самих автоматизаций.
• Значение days меньше contractMinimumDays, у вида нет days или имя вида записано с опечаткой. Сборка конфигурации завершается отказом.
• В byDataClass назван класс, которого нет в списке assist.dataClasses. Сборка конфигурации завершается отказом. Этот же список определяет классы данных, которые платформа вашей компании разрешает передавать помощнику в кабинете.
• Для таблицы соответствия записан срок 0 (на самом виде или на классе, кроме public). Такую запись сборка конфигурации принимает, но платформа с ней не запускается.

Новые сроки начинают действовать после сборки конфигурации и перезапуска платформы.

Какие данные очищаются по другим настройкам

Очистка по правилам автоматизаций не касается следующих данных:

• Завершенные процессы и их журналы удаляются через 90 суток, если срок не изменен. Срок задает настройка службы процессов, значение 0 отключает удаление. Процессы, завершившиеся ошибкой, платформа пока не удаляет, а только считает. Когда удаление таких процессов включат, они будут храниться вместе с данными заявителя 365 суток, если срок не изменят.
• Журнал аудита по умолчанию не удаляется.
• Трассы не удаляются, пока срок их хранения не задан в сервисе сбора телеметрии. Раздел retention описателя этот срок не задает.
• Служебный журнал расхода хранится по умолчанию 30 суток (параметр usageRetentionDays в разделе installation). Удаляются только строки, выгрузка которых подтверждена.
• Сроки хранения резервных копий и порядок их удаления описаны на странице «Резервные копии».

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

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

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