Разбираемся, как распределяется ответственность за баги ИИ-кода | Автор: Марина Погодина
Ошибки ИИ-кода в рабочих проектах в России звучат как что-то абстрактное, пока не падает ваш реальный бот с заявками или CRM с персональными данными. Ошибки в коде ИИ, особенно когда речь про автоматизацию обработки персональных данных по 152-ФЗ, превращаются из технического бага в очень конкретный риск — от штрафов до 20 млн рублей до блокировки сервиса. ИИ для проверки кода на ошибки, все эти «ИИ находит ошибки в коде», Cursor, подсказки в IDE, n8n-сценарии, автогенерация Python-скриптов для аналитики — все это экономит часы, но не снимает юридическую ответственность. В России за баги в автоматизированной системе ПДн отвечает оператор, то есть сам бизнес, а не нейросеть, не разработчик бота и даже не подрядчик, если договором не предусмотрено иное.
Я часто работаю как раз на стыке: AI Governance & Automation Lead, с корнями во внутреннем аудите и ИТ-рисках. Одна из последних историй — Света из маркетинга, которая очень хотела, чтобы лиды из всех форм и Telegram-бота сами стекались в CRM, а данные клиентов аккуратно обезличивались для аналитики. Часть кода для n8n ей помогла написать ИИ, часть добили фрилансером, все казалось логичным, пока в логе не обнаружили, что e-mail одного клиента проскочил без маскировки в выгрузку для подрядчика по рекламе. Ничего катастрофического, но если бы это заметил не внутренний аудит, а Роскомнадзор — штраф и долгие объяснения обеспечены. Я покажу, как такие истории не доводить до «письма счастья», куда реально ложится ответственность за баги ИИ-кода и как сделать так, чтобы автоматизация продолжала экономить часы, а не добавлять седые волосы.
Иногда мне кажется, что за последние пару лет в российских компаниях появилось два лагеря. В первом — осторожные люди, которые боятся трогать автоматизацию ПДн: Excel с зарплатами живет на локальном диске, заявки клиенты отправляют через древнюю форму, а любое упоминание про «ИИ для поиска ошибок в коде» вызывает нервный смешок. Во втором — энтузиасты, которые уже привинтили ИИ-агентов к сайтам, чат-ботам и CRM, а код от нейросети гонят сразу в прод, потому что «скрипт же маленький, что с ним случится». И вот где-то между ними живу я, с одной стороны, безусловно радуюсь каждому скрипту, который снимает рутину, а с другой — привыкла смотреть на любой автоматизированный процесс как на потенциальную ИСПДн с конкретной моделью угроз, журналами и ответственными.
С ИИ-кодом у бизнеса появляется любопытная иллюзия: раз его сгенерировал алгоритм, а не живой программист, то баги как будто «не по-настоящему», особенно если они не ломают функционал, а «всего лишь» не дотягивают до идеала безопасности. На деле именно такие «почти рабочие» скрипты и бьют по компании сильнее всего. В интерфейсе все красиво, менеджеры довольны, стратегия на квартал реализуется, а где-то в глубине логики один неучтенный случай приводит к тому, что персональные данные уезжают дальше, чем должны. И уже неважно, кто именно написал этот фрагмент — ИИ, стажер или фрилансер с другого часового пояса.
Света из маркетинга как раз из лагеря энтузиастов. У нее был понятный запрос: собрать всех пользователей, которые оставляют заявки на сайте, пишут в Telegram-бот и попадают в автоворонку рассылок, сложить их в одну CRM, а потом еще и обезличить данные для аналитики эффективности. В теории — мечта любого маркетолога. На практике — классическая ИСПДн с несколькими контурами, трансграничной передачей и требованием локализации на российских серверах. Мы договорились, что я подключусь к проекту не в момент «все рухнуло», а заранее, чтобы выстроить нормальный контур ответственности и не дать багам скриптов превратиться в административку.
Чтобы не утонуть в юридических формулировках, я держу в голове простой образ: любой автоматизированный процесс с клиентскими или кадровыми данными — как стиральная машина. Если в инструкции написано «не превышать загрузку», а вы напихали туда одеяла и обувь, то от того, что машина умная и с десятком режимов, ответственность за потоп в ванной не исчезает. Кстати, та самая «стиральная машина ошибка uE код» из интернет-форумов — это примерно то же состояние бизнеса, который видит предупреждение от Роскомнадзора, но искренне не понимает, что пошло не так, потому что «мы же всего лишь поставили бота собирать заявки».
Дальше будет про то, как не доводить до «uE» в юридическом смысле: кто отвечает за ошибки в коде ИИ, как построить архитектуру автоматизации под 152-ФЗ, какие проверки вшить в процесс, чтобы ИИ найти ошибку в коде на питон помог, а не устроил утечку, и как Света в итоге выбралась из этой истории с минимальными потерями и максимальной пользой.
Кто в России отвечает за баги ИИ-кода в автоматизации ПДн
Как закон видит оператора ПДн и почему ИИ тут ни при чем
Если отбросить красивые слова про цифровизацию, в 152-ФЗ все довольно прозаично: того, кто определяет цели и средства обработки персональных данных, называют оператором. В переводе на человеческий язык это означает, что если вы — компания, которая решила «внедрить чат-бота для заявок», «сделать аналитику маркетинга на основе истории покупок» или «подкрутить n8n, чтобы HR не копировал резюме вручную», именно вы становитесь тем самым оператором, которого Роскомнадзор будет спрашивать за все баги. И неважно, чей именно код лежит под капотом: старый самописный PHP, аккуратные микросервисы или ИИ для исправления ошибок в коде, который поправил раз за разом одну и ту же функцию.
Когда я первый раз внимательно прочитала свежую редакцию 152-ФЗ, меня поразило, насколько там последовательно игнорируется персона разработчика. Закон как будто спокойно говорит: «Ребята, кто получает выгоду от обработки и контролирует систему, тот и отвечает». Для бизнеса это неприятная честность: привычной перекладки в стиле «это подрядчик накосячил» не работает. Даже когда в цепочке появляется ИИ для нахождения ошибок в коде или генерации скриптов, с точки зрения права он всего лишь инструмент, как компилятор или IDE. Это критично, потому что многие компании подсознательно пытаются считать ИИ чем-то отдельным, как будто юридически это «третья сторона», на которой можно повиснуть ответственность, но нет.
На практике в России это выглядит так: Роскомнадзор в 70% проверок приходит к сайтам и сервисам, где есть автоматизация — виджеты, формы, CRM, боты. Если фиксируется утечка или некорректная обработка (несогласованная передача, отсутствие локализации, неправильное обезличивание), в протокол попадает именно оператор. Да, потом можно в гражданском порядке спорить с разработчиком, взыскивать ущерб, но штрафы по КоАП прилетают бизнесу, а не ИИ и не отдельному программисту. Получается, что юридическая картина мира намеренно проста: кто владеет процессом — тот и отвечает, независимо от того, насколько «умным» был используемый код.
Чтобы не оставлять это в виде теории, удобно зафиксировать мысль в виде небольшой формулы ответственности, хоть она и не из учебника.
Если вы принимаете решение об обработке ПДн и запускаете автоматизацию, то вне зависимости от того, использовали ли вы ИИ для поиска ошибок в коде или писали его вручную, вы остаетесь конечной точкой ответственности для регулятора.
Это звучит слегка сурово, но освобождает от иллюзий и подталкивает строить процессы так, чтобы баги ловились заранее, а не на этапе разбирательств с Роскомнадзором.
Почему «ИИ нашел ошибку в коде» не спасает от штрафа
Есть соблазн думать, что если ИИ находит ошибки в коде и исправляет их, то система становится автоматически «более безопасной» и, значит, риски снижаются. С технической точки зрения, да, вы правда можете уменьшить количество тривиальных багов, особенно в больших кодовых базах, где человеческий глаз уже «замылился». Но 152-ФЗ не оценивает количество багов как таковых, он смотрит на последствия для субъектов данных. Если автоматизация обрабатывает ПДн и в какой-то ветке логики все равно допускает утечку или незаконную передачу, факт того, что до этого ИИ героически вычистил 15 других ошибок, для регулятора не имеет значения (хотя для вашей архитектуры, конечно, имеет).
Юридически это похоже на историю с ассистентом-бухгалтером. Можно использовать умные программы, проверки, подсказки, но если в отчет попала критичная ошибка, спрашивать будут с главбуха, у которого стоит подпись. В автоматизации ПДн подпись заменяется решением оператора «запустить в прод эту систему обработки». Я заметила, что те компании, которые сразу принимают этот факт и перестают надеяться, что «ИИ исправит ошибки в коде и расчистит нам все хвосты», начинают иначе разговаривать и с разработчиками, и с юристами: появляются чек-листы приемки, требования к тестированию, журналы изменений, понятные SLA на реакцию.
Чтобы чуть упростить восприятие, полезно зафиксировать одну фразу. ИИ-код отвечает за скорость и удобство разработки, а ответственность за соблюдение 152-ФЗ всегда остается за оператором ПДн. Это означает, что любые разговоры в духе «это модель не так сгенерировала» или «мы думали, что ИИ найдет ошибку в коде на питон автоматически» хороши для внутреннего ретроспектива, но не работают как аргумент на проверке. ИИ-ассистенты — классный инструмент, но юридически они в одном ряду с любой другой программой, которая помогает, но не принимает решения за вас.
Как Роскомнадзор смотрит на баги: пример с чат-ботом
В практической жизни проверки часто начинаются с простого: у компании есть сайт, чат-бот и форма записи, все крутится вокруг какого-нибудь популярного конструктора или самописной логики на Python с интеграцией в CRM. Где-то по цепочке стоит ИИ для проверки кода на ошибки, подсказки в IDE или автогенерация запроса к базе. При утечке Роскомнадзор реконструирует цепочку: кто владеет доменом, кто получает данные клиентов, где физически находятся серверы, есть ли уведомление об обработке ПДн, соответствует ли форма согласия новой редакции закона, и только потом, если сильно повезет, добирается до деталей кода.
Типовой кейс: утечка e-mail’ов и телефонов из базы, куда заявки попадали через чат-бот на сайте. Компания использовала генерацию кода через ИИ, чтобы быстро сделать интеграцию: «подхватил заявку — отправил в CRM — продублировал в таблицу для аналитики». Один баг в обработке исключения привел к тому, что при падении CRM, данные отправлялись на резервный адрес, не описанный ни в одной политике. Внутри это казалось временным решением «на время миграции», но по факту создало второй контур обработки без уведомления и должной защиты. С точки зрения Роскомнадзора это отдельное нарушение, даже если технически ИИ очень старался снизить общее количество ошибок в коде. Получается, что фокус регулятора — не на том, кто именно писал код и сколько именно там ошибок, а на том, как конкретное поведение системы затронуло субъектов данных.
Как устроена автоматизация ПДн с ИИ-кодом под 152-ФЗ
Что считать ИСПДн и почему даже Excel с макросом уже система
Я заметила, что часть недопониманий вокруг ответственности за ошибки в коде ИИ рождается из простой вещи: многие вообще не считают свои автоматизации «настоящими» информационными системами персональных данных. Кажется, что ИСПДн — это что-то большое, с серверной, стойками и отдельной командой безопасности. А по факту в определении 152-ФЗ достаточно буквально пары условий: наличие персональных данных и использование автоматизации для их обработки. В этот момент ваш невинный Excel с зарплатами, к которому прикрутили макрос обработки, превращается в ИСПДн, как ни грустно.
Если развернуть картину, то любой проект вроде «скрипт собирает заявки, ИИ находит ошибки в коде, а n8n гоняет данные между сервисами» формирует связку из нескольких компонентов: точки сбора (формы, боты, API), транспорт (HTTP-запросы, вебхуки), логика обработки (скрипты, n8n, Make, самописные сервисы), хранение (БД, CRM, файлы), аналитика (обезличивание, BI, отчеты).
Как только в этой цепочке находятся ФИО, контактные данные, сведения о покупках, истории действий или, тем более, биометрия, все это попадает под понятие ИСПДн с обязанностями оператора по уведомлению, защите, локализации и документации.
ИИ при этом остается просто дополнительным градиентом удобства, а не новым юридическим субъектом (хотя иногда хочется его туда записать, честно).
Меня часто спрашивают, действительно ли нужно так серьезно относиться к «простому автоматизированному скрипту», который всего лишь сортирует заявки или очищает данные. Ответ, увы, да. Даже если автоматизация не добавляет новых действий, а только ускоряет старые, она меняет риск-профиль: ошибки в логике, особенно те, что написал или «оптимизировал» ИИ, начинают влиять на сотни записей сразу, а не на одну-две в руках человека. Это означает, что баги, которые раньше жили в пределах рабочего дня одного менеджера, в автоматизации превращаются в системную проблему всей ИСПДн. Именно поэтому законы и регуляторы требуют формализовать такие процессы.
Как выглядит «правильная» архитектура: от локализации до обезличивания
Если собрать воедино требования 152-ФЗ в редакции 2025 года и типичный стек автоматизации у российских компаний, получается достаточно понятная схема. Персональные данные сначала попадают на российский сервер: это может быть хостинг, отечественный облачный провайдер или даже собственная инфраструктура в дата-центре. Уже внутри РФ над ними крутится автоматизация — скрипты, боты, модули аналитики. Только после этого, при необходимости, часть данных может уходить за рубеж, и то при соблюдении правил трансграничной передачи. Я сейчас утрирую, но картинка «Яндекс/российский хостинг — n8n — CRM — BI» заметно легче живет на проверках, чем «лендинг на зарубежном конструкторе — вебхук в иностранный сервис — оттуда в Google Sheets».
В этой архитектуре ИИ для проверки кода на ошибки занимает вспомогательную роль. Он помогает писать более аккуратные обработчики, избавляет от глупостей вроде забытых проверок на null или неправильных типов, но ответственность за то, кто и как имеет доступ к данным, где лежат бэкапы, шифруется ли трафик и как устроено обезличивание, лежит на операторе. Я на практике заметила, что когда в проекте сразу рисуют схему «что где живет» и закрепляют ее в документации (положение об ИСПДн, модель угроз, реестр процессов), сами ошибки в коде ИИ становятся менее страшными, потому что их проще ловить на понятной карте.
Чтобы не превращать это в слишком абстрактное обсуждение, я люблю давать образно-структурированное описание. Базовая архитектура безопасной автоматизации ПДн в России выглядит так: сбор данных — локальная обработка на российских серверах — защитные меры (шифрование, разграничение доступа, журналы) — обезличивание для аналитики — при необходимости, строго контролируемая передача за рубеж. Внутри этой цепочки можно использовать ИИ для поиска ошибок в коде, для улучшения логики, но каждый шаг все равно описан, задокументирован и протестирован. Тогда даже если баг вылезет, вы хотя бы будете понимать, где именно и как его изолировать.
Какие документы и реестры спасают при багах ИИ-кода
Я когда-то думала, что самая скучная часть 152-ФЗ — это всякие реестры процессов, положения и журналы учета. Потом посмотрела несколько реальных проверок Роскомнадзора и поняла, что именно эти «бумажки» превращают необъяснимый хаос багов и патчей в управляемый риск. Если у оператора есть реестр обработки ПДн, где по каждому процессу понятно, какие данные собираются, где хранятся, кто имеет доступ и какие средства защиты применяются, становится легче объяснить, что конкретная ошибка в коде ИИ была эпизодом, а не системной халатностью.
Те же сервисы вроде 152DOC или решения наподобие PrivacyLine, которые помогают составить реестр и документы автоматически, иногда спасают не меньше, чем дорогой аудит.
Когда инспектор видит, что компания хотя бы пыталась структурировать свои процессы, описать ИСПДн и продумать меры защиты, разговор переходит из тона «вы вообще о чем думали» в режим «давайте разберемся, где именно сломалось».
Это не магия, а просто человеческая реакция на то, что риски хоть как-то управляются. Ну и юристу, который приходит после багов ИИ-кода, работать с такой базой несравнимо проще.
В автоматизации я рекомендую, чтобы реестр обработки шел рука об руку с репозиторием кода и схемами n8n/Make. Если уж вы используете ИИ для исправления ошибок в коде, то логично параллельно вести человеческий журнал того, какие именно процессы и ИСПДн он затрагивает. Это критично, потому что при серьезной ошибке сначала зададут вопрос «что именно обрабатывалось и где», и только потом «почему тут баг». Когда ответ на первый вопрос есть в одном-двух документах, а не в переписке на почте, вы экономите часы на разборе и снижаете градус паники внутри команды.
Как ИИ-код ломает и спасает безопасность: разбор типичных ошибок
Где чаще всего стреляет ИИ-код в автоматизации ПДн
Когда я стала системно собирать ошибки в коде ИИ, которые приводят к проблемам с персональными данными, вырисовалось несколько устойчивых сюжетов. Первый — это неправильное обезличивание. Боты и скрипты с ИИ-генерацией часто маскируют только очевидные поля, вроде ФИО и e-mail, но забывают про косвенные идентификаторы: комбинации заказов, уникальные ID, редкие атрибуты. В результате выгрузка для аналитики вроде бы «обезличенная», но при желании по ней легко восстановить конкретного человека. Второй сюжет — размытые границы доступа: ИИ помогает быстро связать несколько сервисов, но в правовой модели доступа никто не успевает разобраться, и в итоге маркетинг видит больше, чем должен, а подрядчики — ровно столько же, сколько внутренние сотрудники (что, признаюсь, иногда удобнее, но незаконно).
Третий популярный тип бага — работа с ошибками. ИИ для поиска ошибок в коде любит оптимизировать обработку исключений, сокращать «лишние» проверки, приводить все к более «чистому» виду. На практике это иногда означает, что крайние случаи, вроде нестандартных запросов, начинают тихо падать в лог без уведомления или уходить в «черную дыру» — временное хранилище, не предусмотренное политиками. Я пару раз видела проекты, где такой «крайний случай» касался как раз запросов субъектов на удаление данных. Формально система их принимала, но из-за бага, с любовью оптимизированного ИИ, до обработки эти запросы не доходили.
Чтобы эти сюжеты не казались слишком теоретическими, полезно их зафиксировать как небольшой перечень симптомов, на которые стоит смотреть.
- Обезличивание касается только очевидных полей, а косвенные идентификаторы остаются.
- Границы доступа между отделами и подрядчиками не пересмотрены после подключения ИИ-кода.
- Логика обработки ошибок упрощена до «положили в лог и забыли», без понятных алертов.
- Тестирование проводилось на «красивых» кейсах, без странных пользовательских сценариев.
- Скрипты в n8n/Make живут своей жизнью, отдельно от документации по ИСПДн.
Каждый из этих пунктов сам по себе не преступление, но в связке они создают прекрасный фон для того, чтобы баг ИИ-кода превратился в юридический кейс.
Как ИИ помогает ловить ошибки, если его правильно встроить
Сейчас картина может выглядеть мрачновато, но это не значит, что ИИ для нахождения ошибок в коде — зло и его лучше спрятать. Наоборот, при нормальной интеграции в процесс разработки и аудита ИИ-ассистенты становятся мощным фильтром для тех самых багов, которые в обычной жизни пролетают мимо глаз. На практике лучше всего работают связки, где ИИ проверяет код не только на синтаксис и типичные уязвимости, но и на соответствие заранее описанным правилам обработки ПДн: «никакой записи в лог без маскировки», «никаких отправок на сторонние домены», «все ошибки при работе с запросами субъектов должны поднимать алерт».
Я несколько раз видела, как простое описание таких правил в текстовой форме, которое потом подсовывается ИИ-ассистенту, поднимает качество кода на голову выше. Да, это не гарантирует защиту от всех возможных нарушений (звучит странно, но работает именно как фильтр), но помогает выловить очевидные нарушения вашей собственной политики обработки данных.
Идеальная картина выглядит так: человек-юрист и человек-технарь формулируют требования, ИИ помогает прогнать код и сценарии n8n через эту «правовую линзу», а уже потом команда руками дорабатывает сложные случаи.
Такой треугольник дает баланс между скоростью, качеством и ответственностью.
На этом фоне запрос «ИИ исправить ошибки в коде» перестает быть волшебным заклинанием и превращается в рабочий инструмент. Если на вход ассистенту скормлены не только куски кода, но и ваша модель угроз, политика обработки ПДн и требования к обезличиванию, шансы получить что-то осмысленное для реальной ИСПДн резко растут. Конечно, это не отменяет необходимости ручного ревью и тестирования (забудь, что я только что сказала про «идеальный» ИИ — без людей там все равно ничего не взлетит), но снижает вероятность того, что в прод уйдет банальный, но разрушительный баг.
Почему «быстрый прод» с ИИ-кодом особенно опасен для ПДн
Когда в компании появляется ИИ, который умеет быстро дописывать и исправлять код, почти всегда случается один и тот же эффект: прод стал ближе. Интервал между «у нас есть идея» и «оно уже работает на реальных данных» сжимается до дней, иногда до часов. Для продуктовой команды это праздник, для юриста по ПДн и ИБ — аккуратный ад. Каждый раз, когда кто-то ставит в чат «я тут накидал скрипт, уже гоняется на боевой базе», в воздухе повисает немой вопрос: а кто проверял, что он делает с персональными данными. И чаще всего ответ — никто, кроме автора и ассистента ИИ.
Я не против быстрого прода как подхода, наоборот, люблю, когда идеи проверяются живо. Но в зоне ПДн быстрый прод без минимального контура проверки — прямой путь к проблемам. Особенно если код сгенерирован или «оптимизирован» ИИ, потому что у команды возникает ложное чувство «ну это же не я сделал, наверняка там все по учебнику». На моей практике самые неприятные кейсы с утечками и странной логикой почти всегда начинались с фразы «мы просто хотели быстро протестировать гипотезу, завтра бы все переписали». В ПДн завтра уже будет поздно, потому что данные клиентов или сотрудников не любят экспериментов.
Как Света из маркетинга внедряла автоматизацию и где все пошло не так
С чего начался проект: связать формы, ботов и CRM без боли
Возвращаясь к Свете из маркетинга, та история почти учебниковая. У нее была привычная боль: заявки приходят из трех мест — формы на сайте, Telegram-бот и лендинг под рекламу. Дальше менеджеры вручную сводят это в одну CRM, теряя по пути контакты, а сама Света делает аналитику в Excel раз в неделю, когда находится время. Руководство сказало «надо автоматизировать», дали ей в помощь разработчика-фрилансера на несколько часов в неделю и зеленый свет на использование ИИ, чтобы ускорить написание скриптов. Казалось бы, идеальная среда для «ИИ для исправления ошибок в коде»: быстрый цикл, небольшой проект, понятная цель.
В первой версии архитектуры все выглядело логично. Формы и бот отправляют данные в n8n, дальше сценарии распределяют их по CRM и в таблицу в отечественном облаке для аналитики. ИИ помог генерацией кода для парсинга payload, обработки дублей и базовой проверки валидации. По пути внедрили маскировку e-mail и телефонов в аналитической выгрузке, чтобы Света могла смотреть эффективность рекламных каналов без прямых идентификаторов клиентов. На бумаге это вполне приличная ИСПДн по 152-ФЗ, особенно если все крутится на российских серверах и есть хоть какая-то документация.
На этом этапе мы с Светой встретились: она пришла «просто проговорить с юристом, все ли ок по 152-ФЗ». Я спросила, есть ли уведомление Роскомнадзора, реестр процессов, описание ИСПДн, модель угроз, а она посмотрела на меня с тем самым взглядом «Марина, мы же просто автоматизировали Excel». Пришлось немного охладить энтузиазм и объяснить, что даже если ИИ находит ошибки в коде и все выглядит аккуратно, это не делает проект невидимым для закона.
После этого мы вместе с технарем быстро собрали реестр: какие данные собираем, где храним, кто имеет доступ, что делаем для защиты, какой класс ИСПДн получается.
Только после этого я согласилась идти дальше.
Как баг в маскировке привел к почти-утечке
Кофе к тому моменту у меня, конечно, уже остыл, потому что когда дошли до тестов, выяснилось самое интересное. Маскировку ИИ-код действительно написал очень красивую: все e-mail и телефоны в аналитической таблице были заменены на «*****», а логика скрипта выглядела опрятно. Но когда я попросила прогнать тест на краевых кейсах и сгенерировать пачку синтетических данных, внезапно обнаружился один маленький, но неприятный нюанс. Если у клиента был только номер телефона без e-mail, а форма передавала его в нестандартном поле, маскировка не срабатывала, и номер попадал в аналитическую выгрузку в открытом виде.
Этот кейс казался экзотическим, пока мы не выгрузили реальные данные за неделю. Оказалось, что примерно 8% заявок шли ровно по этому пути — люди, которые приходили через определенный лендинг, оставляли только телефон, и фрилансер когда-то завел для этого отдельное поле. ИИ для поиска ошибок в коде с честью справился с базовым сценарием, но экзотический путь никто не задал ни при генерации, ни при проверке. Юридически это означало, что «обезличенная» аналитика Светы на самом деле местами содержала персональные данные в исходном виде, а это уже нарушение режима обработки, пусть и не самое страшное.
Мы довольно быстро поправили код (хотя сама я бы, честно, переписала его полностью), заставив ИИ перепроверить все поля, которые могут содержать контактные данные, а не только заранее выбранные. Но осадок остался: если бы Света не пришла к юристу «на всякий случай», а сразу включила аналитику и отдала бы эти выгрузки внешнему подрядчику по рекламе, это уже была бы трансграничная передача ПДн без должного правового основания. Тут даже «ИИ исправить ошибки в коде» не помог бы задним числом — пришлось бы фиксировать инцидент, уведомлять Роскомнадзор и разбираться, насколько это затронуло права субъектов.
Что пришлось доделать в проекте, чтобы не нервничать ночью
После истории с маскировкой Света, как это часто бывает, резко переключилась из режима «мы просто прикрутили автоматизацию» в режим «давайте уже сделаем нормально». Мы с технарем сели и составили список доработок, которые казались «бюрократией» утром и жизненной необходимостью вечером. Первым делом — нормальное тестирование: прогнали n8n-сценарии и ИИ-код на синтетических данных с максимально странными кейсами, включая пустые поля, нестандартные символы, дубли и запросы субъектов ПДн. Потом описали в документации, где именно находятся точки хранения, какие роли имеют доступ и как разграничивается доступ к исходным и обезличенным данным.
Я еще настояла на том, чтобы подключить минимальный мониторинг: если какой-то шаг сценария падает или начинает вести себя нестабильно, приходит алерт не только технарю, но и назначенному ответственному за ИСПДн. Да, это добавляет еще одно уведомление в день, иногда пустое, но превращает ошибки в коде ИИ из «что-то там опять сломалось» в конкретные события, которые можно разбирать. Критичное изменение было в головах: ИИ для исправления ошибок в коде перестал быть «чудо-ассистентом» и стал обычным инструментом, встроенным в понятный процесс с ролями и журналами. После этого я, честно, начала спать спокойнее — и Света тоже.
Как построить минимум защиты от багов ИИ-кода в реальных проектах
С чего начать малому и среднему бизнесу без армии юристов
Помнишь про кофе из начала? Именно в таких ситуациях — когда автоматизация уже запущена, а документы и проверки еще «где-то в планах», — чашка холодного кофе становится символом отложенного головной боли. Но даже без штатного юр-отдела и без отдельного CISO можно сделать несколько шагов, которые резко снизят риск того, что ошибки в коде ИИ превратятся в болезненный кейс с Роскомнадзором. Я всегда предлагаю начинать не с технических утилит, а с описания процесса человеческим языком: какие данные мы собираем, где они проходят, кто их видит и что с ними делаем.
Дальше поверх этого описания легко накидывается минимальный контур 152-ФЗ: уведомление Роскомнадзора, если еще не отправили; простое положение об обработке ПДн; реестр ИСПДн с перечислением систем и процессов. Сервисами вроде 152DOC реально можно закрыть большую часть бумажной рутины за пару дней, но даже если делать все в Word, уже будет прогресс.
Ключевая мысль: пока у вас нет описания процессов, никакой ИИ для поиска ошибок в коде не спасет — он не знает, что для вас нарушение, а что допустимое поведение.
А вот когда процессы описаны, можно переходить к технике.
Чтобы не распыляться, полезно для себя сформулировать небольшой набор шагов в голове.
- Правило: описать, какие ПДн где проходят, прежде чем править или дописывать код.
- Шаг: завести один файл/реестр, где перечислены все автоматизации, затрагивающие ПДн.
- Формула: «одна автоматизация — один ответственный человек» за ее поведение с данными.
- Привычка: любое изменение ИИ-кода, которое касается ПДн, фиксировать в коротком журнале.
Эти простые штуки не требуют сложных систем, но делают ваш проект в разы понятнее и управляемее, даже если код пишет ИИ, а проверять приходится на бегу.
Как встроить ИИ-проверки кода в процесс так, чтобы это имело смысл
Когда процесс хотя бы минимально описан, на сцену уже можно выпускать ИИ-инструменты по полной. Когда я первый раз столкнулась с интеграцией ИИ-проверки кода в контекст ИСПДн, меня приятно удивило, насколько гибко это можно сделать без тяжелых DevSecOps платформ. По сути, вам нужен всего один дополнительный слой: текстовое описание правил работы с ПДн, доступов и обезличивания, которое ассистент получает вместе с кодом. В идеале этот текст укладывается в одну-две страницы и не уходит в крайности вроде «мы заботимся о конфиденциальности» без конкретики.
Дальше схема проста: разработчик (или вы сами, если пишете скрипты для n8n) перед заливкой в прод прогоняете код через ИИ с двумя вопросами: «есть ли тут нарушения этих правил» и «какие места выглядят подозрительно». Да, иногда ответы будут общими, иногда — избыточно осторожными, но в 3-4 кейсах из 10 ИИ действительно указывает на вещи, которые оголенным глазом пропускаешь. Особенно это заметно в цепочках интеграций, где данные гуляют по нескольким сервисам и парам десятков строк кода — там человеческий мозг привык доверять «оно же точно работает». ИИ в этом месте выступает тем самым занудой, который задает вопрос «а точно ли мы нигде не записали лишнее в лог».
Я поняла, что лучшая тактика тут — не пытаться сделать ИИ окончательным судьей, а использовать его как еще один голос в ревью. Если ИИ-код говорит «здесь возможно не хватает маскировки» или «здесь происходит передача на внешний домен», это не значит, что нужно немедленно ломать архитектуру, но это точно значит, что человек должен туда посмотреть. Со временем команда привыкает к такому формату, и запрос «ИИ исправить ошибки в коде» начинает звучать не как надежда на чудо, а как часть нормального цикла «написали — прогнали через ИИ — посмотрели глазами — задеплоили».
Где заканчивается ИИ и начинается человеческая ответственность
Нет, подожди, есть нюанс. При всей любви к автоматизации, в зоне ПДн есть вещи, которые нельзя (и не нужно) перекладывать на ИИ. Это принятие решений о целях обработки, установление сроков хранения, выбор правовых оснований, определение состава субъектов и их прав. Тут никакой ассистент не заменит бизнес-решения и юридическую экспертизу. ИИ может подсказать формулировки, помочь свериться с практикой, но не взять на себя ответственность. Особенно когда речь про биометрию или сложные профилирования, где штрафы в России уже измеряются в десятках миллионов.
На практике разграничение выглядит так: ИИ занимается кодом, люди — политиками и моделями угроз. Да, иногда ИИ помогает собрать драфт документа или подсказать структуру, но последняя правка и подпись все равно за человеком, который понимает, как компания работает и что она готова защищать.
Любой баг в коде ИИ, который вылезет в прод, в итоге будет интерпретирован через призму человеческих решений: утвердили ли вы политику, назначили ли ответственных, описали ли процессы, провели ли тесты.
В этом смысле ИИ — просто еще один участник команды, который не ходит на планерки и не отвечает на письма регулятора.
Получается, что лучшая защита от ошибок ИИ-кода — это не «не использовать ИИ», а выстроить понятную рамку: что он делает, что проверяет, какие ограничения у него есть, как люди над этим надстраиваются. И если в голове удерживать простую мысль «ответственность всегда на операторе ПДн», любые решения по автоматизации принимаются чуть медленнее, но заметно осторожнее. Поверь, это та медлительность, которая потом экономит месяцы на разборе инцидентов и переписке с Роскомнадзором.
Чем закончилась история Светы и сколько часов она в итоге сэкономила
Какие метрики мы заложили и что они показали через три месяца
Та ситуация с коллегой из начала — вот продолжение. Когда мы привели автоматизацию Светы в более-менее приличный вид, договорились сразу, какие метрики будем отслеживать, чтобы понять, работает ли все не только юридически, но и по смыслу. Взяли три простых числа: время обработки заявки от формы до появления в CRM, количество потерянных/дублирующихся лидов и время, которое Света тратит на подготовку еженедельной аналитики. Плюс отдельно отметили, были ли за этот период инциденты с ПДн или странные запросы от пользователей.
Через три месяца получилось достаточно наглядно. Среднее время попадания заявки в CRM сократилось с 2-3 часов «в ручном режиме» до 3-5 минут, включая самые загруженные дни. Потерянные лиды практически обнулились — технически там оставалась пара странных кейсов, но это уже были не баги ИИ-кода, а человеческий фактор на стороне клиентов. Время, которое Света тратила на аналитику, упало с двух вечеров в неделю до примерно 40 минут, и то в основном на интерпретацию данных. Если пересчитать это в часы, автоматизация вернула ей около 20-25 рабочих часов в месяц, которые раньше сжирали Excel и сверка таблиц.
С юридической стороны, за те же три месяца не было ни одного зарегистрированного инцидента с ПДн. Да, пару раз алерты от мониторинга поднимали тревогу: один раз из-за падения одного из узлов n8n, другой раз — из-за странного запроса к API со стороны старого лендинга. Но именно потому, что архитектура и процессы были описаны, эти ситуации решились в течение нескольких часов, не перерастая в утечки. Фактически, те самые меры, которые казались Свете «бюрократией» — реестр процессов, журнал инцидентов, тесты на синтетических данных — сэкономили ей не только часы, но и нервы.
Как компания избежала штрафов и к чему готова теперь
Вишенкой на торте стал неожиданный запрос Роскомнадзора. Не полноценная проверка, а точечный запрос по одной из форм на сайте, которая участвовала в автоматизации. Если честно, я в этот момент слегка напряглась, потому что такие истории редко заканчиваются просто перепиской. Но когда мы начали собирать ответы, вдруг обнаружилось, что все нужные документы и схемы у нас уже есть. Положение об обработке ПДн, уведомление, описание ИСПДн, модель угроз, реестр, схема архитектуры, даже короткое описание, как ИИ-код используется и каким образом тестируется на соответствие политике.
Через пару недель компания получила формальный ответ: замечаний по конкретному процессу нет, запрос закрыт. Да, это не официальный «знак качества», но для меня это был очень четкий сигнал, что выбранная модель «автоматизация плюс осознанное управление ПДн» работает. Света потом как-то сказала в коридоре: «Я раньше думала, что юристам платят за то, чтобы они нас тормозили, а теперь понимаю, что вы иногда просто разворачиваете нас от открытого люка» 🙂. Мне эта фраза запомнилась, потому что она хорошо отражает суть: ограничение скорости с ИИ-кодом часто воспринимается как помеха, но в ПДн это тот случай, когда ограничение — забота.
Сейчас компания уже смотрит дальше: планируют подключать более продвинутую аналитику, моделирование поведения клиентов, в перспективе — элементы персонализации. Мы сразу договорились, что при выходе в эти более сложные зоны, особенно если речь зайдет о биометрии или профилировании с юридическими последствиями, они не будут полагаться только на «ИИ найти ошибку в коде на питон» и быстрые тесты, а пойдут по полному циклу: DPIA, расширенная модель угроз, возможно, консультации с регулятором.
Фактически, история с багом в маскировке стала для них мягкой тренировкой перед более серьезными проектами, показав, что автоматизация и 152-ФЗ вполне могут жить в одном офисе без взаимной ненависти.
Чему научила нас вся эта история про ИИ-код и ответственность
Если отбросить детали, у Светы получилось ровно то, к чему я обычно подталкиваю клиентов: автоматизация, которая действительно экономит время, но не играет в рулетку с персональными данными. Ошибки в коде ИИ никуда не исчезли — они все равно иногда появляются в процессе доработок, новых форм, экспериментов с воронками. Но теперь они ловятся либо на этапе тестов на синтетике, либо через мониторинг, либо в рамках регулярных ревью кода и процессов, а не через жалобы пользователей или запросы регулятора.
Меня лично эта история еще раз убедила, что надежда на то, что «ИИ исправит ошибки в коде лучше, чем любой человек» — слишком naiv для 2025 года. ИИ для проверки кода на ошибки — это помощник, который усиливает ваши процессы, но не заменяет их. Если процесса нет, он лишь быстрее проводит вас по дороге от красивой идеи к потенциальному инциденту. Если процесс выстроен, он помогает экономить часы и, иногда, действительно спасает от глупых багов. Получается, что ключевой навык в этой игре — не писать или править код, а проектировать рамку, в которой и люди, и ИИ двигаются в одном направлении.
Что еще имеет смысл сделать тем, кто автоматизирует ПДн с ИИ
Какие практики стоит внедрить в ближайший месяц
Если ты дочитала до этого места и узнаешь себя в историях с n8n, чат-ботами, ИИ-подсказками в IDE и вечными «мы потом оформим по 152-ФЗ», я бы предложила не растягивать. За один месяц вполне реально перейти от хаотичной автоматизации к вполне управляемой, не нанимая армию консультантов и не переписывая всю архитектуру. Звучит амбициозно, но по шагам это норм. Я заметила, что такой «месячный спринт по ПДн» работает особенно хорошо у небольших команд: меньше игроков, проще договориться.
Первый шаг — честная инвентаризация автоматизаций: где в твоих процессах прямо сейчас живут ПДн и какие скрипты, боты, ИИ-код их трогают. Второй — фиксация этих процессов в одном месте, пусть даже в простой таблице. Третий — минимальное приведение к требованиям 152-ФЗ: уведомление, политика, реестр, назначение ответственного. Четвертый — встраивание ИИ-проверок кода не как разовой акции, а как части цикла разработки. Пятый — запуск хотя бы базового мониторинга и тестирования на синтетических данных. Это не делает тебя «идеальным оператором ПДн», но выводит из зоны хаоса в зону управляемого риска, где ошибки ИИ-кода не равно автоматический штраф.
Если хочется структурировать это глубже, я иногда выкладываю разборы подобных кейсов и чек-листы по автоматизации в своем Telegram-канале MAREN — там много про практическую сторону, без страха и с конкретикой. А на сайте promaren.ru можно посмотреть, чем я занимаюсь как AI Governance & Automation Lead и какие еще разборы у нас есть для российских команд, которые хотят, чтобы контент и процессы делались сами, а люди возвращали себе время.
Как продолжить путь без перегорания и паранойи
Точка, где мы сейчас, для многих компаний выглядит примерно так: ИИ-код уже в проде, автоматизации живут, ПДн обрабатываются, а вопросы «а что по 152-ФЗ?» поднимаются только, когда кто-то приносит новости о штрафах до 20 млн или историях с биометрией. Жить в таком подвешенном состоянии долго тяжело: или начинаешь параноить и тянуть тормоз на любую инициативу, или впадаешь в фатализм и делаешь вид, что «нас это не касается». Мне близок третий путь — аккуратный, но при этом уважительный к времени людей. Когда я строю такие системы, я всегда держу в фокусе две цифры: сколько часов автоматизация экономит и сколько часов она может отнять, если все пойдет не туда.
История Светы показала, что баланс возможен: автоматизация с ИИ-кодом, которая экономит 20+ часов в месяц и при этом не превращает компанию в мишень для Роскомнадзора. Для этого понадобились не чудеса, а довольно приземленные вещи: описание процессов, реестр ИСПДн, минимальная модель угроз, использование ИИ не как магической палочки, а как части цикла проверки кода, тестирование на синтетических данных и готовность человека в нужный момент сказать «стоп, давай проверим, что происходит с ПДн». Это звучит обыденно, но именно такие обыденные вещи и отличают проект, который переживает проверку, от того, который трясет при первом же запросе.
Если мысленно вернуться к той стиральной машине с ошибкой uE код, становится видно, что задача не в том, чтобы никогда не перегружать барабан, а в том, чтобы знать, где вообще находится инструкция, кто несет ответственность за ремонт и что делать, когда на дисплее загорается странная комбинация символов. С ИИ-кодом в автоматизации ПДн все очень похоже: ошибки будут, иногда серьезные, иногда смешные, но если у вас есть инструкция, люди, процессы и немного самоиронии, они перестают быть катастрофой и становятся частью нормальной жизни системы.
Если хочется перейти от чтения к действиям
Если хочешь структурировать все, о чем мы здесь говорили, и спокойно внедрять ИИ-код в рабочие проекты так, чтобы он экономил часы, а не подставлял под штрафы, начни с малого. Возьми один процесс с ПДн — любой, который прямо сейчас живет на скриптах, чат-боте или в n8n, — и прогоните его по тем вопросам, которые мы разбирали: какие данные проходят, где лежат, кто видит, что делает ИИ, как тестируется код, есть ли документы по 152-ФЗ. Уже этого будет достаточно, чтобы увидеть, где узкие места и где ошибка в коде ИИ может «стрельнуть» больнее всего.
Для тех, кто готов перейти от теории к практике, я регулярно разбираю реальные кейсы автоматизации, ИИ-агентов и ИСПДн в Telegram-канале MAREN — там можно посмотреть живые примеры, задать вопросы и увидеть, как другие компании в России решают похожие задачи без магии и хайпа. А если хочется спокойнее познакомиться с моим подходом и философией «white-data-зоны», можно заглянуть на сайт promaren.ru, где собраны проекты, разборы и материалы по автоматизации, которые помогают людям возвращать себе время, не забывая про 152-ФЗ.
Что еще важно знать про ошибки ИИ-кода и ответственность
Как распределяется ответственность за ошибки в коде ИИ между оператором и разработчиком?
Юридически в России ответственность перед Роскомнадзором несет оператор ПДн — компания, которая определяет цели и средства обработки и запускает систему в работу. Разработчик и подрядчики могут нести ответственность по договору и гражданскому законодательству, но штрафы по КоАП приходят оператору, даже если ошибку в коде допустил фрилансер или ИИ-ассистент. Чтобы частично перераспределить риски, имеет смысл прописывать в договоре с разработчиком обязанности по соблюдению 152-ФЗ и механизмы компенсации ущерба.
Можно ли полностью доверить ИИ поиск и исправление ошибок в коде, который обрабатывает ПДн?
Полностью полагаться на ИИ при обработке ПДн рискованно, потому что он не понимает весь контекст правовых требований и реальной архитектуры системы. ИИ хорошо справляется с находкой технических багов и типичных уязвимостей, но не заменяет ручное ревью с учетом 152-ФЗ, внутренних политик и моделей угроз. Оптимально использовать ИИ как дополнительный слой проверки поверх человеческого контроля и четко фиксировать, кто из людей подписывает решение «код готов к продакшену».
Что делать, если из-за бага ИИ-кода произошла утечка персональных данных?
В такой ситуации оператору ПДн нужно зафиксировать инцидент, провести внутреннее расследование и оценить масштаб нарушения прав субъектов. Далее важно в разумный срок уведомить Роскомнадзор, описать причины инцидента, принятые меры по устранению и предотвращению повторения, а также при необходимости уведомить самих субъектов данных. Параллельно стоит пересмотреть архитектуру, настройки ИИ-проверок кода, процессы тестирования и договоры с подрядчиками, чтобы снизить риск повторения подобной ситуации.
Как безопасно использовать ИИ для нахождения ошибок в коде на Python, если в нем обрабатываются ПДн?
Для начала стоит исключить загрузку реальных персональных данных в публичные ИИ-сервисы и использовать синтетические или обезличенные примеры в запросах. Далее имеет смысл дать ассистенту контекст в виде правил обработки ПДн, требований к обезличиванию и ограничениям по внешним сервисам, чтобы он подсвечивал возможные нарушения. После ответов ИИ-код все равно нужно просматривать вручную и тестировать на отдельном стенде, прежде чем вносить изменения в боевую ИСПДн с реальными ПДн.
Нужно ли уведомлять Роскомнадзор, если в ИСПДн добавляется новая автоматизация с ИИ-кодом?
Если новая автоматизация меняет цели или состав обрабатываемых ПДн, затрагивает новые категории субъектов или меняет условия их прав, уведомление Роскомнадзора нужно актуализировать. При доработках внутри уже описанной ИСПДн иногда достаточно обновить внутренний реестр и документы, но при существенных изменениях безопаснее направить новое уведомление. В любом случае добавление ИИ-кода в существующую систему требует пересмотра модели угроз и мер защиты, даже если уведомление формально остается прежним.
Можно ли использовать зарубежные ИИ-сервисы для анализа кода, если проект обрабатывает ПДн россиян?
Использовать зарубежные ИИ-сервисы для анализа кода можно, если при этом не передавать им реальные ПДн или фрагменты базы, позволяющие идентифицировать субъектов. Сам код без данных обычно не подпадает под ограничения локализации и трансграничной передачи, но нужно следить, чтобы в примерах и логах не оказались реальные идентификаторы. Для работы с чувствительными фрагментами лучше использовать локальные решения или закрытые контуры, чтобы не создавать лишних рисков с точки зрения 152-ФЗ и требований к локализации данных в РФ.