Почему по закону риск несёт оператор, а не «бот»
При внедрении ИИ практически весь риск принимает на себя оператор — гражданин или юрлицо, эксплуатирующие нейросеть. Чаще всего оператором выступают компании, которые внедряют ИИ в свой сервис и общаются через него с клиентом. В некоторых случаях оператором выступает государство. За ошибку нейросети отвечает тот, кто ее контролирует и извлекает из нее выгоду. Например, если чат-бот банка сообщил клиенту неверные условия вклада, перед клиентом будет отвечать банк.
Ведь именно он выбрал инструмент, настроил его, интегрировал в клиентский путь и получает экономический эффект от его использования. Банк контролирует, какие данные получает модель, какие ограничения на нее наложены и какой дисклеймер видит пользователь. Даже если чат-бот работает на сторонней модели, ответственность перед клиентом все равно несет оператор. Пострадавшие от ошибки нейросети компании могут сослаться на ст. 1095–1098 ГК, а граждане — на закон «О защите прав потребителей». Вред, причиненный жизни, здоровью или имуществу гражданина либо имуществу юрлица из-за недостатков товара, работы или услуги, возмещается независимо от наличия договора и вины причинителя.
Если ИИ-система встроена в услугу (банковскую консультацию, медицинскую диагностику, расчет кредитного рейтинга), недостаток этой системы — это недостаток услуги, говорит эксперт. И потребитель вправе потребовать полного возмещения убытков, компенсацию морального вреда (ст. 15 ГК), неустойку и штраф в размере 50% от присужденной суммы (п. 6 ст. 13 ГК). При этом стоит помнить: закон «О защите прав потребителей» применяется, когда пострадавший — физическое лицо, получившее услугу для личных нужд.
Положения одобренного Госдумой РФ законопроекта, устанавливая границы ответственности между участниками правоотношений, не вводят специального регулирования ответственности за «ошибки» ИИ, поэтому даже после подписания данного закона и вступления его в силу основой для определения правовой позиции в гражданско-правовых спорах будут являться общие нормы Гражданского кодекса. Это значит, что факт реальных убытков контрагента должен быть подтвержден документально, как и факт возникновения такого убытка в связи с использованием ИИ. Если такие доказательства приведены, необходимо установить на ком лежит ответственность за генерацию ИИ неверных решений. В цепочке могут быть виноваты:
- Разработчик ИИ (если в коде или архитектуре есть дефект).
- Интегратор, который собирал решение и настраивал систему.
- Компания-заказчик, которая внедрила ИИ в бизнес-процессы.
Как документально доказать отсутствие вины: шесть шагов
1. Зафиксируйте факт ошибки и убытков. Сохраните скриншоты выходных данных ИИ, логи системы, подтверждающие неверные результаты, и документы, подтверждающие размер понесённых контрагентом убытков. Либо используйте доказательства, представленные контрагентом при предъявлении претензий.
2. Проведите независимую техническую экспертизу. Это самый важный шаг. Независимый эксперт должен проанализировать следующие ключевые параметры:
- была ли ошибка в программном коде или архитектуре модели;
- соответствовала ли работа информационной системы технической документации и заявленным требованиям;
- могла ли стать причиной сбоя некачественная, неполная или предвзятая обучающая выборка.
3. Докажите добросовестность эксплуатации. Покажите, что вы действовали разумно: провели тестирование перед запуском в рабочем режиме; внедрили процедуры контроля (например, «human-in-the-loop» — обязательный пересмотр ключевых решений человеком); не использовали ИИ для задач, для которых он не предназначен; учитывали предупреждения разработчика об ограничениях модели.
4. Докажите, что не могли выявить дефект самостоятельно. Часто проблема кроется в «чёрном ящике» — сложности понимания внутренней логики модели. Если вы докажете, что дефект был скрытым и его невозможно было обнаружить при обычной проверке, это снимет с вас вину.
5. Проанализируйте входные данные. Часто сбой вызван некорректными, устаревшими или неполными данными, которые вы передали в модель. Докажите, что предприняли все разумные меры для их проверки и валидации.
6. Используйте договорные ограничения. Если в лицензионном соглашении с поставщиком ИИ прямо указано, что сервис предоставляется «как есть» без гарантий, и вы действовали в рамках этих условий, это весомый аргумент.
Критерии, по которым ответственность делят с разработчиком модели
Приведем пример, когда ИИ использовался некорректно, что привело к назначению судом штрафа.
В 2025 году Арбитражный суд Западно-Сибирского округа рассматривал дело № А27-7831/2025. Юристы компании при подготовке кассационной жалобы использовали ИИ: нейросеть сгенерировала правовую позицию, включив ссылки на судебные акты и цитаты из них. Суд выяснил: часть дел вообще не существовала, в других — цитат, на которые ссылались, не было.
Как доказали вину? Суд не списал всё на «ошибку нейросети». Он прямо указал: использование ИИ не освобождает участника процесса от обязанности проверять достоверность представляемых сведений. Суд квалифицировал действия как представление заведомо ложных сведений и проявление неуважения к правосудию. Компанию оштрафовали на 50 тысяч рублей. Этот прецедент закрепил принцип: ответственность несёт тот, кто направил документ в суд, независимо от того, каким инструментом пользовался.
ИТ-юристы распределяют ответственность между разработчиком ИИ-модели и компанией-заказчиком, опираясь на комплекс критериев, которые учитывают техническую природу проблемы, степень контроля и действия каждой стороны.
Ключевые критерии для разделения ответственности:
Техническая природа проблемы. Это главный фильтр. Если ошибка кроется в дефекте кода, архитектуре модели или в некачественных/предвзятых обучающих данных, предоставленных разработчиком, ответственность с высокой вероятностью ляжет на него. Если же проблема в том, что компания использовала модель не по назначению, дала ей некорректные входные данные или не провела валидацию, ответственность будет на заказчике.
Степень контроля над моделью. Разработчик, как правило, контролирует саму технологию: логику, принципы работы, ограничения модели. Компания-заказчик, в свою очередь, контролирует, как модель встраивается в бизнес-процессы: какие данные ей подаются, какие промпты используются, какие сценарии работы задаются, какие права доступа выдаются. Если заказчик сознательно игнорирует предупреждения разработчика об ограничениях модели или не внедряет процедуры проверки её результатов человеком, это усиливает позицию разработчика.
Документирование и прозрачность. Наличие детальной документации на архитектуру, логику работы, ограничения модели и результаты тестирования — важный фактор. Она позволяет установить причинно-следственную связь между действиями разработчика и наступившим вредом. Отсутствие такой документации, особенно при использовании «чёрных ящиков», затрудняет как доказывание вины, так и подтверждение ее отсутствия.
Договорные условия. Условия лицензионного соглашения, гарантии, исключения и лимиты ответственности, прописанные в договоре между сторонами, имеют вес. Часто разработчики прямо указывают, что их решение предоставляется «как есть», без гарантий точности для конкретных целей. Нарушение этих условий со стороны заказчика снижает его шансы на претензии к вендору.
Характер применения ИИ. Если модель используется в высокорисковых сферах (медицина, финансы, правосудие), требования к её безопасности и контролю строже. В таких случаях акцент смещается на необходимость тщательной валидации и мониторинга со стороны заказчика.
Как это работает на практике
Разработчик отвечает за то, что он контролировал: дефекты продукта, предоставление некачественных данных, отсутствие необходимых предупреждений.
Заказчик несёт первичную ответственность перед третьими лицами (клиентами, партнёрами), так как именно он принимает управленческое решение, используя ИИ как инструмент. Однако у него есть право на регресс: если он докажет, что вред возник исключительно из-за фундаментального недостатка модели, который нельзя было выявить при разумной осмотрительности, он может взыскать убытки с разработчика.
НО! Не все так просто!
При оценке зон ответственности необходимо принимать во внимание дополнительные факторы риска:
Автономность и самообучение. Чем выше степень автономности модели и её способность к самообучению, тем сложнее установить прямую причинно-следственную связь между действиями конкретного разработчика и вредом.
Внешние воздействия. Вред может быть вызван не только ошибкой модели, но и противоправными действиями третьих лиц, которые заказчик не мог предвидеть и предотвратить.
Презумпция вины. Законодательство может устанавливать презумпцию вины: субъект несёт ответственность, если не докажет, что предпринял все возможные меры для предотвращения нарушения.
Таким образом, ИТ-юристы анализируют всю цепочку: от кода и данных до бизнес-процессов заказчика и договорных условий, чтобы справедливо распределить риски. Универсального рецепта нет — каждый случай требует детального разбора.
Ключевые критерии для разделения ответственности:
Техническая природа проблемы. Это главный фильтр. Если ошибка кроется в дефекте кода, архитектуре модели или в некачественных/предвзятых обучающих данных, предоставленных разработчиком, ответственность с высокой вероятностью ляжет на него. Если же проблема в том, что компания использовала модель не по назначению, дала ей некорректные входные данные или не провела валидацию, ответственность будет на заказчике.
Степень контроля над моделью. Разработчик, как правило, контролирует саму технологию: логику, принципы работы, ограничения модели. Компания-заказчик, в свою очередь, контролирует, как модель встраивается в бизнес-процессы: какие данные ей подаются, какие промпты используются, какие сценарии работы задаются, какие права доступа выдаются. Если заказчик сознательно игнорирует предупреждения разработчика об ограничениях модели или не внедряет процедуры проверки её результатов человеком, это усиливает позицию разработчика.
Документирование и прозрачность. Наличие детальной документации на архитектуру, логику работы, ограничения модели и результаты тестирования — важный фактор. Она позволяет установить причинно-следственную связь между действиями разработчика и наступившим вредом. Отсутствие такой документации, особенно при использовании «чёрных ящиков», затрудняет как доказывание вины, так и подтверждение ее отсутствия.
Договорные условия. Условия лицензионного соглашения, гарантии, исключения и лимиты ответственности, прописанные в договоре между сторонами, имеют вес. Часто разработчики прямо указывают, что их решение предоставляется «как есть», без гарантий точности для конкретных целей. Нарушение этих условий со стороны заказчика снижает его шансы на претензии к вендору.
Характер применения ИИ. Если модель используется в высокорисковых сферах (медицина, финансы, правосудие), требования к её безопасности и контролю строже. В таких случаях акцент смещается на необходимость тщательной валидации и мониторинга со стороны заказчика.
Как это работает на практике
Разработчик отвечает за то, что он контролировал: дефекты продукта, предоставление некачественных данных, отсутствие необходимых предупреждений.
Заказчик несёт первичную ответственность перед третьими лицами (клиентами, партнёрами), так как именно он принимает управленческое решение, используя ИИ как инструмент. Однако у него есть право на регресс: если он докажет, что вред возник исключительно из-за фундаментального недостатка модели, который нельзя было выявить при разумной осмотрительности, он может взыскать убытки с разработчика.
НО! Не все так просто!
При оценке зон ответственности необходимо принимать во внимание дополнительные факторы риска:
Автономность и самообучение. Чем выше степень автономности модели и её способность к самообучению, тем сложнее установить прямую причинно-следственную связь между действиями конкретного разработчика и вредом.
Внешние воздействия. Вред может быть вызван не только ошибкой модели, но и противоправными действиями третьих лиц, которые заказчик не мог предвидеть и предотвратить.
Презумпция вины. Законодательство может устанавливать презумпцию вины: субъект несёт ответственность, если не докажет, что предпринял все возможные меры для предотвращения нарушения.
Таким образом, ИТ-юристы анализируют всю цепочку: от кода и данных до бизнес-процессов заказчика и договорных условий, чтобы справедливо распределить риски. Универсального рецепта нет — каждый случай требует детального разбора.