Утечка данных: 400 тыс. ₽ вместо 10 млн

«Юридического архитектора пока не тянем — прикрутим эту логику позже, когда будет бюджет».

Так рассуждает едва ли не каждый второй основатель компании (фаундер) на старте. Мотив понятен: строка расходов незаметная, а продукт вроде и так работает. Только у этой экономии есть реальная цена — и это не сэкономленная зарплата специалиста, а тот день, когда в компании случится утечка данных.

Что именно экономят

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

Пропускают куда более конкретный шаг — тот, на котором кто-то заранее, до того как код уйдёт в боевую версию продукта (прод), решает:

• какие данные можно передавать во внешние сервисы без обезличивания;
• что алгоритм вправе решать сам, а что обязан передавать человеку;
• как обращаться с чувствительными данными клиентов на каждом этапе.

Без этого шага такие случаи всё равно кто-то решает — обычно менеджер продукта (продакт) или разработчик, который на него наткнулся, не всегда понимая, что здесь нужна не только продуктовая логика, а ещё и юридическая оценка, которую без специалиста просто неоткуда взять.

Дело «Юкидс»: во что это обошлось на практике

Цену такой экономии наглядно показало дело детской онлайн-академии «Юкидс», о котором писал «Коммерсантъ».

В июне 2025 года база с данными более 300 000 клиентов (имена, телефоны, email) оказалась в открытом доступе: утечка произошла из программы для учёта клиентов (CRM-системы) компании (Битрикс24). Обнаружили её только через три дня — за это время данные успели разойтись по поисковикам и телеграм-каналам.

Важно не путать две разные вещи:

1. Сама утечка. Это зона информационной безопасности: слабый пароль, открытый доступ, невнимательность сотрудника. Юридическая архитектура не настраивает права доступа в такой системе и не отменяет штраф за сам факт утечки — если систему скомпрометировали целиком, регулятор оштрафует независимо от того, была ли где-то на бумаге прописана классификация данных.
2. Зона ответственности юридической архитектуры. Заранее определить, кто в компании обязан узнать о подозрении на утечку не через три дня, а в первый час, и что происходит дальше по протоколу.

Данные «Юкидс» разошлись по сети за три дня. Это не дыра в пароле, а отсутствие протокола. Он не отменяет сам факт нарушения и не гарантирует более мягкий штраф, но от него напрямую зависит, сколько людей успеет пострадать, пока никто не отреагировал.

Судебный прецедент: что заплатила «Юкидс»

5 марта 2026 года Арбитражный суд Москвы признал «Юкидс» виновной по ч. 14 ст. 13.11 КоАП РФ — первое дело по новым, ужесточённым правилам, которые вступили в силу 30 мая 2025 года. Норма применяется при утечке данных более 100 000 субъектов (у «Юкидс» их было более 300 000) и предусматривает штраф для юрлица от 10 до 15 млн рублей.

«Юкидс» заплатила 400 000 ₽. Формально — по-прежнему штраф для юрлица, но по ст. 4.1.2 КоАП РФ для компаний-субъектов малого и среднего бизнеса (МСП) его нельзя опустить ниже минимальной планки, установленной для должностных лиц за то же нарушение — суд применил именно её, потому что «Юкидс» зарегистрирована как микропредприятие.

Это не история про везение, на которое можно рассчитывать заранее.

При повторном нарушении в силу вступает уже ч. 15 той же статьи — штраф, привязанный не к фиксированной сумме, а к проценту от годовой выручки компании (оборотный штраф), от 1 до 3% (но не менее 20 млн ₽ и не более 500 млн ₽).

Есть важная оговорка: «повторность» в КоАП РФ ограничена сроком. По ст. 4.6 новое нарушение должно случиться в течение года с момента, когда компания фактически исполнила первое наказание, то есть заплатила штраф, а не просто когда решение суда вступило в силу (это разные даты).

Если инцидент повторится позже этого срока, более жёсткий сценарий формально не сработает, и снова будет действовать мягкая часть статьи. Но рассчитывать на это как на стратегию — то же везение, что спасло «Юкидс» в первый раз, только отложенное на год.

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

Как это выглядит в продукте на базе ИИ

Похожая логика работает и в продуктах на базе ИИ — только цена ошибки там не всегда измеряется в штрафе регулятора.

Сценарий (вымышленный, но собран из типичных паттернов стартапов на стыке права и технологий, LegalTech): сервис для проверки контрагентов на благонадёжность (скрининга) на базе нейросети выдаёт клиенту заключение «контрагент прошёл проверку», хотя на самом деле модель не смогла обработать часть данных и просто выдала наиболее вероятный ответ, не предупредив об этом.

Клиент подписывает договор, контрагент оказывается недобросовестным, сделка срывается.

• Формально сервис не нарушил закон (специального требования к точности ИИ-проверки пока не существует);
• Но клиент теряет деньги, репутация рушится, а разбираться с недовольным клиентом выходит дороже, чем стоила бы проверка специалиста, который встраивает правовые ограничения в саму техническую реализацию (юридического инженера).

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

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

А как встроить этот список в правила, которые решают, что ИИ обрабатывает сам, а что передаёт человеку (Triage Logic), — решает уже менеджер продукта.

Как считать реальную стоимость риска

Здесь есть соблазн посчитать риск по формуле «вероятность × цена одной ошибки» и получить скромную ожидаемую сумму. Это обманчивая математика: она работает для рисков, которые размазаны по множеству повторений, как в страховании.

Штраф в сотни миллионов или срыв раунда инвестиций из-за инцидента — риск другого типа: он не усредняется по годам работы компании, а либо не случается вовсе, либо случается один раз и может закрыть бизнес сразу.

Юридическая архитектура не обещает нулевую вероятность ошибки — такого не бывает. Но она:

1. Резко снижает саму вероятность: критичные сценарии не решаются наугад.
2. Снижает масштаб катастрофических рисков: процесс останавливает ошибку до того, как она дойдёт до клиента, суда или регулятора.

• Стоимость архитектора на старте — известная и предсказуемая величина.
• Стоимость его отсутствия — мина замедленного действия: может годами лежать незаметно, а потом сработать суммой на два порядка больше, как чуть не случилось с «Юкидс».

Честный контраргумент

Для стартапа, который ещё не нашёл своих первых постоянных клиентов (не дошёл до Product-Market Fit), где вероятность инцидента в первые месяцы объективно низкая, тратить бюджет на архитектуру заранее может быть нерационально — деньги нужнее на проверку гипотез. Это разумная позиция, а не глупость.

Не обязательно закладывать архитектуру с первого дня для всех подряд — важнее знать конкретные ориентиры, после которых экономия перестаёт быть рациональной:

• через продукт проходят данные особой категории (дети, здоровье, финансы) — независимо от объёма;
• количество решений, которые алгоритм принимает без участия человека, уже больше, чем можно вручную перепроверить за день;
• продукт готовится к следующему раунду инвестиций или крупной сделке, где инвестор или партнёр перед сделкой проводит проверку компании (due diligence), которая включает именно эту логику.

Чек-лист: 3 вопроса, чтобы понять, сэкономили вы или отложили катастрофу

1. Кто в компании отвечает за то, какие данные уходят во внешние сервисы — и в каком виде? Если ответ — «как-то само сложилось», это уже красный флаг.
2. Есть ли список решений, которые алгоритм не имеет права принимать без подтверждения человеком? Если его нет, значит, он молча пишется постфактум — уже после первого инцидента.
3. Что будет с бизнесом, если завтра случится утечка или алгоритм примет ошибочное решение? Если единственный ответ — «разберёмся по ходу», это и есть незаложенная стоимость риска.

Часто задаваемые вопросы

Разве это не должен делать штатный юрист? Штатный юрист хорошо разбирается в договорах и трудовом праве — юридический архитектор не заменяет его и не конкурирует с ним за эту работу. Наоборот: он берёт на себя непрофильную для штатного юриста нагрузку — погружение в архитектуру продукта и перевод правовой логики в конкретные технические правила: что ИИ решает сам, а что передаёт человеку (Triage Logic), и список стоп-сигналов, которые останавливают автоматику там, где цена ошибки высока (Red Flags), — и отдаёт готовый инструментарий, а не отбирает зону ответственности.

Подробнее о том, чем это отличается от работы разработчика, — в отдельной статье.

На какой стадии стартапа это уже нужно? Не с первого дня для всех подряд — пока продукт не нашёл своих первых постоянных клиентов, бюджет часто рациональнее тратить на проверку гипотез. Но как только сработал хотя бы один из трёх ориентиров выше (особая категория данных, объём решений без участия человека, приближающийся раунд или крупная сделка), откладывать — это уже не экономия, а осознанный риск, о котором стоит хотя бы знать.

Чем это отличается от истории про дело «ЦСС» с нейросетью в суде? Та статья — про конкретный случай, где ошибка ИИ уже привела к штрафу. Эта — про то, почему компании вообще пропускают этот шаг на старте, и что экономия на нём стоит в среднем, а не только в одном частном деле.

Разве не дешевле просто рискнуть на старте? Иногда да. Если ни один из трёх ориентиров выше не сработал, отложить эту работу может быть рациональнее, чем тратить бюджет на архитектуру, которая пока не нужна.

Но как только сработал хотя бы один, сравнивать нужно не с одним конкретным штрафом — «Юкидс» заплатила 400 000 ₽ во многом благодаря удачной классификации как микропредприятия, — а с диапазоном возможных исходов: от сотен тысяч до сотен миллионов рублей при повторном нарушении, плюс отток клиентов и вопросы инвесторов на следующем раунде.

А если выручка компании меньше 20 млн — штраф всё равно будет 20 млн? В большинстве случаев да, это жёсткий минимум. Но в законе есть узкий коридор: по ч. 3.4-2 ст. 4.1 КоАП РФ, если компания три года подряд тратила на информационную безопасность не менее 0,1% годовой выручки, документально подтвердила соблюдение требований к защите данных и у неё не было прошлых нарушений — штраф при повторном нарушении снижается до 15–50 млн ₽ вместо стандартных 20–500 млн.

Это льгота не за маленький размер бизнеса, а именно за подтверждённые вложения в защиту данных — тот же тезис статьи, только на языке закона.

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

Отчёта на полсотни страниц не будет. Будет конкретная таблица: для каждого типа решения — кто его принимает, алгоритм или человек, и по какому критерию. Разработчик берёт её и сразу превращает в условия в коде, ему не нужно додумывать между строк. Формат может быть лёгким: разовая консультация с чек-листом — это часы, не недели. Полноценный аудит нужен не всегда, объём зависит от задачи.

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