35+ уходят не потому что не тянут технически, а потому что устали в пятый раз переписывать одно и то же на новом фреймворке. Видел и обратное: люди за 50 спокойно тащат то, что молодые боятся трогать, просто их меньше и они не пишут об этом статьи. Выборка по тем, кто ушёл в менеджмент, смещённая, тех кто остался в коде и доволен, ты в ней просто не увидишь.
“Главный барьер” - если коротко, это даже не один 152-ФЗ, а три разных состава по нему в одной схеме.
Первый - момент, когда пользователь вводит в промпт имя/телефон/email. С этой секунды компания становится оператором ПДн и попадает на ст. 6 плюс уведомление в РКН по ст. 22. Никакого “возможно, может быть” - обработка началась.
Второй - передача в зарубежного провайдера (OpenAI, Anthropic). Это ч. 5 ст. 18 в чистом виде, штраф 1-6 млн ₽ по ч. 8 ст. 13.11. До 30 мая 2025 практики по LLM конкретно не было; сейчас trans-border-кейсы уже появляются. Российские модели вроде вашей это снимают.
Третий, самый незаметный - даже если хостится в РФ, но обучали на корпусе с ПДн без обезличивания. Приказ РКН №140 от 19 июня 2025 эту конструкцию закрыл отдельно: “ML-обучение на необезличенных данных”. Пока никто на проверке не попался, но норма есть, ждёт первого.
В проде проще всего фильтровать на уровне промпта: телефоны/email/паспорта режутся regex’ом до отправки в модель, сама фильтрация логируется. Логи нужны, чтобы было что показать, если когда-нибудь спросят “а передавали ли”. Это не идеально, но работает как baseline.
Если опираться на сами тексты предписаний, которые получатели потом постят (с замазанными доменами), бот несложный. Обычный параллельный HTTP-сканер, тянет главную плюс 3-5 страниц по навигации сайта.
На каждой странице проверяет ровно то, что потом упоминают в претензии: ссылка на “Политику обработки/конфиденциальности” и сам текст политики (первые 30K символов смотрят на маркеры по ст. 18.1), формы с полями email/tel/name и видимый ли чекбокс согласия рядом (сложнее всего - потому что Битрикс/Тильда/Caldera Forms размечают чекбоксы каждый по-своему, чисто regex’ом не возьмёшь), cookie-баннер по классам cookie/gdpr/consent или по типовым фразам, популярные счётчики по URL файлов в HTML, ИНН -> дёргают reestr через REST API, GeoIP хостинга.
По UA-блокировке: смысла мало, у бота наверняка обычный браузерный UA - он специально маскируется (странно было бы РКН представляться честно). AS-список выше - корректный, но это базовая защита. Реально останавливает rate-limit на IP-сеть и любой JS-челлендж. Curl-бот JS не исполняет, дальше предписание выписывать не на чем.
Совет про “исправимые нарушения для проверяющего” нормально работает на территориальной проверке, согласен. А вот для автомониторинга он не сработает: туда никто на территорию не едет, всё закрывают HTML-сканером и предписанием на 10 дней.
Из того, что точно проверяют (видно по самим предписаниям, которые получатели потом постят с замазанными местами): редирект http->https, наличие политики обработки на постоянном URL у себя на домене - Google Docs / Notion в качестве “политики” уже ловят как ч. 5 ст. 18 в нагрузку, штраф до 6 млн. Дальше - чекбокс согласия в каждой форме с PII-полем, причём не скрытый через display:none или visually-hidden без label (это юридически = “нет чекбокса”). Cookie-баннер с обеими кнопками - без “Отклонить” согласие не свободное, см. письма РКН 2024. Локализация трекеров - Mailchimp, HubSpot, Google Forms, классика. И ИНН в реестре операторов: нет ИНН в pd.rkn.gov.ru при наличии форм с PII - это ст. 22 + ст. 19.7.
Всё что выше - секундная проверка. Поэтому подготовка “к проверке” сейчас это в первую очередь самопроверка по этому списку. Если что-то из шести пунктов отсутствует - приедут не на территорию, а через почту.
По плану действительно мало - A/B это 50-100 компаний в год, и большая часть из них уже сами держат DPO в штате. Тут панику гнать действительно глупо.
А вот внеплановые в 2025 уже обогнали плановые. По цифрам самого РКН за первое полугодие - около 1 870 проверок, и больше половины из них не “по жалобе субъекта”, а по результатам автомониторинга сайтов (тот же бот из соседней статьи на Хабре). Схема: бот видит, что нет политики обработки в HTML, выписывают предписание на 10 рабочих дней, не устранил - 30-60 тыс. по ч. 3 ст. 13.11. Без визита, без категорий, просто HTML и реестр операторов.
Если открыть любой региональный сегмент (стоматклиники, мелкие интернет-магазины, районные СМИ) - доля сайтов без явной политики там не из ряда вон. Не “как налоговая”, конечно, но и не “один раз в жизни”, как иногда пишут.
Hit-rate 5-20% - это про техническую сложность. С юридической стороны интереснее: для штрафа РКН по ч. 1 ст. 13.11 хватает одного подтверждённого случая идентификации без согласия. Не “всех” - одного.
При этом user-ID Метрики сам по себе уже становится косвенным идентификатором по ст. 3 п. 1 152-ФЗ, если есть связка с IP и поведенческой историей. Свежие московские решения 2024-2025 идут именно в эту сторону. То есть вашему fingerprint->phone тут даже не нужно работать на 100%, чтобы стать предметом разбирательства.
Прогноз “через 5 лет останутся только легальные” - реалистичнее 2-3. 30 мая 2025 верхний потолок по ч. 2 ст. 13.11 для юрлиц подняли до 700 тыс. ₽, на повторе по той же норме - кратно. На таких суммах большие игроки начинают чистить инфраструктуру сами.
согласен, обучение важная часть. Считаю этому мы уделили большое внимание, к тому же оставили за собой текстовые и видео инструкции. К этому моменту мы уже понимали важность обучения, но вот важность анализа заказчика еще не совсем )
Точно — незрелый заказчик. Это и есть диагноз кейса.
Но дихотомия "либо юристы и шарашка по ТЗ, либо незрелый идеалист, который потонет" - ложная. Третий путь: фильтровать на пресейле. Этот заказчик не должен был пройти у нас к договору, и это наша зрелость как подрядчика — её определить. На тот момент её не было — формализованный отказ от 1-2 из 10 появился ровно после таких историй.
Справедливо, вы правы по существу — старая CRM продолжала работать. Мы её отключали в начале запуска, но контроль над тем, что она остаётся отключённой, не удержали. Команда продолжала туда ходить — это и подтвердил позже управляющий, пришедший в компанию через несколько месяцев. По факту — мы не довели отключение до точки, когда вернуться к старому было физически невозможно. Это, конечно, наш просчёт.
Параллельно работала и другая, более сложная часть провала: каждая роль уходила в свой привычный инструмент вне любой CRM — проектировщики в Excel-таблицы раскроя, бухгалтер в 1С, менеджеры в личные телеграм. Эту часть нельзя выключить рубильником, но и без полного отключения старой CRM шансов на приживаемость было заметно меньше — выбор оставался.
Сейчас в каждом проекте у нас прописана дорожная карта отключения старой системы с конкретными датами (read-only → полное отключение) и ответственным со стороны клиента, кто это исполняет и подтверждает.
Тарифная политика — да, эволюция читаемая. Но это путь всех выросших SaaS: amoCRM, RetailCRM, Salesforce — та же модель «затянул внутрь, выйти потом дороже». Б24 здесь не уникален, просто на российском рынке эффект ощущается острее.
Про интерфейс — соглашусь, опций накопилось много, не все полезные. С другой стороны, смарт-процессы из нашего кейса появились относительно недавно и кардинально расширили возможности — то есть это всё-таки развитие, а не только нагромождение лишнего.
Что мебельной повезло уйти именно сейчас — да, согласны. Через год после интеграции с 1С и финансовым модулем стоимость отката была бы заметно больше годовой подписки. И отсюда практический вывод: ключевое решение для собственника — до внедрения, не после. Анти-кейс как раз об этом.
Если я правильно понял, понимаешь, что показывает время, только когда повернешь в определенном положении. Неплохо было бы сделать метки типа: время, температура и т.д., а ведь придется перевернуть несколько раз, прежде чем добраться до нужных цифр.
Мне понравился очерк автора статьи, я неоднократно ловил себя на мысли, что большинство коробочных cms однотипны.
Как разработчик, столкнувшийся с ExpressionEngine позволю подвергнуть некоторой критике «фичи»/модули, которые нам предлагают производители коробочных движков. Например, берем NetCat. Хорошая система, спору нет. Но складывается такое впечатление, что не ты разрабатываешь сайт, а он тебя. Заглядываем, создаем разделы, подключаем модули, причем все уже давно настроено любезно и зачастую не так как тебе надо, где гибкость?
Пробежимся по модулям, это очень интересно: Поиск по сайту — в версии Standart его нету, неужели так сложно снабдить поиском сайт? едем дальше Статистика посещений — лучше Google Analytics все равно не сделаешь, дальше Управление ссылками — промолчу, в EE кстати это можно сделать за 15 минут, дальше
ну и так далее, все же не хорошо поступаю, что гадости говорю, но я хочу выразить главную мысль. CMS не должна диктовать свои решения. Решения должны исходить от разработчика и поистине глубина всех его знаний (разработчика) может раскрыться только в той CMS, которой можно управлять, причем не обладая знаниями php (кстати сказать php я вообще не знаю, хотя разрабатываю сайты на ЕЕ уже давно :)
Просмотрев несколько коробочных решений, в том числе и UMI CMS я вижу однообразие в том, что везде есть понятие «Разделы сайта». Причем разделы сайта видны на всех страницах сайта, мы не можем чтолибо убрать, все проставляется автоматически, никакой гибкости.
35+ уходят не потому что не тянут технически, а потому что устали в пятый раз переписывать одно и то же на новом фреймворке. Видел и обратное: люди за 50 спокойно тащат то, что молодые боятся трогать, просто их меньше и они не пишут об этом статьи. Выборка по тем, кто ушёл в менеджмент, смещённая, тех кто остался в коде и доволен, ты в ней просто не увидишь.
“Главный барьер” - если коротко, это даже не один 152-ФЗ, а три разных состава по нему в одной схеме.
Первый - момент, когда пользователь вводит в промпт имя/телефон/email. С этой секунды компания становится оператором ПДн и попадает на ст. 6 плюс уведомление в РКН по ст. 22. Никакого “возможно, может быть” - обработка началась.
Второй - передача в зарубежного провайдера (OpenAI, Anthropic). Это ч. 5 ст. 18 в чистом виде, штраф 1-6 млн ₽ по ч. 8 ст. 13.11. До 30 мая 2025 практики по LLM конкретно не было; сейчас trans-border-кейсы уже появляются. Российские модели вроде вашей это снимают.
Третий, самый незаметный - даже если хостится в РФ, но обучали на корпусе с ПДн без обезличивания. Приказ РКН №140 от 19 июня 2025 эту конструкцию закрыл отдельно: “ML-обучение на необезличенных данных”. Пока никто на проверке не попался, но норма есть, ждёт первого.
В проде проще всего фильтровать на уровне промпта: телефоны/email/паспорта режутся regex’ом до отправки в модель, сама фильтрация логируется. Логи нужны, чтобы было что показать, если когда-нибудь спросят “а передавали ли”. Это не идеально, но работает как baseline.
Если опираться на сами тексты предписаний, которые получатели потом постят (с замазанными доменами), бот несложный. Обычный параллельный HTTP-сканер, тянет главную плюс 3-5 страниц по навигации сайта.
На каждой странице проверяет ровно то, что потом упоминают в претензии: ссылка на “Политику обработки/конфиденциальности” и сам текст политики (первые 30K символов смотрят на маркеры по ст. 18.1), формы с полями email/tel/name и видимый ли чекбокс согласия рядом (сложнее всего - потому что Битрикс/Тильда/Caldera Forms размечают чекбоксы каждый по-своему, чисто regex’ом не возьмёшь), cookie-баннер по классам cookie/gdpr/consent или по типовым фразам, популярные счётчики по URL файлов в HTML, ИНН -> дёргают reestr через REST API, GeoIP хостинга.
По UA-блокировке: смысла мало, у бота наверняка обычный браузерный UA - он специально маскируется (странно было бы РКН представляться честно). AS-список выше - корректный, но это базовая защита. Реально останавливает rate-limit на IP-сеть и любой JS-челлендж. Curl-бот JS не исполняет, дальше предписание выписывать не на чем.
Совет про “исправимые нарушения для проверяющего” нормально работает на территориальной проверке, согласен. А вот для автомониторинга он не сработает: туда никто на территорию не едет, всё закрывают HTML-сканером и предписанием на 10 дней.
Из того, что точно проверяют (видно по самим предписаниям, которые получатели потом постят с замазанными местами): редирект http->https, наличие политики обработки на постоянном URL у себя на домене - Google Docs / Notion в качестве “политики” уже ловят как ч. 5 ст. 18 в нагрузку, штраф до 6 млн. Дальше - чекбокс согласия в каждой форме с PII-полем, причём не скрытый через display:none или visually-hidden без label (это юридически = “нет чекбокса”). Cookie-баннер с обеими кнопками - без “Отклонить” согласие не свободное, см. письма РКН 2024. Локализация трекеров - Mailchimp, HubSpot, Google Forms, классика. И ИНН в реестре операторов: нет ИНН в pd.rkn.gov.ru при наличии форм с PII - это ст. 22 + ст. 19.7.
Всё что выше - секундная проверка. Поэтому подготовка “к проверке” сейчас это в первую очередь самопроверка по этому списку. Если что-то из шести пунктов отсутствует - приедут не на территорию, а через почту.
По плану действительно мало - A/B это 50-100 компаний в год, и большая часть из них уже сами держат DPO в штате. Тут панику гнать действительно глупо.
А вот внеплановые в 2025 уже обогнали плановые. По цифрам самого РКН за первое полугодие - около 1 870 проверок, и больше половины из них не “по жалобе субъекта”, а по результатам автомониторинга сайтов (тот же бот из соседней статьи на Хабре). Схема: бот видит, что нет политики обработки в HTML, выписывают предписание на 10 рабочих дней, не устранил - 30-60 тыс. по ч. 3 ст. 13.11. Без визита, без категорий, просто HTML и реестр операторов.
Если открыть любой региональный сегмент (стоматклиники, мелкие интернет-магазины, районные СМИ) - доля сайтов без явной политики там не из ряда вон. Не “как налоговая”, конечно, но и не “один раз в жизни”, как иногда пишут.
Hit-rate 5-20% - это про техническую сложность. С юридической стороны интереснее: для штрафа РКН по ч. 1 ст. 13.11 хватает одного подтверждённого случая идентификации без согласия. Не “всех” - одного.
При этом user-ID Метрики сам по себе уже становится косвенным идентификатором по ст. 3 п. 1 152-ФЗ, если есть связка с IP и поведенческой историей. Свежие московские решения 2024-2025 идут именно в эту сторону. То есть вашему fingerprint->phone тут даже не нужно работать на 100%, чтобы стать предметом разбирательства.
Прогноз “через 5 лет останутся только легальные” - реалистичнее 2-3. 30 мая 2025 верхний потолок по ч. 2 ст. 13.11 для юрлиц подняли до 700 тыс. ₽, на повторе по той же норме - кратно. На таких суммах большие игроки начинают чистить инфраструктуру сами.
ТЗ как раз было и было выполнено — система на старте работала. Провалилась приживаемость, а это зона за рамками технического ТЗ. Об этом и кейс
Тут клиент оплачивал помесячно, поэтому у него была возможность в любой месяц отказаться )
согласен, обучение важная часть. Считаю этому мы уделили большое внимание, к тому же оставили за собой текстовые и видео инструкции. К этому моменту мы уже понимали важность обучения, но вот важность анализа заказчика еще не совсем )
Точно — незрелый заказчик. Это и есть диагноз кейса.
Но дихотомия "либо юристы и шарашка по ТЗ, либо незрелый идеалист, который потонет" - ложная. Третий путь: фильтровать на пресейле. Этот заказчик не должен был пройти у нас к договору, и это наша зрелость как подрядчика — её определить. На тот момент её не было — формализованный отказ от 1-2 из 10 появился ровно после таких историй.
совершенно справедливые замечания!
Справедливо, вы правы по существу — старая CRM продолжала работать. Мы её отключали в начале запуска, но контроль над тем, что она остаётся отключённой, не удержали. Команда продолжала туда ходить — это и подтвердил позже управляющий, пришедший в компанию через несколько месяцев. По факту — мы не довели отключение до точки, когда вернуться к старому было физически невозможно. Это, конечно, наш просчёт.
Параллельно работала и другая, более сложная часть провала: каждая роль уходила в свой привычный инструмент вне любой CRM — проектировщики в Excel-таблицы раскроя, бухгалтер в 1С, менеджеры в личные телеграм. Эту часть нельзя выключить рубильником, но и без полного отключения старой CRM шансов на приживаемость было заметно меньше — выбор оставался.
Сейчас в каждом проекте у нас прописана дорожная карта отключения старой системы с конкретными датами (read-only → полное отключение) и ответственным со стороны клиента, кто это исполняет и подтверждает.
Тарифная политика — да, эволюция читаемая. Но это путь всех выросших SaaS: amoCRM, RetailCRM, Salesforce — та же модель «затянул внутрь, выйти потом дороже». Б24 здесь не уникален, просто на российском рынке эффект ощущается острее.
Про интерфейс — соглашусь, опций накопилось много, не все полезные. С другой стороны, смарт-процессы из нашего кейса появились относительно недавно и кардинально расширили возможности — то есть это всё-таки развитие, а не только нагромождение лишнего.
Что мебельной повезло уйти именно сейчас — да, согласны. Через год после интеграции с 1С и финансовым модулем стоимость отката была бы заметно больше годовой подписки. И отсюда практический вывод: ключевое решение для собственника — до внедрения, не после. Анти-кейс как раз об этом.
Как разработчик, столкнувшийся с ExpressionEngine позволю подвергнуть некоторой критике «фичи»/модули, которые нам предлагают производители коробочных движков. Например, берем NetCat. Хорошая система, спору нет. Но складывается такое впечатление, что не ты разрабатываешь сайт, а он тебя. Заглядываем, создаем разделы, подключаем модули, причем все уже давно настроено любезно и зачастую не так как тебе надо, где гибкость?
Пробежимся по модулям, это очень интересно:
Поиск по сайту — в версии Standart его нету, неужели так сложно снабдить поиском сайт? едем дальше
Статистика посещений — лучше Google Analytics все равно не сделаешь, дальше
Управление ссылками — промолчу, в EE кстати это можно сделать за 15 минут, дальше
ну и так далее, все же не хорошо поступаю, что гадости говорю, но я хочу выразить главную мысль. CMS не должна диктовать свои решения. Решения должны исходить от разработчика и поистине глубина всех его знаний (разработчика) может раскрыться только в той CMS, которой можно управлять, причем не обладая знаниями php (кстати сказать php я вообще не знаю, хотя разрабатываю сайты на ЕЕ уже давно :)
Просмотрев несколько коробочных решений, в том числе и UMI CMS я вижу однообразие в том, что везде есть понятие «Разделы сайта». Причем разделы сайта видны на всех страницах сайта, мы не можем чтолибо убрать, все проставляется автоматически, никакой гибкости.