Обязательства по безопасности, которые уже распространяются на Вас как на независимого разработчика

Среди независимых разработчиков широко распространено убеждение, что регулирование в области безопасности и приватности касается только компаний — что обязательства возникают, когда Вы регистрируете юрлицо, нанимаете DPO или подписываете контракт с крупным заказчиком. Это неправда, и уже много лет как неправда. Если Вы фрилансер или инди-разработчик, работающий с данными клиентов, ряд обязательств уже распространяется на Вас сегодня, лично, при Вашем текущем масштабе. Эта статья рассказывает о том, какие это обязательства, называет регламенты, из которых они происходят, и заканчивается практическим вопросом, который действительно важен: что конкретно сейчас открыто на Ваших аккаунтах?

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

По GDPR фрилансер, обрабатывающий данные клиента, является обработчиком — с прямыми обязательствами

Если клиент из ЕС (или клиент, чьи пользователи находятся в ЕС) передаёт Вам персональные данные — базу пользователей для миграции, продакшн-систему для отладки, выгрузку для анализа — Вы почти всегда выступаете как обработчик данных (data processor) по смыслу GDPR, а в некоторых проектах (когда Вы сами решаете, что собирать и зачем) — как контролёр (controller). Ни один из этих статусов не требует наличия компании. Определения GDPR в статье 4 привязаны к понятию «физическое или юридическое лицо» — человек с ноутбуком подпадает под это определение.

Этот статус влечёт прямые, персональные обязательства:

• Статья 28 требует, чтобы Ваша обработка данных для клиента регулировалась договором — соглашение об обработке данных (DPA), которое Вам постоянно присылают корпоративные клиенты, это не бюрократический театр; это юридическое требование для Вас обоих, обязывающее Вас к конкретным обязательствам по безопасности.
• Статья 32 требует от Вас реализации «надлежащих технических и организационных мер» для защиты обрабатываемых персональных данных — соразмерных риску, включая контроль над тем, кто и что может получить к ним доступ.
• Статья 33 требует от обработчика уведомить контролёра «без неоправданной задержки» после того, как ему стало известно об утечке персональных данных — что предполагает, что Вы вообще в состоянии узнать об утечке.
• Статья 82 даёт субъектам данных право на компенсацию от обработчиков за ущерб, причинённый обработкой, нарушающей регламент, а статья 83 подкрепляет всю систему административными штрафами, которые за наиболее серьёзные нарушения могут достигать двадцати миллионов евро или четырёх процентов годового мирового оборота — в зависимости от того, что больше.

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

Закон ЕС об ИИ добавляет обязательства для операторов систем ИИ

Если Ваша работа с клиентами теперь включает встраивание ИИ в продукты — ассистента в приложении клиента, ИИ-агента, автоматизирующего рабочий процесс, модель, принимающую решения, влияющие на людей — то EU AI Act (Закон ЕС об ИИ) имеет к Вам отношение. Закон регулирует не только компании, обучающие модели; он налагает обязательства на операторов (deployers) — тех, кто использует системы ИИ под собственной ответственностью в профессиональном контексте.

Статья 26 устанавливает обязательства операторов для высокорисковых систем ИИ, включая использование систем в соответствии с инструкциями, обеспечение надлежащего человеческого надзора и мониторинг функционирования. Статья 4 требует как от поставщиков, так и от операторов обеспечить достаточный уровень грамотности в области ИИ у людей, работающих с такими системами от их имени. А статья 99 подкрепляет систему административными штрафами за несоблюдение. Какие именно обязательства применяются в конкретном проекте, зависит от того, что делает система, и от категории риска, к которой она относится — но фраза «я её только интегрировал, а не создавал» — это именно та роль, для которой и была написана категория «оператор».

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

Ваши корпоративные клиенты уже регулируются — и их обязательства спускаются на Вас

Даже если Вы никогда не касаетесь персональных данных ЕС и никогда не внедряете систему ИИ, есть третий источник обязательств по безопасности, который применяется практически к любому фрилансеру, работающему с бизнесом любого размера: договоры. Корпоративные клиенты работают в рамках отчётов SOC 2, сертификаций ISO 27001, требований к обработчикам по статье 28 GDPR и программ управления поставщиками, которые их аудиторы реально проверяют. Эти программы не различают поставщика с 500 сотрудниками и поставщика в одном лице. Поставщик есть поставщик.

Именно поэтому анкета по безопасности приходит раньше, чем сам договор. Ваш клиент обязан — своим фреймворком, своим аудитором или собственными клиентами — собирать доказательства безопасности от тех, кому он передаёт данные. Включая Вас. Фрилансеры, способные ответить убедительно («вот что имеет доступ к моей среде разработки, вот как я это контролирую, вот доказательства»), закрывают такие сделки быстрее тех, кто импровизирует. Мы писали о корпоративной версии этой динамики в статье «что требуют аудиторы для управления ИИ в 2026 году»; версия со стороны поставщика попадает к Вам на стол в виде анкеты.

Во что реальный инцидент безопасности обходится независимому разработчику

Если говорить о рисках честно: инцидент безопасности в клиентском проекте может означать прямую финансовую ответственность по пункту об индемнификации в Вашем договоре, может означать ответственность обработчика по статье 82 GDPR, если были затронуты персональные данные, и — что наиболее конкретно для фрилансера — может означать конец отношений с клиентом и рекомендации, которая к ним прилагалась. Для консультанта-одиночки репутационный актив — это и есть весь бизнес. Ничто из этого не экзотическая гипотеза; это обычная цепочка последствий, когда скомпрометированные учётные данные или интеграция с избыточными правами превращаются в инцидент с данными клиента.

Так что же на самом деле открыто на Вашем аккаунте прямо сейчас?

Вот неудобная, конкретная версия вопроса. Ваша работа с клиентами почти наверняка хранится на личном аккаунте GitHub. За годы проектов на этом аккаунте накопились:

• Установленные GitHub Apps — боты для деплоя, инструменты CI, ИИ-ассистенты — каждый из которых держит право доступа, которое Вы одобрили один раз и, вероятно, никогда больше не пересматривали. Некоторые из них имеют права записи или администратора на всё, чем Вы владеете. Некоторые принадлежат проектам, завершившимся в 2024 году.
• Deploy keys (ключи развёртывания) — необслуживаемые SSH-учётные данные, лежащие на серверах, некоторые с правом записи в репозиторий, который они должны были только читать. Если такой сервер скомпрометирован, deploy key с правом чтения-записи — это путь для внедрения кода в продукт клиента.
• Коллабораторы — люди, добавленные во время сотрудничества, которое уже завершилось, но всё ещё имеющие право записи, в том числе в публичных репозиториях.
• Открытость репозиториев — какие из Ваших репозиториев публичны и что в них содержится, — это сам по себе вопрос инвентаризации, на который большинство разработчиков не могут ответить по памяти.

Каждый из этих пунктов машиночитаем через собственный API GitHub, а значит, каждый из них можно проверить — не полагаясь на память, а перечислив, что реально имеет доступ сегодня. Именно такую инвентаризацию теперь формирует коннектор GitHub от 8200.dev — не только для организаций, но и для личных аккаунтов: подключите свой личный логин GitHub, и сканирование перечислит установленные приложения и их права доступа, deploy keys и то, доступны ли они только для чтения, коллабораторов по каждому репозиторию и находки, которые вытекают из этого графа — забытого бота с правами администратора, deploy key с возможностью записи, устаревшее приложение, к которому никто не притрагивался год.

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

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

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