Новая директива ЕС о продуктовой ответственности и ИИ

К декабрю 2026 года в ЕС заработают обновлённые правила продуктовой ответственности — и для многих компаний это будет не «про юристов», а про деньги, репутацию и процессы разработки. Самое неприятное: спорить о том, является ли программное обеспечение «продуктом», станет практически бесполезно. В новой Директиве о продуктовой ответственности (PLD) софт, ИИ-системы и цифровые сервисы прямо попадают в зону строгой ответственности.

Для юридических команд это редкий случай, когда регулятор меняет не только материальные нормы, но и «механику» споров: презумпции, раскрытие доказательств, подход к причинно-следственной связи. А значит, привычный набор «у нас в договоре написано» и «мы предупреждали в пользовательском соглашении» будет работать слабее.

В серии «Искусственный интеллект в праве и юридических технологиях» я люблю темы, где право встречается с инженерией. Обновлённая PLD — как раз такая история: чтобы управлять риском, юристам придётся лучше понимать жизненный цикл ИИ (обновления, переобучение, дрейф моделей), а инженерам — привыкнуть к юридически значимым логам и документации.

Что изменилось в PLD: ИИ и софт официально стали «продуктом»

Ключевое изменение звучит просто: понятие «продукт» расширено и включает программное обеспечение, ИИ-системы и цифровые сервисы. Это закрывает старую дыру, когда ответственность за «вещи» работала понятнее, чем за алгоритмы.

Если раньше в некоторых кейсах спор начинался с вопроса «а можно ли вообще считать это продуктом?», то теперь фокус смещается на другое: был ли дефект, есть ли вред, и как компания контролировала систему на всём протяжении её жизни.

Кого заденет в первую очередь

Не только разработчиков.

• Производители и вендоры ПО/ИИ
• Импортёры и дистрибьюторы, выводящие продукт на рынок ЕС
• Онлайн-маркетплейсы, которые «делают доступным» продукт в ЕС
• Поставщики компонентов в цепочке (модель, датасеты, SDK, облачная инфраструктура) — через договорное перераспределение рисков

Вот неприятная, но практичная формулировка: ответственность становится цепочечной, а значит, если у вас сложная архитектура поставщиков, то «слабое звено» будет тянуть всех.

Почему это важнее, чем кажется

PLD — это про строгую ответственность: пострадавшему обычно не нужно доказывать вину в классическом смысле. И когда софт и ИИ признаны продуктом, бизнесу становится сложнее «уехать» в аргументы вроде «это же просто сервис» или «это же рекомендации, пользователь сам решает».

Судебная динамика меняется: бремя доказывания и раскрытие информации

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

Обновлённая PLD фактически признаёт эту реальность и усиливает процессуальные инструменты для истца.

Обязательное раскрытие: логи, записи решений, техдок

Директива вводит обязанности по раскрытию информации, которая поможет разобраться в том, что произошло:

• логи работы системы и событий
• записи принятия решений (в той мере, в какой они фиксируются)
• техническая документация и сведения о релизах/обновлениях

Для юристов это означает две вещи:

1. Если компания не ведёт логи и не документирует изменения модели, она проигрывает ещё до обсуждения «дефекта».
2. Если компания ведёт логи, но делает это хаотично, без контроля доступа и политики хранения, она создаёт себе риск утечек и санкций уже по другим режимам (коммерческая тайна, персональные данные, кибербезопасность).

Сильная позиция в споре по ИИ начинается не в суде, а в том, как вы проектируете наблюдаемость (observability) и документацию.

«Чёрный ящик» больше не оправдание

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

• какие были тесты до релиза
• какие метрики качества и безопасности вы контролировали
• как вы реагировали на инциденты
• были ли механизмы отката и ограничений

И здесь как раз появляется место для legal tech: системы управления доказательствами, регистры моделей, автоматизация комплаенс-документации, контроль релизов и изменений.

PLD учитывает «живые» системы: обновления, патчи и дообучение

Самая «инженерная» часть реформы: ответственность распространяется на вред, причинённый изменениями после вывода продукта на рынок — обновлениями, патчами и ИИ-модификациями.

Для традиционных товаров это звучит непривычно: холодильник после продажи не становится «другим холодильником». А ИИ-система — становится.

Где риски максимальны: три типичных сценария

1. Финансовые решения (скоринг, антифрод, кредитные лимиты)

   • Модель меняет пороги, растёт доля ложных срабатываний, клиент несёт убытки.

2. Медицинские и околомедицинские решения

   • Обновление меняет чувствительность/специфичность, увеличиваются пропуски критических состояний.

3. Автономные и полуавтономные системы (роботы, транспорт, промышленность)

   • Патч или переобучение меняют поведение в редких сценариях, возникает физический ущерб.

Общий вывод простой: после релиза начинается не «поддержка», а новая зона юридической ответственности.

Практика, которая снижает риск (и помогает в суде)

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

• Политика релизов: кто утверждает изменения модели и почему
• Журнал изменений (model/change log): что поменяли, когда, на каких данных, с какими метриками
• Постмаркет-мониторинг: отслеживание дрейфа, инцидентов, жалоб, регрессий
• Процедуры «kill switch» и отката
• Документация в стиле «папка для суда»: кратко, проверяемо, без маркетинга

Это не бюрократия ради бюрократии. Это способ сделать так, чтобы юридические аргументы опирались на факты, а не на заявления.

Что делать юристу и комплаенсу уже в 2025–2026: план на 90 дней

До вступления директивы в полную силу остаётся время, и его лучше потратить на подготовку. Ранние судебные подходы и первые споры почти наверняка сформируют «обычаи доказывания». В такие моменты выигрывают те, кто готов раньше остальных.

1) Пересоберите карту ответственности в цепочке поставок

Начните с инвентаризации:

• какие ИИ-компоненты вы покупаете (модели, API, датасеты, хостинг)
• кто делает обновления и кто контролирует релизы
• кто общается с конечным пользователем и чьи обещания звучат в интерфейсе

Дальше — договорная часть: гарантии, лимиты ответственности, регрессные требования, SLA по логам и расследованиям.

2) Настройте «доказуемый комплаенс» с помощью legal tech

Для этой директивы особенно полезны инструменты, которые превращают хаос разработки в проверяемую историю:

• реестр моделей и версий
• единые шаблоны техдокументации и риск-оценок
• управление запросами на раскрытие информации (discovery-ready процесс)
• контроль доступа и сроков хранения логов

Если всё это делается вручную в таблицах, вы почти гарантированно не соберёте нужный пакет документов в момент инцидента.

3) Проведите учения по инцидентам

Я сторонник подхода «table-top exercise» для ИИ-инцидентов: 2 часа, один сценарий, чёткие роли.

Пример сценария:

• после обновления скоринговой модели вырос процент отказов для группы клиентов
• появились жалобы и требования возмещения
• регулятор/контрагент просит техническую документацию и логи

Цель учений — выяснить, что вы реально можете извлечь из систем: какие логи есть, где они лежат, кто имеет доступ, как быстро можно восстановить цепочку событий.

Частые вопросы от бизнеса (и короткие ответы)

Будет ли ответственность, если ИИ — «только рекомендации»?

Да, если рекомендация встроена в продукт/сервис так, что разумно влияет на решения и приводит к вреду. Формулировки «не является советом» помогают ограниченно, если фактическое поведение системы другое.

Можно ли «переложить» всё на поставщика модели?

Полностью — нет. Вы можете перераспределить риск договором, но перед пострадавшим и судом это не всегда спасает. Договор — это про регресс, а не про исчезновение ответственности.

Что важнее: объяснимость или качество тестирования?

В споре важнее воспроизводимость и доказуемость контроля: какие тесты были, какие метрики, как вы проверяли релиз и реагировали на регрессии. Объяснимость помогает, но не заменяет дисциплину разработки.

Почему это напрямую связано с ИИ в праве и юртех

Обновлённая PLD делает очевидной мысль: юридический риск ИИ — это управляемый инженерный процесс, а не «что-то, что юристы подпишут в конце». Поэтому юридические технологии становятся не красивым дополнением, а рабочим инструментом:

• быстрее находить и фиксировать факты (логи, версии, датасеты)
• стандартизировать риск-оценку и документацию
• готовиться к раскрытию информации без паники и потерь

К декабрю 2026 вы либо сможете показать «как система устроена и контролируется», либо будете объяснять, почему этого нет.

Следующий шаг, который я бы сделал на месте руководителя юридической функции: выбрать 1–2 критичных ИИ-продукта и провести по ним мини-аудит готовности к PLD — от цепочки поставок до логирования и обновлений. А дальше вопрос, который стоит держать в голове весь 2026 год: если завтра случится инцидент, сможете ли вы за 72 часа собрать доказательства, не разрушив при этом бизнес?