Описание функциональных характеристик
Версия 0.2.0 (редакция RU), проект · Скачать DOCX
Проект: документы проходят юридическую проверку. Пометки [ЗАПОЛНИТЬ] и [ПРОВЕРИТЬ] будут заполнены и сняты до подачи заявления.
1. Общие сведения
1.1. Назначение документа
Документ содержит описание функциональных характеристик программного комплекса «Айтечество» (далее — программный комплекс) и входит в состав документации, прилагаемой к заявлению о включении сведений о программном обеспечении в единый реестр российских программ для электронных вычислительных машин и баз данных. Документ предусмотрен подпунктом «д» пункта 11 Правил формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных и единого реестра программ для электронных вычислительных машин и баз данных из государств — членов Евразийского экономического союза, за исключением Российской Федерации, утверждённых постановлением Правительства Российской Федерации от 16.11.2015 № 1236 (в редакции от 13.08.2026) (далее — Правила).
1.2. Сведения о программном обеспечении
| Параметр | Значение |
|---|---|
| Наименование | Программный комплекс «Айтечество» |
| Версия | 0.2.0 (редакция RU) |
| Правообладатель | Индивидуальный предприниматель Орлова Юлия Витальевна |
| Класс программного обеспечения | 02.06 «Серверное и связующее программное обеспечение» (раздел 02 «Системное программное обеспечение» классификатора программ для электронных вычислительных машин и баз данных, утверждённого приказом Минкомсвязи России от 22.09.2020 № 486, в редакции приказа Минцифры России от 04.12.2023 № 1041) |
| Средство защиты информации | Не заявляется. Основная функция программного комплекса — интеграция приложений и пользователей организации с сервисами больших языковых моделей с обработкой текста запросов по правилам организации (раздел 1.3); сертификат соответствия по требованиям безопасности информации не оформлялся |
| Коды ОКПД 2 | 58.29.31.000 «Обеспечение программное системное для загрузки»; 63.11.13.000 «Услуги по предоставлению программного обеспечения без его размещения на компьютерном оборудовании пользователя» |
| Отнесение к сфере искусственного интеллекта | Да: программный комплекс применяет технологию обработки естественного языка (поиск и классификация именованных сущностей в тексте — фамилий, имён и отчеств, названий организаций и географических названий) и обеспечивает организациям доступ к большим языковым моделям |
| Способы предоставления | Удалённый доступ через сеть Интернет к инсталляции правообладателя (облачная версия); установка в инфраструктуре заказчика по лицензионному договору |
| Язык графического интерфейса | Русский; дополнительно доступен английский (раздел 10.3) |
1.3. Назначение программного комплекса
Программный комплекс предназначен для подключения сотрудников и информационных систем организации к большим языковым моделям через единую точку доступа, в которой текст запросов обрабатывается по правилам организации. Он устанавливается между сотрудниками и информационными системами организации, с одной стороны, и провайдерами языковых моделей, с другой, и выполняет следующие основные функции:
- принимает запросы приложений и сотрудников через единый API и веб-чат и направляет их провайдерам моделей по маршрутам организации с учётом ключей доступа, квот и ограничений тарифа;
- обнаруживает в тексте запросов к модели персональные данные, реквизиты, учётные данные, коммерческую и иную чувствительную информацию;
- в соответствии с политикой организации заменяет обнаруженные значения условными обозначениями (псевдонимами), обобщает их, блокирует запрос или пропускает его без изменений;
- передаёт модели только обработанный (замаскированный) запрос и восстанавливает исходные значения в ответе модели, в том числе в потоковом ответе;
- ведёт журнал запросов, содержащий только метаданные (без содержимого запросов и ответов), и журнал действий администраторов;
- предоставляет организации веб-консоль для управления политиками, пользователями, ключами доступа, подключениями к моделям, оповещениями и оплатой, а также веб-чат для работы сотрудников с моделями.
Поддерживаются провайдеры языковых моделей YandexGPT и GigaChat, а также модели, развёрнутые в инфраструктуре заказчика и предоставляющие OpenAI-совместимый API. Приложения заказчика подключаются к программному комплексу через OpenAI-совместимый API (протокол Chat Completions) или собственный API маскирования.
Использование программного комплекса само по себе не обеспечивает соответствия обработки персональных данных требованиям законодательства Российской Федерации: заказчик определяет политики обработки и отвечает за выбор провайдера модели.
1.4. Состав программного комплекса
| Компонент | Назначение |
|---|---|
| Шлюз (gateway) | Приём запросов к моделям, проверка ключей доступа и ограничений, обнаружение и маскирование данных, применение политик, проксирование к провайдерам моделей, восстановление данных в ответах |
| API управления (api) и фоновые задачи (worker) | Учётные записи, организации, роли, политики, подключения к моделям, журнал запросов, аудит, оповещения, вебхуки, биллинг, письма, хранение и удаление данных |
| Сервис распознавания именованных сущностей (nlp) | Обнаружение фамилий, имён и отчеств, названий организаций и географических названий с учётом морфологии русского языка |
| Сервис извлечения текста (extractor) | Извлечение текста из вложенных документов для их маскирования |
| Веб-приложение (web) | Сайт, веб-консоль и веб-чат |
| База данных | Схема PostgreSQL: настройки, политики и их версии, журнал запросов, аудит, биллинг |
2. Обнаружение данных
2.1. Категории данных
Программный комплекс обнаруживает 27 встроенных категорий данных, объединённых в группы, и данные по пользовательским правилам организации.
| Группа | Категории | Действие по умолчанию |
|---|---|---|
| Персональные данные | ФИО; дата рождения; паспорт; СНИЛС; полис ОМС; водительское удостоверение; госномер автомобиля | Псевдонимизация; дата рождения — обобщение |
| Контактные данные | Телефон; электронная почта; почтовый адрес; IP-адрес; ссылки доступа; аккаунты в мессенджерах | Псевдонимизация |
| Финансовые данные | Банковский счёт; БИК; номер карты; IBAN; денежные суммы | Псевдонимизация |
| Корпоративные идентификаторы | ИНН; ОГРН / ОГРНИП; КПП; ОКПО | Псевдонимизация |
| Коммерческая тайна | Названия организаций | Псевдонимизация |
| Медицинские данные | Диагнозы и коды МКБ | Псевдонимизация |
| Учётные данные | Пароли, токены, ключи | Блокировка запроса |
| Геолокация | Координаты; географические названия | Координаты — псевдонимизация; географические названия — пропуск |
| Пользовательские правила | Значения по шаблонам, словарям и стоп-словам организации | По настройке правила |
2.2. Методы обнаружения
- Шаблоны — регулярные выражения для телефонов, адресов электронной почты, почтовых адресов, ссылок, координат, госномеров, денежных сумм, учётных данных и др.
- Контрольные суммы — проверка контрольных разрядов ИНН, ОГРН, СНИЛС, номеров карт, IBAN, банковских счетов (в паре с БИК).
- Контекст — значения без контрольной суммы (паспорт, полис ОМС, водительское удостоверение, БИК, КПП, ОКПО, дата рождения) признаются по ключевым словам рядом со значением.
- Словари — медицинские диагнозы и коды МКБ (около 2 200 терминов), словари организации с учётом морфологии русского языка.
- Распознавание именованных сущностей — ФИО, названия организаций и географические названия определяются отдельным сервисом с моделями для русского и английского языков.
Для каждой категории политика задаёт минимальную уверенность обнаружения (по умолчанию 0,5). Обнаружение основано на вероятностных методах и не гарантирует выявления всех значений; качество обнаружения контролируется на эталонном наборе текстов при каждом изменении программного комплекса (см. «Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения»).
3. Обработка обнаруженных данных
3.1. Действия
| Действие | Результат |
|---|---|
| Пропустить | Значение передаётся без изменений и не считается срабатыванием |
| Предупредить | Значение передаётся без изменений; запрос отмечается в журнале, срабатывают оповещения |
| Обобщить | Значение заменяется диапазоном и не восстанавливается в ответе: денежная сумма — интервалом (например, «≈40–50 млн ₽»), дата рождения — десятилетием («1980-е годы»); для остальных категорий применяется псевдонимизация |
| Псевдонимизировать | Значение заменяется условным обозначением вида [ФИО_1], [ИНН_1] и восстанавливается в ответе |
| Блокировать | Запрос целиком отклоняется с сообщением «Запрос заблокирован политикой защиты данных.» |
Для каждой категории определён перечень допустимых действий: например, учётные данные нельзя пропустить, а псевдонимы учётных данных не восстанавливаются.
3.2. Условные обозначения
Условное обозначение состоит из метки категории и порядкового номера значения в запросе: одно и то же значение во всём запросе получает одно обозначение, разные значения — разные номера. Метки выводятся на русском или английском языке (настройка «Язык заглушек»). Для ФИО и географических названий модель может добавить к обозначению падеж (например, [ФИО_1:род]); при восстановлении подставляется форма значения в этом падеже. По настройке политики шлюз добавляет в запрос инструкцию для модели о сохранении условных обозначений.
Для запросов на получение векторных представлений (embeddings) используются обозначения, не зависящие от запроса (метка с ключевым хешем значения или только метка — настройка организации «Псевдонимы в эмбеддингах»), и восстановление не выполняется.
3.3. Восстановление данных в ответе
Исходные значения хранятся только в оперативной памяти шлюза на время обработки одного запроса и подставляются в ответ модели вместо условных обозначений. В потоковых ответах (Server-Sent Events) восстановление выполняется по мере поступления фрагментов: шлюз удерживает только окончание фрагмента, которое может оказаться началом условного обозначения. Восстанавливаются текст ответа, рассуждения модели и аргументы вызовов инструментов. Внутри ссылок (URL) обозначения по умолчанию не восстанавливаются, а в адресах изображений Markdown — никогда, чтобы исходные значения не уходили на внешние адреса при открытии ответа.
3.4. Контроль перед отправкой
Перед отправкой провайдеру шлюз повторно проверяет итоговое тело запроса на наличие исходных значений, подлежащих замене. Если такое значение найдено, запрос не отправляется, а клиент получает сообщение «Не удалось замаскировать запрос; он не был отправлен.»
3.5. Поведение при отказах
Если обработать запрос по политике организации невозможно, программный комплекс по умолчанию отклоняет его, а не передаёт провайдеру необработанным:
- при недоступности сервиса распознавания сущностей запрос по умолчанию отклоняется («Сервис распознавания имён недоступен, повторите позже.»); политика может разрешить обработку только шаблонами с отметкой запроса в журнале;
- поля запроса неизвестного шлюзу формата по настройке политики проверяются как текст или приводят к отклонению запроса;
- превышение времени маскирования (5 секунд по умолчанию), размера запроса (25 МБ) или объёма текста приводит к отклонению запроса;
- при недоступности хранилища счётчиков ограничения запросов применяются по счётчикам каждого экземпляра шлюза, а запросы к платформенным моделям, оплачиваемым с баланса, отклоняются.
4. Политики
4.1. Содержание политики
| Раздел | Назначение |
|---|---|
| Категории | Действие и минимальная уверенность для каждой категории |
| Белый список | Значения (точные или по регулярному выражению, до 1 000), которые не маскируются |
| Стоп-список | Ключевые слова и выражения, которые блокируют запрос, маскируются или вызывают предупреждение |
| Шаблоны | Пользовательские регулярные выражения (до 100) |
| Словари | Пользовательские словари с учётом морфологии (до 20 словарей по 20 000 терминов) |
| Вложения | Действия для изображений, документов и аудио (раздел 5) |
| Настройки | Поведение при отказе распознавания сущностей, обработка неизвестных полей, восстановление в ссылках, инструкция для модели, язык условных обозначений, максимальный размер запроса |
4.2. Применение политик
У каждой организации есть политика по умолчанию, которая применяется ко всем запросам. Дополнительные политики применяются ко всем запросам организации или только к выбранным группам, API-ключам и сотрудникам и могут действовать в заданный период времени. Если к запросу применяется несколько политик, для каждой категории выбирается самое строгое действие (блокировать — псевдонимизировать — обобщить — предупредить — пропустить); аналогично выбираются самые строгие настройки вложений и поведения при отказах и наименьший допустимый размер запроса.
Каждое изменение политики сохраняется как новая версия; версии можно сравнить и восстановить. При создании политики можно выбрать шаблон: «Базовая», «Финансы и банки», «Юристы», «Здравоохранение», «HR и рекрутинг», «Строгая (M&A, аудит)». Проверка политики на тексте и просмотр действующей политики выполняются в веб-консоли до её сохранения.
5. Вложения
Политика задаёт действия для вложений в запросах: изображения и аудио — пропустить, удалить из запроса или заблокировать запрос (по умолчанию — заблокировать); документы — дополнительно извлечь текст (по умолчанию). При извлечении текст документа маскируется по политике и передаётся модели вместо файла; сам файл модели не передаётся.
Поддерживаемые форматы документов: PDF, DOCX, DOC, XLSX, XLS, PPTX, PPT, RTF, ODT, ODS, ODP, TXT, CSV, MD. Формат определяется по содержимому файла; зашифрованные файлы отклоняются; распознавание текста на изображениях (сканах) не выполняется. Ограничения: до 20 МБ на файл и 20 файлов в запросе, до 500 страниц и 1 МБ извлечённого текста на документ. Каждый документ обрабатывается в отдельном процессе с ограниченными ресурсами во временном каталоге, который удаляется после обработки; сервис извлечения текста не имеет доступа к сети.
6. API шлюза
6.1. Методы
| Метод и путь | Доступ | Назначение |
|---|---|---|
| POST /v1/chat/completions | API-ключ; сеанс веб-консоли | Запрос к языковой модели в формате OpenAI-совместимого API (Chat Completions), в том числе с потоковым ответом |
| POST /v1/embeddings | API-ключ | Получение векторных представлений текста |
| GET /v1/models | API-ключ; сеанс веб-консоли | Перечень моделей, доступных ключу |
| POST /aitech/v1/mask | API-ключ; сеанс веб-консоли | Маскирование текста без обращения к модели; возвращает маркер восстановления или таблицу соответствия |
| POST /aitech/v1/unmask | API-ключ; сеанс веб-консоли | Восстановление исходных значений в тексте по маркеру восстановления |
| POST /aitech/v1/policy/test | Сеанс веб-консоли | Проверка политики на тексте |
| GET /aitech/v1/me | Сеанс веб-консоли | Сведения о пользователе и организации |
| POST /aitech/v1/demo/mask | Без аутентификации | Демонстрация маскирования на сайте (до 2 000 символов, с ограничением частоты) |
| GET /healthz, GET /readyz | Без аутентификации | Проверка состояния шлюза |
API-ключ передаётся в заголовке Authorization (Bearer) или api-key. Маркер восстановления зашифрован (AES-GCM), действует 24 часа и может быть ограничен API-ключом, сотрудником или организацией.
6.2. Ошибки
Ошибки возвращаются в формате OpenAI-совместимого API с кодом и сообщением на языке организации или пользователя, например: «Неверный или отозванный API-ключ.», «Модель недоступна для этого ключа или тарифа.», «Слишком много запросов, повторите позже.», «Исчерпана месячная квота запросов.», «Недостаточно средств на балансе для платформенных моделей.», «Адрес провайдера запрещён».
6.3. Ограничения частоты и квоты
Шлюз ограничивает число запросов в минуту на API-ключ, организацию и пользователя веб-консоли (лимиты определяются тарифом; для ключа можно задать меньший лимит), число одновременных потоковых ответов, объём текста, обрабатываемого распознаванием сущностей, и число неудачных попыток аутентификации. Месячная квота запросов организации определяется тарифом.
6.4. Разрешённые IP-адреса
Организация может задать перечень разрешённых IP-адресов и подсетей (IPv4 и IPv6, до 100 записей). Если перечень задан, шлюз отклоняет запросы с других адресов с сообщением «Запросы с этого IP-адреса запрещены.»; ограничение действует для всех обращений к шлюзу — с API-ключами и из веб-консоли (чат, песочница, проверка политик). Пустой перечень означает отсутствие ограничения. Адрес клиента определяется с учётом заголовков только доверенного обратного прокси инсталляции.
7. Провайдеры моделей
7.1. Подключения
| Вид подключения | Параметры |
|---|---|
| YandexGPT | API-ключ, идентификатор каталога; запросы отправляются с запретом журналирования данных на стороне провайдера |
| GigaChat | Ключ авторизации и область доступа (физические лица, ИП и юридические лица, корпоративный доступ); маркер доступа получается и обновляется автоматически; сертификат Russian Trusted Root CA встроен |
| OpenAI-совместимый API | Адрес модели, развёрнутой в инфраструктуре заказчика (например, на сервере вывода моделей), необязательный ключ, до 10 дополнительных заголовков, проверка сертификата TLS; для региона РФ требуется подтверждение администратора |
Учётные данные подключений хранятся в базе данных в зашифрованном виде. Проверка подключения и получение перечня моделей провайдера выполняются из веб-консоли.
7.2. Модели и маршруты
Модель, доступная клиентам, задаётся маршрутом: псевдоним модели (например, yandexgpt, gigachat-pro) связывается с подключением и идентификатором модели у провайдера. Платформенные модели (YandexGPT Pro и Lite, GigaChat Lite, Pro и Max) предоставляются всем организациям инсталляции по учётным данным правообладателя или оператора инсталляции и оплачиваются с баланса организации по числу токенов. Организация может подключить собственные модели; маршрут организации с тем же псевдонимом заменяет платформенный. Перечень моделей, доступных API-ключу, можно ограничить.
7.3. Ограничение адресов провайдеров
Шлюз и API управления не допускают подключения к узлам из встроенного списка иностранных сервисов искусственного интеллекта; список действует во всех режимах работы и может быть только расширен администратором инсталляции. Запрет проверяется при сохранении подключения и при каждом установлении соединения. Соединения с адресами частных сетей и по незащищённому протоколу HTTP запрещены, если администратор инсталляции явно не разрешил их для моделей в локальной сети.
8. Журнал запросов и аудит
8.1. Журнал запросов
По каждому запросу сохраняются только метаданные: время, организация, API-ключ или сотрудник, источник (API, чат, песочница), вид метода, провайдер и модель, признак потокового ответа, решение (пропущен, замаскирован, с предупреждением, заблокирован, ошибка), код ответа, число найденных значений по категориям и применённые действия, причины блокировки и предупреждений, версии применённых политик, сведения о вложениях, объём текста и число токенов, стоимость, задержки обработки, адрес и клиентское приложение отправителя. Содержимое запросов и ответов не сохраняется.
Срок хранения журнала задаётся организацией (от 7 дней до максимума тарифа, по умолчанию 90 дней); записи старше срока удаляются автоматически. Журнал просматривается в веб-консоли с фильтрами (решение, категория, источник, модель, пользователь, API-ключ) и выгружается в форматах CSV и JSONL (до 1 млн записей); выгрузка фиксируется в аудите. Сотрудник видит свои запросы, администраторы, ИБ-офицеры и аудиторы — запросы всей организации.
8.2. Расследования
Для найденных значений сохраняются ключевые хеши (HMAC), не позволяющие восстановить значение (настройка организации «Отпечатки для расследований», по умолчанию включена). ИБ-офицер может найти запросы, в которых встречалось заданное значение (например, номер паспорта), не раскрывая содержимого запросов.
8.3. Аудит действий
Изменения настроек организации, политик, ключей, участников, подключений и выгрузки журналов фиксируются в журнале аудита (кто, когда, что изменил). Срок хранения записей аудита — 1 095 дней; IP-адреса и сведения о клиентском приложении в записях аудита удаляются через 12 месяцев.
9. Оповещения и вебхуки
Правила оповещений срабатывают на заблокированные, замаскированные или отмеченные предупреждением запросы (с отбором по категориям), при превышении порога за скользящее окно, с интервалом подавления повторов. Оповещения отправляются по электронной почте выбранным сотрудникам и ролям и в вебхуки.
Вебхуки отправляют события request.blocked, request.warned, alert.fired, policy.updated в формате JSON или CEF (для систем мониторинга событий безопасности) с подписью HMAC-SHA256 в заголовке X-Aitech-Signature. Недоставленные события отправляются повторно (до 6 попыток); после 20 неудач подряд вебхук отключается, а владелец и администраторы получают письмо.
10. Веб-консоль
10.1. Пользователи и роли
Программный комплекс поддерживает несколько организаций в одной инсталляции; данные организаций изолированы. Пользователь регистрируется по адресу электронной почты с подтверждением, может состоять в нескольких организациях и переключаться между ними. Вход защищён паролем и, по выбору пользователя, двухфакторной аутентификацией (одноразовые коды TOTP и резервные коды); пользователь видит и может завершить свои активные сеансы.
| Роль | Права |
|---|---|
| Владелец | Все действия, включая оплату подписки, удаление организации, передачу прав владельца и назначение администраторов |
| Администратор | Всё, кроме оплаты подписки, удаления организации и передачи прав |
| ИБ-офицер | Политики, оповещения, вебхуки, аудит и расследования; просмотр подключений к моделям |
| Аудитор | Только просмотр: аудит, аналитика, политики, журнал запросов |
| Сотрудник | Чат, свои API-ключи и свои запросы |
Сотрудники приглашаются по электронной почте (ссылка действует 7 дней) и объединяются в группы, к которым применяются политики.
10.2. Разделы
| Раздел | Назначение |
|---|---|
| Обзор | Начальные шаги, личная статистика за 7 дней, сведения о подключении приложений; для администраторов — активность организации: запросы по дням, найденные данные, модели, активные пользователи |
| Чат | Работа сотрудника с моделями через шлюз с вложениями; просмотр замаскированного запроса («Что увидела модель»); история хранится только в браузере и выгружается в JSON |
| Песочница | Маскирование произвольного текста, восстановление и проверка с моделью |
| API-ключи | Создание личных и сервисных ключей с группой, лимитом запросов, сроком действия и перечнем моделей; отзыв ключей |
| Журнал запросов | Просмотр, фильтры и выгрузка журнала (раздел 8) |
| Расследования | Поиск запросов по значению (раздел 8.2) |
| Политики | Создание и редактирование политик, версии, шаблоны, итоговые действия по категориям с учётом всех применимых политик |
| Аудит | Журнал действий в организации |
| Оповещения | Правила оповещений и вебхуки |
| Участники | Участники, приглашения, группы, места тарифа, передача прав владельца |
| Провайдеры и модели | Платформенные модели, подключения к провайдерам, маршруты моделей |
| Оплата | Тариф, баланс, способы оплаты, платежи и счета |
| Настройки | Профиль и реквизиты организации; параметры шлюза (срок хранения журнала, отпечатки для расследований, чат и модель по умолчанию в чате, язык условных обозначений, псевдонимы в эмбеддингах, разрешённые IP-адреса); удаление организации; безопасность и профиль пользователя; выгрузка и удаление персональных данных пользователя |
Для администраторов платформы доступны разделы управления организациями (тариф, статус, баланс, кредитный лимит), счетами (отметка об оплате, аннулирование), возвратами, заявками с сайта и статистикой; вход в них требует двухфакторной аутентификации. Средства учёта прав использования описаны в документе «Описание технических средств активации, выдачи, распространения и управления лицензиями».
10.3. Язык интерфейса
Графический пользовательский интерфейс программного комплекса — сайт, веб-консоль и веб-чат — реализован на русском языке: все надписи, сообщения и письма пользователям имеют русскую редакцию, которая в режиме работы для Российской Федерации используется по умолчанию. Сообщения шлюза об ошибках выводятся на русском языке, если русский язык выбран для организации или пользователя. Пользователь может переключить интерфейс на английский язык.
11. Биллинг
Встроенный биллинг включается администратором инсталляции. Организация выбирает тариф («Пилот», «Старт», «Команда», «Бизнес», «Корпоративный»); тариф определяет число мест, месячную квоту запросов, срок хранения журнала, доступные функции (пользовательские шаблоны и словари, политики по расписанию, расследования, вебхуки, выгрузка для систем мониторинга событий безопасности, платформенные модели), число подключений к провайдерам и лимиты частоты запросов. Пробный период («Пилот») предоставляется один раз на владельца и ИНН организации. Повышение тарифа применяется сразу с перерасчётом, понижение — со следующего периода.
Оплата принимается через ЮKassa: банковской картой, через СБП, SberPay, а также по счёту для юридических лиц (счёт на оплату в PDF с реквизитами продавца; оплата отмечается администратором платформы). Кассовые чеки формируются через ЮKassa. По согласию плательщика сохранённая карта или SberPay используются для автопродления подписки; неуспешное списание повторяется, после чего действует льготный период. Использование платформенных моделей оплачивается с предоплаченного баланса организации по цене за миллион токенов. При исчерпании квоты, баланса или неактивной подписке шлюз отклоняет запросы с соответствующим сообщением.
12. Персональные данные пользователей и удаление данных
Пользователь может выгрузить свои персональные данные (файл JSON) и удалить учётную запись из веб-консоли; выгрузка выполняется в срок до 10 рабочих дней, удаление — до 30 дней. Владелец может удалить организацию: подписка отменяется, API-ключи и сохранённые карты отзываются, выставленные счета аннулируются, через 30 дней данные удаляются, платёжные документы хранятся 5 лет. Организации без активности в течение 180 дней удаляются автоматически после уведомления за 14 дней.
13. Режимы работы
Режим работы инсталляции задаётся при установке. В режиме для Российской Федерации расчёты ведутся в рублях через ЮKassa, язык по умолчанию — русский, регистрируются организации, зарегистрированные в Российской Федерации, доступны платформенные модели YandexGPT и GigaChat и заполнение реквизитов организации по ИНН.