С 1 сентября 2026 года владельцы доменов в зонах .ru, .рф и .su обязаны подтвердить личность через «Госуслуги». Нерезиденты — не исключение. Рассказываем, как это сделать и что делать, если связи с Россией нет.
С 1 сентября 2026 года вступает в силу Федеральный закон № 569-ФЗ. Он обязывает всех владельцев доменов в зонах .ru, .рф и .su подтверждать личность через портал «Госуслуги» (ЕСИА). Без этого не получится продлить домен, передать его другому владельцу, сменить регистратора или даже просто изменить NS-записи.
Нерезиденты подпадают под это правило. К счастью, у них есть возможность пройти идентификацию, хотя сделать это чуть сложнее. Рассказываем по шагам, как нерезиденту зарегистрироваться на «Госуслугах», подтвердить данные и что делать, если нормальной связи с Россией нет.
Зачем приняли этот закон
Раньше зарегистрировать домен в зонах .ru или .рф можно было почти анонимно — технически требования к верификации были всегда, но их было легко обойти, а на подтверждение данных давалось так много времени, что злоумышленники успевали совершить мошеннические действия и скрыться.
Масштаб проблемы такой: только за 2025 год в России заблокировали больше 60 тысяч вредоносных доменов.
Новый закон (569-ФЗ) закрывает эту схему. Теперь домен будет привязан к подтвержденной личности через «Госуслуги». Анонимность в национальных зонах заканчивается. А значит, мошенникам станет сложнее прятаться, а добросовестным владельцам — спокойнее: доменное пространство станет прозрачнее и безопаснее для всех.
Как нерезиденту пройти всю процедуру
Для управления доменом после 1 сентября нужна именно подтвержденная учетная запись на «Госуслугах». Упрощенная (по телефону или почте) не подойдет.
Часть 1. Регистрируемся на «Госуслугах»
Этап 1. Указываем имя и контакты.На странице регистрации выберите «Другой способ регистрации». Укажите:
фамилию и имя;
электронную почту;
российский номер телефона (если есть).
Подтвердите почту — перейдите по ссылке из письма. Если указали телефон, придет СМС с кодом. Придумайте пароль.
Этап 2. Указываем СНИЛС и паспорт. Вам потребуется СНИЛС. Если его нет — оформите. Для этого нужно прийти в отделение Социального фонда или МФЦ. С собой: паспорт и его нотариально заверенный перевод на русский.
Важно: СНИЛС должен быть оформлен на тот паспорт, который действует сейчас.
После получения СНИЛС зайдите в личный кабинет на «Госуслугах» и внесите данные паспорта и СНИЛС.
Этап 3. Подтверждаем личность. Здесь два варианта. Первый — лично прийти в центр обслуживания. С собой: паспорт, нотариально заверенный перевод паспорта, адрес электронной почты. Второй — онлайн через банк. Этот способ подойдет, если у вас есть счет в российском банке и российский номер телефона. Главное, чтобы в банке вы открывали счет по тому же паспорту.
Для подтверждения личности любым способом нужен СНИЛС, который был оформлен больше 14 дней назад. После подтверждения вы получаете полный доступ ко всем услугам портала.
Часть 2. Проходим идентификацию у регистратора доменов
Когда у вас есть подтвержденная учетная запись на «Госуслугах», нужно привязать ее к вашему аккаунту у регистратора доменов.
Сейчас идентификацию через «Госуслуги» поддерживают не все регистраторы. Например, у Рег.ру это уже работает. Если ваш регистратор еще не подключился — можно перенести домены к тому, у кого интеграция есть.
Этап 1. Зайдите в личный кабинет регистратора, откройте раздел «Настройки».
Этап 2. Нажмите кнопку «Заполнить через Госуслуги» и войдите в свой аккаунт на портале.
Этап 3. Разрешите передачу данных. Через несколько дней (обычно до трех рабочих дней) вам придет письмо на почту, указанную на «Госуслугах», с подтверждением.
После этого ваш профиль у регистратора будет подтвержден, и вы сможете спокойно управлять доменами.
Что делать, если нет СНИЛС, банковского счета и возможности приехать в Россию
Вся описанная выше процедура требует либо личного присутствия в России, либо счета в российском банке, либо СНИЛС. А если у вас ничего этого нет?
В таком случае можно воспользоваться механизмом доверенного администратора. Например, Рег.ру с 1 июня 2026 года запускает услугу «Доверенный администратор»: подключить можно в личном кабинете. Сервис помогает администраторам-нерезидентам РФ сохранить свои домены и контроль над ними.
Рассказываем, как заводы отказались от собственных паровых машин в пользу электросетей — и почему компании сейчас делают то же самое с серверами и облаками.
Примерно 200 лет назад у каждого крупного производства была собственная паровая машина. Громоздкая, дорогая, требовавшая топлива, инженеров и постоянного ухода. Примерно 20 лет назад у многих компаний была своя серверная — со стойками, гулом кондиционеров и сисадмином, который знал, где лежит запасной блок питания.
История развития энергии и ИТ удивительно похожа. Сначала все строят у себя. Потом появляются те, кто делает это лучше, дешевле и в одном месте. А остальные просто подключаются и платят за использование.
И вот ирония: в России ЦОДам предложили строить собственные электростанции. Минцифры и Минэнерго разрабатывают схему, по которой дата-центры в столичном регионе в ближайшие 5–7 лет должны будут сами обеспечивать себя энергией. Получается, история идет по спирали. Сначала были свои паровые машины, потом — центральные электростанции и сети. А теперь крупные потребители снова вынуждены думать о собственной генерации. Давайте посмотрим, как это работало в промышленности — и как повторяется в технологиях.
До: паровые машины в промышленности и серверные комнаты в ИТ
Промышленность. Первые паровые машины появились еще в конце XVII века, но по-настоящему менять мир они начали после разработок Джеймса Уатта во второй половине XVIII века. Он сделал паровую машину в пять раз мощнее и приспособил ее для вращения станков и мельниц.
Это стало энергетической основой промышленной революции. Заводы больше не зависели от рек или ветра — их можно было строить где угодно. К 1810 году в одной только Англии работало около пяти тысяч паровых машин, а через 15 лет их число выросло втрое.
Паровая машина Уатта
Но была и обратная сторона. Паровая машина занимала много места, требовала угля и постоянного присмотра инженеров. Расширить производство означало купить еще одну машину, построить для нее помещение, нанять дополнительных людей. Это было дорого и медленно.
ИТ-сфера. До появления облачных сервисов компании поступали похожим образом: покупали собственные серверы и размещали их прямо в офисе. Часто — с большим запасом мощности, потому что «вдруг пригодится». В среднем такое железо работало меньше чем наполовину своих возможностей, но деваться было некуда, потому что других вариантов оперативно расширить мощности просто не существовало.
Для обслуживания нужен был хотя бы один системный администратор, а лучше команда. Серверная требовала кондиционирования, защиты от пыли, бесперебойного питания. Когда компании становилось тесно — покупали новый сервер, искали место, ждали доставки и настройки.
Так выглядела «серверная» в начале нулевых
Масштабирование было возможным, но медленным и дорогим. Чем больше становился бизнес, тем больше ресурсов уходило на то, чтобы просто поддерживать железо в рабочем состоянии, а не на развитие.
После: централизованные электростанции и серверы в облаке
Промышленность. Всё изменилось в 1882 году, когда Томас Эдисон построил первую централизованную электростанцию на Манхэттене. Она вырабатывала постоянный ток и питала целый район Нижнего Манхэттена. Энергия перестала быть личным делом каждой фабрики — ее можно было производить в одном месте и распределять между многими.
Эскиз электростанции Эдисона
Правда, постоянный ток не передавался на большие расстояния. Следующий шаг сделали Джордж Вестингауз и Никола Тесла, внедрив переменный ток. Его можно было передавать на километры, подключая всё больше потребителей без потери эффективности.
Для заводов это означало простую вещь: больше не нужно покупать и обслуживать собственные паровые машины. Достаточно подключиться к сети и платить только за то, сколько энергии реально использовали. Хотите расшириться — включаете дополнительные станки, не строя новых котельных.
ИТ-сфера. В ИТ похожая революция произошла с появлением облачных сервисов. Amazon, Google, Microsoft первыми построили огромные центры обработки данных. Гораздо больше и эффективнее, чем любая серверная, которую большинство компаний могло бы создать самостоятельно.
Теперь бизнесу не нужно покупать серверы, держать штат инженеров и сталкиваться с трудностями при масштабировании. Достаточно выбрать нужную конфигурацию в облаке — и платить по факту использования, как за электричество.
Хотите больше мощности — добавили пару щелчков мыши. Нужно меньше — убавили. Никаких ожиданий доставки, никаких поисков лишнего места в стойке.
Вид одного из ЦОДов Рег.облака
Кроме того, облачные провайдеры предлагают высокий уровень безопасности, регулярные обновления оборудования и программного обеспечения — то, что собственными силами обеспечить и сложно, и дорого.
Мировой рынок облачных услуг продолжает расти: по итогам 2025 года затраты на глобальном рынке облачных инфраструктур достигли $419 млрд. Компании переходят в облака, чтобы оптимизировать ИТ-расходы и быстрее запускать новые проекты. Особенно активно это происходит в сфере искусственного интеллекта, где потребность в вычислительных мощностях растет очень быстро.
Выводы
Облачные технологии — это своего рода электричество XXI века. Точно так же, как появление электростанций когда-то избавило заводы от необходимости иметь собственные паровые машины, облака избавляют компании от собственных серверных.
Это не значит, что свой сервер плох. У него есть свои плюсы, особенно для очень специфических задач. Но для большинства бизнесов облако — просто более удобный, гибкий и предсказуемый по затратам вариант.
Не нужно покупать железо, нанимать сисадминов, думать о кондиционерах и резервном питании. Нужно просто взять ровно столько ресурсов, сколько требуется сейчас, и заплатить только за них, как, например, можно сделать в Рег.облаке.
Ваш 1С:Документооборот хранит персональные данные не только в базе. Они еще в файлах-вложениях, в поисковом индексе и в журнале регистрации действий. Обычное облако не дает защиты, а защищенное — лишь фундамент. Разбираемся, кто за что отвечает в этой цепочке и на чем можно сэкономить без риска.
Сегодня рассмотрим ситуацию, в которой оказываются многие, когда переносят 1С:Документооборот в облако. Кажется: взял виртуальный сервер, поставил туда 1С — и всё работает. Но есть один нюанс, про который узнаешь либо от ИТ-специалиста, либо от проверяющих органов.
А нюанс в том, что у людей в документах есть персональные данные. И они могут быть не только в самой базе, а еще в файлах-вложениях, в поисковом индексе и в журнале, где записано, кто что делал.
Тяжелая артиллерия: как не запутаться в 152, 242, 1119 и 21
Многие думают, что вопрос с персональными данными регулируется одним-единственным законом — 152-ФЗ. На самом деле это целая цепочка из нескольких документов, и проходить ее нужно последовательно. Вот как это выглядит на практике.
Шаг 1.152-ФЗ — главный закон о персональных данных. Он определяет, кто такой оператор (то есть вы, если храните и обрабатываете ПДн), какие у вас обязанности и что будет за их несоблюдение. Без понимания этого документа остальные не имеют смысла.
Шаг 2. 242-ФЗ — поправка про локализацию. Согласно поправке, собирать, хранить и обрабатывать персональные данные граждан России нужно на серверах, которые физически находятся в России. Это как раз то, что закрывает обычный российский ЦОД. Но только это — и ничего больше.
Шаг 3.Постановление Правительства № 1119 — уровни защищенности. Здесь начинается самое интересное. Система с ПДн получает один из четырех уровней защищенности:
УЗ-4 — низший (например, только ФИО и телефоны, небольшое количество людей);
УЗ-3 — средний;
УЗ-2 — высокий;
УЗ-1 — высший (спецкатегории данных, большой объем, высокие риски).
Вы сами определяете уровень защищенности специальным документом: он зависит от трех вещей: какие именно данные вы обрабатываете (просто ФИО или еще и данные паспортов, а может, и медицинские данные), сколько людей затронуто и какие угрозы для вас актуальны.
Шаг 4.Приказ ФСТЭК № 21 — что конкретно делать. Под каждый уровень защищенности в этом приказе прописаны конкретные меры. Например, для УЗ-4 — одни требования, для УЗ-2 — другие: обязательное шифрование, сертифицированные средства защиты, отдельный контроль доступа и так далее.
Самое важное про порядок действий: нельзя пропустить ни один из шагов. Сначала вы определяете, какие данные у вас обрабатываются и где. Затем разрабатываете модель угроз — смотрите, что именно может пойти не так: кто и как может получить доступ, какие каналы утечки существуют. И только на основании трех вещей — типов персональных данных, актуальных угроз и количества субъектов — определяете и актом закрепляете уровень защищенности. Далее под этот уровень реализуете конкретные меры из приказа № 21.
Отдельно про аттестацию. Аттестация обязательна для ГИС (Государственная информационная система) и для тех систем, где это прямо установлено нормативно или условиями взаимодействия с государственной системой. Для обычной информационной системы персональных данных аттестация, как правило, не обязательна, а проводится добровольно или по специальному требованию.
Что это значит на практике? Если вы выбираете не свое железо в собственном ЦОДе, а облачную модель — то аттестованное облако становится практически единственным способом законно работать с персональными данными. Для обычного публичного облака или хостинга вы никогда не сможете обеспечить требования по защите на уровне ЦОДа, гипервизоров и виртуализации — провайдер просто не предоставит для этого нужных средств и документального подтверждения.
Аттестованное облако — это готовый инфраструктурный слой, который уже прошел проверку. Вы платите — и вам не нужно самим всё это проектировать и тратиться на строительство с нуля. Удобно, но важно понимать: аттестация закрывает только фундамент, а не весь дом целиком.
Матрешка ответственности: кто за что в ответе (спойлер: провайдер меньше, чем вы думаете)
Соответствие 152-ФЗ — это всегда совместная работа. Разложим, кто за что отвечает.
Инфраструктура — зона ответственности провайдера защищенного облака. Провайдер должен обеспечить физическую защиту ЦОДа, защиту среды виртуализации и гипервизора, сегментацию и изоляцию сетей, межсетевой экран на периметре, обнаружение вторжений, защиту каналов администрирования, а главное — использовать средства защиты, сертифицированные ФСТЭК и ФСБ. Это то, чего у обычного облака нет, а у защищенного — есть из коробки.
Но подходы у провайдеров различаются. Часто защищенное облако закрывает межсетевой экран и систему обнаружения вторжений (МЭ+СОВ) только для своей управляющей инфраструктуры — клиенту приходится разворачивать и обслуживать свои МЭ+СОВ самостоятельно. Есть и другой подход, например, у Рег.облака: когда провайдер берет на себя и эту настройку, давая клиенту готовый периметр. При выборе стоит обращать на это внимание.
Гостевая ОС виртуальной машины — ваша зона ответственности. У вас есть два пути: либо использовать сертифицированную операционную систему, либо установить на обычную ОС сертифицированное средство защиты от несанкционированного доступа (СЗИ). В любом случае также потребуются антивирус, своевременные обновления, включенная регистрация событий и ограничения на запуск программ.
Приложение 1С:Документооборот — ваша зона ответственности. Внутри самой 1С вы настраиваете роли и разграничение прав, ограничение доступа на уровне записей, парольную политику, защищаете тома хранения файлов (про них часто забывают), контролируете выгрузки, печать и обмен, а при необходимости — включаете шифрование.
Организационный слой — ваша зона ответственности. Нужно разработать модель угроз, актом определить уровень защищенности (УЗ), утвердить политику обработки персональных данных, собрать согласия от сотрудников и клиентов, назначить ответственного за обработку ПДн, зарегистрироваться в реестре операторов Роскомнадзора, подготовить регламент реагирования на инциденты и подписать с провайдером договор-поручение по статье 6 №152-ФЗ, а также регулярно проводить оценку эффективности принятых мер защиты — потому что мало внедрить, надо еще доказать, что это работает.
Так, обычный облачный сервер не покрывает даже первый слой: средства защиты не сертифицированы, а договор-поручение провайдер с вами не заключит — потому что необходимые меры защиты не предусмотрены, и такое облако по закону просто не подходит для хранения персональных данных. Защищенное облако охватывает первый слой целиком и оформляет поручение. Причем, например, Рег.облако закрывает самый сложный с точки зрения сертификации и требований слой. Это заметно упрощает подготовку проектной документации: вы можете делать отсылки к уже реализованным мерам и процессам защиты. Но слои со второго по четвертый в любом случае остаются за вами.
Чек-лист: какое облако выбрать под 1С:Документооборот
Пролистайте пункты. Если хотя бы на один ответили «да» — вам нужно защищенное облако.
сканы паспортов контрагентов (физлиц) или доверенности с ФИО.
✅ Если да — вы оператор ПДн. Обычное облако не подходит.
2. Важна ли защита от атак и взломов?
✅ Если да — защищенное облако дает сертифицированные средства защиты. У обычного облака их нет.
3. Планируете ли рост?
Например, завтра может появиться кадровый учет или договоры с физлицами. Тогда закон потребует защиту задним числом.
✅ Если да — лучше заложить защищенное облако сразу.
Когда можно остаться на обычном облаке или свом сервере? Таких случаев мало, но они есть. Например, если в системе абсолютно нет персональных данных (только юрлица, ИНН/КПП компаний, счета без ФИО). Вы готовы должны быть готовы взять на себя полную настройку ОС, СЗИ, МЭ+СОВ и обслуживание, а бюджет критически ограничен.
Но даже если рассматривать вопрос шире, без привязки к 152-ФЗ: защищенное облако объективно безопаснее. А такие важные для работы организации системы, как 1С:Документооборот, лучше в любом случае размещать в надежном месте — независимо от того, есть там формально ПДн или нет.
Итог: с чего начать, чтобы не получить штраф
Обычный облачный сервер решает только один вопрос — локализацию данных в России. Это необходимо, но недостаточно. 1С:Документооборот почти всегда работает с персональными данными, а они находятся не только в базе, но и в файлах, поисковом индексе и журналах.
Защищенное облако покрывает инфраструктурный слой и оформляет договор-поручение, а всё остальное — настройку ОС, самой 1С и документы — остается за вами. И это не вина провайдера, просто так прописано в законе. Самые дорогие ошибки случаются не там, где забыли включить шифрование, а там, где неправильно поняли, кто за что отвечает, и какой уровень защищенности вам нужен. С этого стоит начинать.
Что касается защищенного Рег.облака — оно как раз размещено в изолированном сегменте дата-центра, имеет аттестат по высшему уровню УЗ-1 и соответствует приказам ФСТЭК № 21. Защита построена на сертифицированных ФСТЭК и ФСБ средствах, с оператором подписывается договор-поручение.
А как у вас организована работа с персональными данными в 1С? На что обращали внимание в первую очередь?
Если у вас есть домен в зоне .ru, .рф или .su — готовьтесь: с 1 сентября 2026 года без «Госуслуг» не обойтись. Рассказываем, что случилось, кого это коснется и почему не стоит ждать до последнего дня.
Важный момент для тех, у кого есть сайт в зоне .ru, .рф или .su. Обратите внимание на 1 сентября 2026 года — именно с этой даты старый добрый способ «заполнил форму, оплатил, забыл» перестанет действовать. Расскажем, что изменилось, как подготовиться и что важно сделать уже сейчас. Обо всём по порядку.
С 1 сентября 2026 вступает в силу Федеральный закон № 569-ФЗ. Теперь если вам нужно зарегистрировать, продлить, передать домен или поменять NS-серверы — нужно подтверждать личность через портал «Госуслуги».
И да, это касается всех без исключения: обычных пользователей, ИП, юрлиц (как российских, так и зарубежных), нерезидентов. Важный нюанс: подойдет только подтвержденная учетная запись.
Что за закон
Раньше отдельного закона, который привязывал домен к реальному человеку, не было. В результате анонимность владельца — обычная история для Рунета. И этой анонимностью активно пользовались те, кто разворачивает фишинговые сайты и мошеннические схемы под видом нормальных сервисов.
Цифры говорят сами за себя. По итогам 2025 года Координационный центр .RU/.РФ заблокировал почти 61 тысячу вредоносных доменов в национальных зонах. Фишинг остается главной головной болью: его доля в жалобах регистраторам снизилась с 82,6 % в 2024 году до 67,9 % в 2025-м, но в штуках это всё равно огромный поток.
Идея 569-ФЗ — перекрыть удобный для злоумышленников путь: когда домен регистрируют на анонимные данные, его блокируют, а он создает новый — и по новой. Интеграция с ЕСИА связывает домен с подтвержденной личностью администратора. Анонимной регистрации в национальных зонах в прежнем виде больше не будет.
Как это будет выглядеть в реальной жизни
Пытаетесь зарегистрировать или продлить домен. Система вежливо, но настойчиво просит: «Авторизуйтесь через “Госуслуги” прямо в личном кабинете регистратора». Вы даете согласие — и портал передает регистратору ваши данные: ФИО, дату рождения, СНИЛС/ИНН, контакты.
Регистратор не получает ваш пароль от «Госуслуг» и в вашу учетную запись не заглядывает. Только то, что надо для подтверждения.
Физические лица и ИП могут пройти идентификацию можно уже сейчас. Например, в Рег.ру (один из немногих регистраторов, у кого уже готова интеграция с «Госуслугами») процедура для физлиц и ИП доступна прямо в личном кабинете. Вот как это выглядит по шагам:
Шаг 1. Заходите в личный кабинет, в правом верхнем углу находите раздел «Настройки».
Шаг 2. Нажимаете кнопку «Заполнить через Госуслуги» и авторизуетесь на портале.
Шаг 3. Разрешаете передачу данных. Всё. После проверки на почту (ту, что привязана к «Госуслугам») придет уведомление с результатом. Обычно проверка занимает до трех рабочих дней, но быстрее, если специалисты не перегружены.
Три типичные ситуации, которые лучше проверить заранее
А теперь к самому интересному — к тому, на что действительно стоит обратить внимание уже сегодня. Давайте посмотрим на три самые популярные ситуации, которые после 1 сентября 2026 года могут потребовать значительно больше вашего внимания, чем обычно. И что лучше проверить заранее, пока есть время.
Домен на бывшем сотруднике. Ситуация: сисадмин в 2015 году зарегистрировал корпоративный домен на себя, а в 2022 уволился. Домен с тех пор просто продлевают — всё работает, все привыкли.
Но с 1 сентября продлить такой домен без подтвержденной личности того самого сисадмина уже не выйдет. Сменить администратора (то есть передать домен компании) — тоже. Старые правила еще действуют, поэтому решать вопрос нужно сейчас, пока есть время.
Что делать: найти бывшего сотрудника и прямо сейчас оформить смену администратора домена на юридическое лицо или на действующего сотрудника с подтвержденным аккаунтом на «Госуслугах». Если контакт потерян — проконсультироваться с регистратором: возможно, потребуется предоставить документы, подтверждающие право на домен.
Корпоративный домен на физическом лице. Иногда домен компании оформлен не на юрлицо, а на конкретного человека — основателя, директора или маркетолога. После 1 сентября идентификацию проходит именно этот человек. Если он не может или не хочет подтверждать учетную запись на «Госуслугах», то продлить домен не получится.
Что делать: если этот человек готов сотрудничать — пусть подтвердит свою личность через «Госуслуги» у регистратора. Если нет — лучше заранее передать домен на юрлицо или на другого человека, у которого с идентификацией проблем не будет.
Домен, срок которого истекает в сентябре–декабре 2026 года. Если регистрация заканчивается в первые недели или месяцы после вступления новых правил, а подтвержденной личности у администратора домена нет — продлить не получится. Домен сначала переходит в статус ожидания продления, а затем становится доступным любому желающему. Забрать его сможет любой, кто первый заметит и успеет оформить.
Что делать: не ждать последнего дня и уже сейчас проверить, на кого оформлен домен. Если на физлицо — убедиться, что у человека есть подтвержденный аккаунт на «Госуслугах» и он готов пройти идентификацию у регистратора до сентября. Оптимальный вариант — заранее передать домен на нужное лицо или компанию, пока это ещё можно сделать по старым правилам.
Чек-лист: что проверить прямо сейчас (не откладывая на завтра)
Времени до сентября достаточно, но если отложить всё на последний месяц, есть риск что-то упустить. Вот простой план:
Составьте список всех своих доменов в зонах .ru/.рф/.su. Сюда же полезно добавить домены, которые оформлены на компанию, если вы за нее отвечаете. Даже забытые домены имеют обыкновение напоминать о себе в самый неподходящий момент (например, когда на них вдруг оказывается привязан важный сервис). Что сделать: зайдите в личные кабинеты всех регистраторов, где у вас когда-либо были домены, и выпишите их.
Посмотрите, кто числится администратором каждого домена. Иногда оказывается, что домен записан на сотрудника, который давно уволился, или на партнера, с которым вы больше не работаете. Что сделать: посмотреть данные. Эта информация обычно доступна в личном кабинете регистратора в карточке домена или в выписке WHOIS.
Проверьте, есть ли у администратора подтвержденная учетная запись на «Госуслугах». Если у администратора учетная запись не подтверждена — сейчас самое время этим заняться, пока спешки. Что сделать: зайти на «Госуслуги» и убедиться, что профиль подтвержден.
Посмотрите даты окончания регистрации. Особое внимание — доменам, срок которых истекает в сентябре–декабре 2026 года. Они попадают под удар в первую очередь: новые правила уже действуют, а старым порядком продлиться не выйдет, если не пройти идентификацию. Что сделать: отметьте в календаре напоминание за 1–2 месяца до истечения срока, чтобы спокойно разобраться с идентификацией (или продлить домен заранее по старым правилам, если успеете до сентября).
Найдите домены, оформленные на людей, с которыми вы больше не работаете. Бывшие сотрудники, фрилансеры, знакомые знакомых — если домен записан на них, после 1 сентября без их личного участия ничего не сделать. Что сделать: заранее, пока действуют старые правила, оформите смену администратора на компанию или на другого человека с подтвержденным аккаунтом.
На сегодня готовую интеграцию с «Госуслугами» имеют всего несколько регистраторов. Рег.ру — один из них. Для физических лиц и ИП идентификация уже работает в личном кабинете. Выглядит это просто: авторизовались через «Госуслуги» — данные подтянулись сами. Ничего вручную заполнять и сканы отправлять не нужно.
Если ваш регистратор пока не подключил интеграцию — переживать раньше времени не стоит. У вас есть два варианта. Первый — подождать, когда регистратор завершит настройку. Второй — перенести домены к тому регистратору, у которого функционал уже работает. Перенос домена между регистраторами процедура стандартная и обычно не занимает много времени.
Что, если бы рыцари не ходили в крестовые походы, а листали ленту, а мастера не стояли на площади, а запускали таргет? Мы решили пофантазировать и представить, как могли бы продвигать бизнес средневековые ремесленники — кузнец, портниха и аптекарь.
Кузнец Гюнтер — сайт «Меч за 3 дня»
Гюнтер понял: кричать «КУЮ МЕЧИ!» на базаре больше не работает. Все уважающие себя рыцари сидят в интернете и ищут «лучший меч с доставкой». Поэтому Гюнтер заказал себе сайт под ключ с формой заказа оружия, кнопкой «Рассчитать кольчугу» и капчей «Нажми на все наковальни, где есть огонь».
На сайте — портфолио мечей, видео с краш-тестами (против щита, против дубовой двери, против соседского петуха) и отзывы от графов: «Меч острый, как язык моей тещи. 10/10».
Портниха Эльза — рассылка «Как подобрать платье, чтобы не сожгли на костре»
Эльза шила платья для всех — от дочек мясника до баронесс. Но чтобы не сидеть неделями без заказов, она собрала почтовую базу клиенток и запустила рассылку. Тема письма: «Лен, шерсть или крапива? Что в моде этим летом».
Она делилась секретами:
как скрыть карманы под корсетом,
какой воротник делает шею лебединой,
почему зеленый бархат — к удаче, а красный — к приглашению на турнир.
А в конце каждого письма — ссылка: «Записаться на примерку». Клиентки обожали ее, и даже инквизиция не придиралась.
Аптекарь Гуго — блог «Лечение без ампутации»
Гуго торговал настойками, припарками и порошками от хворей. Но конкуренты-шарлатаны продавали «корешки от всего» и уводили клиентов. Тогда Гуго стал вести блог: «Как не умереть зимой», «Пять трав, которые лучше чеснока», «Чумной бубон? Не паникуем!».
Он объяснял, что кровопускание — это не модно, а просто опасно. Учил различать простуду от порчи. И даже выложил бесплатный гайд «Источник чистой воды: где копать».
Блог приносил ему доверие и очередь из пациентов, которые приходили уже с распечатанным постом.
И главное. Все эти сайты, блоги и рассылки реально сделать за вечер, даже если вы кузнец, а не программист. Если совсем не хочется разбираться — закажите Рег.решение «Сайт под ключ»: вам сделают всё от домена до кнопки «Заказать». Если любите покрутить руками — берите Конструктор сайтов Рег.ру, там шаблоны под любой бизнес. А для рассылок как у портнихи Эльзы — «Почта под ключ»: ящик с вашим именем, защита от спама и резервное копирование.
В чем разница между Free Trial, бесплатным VPS и полноценным Free Tier.
У многих стартаперов, разработчиков и энтузиастов рано или поздно возникает задача: нужно запустить сервис, потестировать обновление или поставить бота, который не падает, когда вы выключаете домашний ноутбук.
Платить ради эксперимента — вроде не жалко, но и как-то неправильно. Особенно когда денег пока нет, а идею проверить хочется. Хорошо бы найти бесплатный вариант. На рынке действительно есть разные предложения. Давайте разберемся, какие бывают бесплатные облачные программы и кому и для чего они подходят.
Ниже — краткий ликбез и три живых сценария с примерами.
Какие бесплатные облачные программы бывают (и почему большинство — не вариант)
Если коротко, то есть три модели. И две из них для серьезных проектов не подходят.
Первый вариант: Free Trial (пробный период). Вам дают доступ на 7–60 дней, чтобы вы попробовали облако. Потом — либо плати, либо прощай. Для проверки гипотезы на пару недель — ок. Для сервиса, который должен жить долго — не годится.
Второй вариант: тестовый период VPS (virtual private server, виртуальный выделенный сервер). Звучит круто. Но обычно это отдельный, изолированный продукт на старом железе. А главное — когда ваш проект подрастет, вы не сможете просто увеличить мощность. Придется мигрировать на другой сервер с переносом всех данных.
Третий вариант: полнофункциональный Free Tier. Это когда вам дают полноценный облачный сервер на постоянной основе, но при этом он является частью большой экосистемы. То есть вы можете пользоваться всеми плюшками платформы, а когда проект вырастет — бесшовно переключиться на более мощную конфигурацию и начать платить.
Именно такой вариант недавно запустил Рег.облако. У Free Tier Рег.облака конфигурация не застывает. Если вам мало базовых ресурсов — можно обратиться в техподдержку и попросить увеличить их бесплатно.
Теперь разберем задачи, в которых бесплатное облако реально выручает.
Запуск своего стартапа — когда денег нет, а идея есть
Самая больная тема. Вы придумали сервис, написали код, а тратить деньги на сервер до первых клиентов — страшно. Бесплатный Free Tier здесь — спасение.
Вы спокойно разворачиваете бэкенд, базу данных, вешаете на него тестовый домен и даете доступ первым пользователям. Причем это не какая-то «песочница для игрушек», а полноценный сервер. А главное — когда сервис «выстрелит», вы не будете в панике переезжать посреди ночи. Вы просто в пару кликов увеличиваете мощность, и всё продолжает работать. Клиенты даже не заметят.
Пример. Два разработчика делают сервис для генерации коммерческих предложений для малого бизнеса. На бесплатном сервере они запускают бэкенд на Python, базу и админку. Дают доступ 10 первым клиентам бесплатно. Через месяц выясняется — сервис реально нужен, люди готовы платить. Команда увеличивает RAM и ядра, подключает платежную систему и начинает зарабатывать. Никто не спит ночами с миграциями.
Пет-проекты и вспомогательные сервисы — то, что вечно делают на коленке
Бывают ситуации, когда нужно, чтобы по расписанию запускался скрипт, стучал бот в Телеграме или собиралась статистика. Раньше вы держали это на домашнем компе, но когда уходили в отпуск или выключали его — всё падало.
Бесплатный облачный сервер решает это идеально. Он работает 24/7, у него есть постоянный адрес, и ему не нужен присмотр. А если ваш «пет-проект» внезапно станет важным для всей компании — вы всегда можете докупить ресурсов и перевести его в разряд боевых.
Пример. В отделе маркетинга каждый месяц собирают отчет по рекламе из 5 источников. Один аналитик написал Python-скрипт, который всё собирает и кидает итог в корпоративный чат. Раньше скрипт крутился на его рабочем ноутбуке. Если он уходил в отпуск — отчета нет. Теперь скрипт живет на бесплатном сервере и запускается по расписанию 1-го числа каждого месяца. Все счастливы, никто никого не дергает.
Тестовый стенд для бизнеса — чтобы не ломать работающий сайт
Это для тех, у кого уже есть работающий бизнес, но любое обновление — как прыжок с парашютом. Нет денег на отдельный платный сервер для тестов, а проверять новую фичу прямо на живом магазине — самоубийство.
Бесплатный Free Tier здесь дает полноценную «песочницу», которая является точной копией вашей боевой инфраструктуры (потому что это та же экосистема). Вы спокойно тестируете обновления, гоняете тестовые заказы, ищете узкие места — и только потом выкатываете на продакшен.
Пример. Интернет-магазин на 10 000 товаров. Разработчики сделали новый умный фильтр каталога. Вместо того чтобы втыкать его на живой сайт, они разворачивают точную копию магазина на бесплатном сервере, прогоняют 500 тестовых заказов, находят проблему с кешированием, фиксят её — и только потом обновляют работающий магазин. Ни одного сбоя, ни одного простоя.
В итоге
Бесплатное облако — это не просто «потыкать кнопки» и забыть. Это реальный инструмент, на котором можно запускать MVP, держать корпоративных ботов и тестировать обновления без стартовых вложений и с возможностью бесшовного роста.
Минимальная конфигурация Free Tier Рег.облака на срок до 6 месяцев: 1 vCPU, 1 ГБ RAM, 10 ГБ на NVME. И если вам вдруг станет мало — пишете в поддержку, и конфигурацию увеличивают.
Большинство компаний уже «потрогали» нейросети, но лишь единицы знают, как заставить их работать, а не просто генерировать стихи про котиков.
В 2025 году уже 62% айтишников использовали ИИ в работе. Год назад было в два раза меньше — около 30%. А к 2028 году, по прогнозам, показатель достигнет 98%.
Вместе с экспертами Рег.облака разберемся, какой путь прошли нейросети за последние пару лет, почему «поиграть с промптами» и «построить продуктовый пайплайн» — две большие разницы, и как компании могут перейти из первой категории во вторую без лишней боли. Спойлер: дело не в магии, а в правильной инфраструктуре и честном понимании того, с какими моделями вы работаете и где они живут.
Три волны внедрения
У каждой технологии есть три волны внедрения: первое касание, осознанное использование и глубокая интеграция. ИИ — не исключение.
Первое касание (2022 — начало 2023). Триггер: ноябрь 2022 года — релиз ChatGPT. Сотрудники массово начали «тыкать» нейросети сами. Разработчики — копипастить код из ChatGPT в продакшен без ревью и даже без понимания, работает ли он в принципе. Инженеры — просить нейросеть написать Dockerfile или docker-compose.yml «с потолка». Маркетологи генерировали посты, юристы пробовали писать договоры. Хаотично, весело, но не системно.
Осознанное использование (середина 2023 — настоящее время). Вы перестаете просить ChatGPT написать тост на юбилей начальника и начинаете использовать LLM как штатный инструмент. Промпты превращаются в шаблоны. Результат перестает быть случайным и начинает быть воспроизводимым. Где-то появляется API-интеграция, где-то — простой RAG (метод оптимизации ответов языковых моделей) поверх внутренней документации. Мы находимся ровно здесь, в середине второй волны.
Глубокая интеграция (горизонт 2–4 года). Когда LLM не «прикручена сбоку», а вшита в каждый бизнес-процесс. Например, договор проверяется моделью автоматически, тикет в Jira обрабатывается без участия человека, а поиск по внутренней базе знаний работает лучше, чем поиск у Google. А код-ревью происходит в реальном времени — написал строчку, модель уже подсветила потенциальную проблему. Это будущее.
Разрыв между первой и второй волной сейчас огромен. Между «мы поиграли с промптами» и «у нас работает продуктовый пайплайн с LLM» лежит пропасть. И именно тот, кто перейдет эту пропасть сегодня, получит конкурентное преимущество. Потому что к моменту, когда ИИ станет массовым (третья волна), у него уже будут отлаженные сценарии и накопленные данные: тогда догонять будет в разы дороже.
Сценарии, которые работают уже сейчас
Давайте без «через 5 лет роботы заберут наши рабочие места». Вот список задач, которые команды средней руки могут решать с помощью ИИ уже сейчас.
Поиск по внутренним документам с персональными данными. У вас есть сто тыщ договоров, внутренних инструкций, переписок в Jira и служебных записок. Найти в этом что-то руками — достаточно трудоемко. LLM + ваше хранилище (S3, база, облако) + хорошо настроенный RAG = поиск, который работает. И главное: данные никуда не утекают.
Личный ассистент для чувствительной информации. Корпоративный аналог Notion с умным поиском. Только Notion хранит данные у себя, а вы — у себя. Задаете вопрос: «А какой у нас был прецедент по налогам в третьем квартале прошлого года?». Модель лезет во внутренние доки и отвечает.
Внутренний помощник техподдержки (первой линии). Берете историю тикетов из вашей сервис-деск, добавляете техническую документацию, натравливаете LLM. В итоге оператор первой линии вместо «я не знаю, спрошу у старшего» получает готовый вариант ответа за секунду. А опытные сеньоры перестают отвлекаться на «как сбросить пароль?».
Доверенный ассистент для внешних пользователей. Публичный чат-бот, который отвечает строго по вашим данным. Никаких «нейросеть придумала несуществующую акцию» или «бот посоветовал то, чего у нас нет». Модель просто не имеет права уходить за пределы вашей базы знаний. Это лечится правильной настройкой инференса и промптов.
Генерация и проверка документов по локальному комплаенсу. Договоры, акты, счета, регуляторная отчетность. У вас есть шаблоны, есть требования, есть юридическая служба, которая все равно перечитывает каждую бумажку. LLM может сгенерировать черновик по шаблону или проверить готовый документ на соответствие вашим внутренним правилам. Экономит часы юристов.
Что важно: все эти задачи не требуют глубокой ML-экспертизы. Не надо дообучать модель с нуля, не надо писать свой трансформер. Достаточно готовой инфраструктуры и человека, который понимает, как склеить RAG с API.
Честный разговор про российский рынок моделей
Прежде чем говорить о том, как внедрять, — важный контекст про то, с чем работаем. В России нет фундаментальных моделей уровня GPT или Qwen, созданных с нуля. Почти все решения — доработанные версии открытых моделей. Конкуренция идет не в создании базовых технологий, а в настройке импортной основы, сборе данных и удобстве продуктов.
Российские нейросети в сложных задачах — разные языки, наука, программирование — пока отстают от мировых лидеров. В повседневных сценариях на русском языке — письма, бытовые вопросы, саппорт — работают достойно и конкурентоспособны. Технически доступ к DeepSeek, ChatGPT и другим пока возможен. Но открытые публичные сервисы не подходят, когда:
есть конфиденциальные или персональные данные;
нужна постоянная гарантированная интеграция — без внезапных изменений API и ценовой политики;
агент должен работать по внутренним источникам и базам знаний.
Для большинства реальных корпоративных задач это именно тот случай. Потому что «поиграть с ChatGPT» — это одно, а «построить продуктовый пайплайн с LLM внутри периметра» — совсем другое. И вот для второго варианта российские open-source сборки плюс своя или арендованная инфраструктура — вполне рабочий инструмент.
Где размещаться
Если публичные облака с иностранными моделями не подходят, остается два пути. Первый: поднимать свое железо в собственной стойке. Покупать GPU, настраивать охлаждение, думать о резервировании, ждать поставки полгода.
Второй: арендовать инфраструктуру в российской юрисдикции — с контролируемым доступом, понятными зонами ответственности и, главное, без сюрпризов в виде «а давайте мы заблокируем ваш API в понедельник утром». Для бизнеса выбор очевиден — не каждый готов стать владельцем дата-центра ради одного проекта с LLM.
Что хороший облачный провайдер может дать из коробки? Список не такой уж маленький: аренда GPU-серверов и GPU-виртуалок, готовые инференсы моделей по API, low-code и no-code инструменты для сборки пайплайнов, плюс сопутствующая инфраструктура — хранилища, очереди, чат-боты. Это позволяет не тратить месяцы на настройку железа и написание бойлерплейта, а сосредоточиться на том, ради чего все затевалось — на продуктовой логике и бизнес-сценариях.
Но просто «арендовать GPU» — мало. Потому что дальше начинается самое интересное: как поднять инференс, чтобы он не падал под нагрузкой? Как прикрутить RAG к внутренней базе знаний? Как организовать оркестрацию, когда у вас не один бот, а десять? Команды, которые пробовали собрать этот стек из open-source компонентов вручную, обычно заканчивают одинаково: либо через месяц бросают, либо получают конструкцию, которая работает «через раз». И вот здесь как раз нужна не просто «аренда железа», а платформа, где эти грабли уже собраны в один пакет.
Всё перечисленное выше — поиск по документам, ассистент техподдержки, генерация договоров — упирается в три вещи: где живёт модель, как она получает доступ к вашим данным и кто отвечает за то, чтобы инференс не лёг под нагрузкой.
ИИ-платформа Рег.облака построена вокруг подготовленного окружения с vLLM — высокопроизводительным инференс-движком, который позволяет запускать большие языковые модели на GPU без танцев с бубном. Но просто инференса мало. В платформу уже вшиты сервисы, которые закрывают типовые сценарии:
JupyterHub — для командной разработки ML-моделей с интеграцией в Git и S3. Никакой магии, просто рабочее окружение для дата-сайентистов.
Open WebUI — корпоративный ИИ-ассистент с предустановленными моделями. Это тот самый «личный помощник» из сценариев выше, только уже собранный и готовый к использованию.
n8n — low-code среда для визуальной сборки автоматизаций. Хотите, чтобы бот сам ходил в базу знаний, потом в LLM, потом отправлял ответ в Telegram? Настроили в несколько кликов.
Зачем хранить диски, если можно открыть приложение? И зачем покупать сервер, если можно арендовать мощность на час? За последние 20 лет цифровое потребление перевернулось с ног на голову. И дальше будет только интереснее.
Лет двадцать назад всё было по-другому. Музыку покупали на дисках и складывали в башню на полке. Фильмы — на DVD. Программы — в коробках с дистрибутивами. Владеть считалось круто. Сегодня тот же самый контент просто открывают в стриминге, ничего не скачивая и не храня. И эта эволюция затронула не только развлечения, но и бизнес-софт, и даже серверы. Вспоминаем, как менялись модели потребления и куда всё катится дальше.
Эпоха коробок и CD
Сначала был культ владения. CD-диски с музыкой, DVD-фильмы, коробочные версии Windows и Office — всё это стояло на полках, собирало пыль и считалось чуть ли не предметом гордости.
Для бизнеса это означало одно: капитальные затраты (CAPEX). Покупаешь серверные стойки, сетевое оборудование, лицензии — и всё это сразу, большими деньгами. Например, в 1999 году коробочная версия Microsoft Office 2000 Standard стоила около $540. С учетом инфляции — под $1000 сегодня.
Но проблемы быстро вылезли наружу:
Дорого. Надо выложить кучу денег сразу.
Долго. Чтобы увеличить мощность, нужно закупать новое железо, ждать поставку, настраивать — это недели и месяцы.
Ненадежно. Если сервер упал — сам с ним разбирайся. Резервное копирование и отказоустойчивость требуют двойных и тройных вложений.
Устаревает. Купил — а через пару лет железо уже не тянет, софт не обновляется, надо снова тратиться.
Виртуализация и переезд в чужие стойки
Потом появилась виртуализация. Стало можно не покупать сто новых серверов, а запустить сто виртуальных машин на десяти физических. А еще появились дата-центры, куда можно было сдать свое железо в аренду и не париться с электричеством и охлаждением.
Вроде прогресс. Но проблемы остались:
Железо всё равно твое. Ты его купил, ты его обслуживаешь, ты его меняешь, когда оно ломается. Капитальные расходы никуда не делись.
Масштабирование — боль. Хочешь добавить памяти на сервере с базой данных? Уперся в лимит материнской платы — покупай новый сервер. Во время черной пятницы интернет-магазин нельзя просто так взять и добавить мощности — надо было закупать железо заранее.
Привязка к конкретному «железу». Сломался сервер — простаивай, пока не починишь.
Бизнес арендовал «квадратные метры» в чужом ЦОДе, но все риски и возня с виртуалкой оставались на нем. Стало понятно — нужен следующий шаг.
Подписочная экономика: плати каждый месяц и не парься
Дальше всё пошло по пути подписок. Spotify вместо MP3, Netflix вместо торрентов, а в бизнесе — облака и программное обеспечение как услуга (SaaS). Вместо того чтобы покупать сервер, ты арендуешь виртуальную машину у провайдера. Вместо покупки Photoshop — платишь каждый месяц.
Для бизнеса это стало прорывом:
Нет капитальных расходов. Не надо выкладывать миллионы сразу. Платишь помесячно из операционки.
Скорость. Развернуть новый сервер — пять минут, а не три месяца.
Гибкость. На время распродажи добавил мощности, после — убрал.
Казалось бы, рай. Но и здесь вылезли нюансы.
Счет может неконтролируемо расти. Забыл выключить тестовую среду — платишь за воздух. Настроил неоптимально — деньги летят в трубу.
Вендорская зависимость. Засели в одном облаке — переехать к другому провайдеру та еще эпопея, дорого и больно.
Смерть от тысячи подписок. Кроме основного облака, у компании ещё система управления взаимоотношения с клиентами (CRM) за 20 тысяч, планирование ресурсов предприятия (ERP) за 30 тысяч, маркетинговый сервис за 15, коммуникации за 10… В итоге средний стартап легко тратит 30–50 тысяч рублей в месяц только на подписки. И контролировать этот зоопарк становится отдельной болью.
Что дальше? Подписки уходят, но не совсем
Сейчас тренды снова меняются: вместо одного подхода побеждает разнообразие.
Вот что набирает силу:
ИИ как услуга. Платишь не за абонемент, а за «единицы интеллекта». Загрузил картинку в нейросеть — списали копейки. Загрузил сто — списали больше. Вычисления становятся цифровым товаром, как электроэнергия.
Оплата по мере использования (pay-as-you-go). Это реакция на «смерть от тысячи подписок». Бизнесу надоело платить за то, чем не пользуется. Хочешь — арендуй сервер целиком. Хочешь — плати за каждый час процессора и каждый гигабайт диска. Именно так, например, работают современные облака вроде Рег.облака, где деньги списываются только за потребленные ресурсы, а не за факт аренды.
Коротко: от «владеть» к «иметь доступ»
Если оглянуться на 20 лет назад, путь очевиден. Сначала — коробки, диски, капитальные расходы, гордое обладание пыльными полками с софтом. Потом — виртуализация и размещение серверов, шаг вперед. Сейчас — подписки и облака, гибкость и операционные затраты, но с риском потерять контроль над расходами и оказаться в зависимости от вендора.
Дальше мир движется не к одной «правильной» модели, а к их умному смешению. Где-то нужна подписка, где-то — оплата по факту, где-то — вообще поминутная тарификация. Главный итог эволюции: бизнесу больше не нужно владеть инфраструктурой. Достаточно иметь к ней доступ, когда это реально надо, и платить только за то, что реально использовал — как это уже сейчас делают в Рег.облаке.
