Администрация Трампа делает ставку на иски: кто заплатит за ИИ-сбой

Администрация Трампа выбрала юридическую ответственность главным рычагом для обеспечения безопасности ИИ. Об этом сообщает Bloomberg. Подход выглядит экономным: не нужно создавать лицензирующий орган и согласовывать списки запрещённых архитектур. Достаточно дать понять, что за вред придётся платить. Но у такой схемы есть слабое место, и оно уже видно: закон пока не говорит, кто именно должен платить, когда модель «уходит в разнос». Те, кто её создал, или те, кто встроил её в свой продукт.

В публикации Bloomberg нет конкретных статей закона, сумм или сроков, поэтому детали механизма пока неясны. Зато сама логика понятна, и её можно разобрать на опыте уже случившихся споров.

Две цепочки ответственности

У любой ИИ-системы в продакшене как минимум два участника. Первый обучает модель и определяет её базовое поведение. Второй подключает её к своим данным, пишет системный промпт, выдаёт ей инструменты и решает, где её можно использовать. Ущерб чаще всего возникает на стыке: модель ошиблась, а компания дала ей доступ к тому, к чему доступа давать не стоило.

Европейский AI Act закрепил это разделение на уровне терминов: есть «провайдер» и «деплоер», и обязанности у них разные. В США единой рамки нет. Остаются продуктовая ответственность, нормы о небрежности и договорное право. Суды применяют их к ИИ по аналогии, и результат непредсказуем.

Показательный пример из 2024 года: трибунал в Британской Колумбии постановил, что Air Canada отвечает за неверную информацию о скидках, которую выдал её чат-бот. Авиакомпания пыталась доказать, что бот — отдельный субъект. Не вышло. Ответил тот, кто развернул систему перед клиентом, а не тот, кто её обучил.

Где заденет разработчиков

До этого Калифорния в 2024 году рассматривала законопроект SB 1047 с нормами об ответственности разработчиков крупных моделей. Губернатор Ньюсом его ветировал, во многом из-за возражений отрасли. Теперь идея ответственности возвращается, только уже с федерального уровня и в логике поддержки рынка, а не его сдерживания.

У разработчиков типичная защита — пользовательские соглашения, которые перекладывают риск на клиента. Исключение — защита от исков об авторском праве: Microsoft, Google и OpenAI предлагали корпоративным клиентам такие гарантии. Для вреда от поведения модели подобных гарантий нет. Если ответственность станет реальной, эти условия придётся переписывать.

Основные точки напряжения:

• Граница между дефектом модели и неправильным внедрением: кто доказывает, что именно сломалось.
• Агентные системы: чем больше автономии и доступа к инструментам, тем сложнее разложить вину по цепочке.
• Договорные оговорки: смогут ли разработчики и дальше отказываться от ответственности в лицензиях.
• Страхование: рынок покрытия ИИ-рисков пока тонкий, и тарифы будут зависеть от первых громких решений.
• Открытые модели: непонятно, кто отвечает за вред, если веса скачали и дообучили третьи лица.

Что делать компаниям уже сейчас

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

Разработчикам моделей стоит документировать тестирование и известные ограничения. Это будет их основной аргумент, что дефекта в продукте не было. Для всех остальных практический вывод простой: ограничивайте права агентов минимально необходимыми и оставляйте человека в точках, где цена ошибки высока. Когда ответственность станет предметом судебных исков, именно такие решения будет разбирать суд.