ИИ, разработка и контент обсуждаются сейчас повсюду, но мало кто задумывается о том, как все это выглядит с правовой точки зрения. Между тем вопросы по части интеллектуальной собственности и других юридических аспектов AI-разработки уже возникают и в ближайшее время будут становиться только актуальнее.
Представьте: ваша команда готовится к релизу. Модель обучена, тесты пройдены, инфраструктура развернута. Но тут в созвон заходит юрист и спрашивает: «На каких данных вы обучались? Проверяли ли вы лицензии библиотек? Есть ли у вас согласие на обработку персональных данных?» Как правило, особенно в крупных компаниях, после таких вопросов релиз откладывается надолго – как минимум на месяц, пока не будут устранены все риски.
Мы разберем три ключевые управленческие дилеммы и конкретные решения, которые работают на практике.
Первая – скорость против безопасности: как быстро выкатывать AI-решения и не получить штрафы или судебные иски.
Вторая – правовой комплаенс: когда следует проводить проверку – во время разработки, перед релизом или уже после инцидента.
Третья – распределение ответственности: кто в итоге заплатит, если что-то пойдет не так.
В завершение будет практический чек-лист, который можно сразу применять в работе.
Цена AI-ошибки для бизнеса
Начнем с главного вопроса: почему нельзя было поговорить об этом пару лет назад и почему через пару лет будет уже поздно? Потому что 2025–2026 годы, по моему мнению, – это момент, когда правовое регулирование искусственного интеллекта из теории плавно превращается в реальную юридическую практику с конкретными цифрами.
В Европе с февраля 2025 года действует Европейский акт об искусственном интеллекте. Предельные штрафы за разного рода нарушения достигают 35 млн евро или 7% годового оборота компании – в зависимости от того, какая сумма больше. Такие санкции предусмотрены, например, за использование запрещенных AI-практик: манипуляционных систем, социального скоринга и так далее. Для сравнения: это жестче, чем законодательство о персональных данных GDPR, где максимальный штраф составляет 20 млн евро или 4% оборота компании.
В США группа из 42 генеральных прокуроров штатов объединилась для контроля за применением искусственного интеллекта. Причиной стали расследования дискриминации в алгоритмах найма крупных компаний, кредитного скоринга и страхования.
Российская практика также активно формируется. Тенденция юридической практики в сфере IT в России, как и во многих других странах, заключается в том, чтобы аккумулировать лучшие примеры из зарубежной практики и адаптировать их к новой реальности. Уже существует ряд дел, о которых мы поговорим дальше. Если кратко: суды не наделяют искусственный интеллект правосубъектностью, ответственность всегда лежит либо на человеке, либо на организации.
Страховые компании с прошлого года также начали требовать определенные райдеры в сфере AI-безопасности. Дополнительные условия, связанные с искусственным интеллектом, уже появляются в полисах киберстрахования мировых страховых компаний. В рамках страхования приходится доказывать, есть ли у компании процессы комплаенса. Если их нет, страховое покрытие может быть меньше либо сама страховка обойдется дороже.
Здесь возникает парадокс, с которым сталкиваются практически все команды. С одной стороны, важна скорость: конкуренты не дремлют и регулярно выкатывают новые функции, инвесторы поджимают, а команда готова работать в режиме непрерывного развертывания. С другой стороны, это порождает определенные риски. Один неверный шаг – и компания оказывается в суде.
Один из недавних примеров – дело Stability AI против Getty Images. Сумма иска составила 1,8 млрд долларов: AI-сервис использовал датасет без проверки лицензионных условий Getty Images. В ноябре 2025 года основные претензии по авторским правам по этому делу уже были устранены. Возможно, стороны заключили мировое соглашение, но это не точно. Тем не менее дело показало, насколько дорого может обойтись игнорирование прав на данные.
Другой реальный кейс связан с Amazon. Еще в 2018 году компания разработала систему для автоматизации найма разработчиков. Система обучалась на резюме, полученных за десять лет, и большинство из них принадлежало мужчинам. В результате алгоритм начал дискриминировать женщин: он снижал рейтинг резюме, в которых упоминался женский шахматный клуб, и занижал оценки выпускниц женских колледжей. Amazon потратил год на исправление системы, но в итоге полностью закрыл проект, потому что риски репутационных и правовых потерь стали слишком серьезными.
Российские суды традиционно перенимают зарубежную практику. В нашем случае это лишь вопрос времени.
Три пути CI/CD
Первая управленческая дилемма – как сохранить скорость и не получить штрафы. Есть три пути, и у каждого из них есть свои плюсы и минусы.
Первый путь – Fast Track, быстрый, но рискованный вариант. Команда использует общедоступные SDK, берет популярные датасеты без глубокой проверки лицензий и минимально тестирует систему на алгоритмическую предвзятость. В результате деплой происходит за считаные недели. Но такая схема работает только до первого инцидента.
Что может пойти не так? Первый риск – нарушение авторских прав на обучающие данные. Мы уже говорили о деле Getty Images против Stability AI, где использовались изображения из интернета. Даже после частичного отзыва претензий компания потратила миллионы на юридическую защиту.
Второй риск – алгоритмическая предвзятость. Пример Amazon здесь достаточно показателен.
Третий риск – будущие суды и штрафы. Регуляторы дозревают медленно, но иногда применяют нормы ретроспективно. В нашей практике мы уже сталкивались с похожими ситуациями, например при вступлении в силу закона об использовании иностранных слов, а также норм, связанных с пропагандой в музыке и видеоконтенте.
Второй путь – Safe Track, то есть избыточное документирование. Это полная противоположность первому варианту. Здесь фиксируется каждый шаг, юристы внедряются во все процессы разработки, а на протяжении всей процедуры создаются целые тома документов, отражающие каждое действие разработчиков.
Safe track позволяет максимально снизить вероятность наступления рисков. Но одновременно растут и сроки, и бюджет разработки. Многие представители крупных корпораций наверняка знакомы с ситуацией, когда юристы на каждом шагу вклиниваются в процессы со своими регламентами.
Эти два пути – полные противоположности. Но существует и средний вариант: риск-ориентированный подход (Risk-Based).
Risk-Based в деле
Риск-ориентированный подход – это интеграция правовой функции в бизнес-процессы. Это сложно, но реально. При таком системном подходе правовая функция становится частью команды и перестает быть внешним контролером, всевидящим оком, которое только ищет нарушения регламентов компании.
Правовая функция участвует во всех этапах через механизмы согласования, но не блокирует работу, а консультирует команду и помогает принимать информированные решения. Формы участия могут быть разными: асинхронное согласование технических решений, регулярные чек-пойнты в ключевых контрольных точках продуктового цикла, а также системный процесс выявления рисков.
Этот процесс состоит из трех основных шагов. Рассмотрим их на примере.
Первый шаг – идентификация риска. Допустим, мы используем датасет X с лицензией Y, которая разрешает только некоммерческое использование.
Второй шаг – оценка толерантности к этому риску. С точки зрения бизнеса мы понимаем, что продукт коммерческий, поэтому потенциальные последствия судебного спора будут серьезными. При этом вероятность обнаружения может быть средней или, например, низкой, если код обфусцирован и нарушение трудно выявить.
Третий шаг – формирование рекомендаций, которым следует компания. Например, вариант А – заменить датасет на набор данных с лицензией Creative Commons, допускающей свободное, в том числе коммерческое, использование. Вариант Б – получить разрешение правообладателя и заложить резерв на возможные претензии.
При риск-ориентированном подходе скорость релиза сохраняется, а риски идентифицированы и документированы – это самая сложная часть. Бизнес принимает осознанное решение о собственном риск-аппетите: мы знаем проект, знаем о риске, оцениваем его определенным образом и принимаем решение.
Ключевой момент заключается в том, что юристы помогают бизнесу принимать информированные решения. Устранить все риски невозможно, и мы как юристы к этому не стремимся. Наша задача – сделать так, чтобы рисками можно было качественно управлять.
Три модели комплаенса
Вторая дилемма – когда проводить правовую проверку: во время разработки, перед релизом или уже после запуска и возникновения инцидента. Правильный ответ зависит от риск-профиля системы. Это касается не только искусственного интеллекта, но сосредоточимся именно на AI-системах.
Первая модель – Compliance by Design, то есть встроенный правовой комплаенс. Такой подход чаще встречается в крупных компаниях, где есть собственный правовой департамент и проверки проводятся на каждом этапе: при выборе данных, обучении модели, тестировании и последующем мониторинге. Это continuous compliance – непрерывное отслеживание инцидентов и соблюдения требований.
Такой подход необходим для высокорисковых систем, например в медицине или кредитовании. Здесь толерантность к рискам низкая, а ошибка может стоить жизни, здоровья или свободы учредителей – этого никто не хочет.
В качестве примера можно привести банковскую скоринговую систему для оценки кредитоспособности. С точки зрения европейского законодательства она относится к критическим системам и требует формирования полного пакета документов.
Вторая модель – финальная проверка, или Gate-Review. Она проводится один раз перед запуском продукта. Формируется чек-лист, например из 15–20 пунктов, и по нему юристы совместно с разработчиками проверяют продукт. После этого команда либо получает «зеленый свет» и выходит в релиз, либо дорабатывает систему, исправляя выявленные проблемы.
Эта модель применяется для среднерисковых AI-систем: маркетинговых инструментов, HR-tech – если исключить из него вопросы найма и говорить только об управлении персоналом, – клиентского обслуживания и рекомендательных технологий. Здесь толерантность к рискам средняя. Ошибка может привести не к угрозе жизни или свободе кого-либо из учредителей, а к штрафам или репутационным потерям. Это серьезно, но не катастрофично.
Наиболее распространенный пример – AI-чат-боты для клиентской поддержки. Перед запуском нужно проверить, нет ли утечки данных и какой-либо предвзятости, корректно ли обрабатываются запросы и так далее.
Третий вариант – реактивный постконтроль (Reactive): проверка после запуска и реакция на инциденты. Систему запускают, мониторят и исправляют, если что-то пошло не так.
Такой подход можно применять для низкорисковых систем: внутренних инструментов в корпоративном контуре, прототипов и экспериментальных функций без доступа к реальным, особенно критичным, данным. Здесь толерантность к рискам высокая, и компания готова принять последствия возможных ошибок.
Опасность все равно остается. Стоимость исправления после релиза может быть кратно выше, чем при выявлении риска на среднем или начальном этапе. Если инцидент становится публичным, к этому добавляются репутационные потери. Но в целом это рабочая схема для низкорисковых систем.
Российская судебная практика
Российские судебные дела уже начинают формировать правила игры. Рассмотрим наиболее релевантную практику.
Первое дело – Reface против «Бизнес-аналитики». В кругу юристов это, пожалуй, самое известное российское дело об искусственном интеллекте.
Возможно, вы видели рекламное видео, в котором человек с лицом Киану Ривза постоянно заходит в комнату и проверяет, выключен ли утюг. Эту рекламу создала Reface Technologies. Ответчик, компания «Бизнес-аналитика», использовал видео без разрешения истца, после чего правообладатель обратился в суд.
Ответчик исходил из того, что созданный с помощью AI материал не охраняется авторским правом и его можно свободно использовать. Суд с этим не согласился. Он приравнял использование дипфейк-технологии к применению других инструментов – например, Photoshop или программ-интерпретаторов. В данном случае технология использовалась исключительно как инструмент в руках человека, а творческий характер конечному результату придавал человек.
Главный вывод: искусственный интеллект – это прежде всего инструмент. Конечную ответственность за то, что мы создали с его помощью, несем мы, люди.
Второе дело касалось защиты изображения, созданного с использованием искусственного интеллекта. Кто-то использовал эту картинку без разрешения, и правообладатель обратился в суд, чтобы защитить свои права.
Чтобы подтвердить, что изображение было создано именно истцом, он приложил исходные файлы – картинки, которые сам создал вручную, а затем переработал с помощью искусственного интеллекта. Суду этого оказалось достаточно: он признал объект охраняемым авторским правом и защитил права истца.
Вывод для нас: процессы следует по возможности документировать. Сохраняйте исходники, промежуточные версии, технические задания и промпты. Иногда даже подрядчики требуют сохранять промпты. Если впоследствии придется доказывать авторство, это станет страховкой на будущее.
Существует и позиция Суда по интеллектуальным правам по дипфейкам: они защищаются авторским правом, если присутствует вклад человека. Это уже базовый принцип интеллектуальной собственности. Объект, в том числе код, должен быть выражен в объективной форме – его можно увидеть или иным образом воспринять – и создан творческим трудом человека.
Зафиксируем: AI может быть инструментом, но конечный результат защищается авторским правом только при наличии творческого вклада человека.
Что НЕ работает
Рассмотрим варианты, которые точно не работают, хотя на практике их нередко используют как наиболее интуитивно понятный способ решить проблему с искусственным интеллектом. Ситуация сложная, специального закона пока нет, хотя уже появляются слухи, что в России разрабатывается его прототип. Поэтому многие проекты пытаются организовать комплаенс по-своему.
Первая частая ошибка – создание этических комитетов по искусственному интеллекту. Собираются крупные или не очень крупные руководители, обсуждают, что можно сделать, и формируют какие-либо документы.
В реальности такая группа собирается раз в квартал и обсуждает абстрактные вещи: транспарентность, открытость, безопасность, общие принципы защиты. Но это не работает, потому что комитет оторван от операционной деятельности. Нет интеграции в реальные процессы разработки и влияния на управленческие решения.
Вторая ошибка, иногда вытекающая из первой, – создание сложных политик без их внедрения. Я видел политики использования искусственного интеллекта в деятельности компании объемом в сотни страниц. Процедуры и матрицы ответственности – это хорошо, но в реальности такие материалы зачастую никто не читает и, будем честны, никто не применяет.
При личном общении с разработчиками я слышал примерно следующее: «Да, у нас есть политика, ее нужно использовать. Но тогда мы будем работать бесконечно».
Такой подход не работает прежде всего потому, что документы слишком сложны для понимания и применения. Никто не задается вопросом, как сделать их проще и понятнее для разработчиков. Кроме того, отсутствует механизм влияния и адаптация требований под конкретные проекты.
Решение 1: Карта рисков
Для решения описанных управленческих дилемм существует несколько работающих инструментов. Первый – конкретная карта рисков для каждого AI-проекта.
Сначала нужно идентифицировать все точки правового риска. Мы смотрим на жизненный цикл проекта и на то, что именно делаем.
Если работаем с датасетами, обращаем внимание на лицензии, персональные данные и права на базы исходных данных. Если используем конкретные модели, смотрим на компоненты, условия их использования и патенты. Если применяем output, то есть результат работы системы, например пишем код при помощи AI-агента, выясняем, какие права возникают на результат деятельности этого агента и кто отвечает за вредоносный контент, который мы ему передали.
Затем каждый риск оценивается по матрице: учитываются вероятность наступления и степень влияния. Например, вероятность обнаружения нарушения может быть низкой, если используется обфусцированный код. Но влияние будет высоким, если мы без разрешения взяли чужой код и нарушили авторские права.
После этого риски приоритизируются по простой системе: красные, желтые и зеленые – высокие, средние и низкие.
Самое главное – назначить владельца риска. У каждого критического риска должен быть конкретный владелец: человек или подразделение, которое отвечает за его митигацию. Если такого владельца нет, система несостоятельна.
Решение 2: Бизнес-процесс
Второй инструмент – процессы согласования, адаптированные к жизненному циклу проекта. Они не должны быть оторваны от разработки, как это зачастую происходит в крупных компаниях: у правовой функции есть собственный процесс, который существует отдельно от всех остальных. Нет, правовая функция должна быть максимально интегрирована в разработку.
Вариантов может быть много. Обычно это встраивание чек-пойнтов в цифровой жизненный цикл проекта. В первую очередь речь идет о таких точках, как инициация, выбор данных, разработка и постконтроль после релиза.
Существуют щадящие и при этом эффективные формы участия юристов. Это может быть асинхронное ревью документов и решений. Мне, например, наиболее импонируют технические и инвестиционные комитеты, где решения по конкретным проектам совместно принимают несколько функций: экономика, бухгалтерия, маркетинг, продуктовая команда и юристы.
Еще один вариант – юрист в составе продуктовой команды. Но в этом случае он должен обладать хорошим техническим бэкграундом, чтобы понимать, что происходит в проекте.
Главный принцип: процессы должны быть легковесными, быстрыми и интегрированными в то, что команда уже делает. Не следует создавать параллельную бюрократию – нужно встраиваться в существующий workflow.
Чек-лист для правового аудита
Для практической работы можно использовать приложенный к статье чек-лист, который позволяет бесшовно встроить правовой комплаенс в разработку. В нем вопросы разделены по матрице рисков: учитываются вероятность наступления и обнаружения риска, степень его влияния и другие параметры.
Для каждого проекта можно создать страницу в Confluence с этим чек-листом или отдельную страницу с заполненными ответами. Формат может быть любым – важно, чтобы проверка была встроена в привычный рабочий процесс команды.
Кто в итоге заплатит?
Последний блок связан с самым неприятным вопросом: когда что-то идет не так, кто за это заплатит?
Здесь нужно учитывать несколько важных факторов.
Первое: суды не наделяют искусственный интеллект правосубъектностью. По-русски говоря, ИИ сам не принимает решения в юридическом смысле, он не человек и не человекоподобный субъект. Как бы мы его ни гуманизировали, он не несет никакой ответственности.
Из этого следует важный вывод: ответственность за все, что сделано при помощи AI, всегда будет лежать на людях или организации.
Второе: в суд подадут на одного, а в итоге заплатить может другой. Истец обычно предъявляет требования тому, кого легче всего найти. Например, если компания самостоятельно разрабатывает AI-модель, первым делом обычно обращаются к владельцу или оператору системы. Затем в ходе внутреннего разбирательства может выясниться, что проблема возникла по вине подрядчика или субподрядчика.
Сначала недовольный пользователь найдет уязвимость и взыщет деньги с владельца системы. После этого владелец пойдет дальше по цепочке с регрессным требованием. Возникает своеобразная лестница, по которой ответственность спускается от одного контрагента к другому.
Третье: существуют пределы ограничения ответственности. Даже если в договоре написано, что ответственность ограничена, это работает не всегда.
Ограничение ответственности не действует, если нарушение было умышленным, то есть мы специально создали предвзятый ИИ. Оно также может не применяться к деликтам, то есть причинению вреда жизни и здоровью, например в MedTech, к злоупотреблениям и намеренному искажению фактов или мошенничеству. Мы знаем, какие искажения, например, могут возникать у DeepSeek: многие видели такие видео и сами пытались добиться от системы правды в некоторых вопросах.
Отдельная категория – потребительские споры. Закон о защите прав потребителей не позволяет безусловно ограничить ответственность перед потребителем, и владельцы AI-систем не являются исключением.
Кто и как отвечает в AI-экостистеме
Первая модель касается работника, то есть разработчика – физического лица. Здесь можно выдохнуть. Ответственность работника наступает по трудовому законодательству и, что важно, обычно ограничена средним месячным заработком, если у работника не было умысла сделать что-то плохое или грубой неосторожности.
Грубую неосторожность тоже трудно доказать, поскольку в трудовых спорах суды чаще встают на сторону работников. Работодатель редко предъявляет требования к работнику. Закон намеренно делает перекос в сторону работника, потому что с точки зрения права он является слабой стороной: с одной стороны – большая компания, с другой – обычный работник, который выполняет свою работу.
Основная ответственность разработчика как подрядчика – договорная ответственность перед заказчиком. Типичные модели предусматривают фиксированную границу, например ограничение суммой контракта, а также отдельные лимиты для нарушений в сфере интеллектуальной собственности, персональных данных и других областях. В договорах могут быть предусмотрены и положения о возмещении ущерба.
Заказчик отвечает перед конечными пользователями и третьими лицами. Владелец системы часто несет основное бремя, даже если в произошедшем виноват разработчик. В дальнейшем заказчик может предъявить требования разработчику.
Заказчик может защищаться через EULA, то есть пользовательскую оферту, а также через договоры с разработчиками, в которых можно прописать ограничения ответственности.
Пользователь отвечает по пользовательскому соглашению или лицензии. Например, если он незаконно использует платную подписку на AI-сервис, ответственность может выражаться в блокировке. Обычные ограничения также устанавливаются условиями использования. При этом для B2C-пользователей такие ограничения могут быть оспорены.
Если компания не приобретает Enterprise-версию AI-агента, а использует бесплатный инструмент для работы с кодом, при нарушениях со стороны пользователей иногда невозможно полностью избежать неограниченной ответственности.
Владелец системы может быть отдельным лицом, не совпадающим с заказчиком, но по цепочке он отвечает аналогичным образом.
Что делать? Защита от рисков
Разработчикам следует включать в контракты четкие ограничения ответственности. Также нужно требовать от заказчиков заверения и гарантии законности данных, которые они передают в разрабатываемую модель. Кроме того, необходимо оформлять условия о возмещении ущерба в сфере интеллектуальной собственности. Сейчас этот вопрос особенно актуален, и его обязательно следует учитывать.
Для заказчиков главный принцип – использовать зеркальные меры ответственности. Если разработчик дал вам определенные гарантии, пользователям следует обещать то же самое и не больше.
Нужно документировать все решения, желательно фиксировать варианты письменно и сохранять исходники – как в деле, о котором мы говорили ранее.
Для всех действует общий принцип: лучше писать, чем не писать. Если вы провели внутреннюю проверку, задокументируйте ее. Если приняли определенный риск, лучше зафиксировать это в бюджете или ином документе, а не держать в уме.
Следует отслеживать всю цепочку ответственности и создания кода: откуда взяты данные, кто принял то или иное решение, какие рассматривались альтернативы и так далее.
В идеальном мире все риски распределены справедливо. Но в реальности платит тот, у кого хуже юристы или хуже договор. Поэтому лучше все документировать.
Ключевые выводы
Подытожим три ключевые дилеммы.
Для сохранения скорости нужен риск-ориентированный подход. Он позволяет не останавливать разработку и при этом избегать критических рисков.
Модель комплаенса следует выбирать под риск-профиль системы: встроенный Compliance by Design, финальный Gate-Review или реактивный постконтроль (Reactive).
Искусственный интеллект не несет ответственности. Суды рассматривают действия людей и компаний, поэтому ответственность нужно заранее распределять договорами.
Работающие решения – это карта правовых рисков, легкие процессы согласования, встроенные в жизненный цикл, чек-лист для правового контроля и четкое распределение ответственности через договоры.
Неосязаемые ключевые правила:
Первое – интегрируйте правовую функцию в существующие процессы. Не создавайте параллельную бюрократию: она всегда работает хуже, чем встроенное участие юристов.
Второе – по максимуму документируйте все решения. Это ваша страховка.
Третье – распределяйте ответственность договорами до возникновения проблем, а не после.
Не игнорируйте лицензии на открытые данные. Если что-то находится в открытом доступе в интернете, это не означает, что материал доступен всем без ограничений. Всегда существуют определенные условия, в том числе условия со звездочкой.
Не ограничивайтесь финальной проверкой для высокорисковых систем. Чем выше риск системы и вероятность его реализации, тем важнее проводить проверку на ранних и промежуточных этапах. Лучше перепроверить, чем недопроверить.
Не полагайтесь на аргумент «виноват AI». Суды его не примут и в первую очередь предъявят требования вам. Это грустно, но это правда.
Начать следует с одного пилотного AI-проекта. Возьмите небольшую команду с участием юриста, пройдите весь чек-лист, примите ключевые решения по рискам, а затем масштабируйте найденные паттерны.
И помните: комплаенс не замедляет AI-разработку. Он защищает бизнес и дает уверенность для масштабирования.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
