Кто отвечает за ошибку ИИ: что на самом деле сказано в 243-ФЗ
Статья об ответственности уместилась в отсылку к общему законодательству. Разделения ролей между разработчиком, оператором и пользователем в законе нет. Разбираем, какие нормы работают вместо специальных и что стоит закрыть договором, пока подзаконных актов не существует.
Коротко
243-ФЗ не создал ни специальной ответственности за ошибку модели, ни разделения ролей между разработчиком, оператором и пользователем. Статья 11 отсылает к общему законодательству, и на этом заканчивается.
Ответственность при этом никуда не делась: работают те же нормы, что и до закона, — договорные, деликтные, требования 152-ФЗ и отраслевое регулирование. Изменилось только ожидание, что закон расставит роли за участников проекта.
Главное: границу между вендором и заказчиком сейчас проводит договор. Эту работу можно сделать до появления подзаконных актов — она от них не зависит.
По состоянию на 14 сентября 2026 года. Подзаконных актов и правоприменительной практики по 243-ФЗ на эту дату нет. Материал носит аналитический характер и не является юридической консультацией.
Вопрос об ответственности приходит раньше вопроса об архитектуре. На встрече по пилоту его поднимает юридическая служба или директор по рискам — раньше, чем команда доходит до схемы контура. Формулировка почти всегда одна: хорошо, а если система ошибётся — кто отвечает?
До июля 2026 года ответ был неудобным, но понятным: специальных правил нет, разбираться будут по общим. От закона об ИИ ждали, что этот пробел он закроет. В мартовской редакции законопроекта конструкция ответственности выглядела куда подробнее; в подписанный текст она не дошла.
Дальше — о том, что именно сказано в статье 11, какие нормы работают вместо специальных, где у оператора возникает реальный риск и что имеет смысл зафиксировать в договоре с вендором прямо сейчас. Материал рассчитан на тех, кому предстоит объяснять это внутри компании: руководителей ИБ, корпоративных юристов, владельцев процессов, где модель уже подсказывает решения.
Что сказано в статье 11
Статья об ответственности в законе есть, и состоит она из отсылки: участники отношений в сфере искусственного интеллекта несут ответственность в соответствии с законодательством Российской Федерации. Дальше — ничего. Ни распределения между разработчиком модели, оператором системы и конечным пользователем. Ни презумпций. Ни критериев освобождения. Ни специальных составов правонарушений.
Формулировку стоит сверять по официальной публикации: publication.pravo.gov.ru, номер опубликования 0001202607260003. Пересказы расходятся между собой, и по этой статье особенно заметно — её излагают то как «закон ввёл ответственность за ИИ», то как «ответственности не предусмотрено». Оба варианта неточны. Постатейный разбор действующего текста мы публиковали отдельно.
Как из проекта уходили уровни риска, реестр доверенных моделей и развёрнутая конструкция ответственности — это хроника прохождения законопроекта. Она полезна для понимания логики регулятора, но описывать через неё действующие правила нельзя: в подписанном тексте этих институтов нет.
Что работает вместо специальных норм
Юридический смысл отсылки простой: специальных правил нет, значит применяются общие. Их набор известен и никак не связан с тем, участвовала ли в решении модель.
Если ущерб возник у контрагента по договору, работают правила о возмещении убытков и об ответственности за нарушение обязательства. Для предпринимательской деятельности она наступает независимо от вины, если стороны не договорились об ином, — эта оговорка в договорах с ИТ-подрядчиками появляется почти всегда, и именно вокруг неё идёт торг. Если вред причинён третьему лицу вне договора, применяются нормы о деликте, где вина причинителя предполагается и опровергать её придётся ему.
Для решений, затрагивающих граждан, добавляются правила о вреде вследствие недостатков товаров, работ и услуг и законодательство о защите прав потребителей. Если в контуре обрабатываются персональные данные, действует свой режим ответственности оператора — разбор требований 152-ФЗ к ИИ-системам у нас есть отдельно.
Часть юристов обсуждает применение к автономным системам конструкции источника повышенной опасности, то есть ответственности без вины. Практики применительно к ИИ нет, и позиция спорная: суды традиционно применяют эту норму к деятельности определённого рода, и программное обеспечение под неё до сих пор не подводили. Следить за дискуссией имеет смысл, строить на ней договорную защиту — преждевременно.
Ещё одно, о чём приходится напоминать почти на каждом обсуждении. Ни 243-ФЗ, ни Гражданский кодекс не делают модель субъектом права. Отвечает лицо. Спор идёт только о том, какое именно и в каком объёме.
Четыре роли, которые закон не развёл
Разработчика закон определяет, остальных участников цепочки — нет. При этом в реальном проекте их как минимум четверо, и обязанности между ними приходится распределять вручную.
| Роль | Что делает | Чем рискует | Чем закрывается |
|---|---|---|---|
| Разработчик модели | Обучает базовую модель, определяет её свойства и лицензию на веса | Претензии по правам на обучающие данные; с 1 марта 2027 года — обязанности статьи 8 для обладателей суверенного или национального статуса | Лицензия на веса, техническая документация, гарантии и возмещение в договоре поставки |
| Интегратор | Разворачивает модель в контуре, настраивает RAG, интегрирует с источниками | Договорная ответственность за качество и сроки работ, за доступ к данным заказчика в ходе проекта | Методика приёмки, SLA, поручение на обработку персональных данных |
| Оператор системы | Эксплуатирует систему в своих процессах, выпускает решение наружу | Ответственность перед третьими лицами и регуляторами, убытки от ошибочных решений, последствия утечки | Регламент проверки ответов человеком, журналирование, право регресса к вендору |
| Пользователь | Применяет подсказку модели в конкретном рабочем действии | Перед третьим лицом отвечает работодатель; у самого сотрудника — дисциплинарная и материальная ответственность в пределах, установленных трудовым законодательством | Инструкция, обучение, зафиксированное определение того, что считается решением системы |
Ответственность разработчика ИИ: почему она редко доходит до заказчика
В большинстве корпоративных внедрений первая строка таблицы к участникам проекта отношения не имеет. Интегратор, развернувший открытую модель в контуре заказчика, разработчиком базовой модели не является: он её не обучал. Заказчик становится оператором. Разработчик остаётся где-то за периметром сделки — иногда это зарубежная лаборатория, иногда российская команда, выложившая веса под открытой лицензией, и предъявить ей претензию по качеству ответа практически невозможно.
Отсюда смещение центра тяжести. Оператор — тот, чьё решение уходит наружу, к клиенту, контрагенту или регулятору. Он отвечает первым, а дальше пытается переложить часть последствий на вендора в объёме, который заранее записан в договоре. Если не записан, объём равен нулю.
Регресс при этом работает не так симметрично, как выглядит в таблице. К разработчику открытой модели он практически недоступен: лицензия на веса почти всегда исключает гарантии качества и пригодности для конкретных целей, и договора с вами у разработчика нет. К интегратору регресс возможен, но упирается в предел ответственности в его договоре и в необходимость доказать, что ущерб вызван его работами, а не составом данных, который готовил заказчик. Отсюда практическое следствие: спор о качестве корпуса дешевле закрыть актом на этапе подготовки данных, пока стороны ещё не в конфликте.
Где у оператора возникает риск
Ошибочный ответ внутри процесса. Самый частый и самый скучный сценарий. Ассистент по внутренней нормативке отвечает по недействующей редакции регламента: в архиве лежат обе версии, признака актуальности у документа нет. Модель отработала штатно — нашла релевантный фрагмент и процитировала. Спор о качестве системы при этом начинается с вопроса, чьей зоной ответственности была подготовка корпуса.
Утечка через контур. Здесь ответственность урегулирована подробно и давно, а требования 152-ФЗ никак не зависят от закона об ИИ. Вектор при этом редко выглядит как взлом. Регулярно срабатывают права доступа в источниках, из которых собирался индекс: модель по умолчанию видит весь корпус, и разграничение прав на уровне пользователя нужно проектировать отдельно. Второй регулярный источник — журналы промптов и ответов: в них попадают фрагменты документов, а хранятся они в системе, которой нет в модели угроз. Отдельная категория инцидентов связана с манипуляцией моделью через содержимое обрабатываемых документов; разбор атак на LLM в закрытом контуре мы делали раньше.
Вред третьему лицу. Реже, но сложнее всего. Клиент получил отказ, тариф или оценку, в подготовке которых участвовала модель, и оспаривает результат. Разбор упирается в воспроизводимость: какая версия модели работала, какой был системный промпт, какие документы попали в контекст, кто утвердил результат. Если эти данные не сохранялись, позиция оператора строится на объяснениях, а позиция второй стороны — на самом факте убытка.
Отсюда правило первых суток: получив претензию, журналы за спорный период и текущую версию модели вместе с системными инструкциями выгружают и фиксируют отдельно — до того, как их перезапишет ротация или плановое обновление. Про страхование такой ответственности спрашивают почти всегда; на российском рынке подобные полисы пока штучные, и закладывать их в план снижения риска рано.
Как распределить ответственность договором
Пока специальных норм нет, договор остаётся единственным местом, где роли фиксируются заранее, а не в момент разбирательства. Ниже — то, на что стоит смотреть в договоре с ИИ-подрядчиком. Это ориентиры для внутреннего обсуждения; формулировки под конкретную сделку готовит юрист.
Три формулировки, которые стоит держать под рукой
Исключения из предела ответственности. «Ограничение ответственности, установленное настоящим пунктом, не применяется к убыткам, возникшим вследствие разглашения или утраты персональных данных, нарушения прав третьих лиц на результаты интеллектуальной деятельности, а также умышленных действий Исполнителя».
Данные заказчика и производные. «Исполнитель не вправе использовать данные Заказчика, включая журналы запросов и ответов, векторные представления корпуса и кэш генераций, для обучения или дообучения моделей, а также передавать их третьим лицам».
Смена версии. «Замена базовой модели, её весов или системных инструкций производится по предварительному письменному согласованию с Заказчиком; для сегмента, прошедшего аттестацию, — после оценки влияния на аттестованную конфигурацию».
Это заготовки для разговора с юристом, а не готовый текст договора: они не учитывают ни предмет вашей сделки, ни применимое к ней регулирование.
Как это выглядит в переговорах — в таблице ниже. Левая колонка описывает типичную первую редакцию, которую присылает вендор, правая — позицию, к которой стоит двигаться заказчику.
| Параметр | Типичная редакция вендора | Ориентир для заказчика |
|---|---|---|
| Предел ответственности вендора | Ограничение процентом от цены договора, косвенные убытки исключены | Цена договора или годового вознаграждения; из-под предела выведены утечка персональных данных, нарушение прав третьих лиц, умысел и грубая неосторожность |
| Хранение журналов промптов, ответов и версий | Короткий срок хранения либо условие отсутствует | Не менее 12 месяцев, с возможностью выгрузки на стороне заказчика |
| Реакция на инцидент с качеством ответов | Общий срок ответа на обращение, без обязанности воспроизвести инцидент | Фиксация в течение суток, совместный разбор с воспроизведением — 5 рабочих дней |
| Смена базовой модели или весов | Право вендора без уведомления | Уведомление за 30 дней, для аттестованного сегмента — предварительное согласование |
| Использование данных заказчика для дообучения | Не оговорено | Прямой запрет, включая производные: логи, векторные представления, кэш генераций |
Левая колонка описывает то, что чаще всего оказывается в первой присланной редакции, — по нашей договорной практике, без претензии на рыночную статистику. Правая — не норматив, а позиция, с которой имеет смысл входить в переговоры: конкретные сроки и пределы зависят от предмета сделки и переговорной силы сторон.
Ревизия портфеля договоров упирается в объём: у крупного заказчика это десятки документов разных лет, где условия об ответственности написаны по-разному. Сравнение редакций, поиск расхождений и подготовка протокола разногласий — та часть работы, которую закрывает ContractGuard, ИИ-ассистент юридической службы. Юридическую квалификацию он не заменяет и решение не принимает: снимает механическую часть, оставляя юристу оценку.
Что меняет аттестованная среда
Инфраструктура ответственность не переносит. Оператор остаётся оператором независимо от того, где выполняется инференс. Меняется другое — доказательственная позиция при разборе.
В закрытом контуре журнал обращений полный и лежит у заказчика, версия модели зафиксирована и не меняется по решению провайдера, а маршрут данных ограничен периметром и проверяется сетевыми средствами. В облачной схеме те же обстоятельства приходится подтверждать документами провайдера, состав которых заказчик не определяет.
Аттестация объекта информатизации добавляет внешне подтверждённый факт: среда соответствовала требованиям на конкретную дату, есть модель угроз, аттестат и комплект документации. Иммунитета это не даёт — при инциденте разбирают, были ли реализованы предусмотренные меры. Но разница между «мы считали, что защищено» и предъявленным аттестатом в разборе существенная. Формально работающая локальная установка с записью в реестре ПО такого подтверждения не даёт: локальная версия и аттестованный объект — разные вещи.
Для сценариев, где эти требования обязательны, у нас есть AI-Контур — GPU-инфраструктура и российская модель в периметре заказчика с работами по аттестации сегмента, и отдельное направление ИИ для объектов КИИ.
Что может измениться
Первое направление — обязанности разработчиков моделей со статусом. Они включаются 1 марта 2027 года и касаются мер безопасности, правил эксплуатации и технической документации. Прямо на распределение ответственности это не влияет, но появление обязательного комплекта документации меняет расклад в споре: наличие или отсутствие документа становится аргументом.
Второе — случаи обязательного применения суверенных и национальных моделей. Право установить их у Правительства есть, перечня на сегодня не существует, для банковской сферы вопрос решается по согласованию с Центральным банком; что из этого следует для финансовых организаций, разбирали в материале про финансовый рынок.
Третье, и для темы ответственности самое важное: любые закреплённые в подзаконных актах требования к процедурам постепенно формируют стандарт должной осмотрительности. Как только появится описанный порядок, отклонение от него в конкретной организации станет доказательством вины. Обратной силы у этого нет, но проекты, которые уже сегодня ведут журналы и фиксируют версии, окажутся в лучшем положении.
Сроков появления этих актов никто не объявлял, и планировать в расчёте на то, что специальный состав ответственности всё-таки появится, не стоит. За четыре месяца между публикацией проекта и подписанием закона конструкция ответственности не выросла, а сжалась до одной отсылочной статьи.
Что дальше
Четыре действия, которые не зависят от содержания будущих подзаконных актов и дают эффект уже сейчас.
После этих четырёх пунктов у юридической службы остаётся один содержательный вопрос вместо десяти: какой объём ответственности вендор согласился взять письменно.
Частые вопросы
Кто отвечает, если ИИ принял ошибочное решение?
Специальных правил 243-ФЗ не устанавливает: статья 11 отсылает к общему законодательству. В корпоративных сценариях решение юридически принимает организация, применяющая систему, и перед третьим лицом отвечает она. Требования к вендору предъявляются отдельно и по договору — в объёме, который в этом договоре зафиксирован.
Ввёл ли 243-ФЗ штрафы за ошибки ИИ?
Нет. Специальных составов правонарушений и санкций за ошибки моделей в законе нет. Ответственность наступает по общим правилам гражданского и административного законодательства. Ужесточение ответственности за утечки персональных данных — отдельный регуляторный трек, к закону об ИИ он отношения не имеет.
Что писать в договоре с ИИ-подрядчиком?
Минимальный набор: юрисдикция обработки и хранения данных вместе с производными, права на веса модели и возмещение при претензиях правообладателей, состав и сроки хранения журналов, порядок разбора инцидента, согласование смены версии модели, пределы ответственности с прямо названными исключениями. Формулировки под конкретную сделку должен готовить юрист.
Снижает ли on-premise юридические риски?
Ответственность инфраструктурой не переносится, но доказательственная позиция меняется. В закрытом контуре есть полный журнал обращений, зафиксированная версия модели и подтверждаемый факт, что данные не покидали периметр. Аттестация объекта информатизации добавляет внешнее подтверждение состояния среды на дату.
Нужно ли ждать подзаконных актов, прежде чем править договоры?
Договорная работа от них не зависит. Подзаконные акты будут определять случаи обязательного применения суверенных и национальных моделей и порядок присвоения статуса, а распределение рисков между заказчиком и вендором закрывается общими нормами гражданского права, которые действуют сейчас.
Можно ли переложить ответственность на вендора полностью?
Нет. Перед третьим лицом и регулятором отвечает организация, применяющая систему; договор распределяет последствия между сторонами, но не переносит публично-правовую ответственность. Реальный предел — объём, который вендор согласился взять письменно, за вычетом ограничения ответственности в его же договоре. Модель субъектом права не является ни по 243-ФЗ, ни по Гражданскому кодексу.
Актуальность материала
Разбор подготовлен 14 сентября 2026 года. Подзаконных актов и правоприменительной практики по 243-ФЗ на эту дату нет. AZONE-AI не является юридической фирмой: материал носит аналитический характер, содержит в том числе экспертные трактовки и не заменяет юридическую консультацию. Перед принятием решений сверяйтесь с официально опубликованным текстом закона (publication.pravo.gov.ru, номер опубликования 0001202607260003) и привлекайте профильных юристов.
Чек-лист: договор с ИИ-подрядчиком
PDF, 14 страниц для юридической службы, ИБ и ИТ. Восемь блоков проверки с полем «что просить», три готовые формулировки, переговорные позиции по спорным пунктам и заготовка протокола разногласий.
Снизить юридические риски внедрения
Разберём конкретный сценарий: кто в нём владелец решения, что фиксируется в журналах, какие пункты договора с вендором оставляют риск на вашей стороне. Пилотный проект AZONE-AI включает проработку этой рамки вместе с архитектурой контура — до того, как система выйдет в промышленную эксплуатацию.