Как SaaS‑стартапы влетают в бюрократию: разбор типовых ошибок при попытке попасть в реестр Минцифры

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

Почему регистрация в реестре — не только формальность

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

Какие ошибки допускают при регистрации

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

Переведите сайт на российский домен, например,.ru или домен 2‑го уровня, лучше регистрировать его у российского регистратора. И обязательно укажите владельцем домена компанию, а не генерального директора. Оформите контактные данные компании, ее юридический адрес и реквизиты на сайте, а также сохраните скриншоты/реестровые данные регистрации.

Нет ЦОД или нет договора с ЦОД. Еще недавно размещение информации на базе зарубежного провайдера считалось нормой. Но сейчас Минцифры ждут договора именно с российским дата‑центром. Ведь так мы можем избежать утечки персональных данных и больших штрафов за это.

Вся инфраструктура компании должна быть размещена на территории России. Если не заключен договор с российским ЦОД, но при этом нужно попасть в реестр, то готовьтесь в срочном порядке переносить сервера.

Опенсорс и западные LLM в составе продукта. Когда дело доходит до технического аудита, то внезапно вылезают высокорисковые компоненты под лицензиями AGPL, GPL или, например, интеграция зарубежных LLM (OpenAI и пр.) без коммерческих/локальных альтернатив и без оценки рисков. Использование иностранных лицензии и внешних сервисов могут препятствовать признанию ПО «отечественным» или вообще создать риски утечки и зависимости от зарубежных поставщиков.

Исправить это поможет поведение картирования зависимостей (SBOM — список компонентов). Также стоит проверить лицензии и их совместимость с моделью распространения продукта. По высокорисковым компонентам подготовьте план замены/перелицензирования или получения коммерческой лицензии. В случае с LLM, рассмотрите локальные российские модели или self‑host решения и оформите договоры на их использование.

Практический чек‑лист перед подачей в реестр

Правообладание:

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

Домен и сайт:

• домен в зоне РФ, зарегистрирован на компанию (не на физлицо);
• настройка WHOIS/реестра и контактных данных компании на сайте.

Инфраструктура:

• договор с российским ЦОД или подтверждение размещения серверов в РФ;
• схема архитектуры (где хранятся данные, как происходит резервирование и бэкап).

Компоненты и лицензии:

• SBOM — список всех зависимостей и лицензий;
• планы по замене/перелицензированию компонентов под конфликтными лицензиями.

Документация:

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

Юридические и кадровые вопросы:

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

Что делать, если вы уже получили отказ

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

Вывод