Реестр моделей: проверяем статус без мифов

Короткий ответ: GigaChat есть в едином реестре российского программного обеспечения под записью № 20407 от 14 декабря 2023 года. Это не доказывает его включение в отдельный реестр доверенных моделей. Для YandexGPT и SberGPT такого подтверждения я не нашёл. Условия закупки смотрят отдельно.

Два реестра, которые нельзя смешивать

Слово «реестр» звучит убедительно, но само по себе ничего не говорит о назначении списка. В России действует единый реестр российского программного обеспечения: в нём фиксируют конкретные программные продукты, правообладателей, классы и дату регистрации. На его официальном сайте можно искать по названию и номеру записи, а также смотреть исключённые записи. Это проверяемая карточка продукта, а не универсальный пропуск в государственные системы и не сертификат на все возможные сценарии применения.

В публичных обсуждениях отдельно фигурировал проект правил о доверенных моделях для государственных систем и критической инфраструктуры. Проект, обсуждение требований и действующая запись в реестре — разные юридические состояния. Нельзя перенести термин из проекта в публикацию так, будто реестр уже действует и конкретная модель уже получила статус. Тут бюрократическая магия простая: пока нет решения и записи в официальной системе, есть только предположение. Постановление № 1236 тоже не подходит как основание: оно принято в 2013 году и регулирует реестр российского ПО, а не правила сертификации моделей для госконтрактов. Ещё одна частая ошибка — считать, что само слово «отечественный» автоматически отвечает на вопросы о совместимости, хранении данных или уровне защиты. Карточка реестра нужна для конкретной проверки состава российского ПО и прав на него. Она не заменяет архитектурный проект, модель угроз, договор и оценку последствий для данных. Если речь идёт о закрытой системе, решение принимают по её требованиям и применимым правилам, а не по рекламному ярлыку на сайте.

• Проверяйте название реестра
• Сверяйте номер и правообладателя
• Читайте статус записи

Что подтверждено по GigaChat и YandexGPT

По GigaChat подтверждается конкретный факт: в едином реестре российского ПО есть запись № 20407 от 14 декабря 2023 года. В карточке указано наименование GigaChat, правообладатель — ПАО «Сбербанк России», а также классы программного обеспечения. Это подтверждает регистрацию продукта в этом реестре. Оно само по себе не подтверждает прохождение отдельной проверки безопасности, соответствие условиям конкретной закупки или допуск к любому контуру критической инфраструктуры. Такие выводы требуют самостоятельного документа.

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

• GigaChat: запись № 20407
• YandexGPT: статус не подтверждён
• Проверяйте карточку продукта

Что известно о SberGPT и названиях линеек

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

У крупных поставщиков есть разные продукты, версии и сервисы. Запись на один продукт не распространяется автоматически на другие продукты того же правообладателя. И наоборот: если в документах фигурирует имя семейства, нужно выяснить, совпадает ли оно с названием программного обеспечения в записи и с тем, что реально поставляют заказчику. Версия, API, облачный сервис и лицензируемый продукт могут быть разными объектами. В реестре важна конкретная запись, а не похожесть брендов. Никакой прогноз «в ближайшие кварталы» эту проверку не заменит. Не подменяйте доказательство интервью, обзором или пересказом новости. Они полезны как указатель, куда смотреть, но первичным подтверждением остаются карточка, решение или нормативный акт. Если поставщик заявляет, что статус уже изменился, попросите ссылку и дату изменения. Я фиксирую обе: дата документа и дата проверки не всегда совпадают. Так читатель видит, на какой момент относится утверждение и может перепроверить его без догадок.

• Не путайте бренд и продукт
• Не выдавайте прогноз за решение
• Ищите запись по точному названию

Что запись означает для госзакупки

Запись в реестре российского ПО может иметь значение там, где закупочная документация и действующие правила требуют российского программного обеспечения. Но номер записи не гарантирует победу в тендере, не отменяет требования технического задания и не заменяет проверку прав на использование. Заказчик оценивает предложение по условиям конкретной процедуры: совпадает ли продукт, подходит ли функциональность, подтверждены ли лицензия, поставка, поддержка и другие условия. Статья 34 закона № 44-ФЗ регулирует цену контракта; она не устанавливает автоматический допуск модели в закупку. Прежняя ссылка статьи на эту норму была неверной.

Я бы проверял вопрос в таком порядке: читаю извещение и техническое задание, нахожу точное наименование нужного ПО, сверяю реестровую запись и правообладателя, проверяю лицензионные условия, а затем уточняю, есть ли в закупке специальные требования к размещению и обработке данных. Если условие неясно, его надо задать заказчику в установленном порядке до подачи заявки. Фраза «модель доверенная» без официальной нормы и документа не снимает неопределённость. Она только делает риск менее заметным — примерно как заклеить индикатор неисправности. Условия по российскому ПО в закупках зависят от применимых ограничений и исключений, состава объекта закупки и формулировок извещения. Поэтому одного ответа «продукт отечественный» недостаточно. Для сложной закупки полезно сохранить копию карточки на дату подготовки заявки и отдельный список требований, которым продукт должен соответствовать. Если участник предлагает эквивалент, нужно оценить его именно по критериям документации, а спорный пункт заранее уточнить у заказчика официальным запросом.

• Читайте документацию закупки
• Сверяйте точный продукт
• Проверяйте лицензию и условия

API: ключ, модель и границы интеграции

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

У Yandex Cloud документация описывает API для вариантов YandexGPT Lite и Pro; в запросе указываются ресурс модели и учётные данные с нужными правами. База знаний также отмечает, что модели можно подключать к 1С через HTTP API. Платформа 1С поддерживает HTTP(S)-запросы, так что техническая сторона такой интеграции опирается на штатные средства, хотя конкретная конфигурация требует разработки и проверки. Это полезная практическая информация из базы знаний, но она тоже ничего не говорит о закупочном статусе. До интеграции я фиксирую, какие данные отправляются поставщику, кто имеет право их видеть, где ведутся журналы и как долго сохраняются запросы. Персональные и коммерческие сведения нельзя отправлять в сервис только потому, что он удобен. Нужны правовое основание, договорные условия и согласованный сценарий. Технический ключ подтверждает возможность авторизовать API-запрос, но не право передавать любые сведения. Разведите секреты по окружениям, выдавайте минимальные полномочия и предусмотрите замену ключа без остановки всей системы. Для пилота используйте синтетические или обезличенные данные, проверьте журналирование и выясните, можно ли отключить запись запросов. В документах интеграции укажите владельца учётной записи, порядок отзыва доступа и процедуру на случай утечки секрета.

• Выдавайте ключи с ограниченным доступом
• Проверяйте права и тариф
• Согласуйте состав передаваемых данных

Мой чек-лист перед заявлением о статусе

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

Если условный заказчик ООО «Азимут-Строй» попросит меня подтвердить пригодность модели для закупки, я начну с его документации, а не с рекламной страницы поставщика. Затем сопоставлю требуемую функцию с карточкой продукта, проверю лицензию, место и режим обработки данных и зафиксирую, кто отвечает за поддержку. Для интеграции отдельно проведу пилот на обезличенных данных и проверю журналирование, права доступа и поведение при отказе API. Это не «сертификация за две недели»: срок и результат нельзя обещать, пока неизвестны требования и процедура. Сначала документы, потом обещания. В итоговой записке полезно разделить факты, неизвестное и решение заказчика. Например: «карточка GigaChat найдена; отдельное подтверждение доверенного статуса не установлено; применимость к этой закупке определяется документацией». Такой вывод честнее универсального «разрешено» и помогает ответственной стороне принять решение. Обновляйте записку при смене версии, договора или закупочных условий. Утверждение, которое было верным для одной поставки, не становится бессрочным разрешением для следующей.

• Найдите первичную карточку
• Сверьте объект и правообладателя
• Отделите проект от действующего решения
• Проверьте закупочные и технические условия

Частые вопросы