Кто отвечает за ИИ-агента: юридический контур цифрового сотрудника

Это вторая часть материала про ИИ-агентов в корпоративном контуре для блога ЛАНИТ. В первой ^[1] речь шла о том, как ограничить агента технически, какие полномочия ему давать, как разделять доверенные и недоверенные источники, что логировать и как тестировать систему до запуска. Здесь – о следующем вопросе. Что происходит, если ограничения все-таки не сработали, агент сделал что-то не то, а последствия уже наступили?

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

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

Движения тектонических плит законодательства

В марте 2026 года Минцифры представило проект закона об ИИ ^[2], который выглядел как попытка довольно подробно разложить участников цепочки. Это – разработчик модели, оператор системы, владелец сервиса и пользователь. Проект прямо говорил об ответственности за результат «соразмерно степени вины каждого» и отдельно перечислял обязанности разных участников.

К лету Правительство внесло ^[3] в Госдуму новый, существенно переработанный законопроект уже под другим названием. Уже 26 июля 2026 года был подписан Федеральный закон № 243-ФЗ ^[4] «О поддержке развития технологий искусственного интеллекта ^[5] в Российской Федерации». В итоговой версии нет прежней четырехзвенной схемы и нет правила о распределении ответственности «соразмерно степени вины». Закон вообще стал заметно уже и в значительной степени сосредоточился на больших фундаментальных моделях – в тексте закона это модели не менее чем с одним миллиардом параметров, которые используются как основа для большого числа разных задач.

Статья 11 ^[6] итогового закона сформулирована намного проще, чем в марте. За нарушение самого закона и принятых по нему актов участники отношений в сфере разработки, внедрения и применения больших фундаментальных моделей несут ответственность в соответствии с законодательством Российской Федерации. Т. е. готовой специальной матрицы «если агент сделал X, отвечает Y» закон не дает.

При этом регулирование уже развивается, статья 13 ^[7] закона устанавливает общую дату вступления в силу 1 сентября 2026 года, а ряд наиболее содержательных положений (обязанности разработчиков суверенных и национальных больших фундаментальных моделей, маркировка отдельных материалов и нормы об интеллектуальных правах) начнут действовать с 1 марта 2027 года.

Есть и отдельный судебный трек. В мае 2026 года председатель Верховного суда поручил ^[8] впервые в масштабе страны обобщить судебную практику по делам, связанным с ИИ, отдельно упомянув возмещение вреда и вопрос надлежащего ответчика. А Пленум Верховного суда уже указал ^[9], что участники гражданского дела должны сообщать суду, если представляют сведения о фактах, полученные с использованием ИИ.

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

Вымышленный пример: один агент, много ответственных

Чтобы разобраться, как все может происходить при инциденте, возьмем вымышленную компанию «Северторг» – оптового поставщика стройматериалов, работающего с несколькими сотнями дилеров. Представим, что компания автоматизировала обработку входящих заявок. Раньше менеджер читал письмо, сопоставлял позиции с номенклатурой, проверял остатки, готовил счет и отвечал клиенту. Теперь значительную часть этой работы делает ИИ-агент, а менеджер должен согласовать результат.

Решение собрал также вымышленный подрядчик «Логика ИИ». Он написал системные инструкции, настроил RAG по номенклатуре и прайсам, интеграции с почтой и учетной системой, развернул решение и сопровождает его по договору. Внутри используется базовая языковая модель внешнего вендора по API.

Теперь ломаем сценарий. Агент находит в поисковом индексе прошлогодний прайс, выставляет дилеру счет по старой цене, дилер его оплачивает и требует отгрузить товар. Разница для одной позиции – несколько сотен тысяч рублей.

Кто здесь отвечает? Вендор базовой модели мог заранее не предупреждать, что модель способна выдавать правдоподобные, но неверные значения и не должна использоваться как источник истины для цен. Подрядчик построил индекс, в котором одновременно лежали актуальные и устаревшие документы, и не сделал финальную проверку цены против учетной системы. «Северторг» определил бизнес-процесс, в котором агент вообще имеет возможности подготовить счет, и это их решение, какой контроль должен выполнить менеджер. Сам менеджер мог согласовать документ не глядя. А если дилер специально применил джейлбрейк и добрался до старого прайса через уязвимость агента, появится еще один участник истории.

Я сейчас намеренно не пытаюсь распределить между ними юридические проценты вины. Для этого не хватает ни фактов, ни договора, ни конкретной правовой квалификации. Но как инженерный пример он полезен именно тем, что показывает – факт, что агент ошибся, завязан на многих звеньях цепи.

И еще важнее другое – в этой цепочке нигде не появляется самостоятельный ответственный субъект по имени «ИИ-агент». Он остается частью системы, которой управляют люди и организации.

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

Когда все уже случилось

Российский кейс: штраф за непроверенные ссылки

Весной 2026 года Арбитражный суд Западно-Сибирского округа рассмотрел вопрос о судебном штрафе по делу № А27-7831/2025 ^[10]. Спор сам по себе был обычным: бухгалтерские услуги и долг около 50 тысяч рублей. Интересным его сделала кассационная жалоба.

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

Суд отдельно отметил, что использование ИИ не является оправданием, ответственность за достоверность сгенерированного текста несет участник дела, который эту технологию использовал. Штраф в 50 тысяч рублей наложили не на конкретного представителя, а на компанию как сторону процесса. К моменту рассмотрения вопроса о штрафе представитель уже был другим ^[11], но это ничего не изменило, поскольку нарушение произошло в момент, когда компания подала документ от своего имени.

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

Чат-бот – это все равно голос компании

Похожая история раньше произошла с Air Canada. В деле Moffatt v. Air Canada ^[12] пассажир спросил чат-бота авиакомпании о льготном тарифе в связи со смертью родственника. Бот сообщил, что можно купить обычный билет и затем запросить перерасчет в течение 90 дней с даты выписки билета. На основной же странице Air Canada правила были другими, льготный тариф нельзя было оформить задним числом после поездки. Пассажир последовал совету чат-бота, а потом получил отказ.

Трибунал Британской Колумбии не принял попытку отделить сообщения чат-бота от самой авиакомпании. Для клиента и страница с правилами, и чат-бот были частями сайта Air Canada. Компанию обязали компенсировать ущерб и расходы – всего чуть больше 800 канадских долларов.

Важная оговорка, в деле вообще не было установлено, на какой технологии работал чат-бот. Мы не знаем, был ли это LLM, сценарная система или что-то еще. Поэтому это не «прецедент про языковые модели». Он полезен другим – автоматизированный интерфейс не перестает быть интерфейсом организации только потому, что ответы в нем формирует программа.

Ответственность не заканчивается на том, кто нажал Enter

В апреле 2026 года американский федеральный магистрат-судья Питер Канг оштрафовал ^[13] руководителя и владельца юридической фирмы за недостаточный контроль работы младшего юриста. В поданном в суд документе оказалась ложная ссылка на судебное решение. Руководитель фирмы объяснил суду, что они пользовались профессиональным ИИ-помощником для юристов CoCounsel от Westlaw, а продавец уверял его, что галлюцинации исключены. Суд констатировал, что ссылка появилась отчасти из-за ИИ, но в конечном счете из-за недостатка внимания ^[14] и контроля.

Но для вывода суда это оказалось вторично. Руководитель фирмы был указан в деле как counsel of record (адвокат, официально представляющий сторону перед судом), его имя стояло на поданном документе, и суд счел, что он должен был проверить его содержание и цитаты. Партнера оштрафовали на 1 001 доллар ^[15] и обязали пройти обучение ^[16] по контролю работы юристов и этичному использованию ИИ.

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

Еще два дела

Еще два свежих дела из Миссисипи и Небраски показывают похожую проблему с разных сторон. В июне 2026 года федеральный судья Шарион Эйкок в Миссисипи дисквалифицировала ^[17] всех четырех адвокатов, участвовавших в одном контрактном споре: обе стороны представили документы с фиктивными ссылками. Двум юристам, непосредственно использовавшим ИИ при подготовке материалов, на два года запретили практиковать в этом федеральном округе и назначили штрафы в 2 500 и 3 500 долларов. Еще два адвоката выступали как local counsel (местные юристы, подключенные к делу вместе с основными адвокатами и отвечавшие за представительство в этом суде), хотя они сами спорные документы не готовили, каждому назначили штраф в 1 000 долларов.

Второе дело Prososki v. Regan ^[18] дошло до Верховного суда Небраски. В апелляционной жалобе обнаружили многочисленные несуществующие или неточные ссылки и цитаты. Широко разошлась цифра «57 проблемных ссылок из 63», но в тексте решения ее нет. Адвокат отрицал, что пользовался ИИ, и суд указал, что на его выводы это не влияет. Сам суд констатировал многочисленные дефекты, исключил жалобу и передал вопрос о поведении ^[19] адвоката дисциплинарным органам.

Это уже не пара странных историй из первых лет ChatGPT. В декабре 2025 года совместное исследование Авито и ^[20]Право.ru ^[21]  показало, что 88% опрошенных юристов уже используют ИИ в работе. Чем шире технология входит в обычный профессиональный процесс, тем меньше смысла рассматривать такие инциденты как исключение.

Когда ошибку первой находит внешняя сторона

Есть еще один неприятный сценарий, когда организация сама долго не замечает систематическую ошибку ^[22].

Нью-Йорк запустил чат-бот MyCity осенью 2023 года как единое окно для предпринимателей. Он должен был объяснять городские правила и требования. В 2024 году журналисты The Markup и THE CITY начали задавать ему практические вопросы ^[23] и получили набор советов, которые при выполнении приводили бы к нарушению закона. Например, чат-бот советовал удерживать часть чаевых сотрудников, дискриминировать арендаторов с жилищными субсидиями или отказываться принимать наличные. На вопрос, можно ли подать посетителям сыр, испорченный крысами, бот ответил: «Да, вы все еще можете подать сыр клиентам, если на нем есть укусы крысы». Затем посоветовал оценить степень повреждения и предупредить посетителей.

После публикации город проект защищал, добавлял предупреждения и дорабатывал ответы. В январе 2026 года новая администрация объявила ^[24], что закроет чат-бот как функционально непригодный и в рамках сокращения расходов. 4 февраля его действительно сняли с сайта.

Систему создала, эксплуатировала и мониторила организация, а убедительный набор ошибок собрали журналисты. Отсюда вывод, что оценку качества нельзя заканчивать в момент приемки. Для агента нужен постоянный набор контрольных сценариев, включая ошибки, которые редко встречаются в штатном потоке, но имеют тяжелые последствия. В первой части статьи в том числе я писал про red teaming ^[25].

Форма иногда важнее смысла

В январе 2026 года суд в нидерландском Зволле разбирал ^[26] необычную историю. Для свадебной церемонии знакомый пары, выступавший однодневным регистратором, подготовил речь с помощью ChatGPT. В речи не оказалось обязательного заявления, предусмотренного статьей 1:67 Гражданского кодекса Нидерландов.

Здесь важно точно сформулировать результат. Суд не просто признал брак недействительным, он установил, что в юридическом смысле брак вообще не был заключен, поскольку обязательная декларация не прозвучала, и распорядился удалить запись. Текст может быть убедительным, красивым и полностью соответствовать ожиданиям пользователя по смыслу, но не выполнять обязательное формальное условие процесса.

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

По дороге в светлое ИИ-будущее не забываем про закон о персональных данных

Отдельно стоит рассмотреть вопрос, что делать с агентами, которые участвуют в решении, которое затрагивает человека.

Статья 16 закона «О персональных данных» ^[27] запрещает решения, основанные исключительно на автоматизированной обработке персональных данных, если они порождают юридические последствия для человека или затрагивают его права и законные интересы. Но запрет не абсолютный, такие решения допускаются при наличии письменного согласия субъекта либо в случаях, прямо предусмотренных федеральным законом с соответствующими гарантиями.

Оператор при этом должен объяснить человеку порядок принятия решения и возможные последствия, предоставить возможность возражения, разъяснить порядок защиты прав и рассмотреть возражение в течение 30 дней.

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

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

Где тут заканчивается юридическая плоскость и начинается организационная, и наоборот – решать вам.

Кто виноват и что делать – сказали бы мы, если у нас остались логи

Ответственный должен уметь проверить агента

Очень удобно написать в регламенте, что окончательное решение принимает сотрудник. В архитектурной схеме это снимает половину вопросов. В реальной жизни появляется следующий: способен ли этот сотрудник понять, что агент ошибся?

В материале МТС про ИИ-агентов в продажах приводится ^[28] практическая оценка, что контроль двух агентов может занимать 15-20 часов в неделю, а при большем их количестве проверка начинает забирать более половины рабочего времени. Это не универсальный норматив и не юридический порог, но как иллюстрация проблемы оценка показательная. 

Чем больше поток, тем сильнее соблазн превратить проверку в формальность. Одновременно возникает automation bias ^[29] – склонность избыточно полагаться на автоматизированную рекомендацию. В классическом эксперименте ^[29] с системой поддержки решений участники допускали и ошибки пропуска, и ошибки следования неверной рекомендации даже при наличии других корректных сигналов.

Но есть и более долгосрочный вопрос, который заключается в том, что обычно экспертиза растет снизу вверх. Младший специалист читает документы, вручную делает разборы, ошибается, получает обратную связь, постепенно набирает насмотренность и через несколько лет способен быстро замечать нетипичную проблему. Именно такие рутинные задачи первыми хочется отдать агенту.

Получается парадокс ^[30]. Чем успешнее мы автоматизируем работу начинающих специалистов, тем меньше у них остается материала, на котором можно вырастить квалификацию. Через несколько лет организация рискует получить много автоматизации и мало людей, которые способны содержательно контролировать ее результаты.

Поэтому human-in-the-loop (человек в контуре) – это еще и задача управления компетенцией. Если человек остается конечным ответственным (а судя по всему во многих случаях это будет так в ближайшее время), организация должна специально поддерживать его способность проверять систему: оставлять часть задач для ручного разбора, проводить выборочные независимые проверки, разбирать инциденты, ротировать сотрудников и проверять квалификацию не реже, чем качество самого агента.

Чтобы доказать, кто действовал: идентичность агента

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

Евгений Кокуйкин из Raft разбирает ^[31] эту тему через Non-Human Identity – учетные записи, ключи, сертификаты и токены, которыми пользуются приложения, сервисы и агенты. Автор приводит показательный пример: там, где у инженера раньше было несколько корпоративных и сервисных учетных сущностей, появление кодинг-агентов, MCP-серверов, автономных помощников и CI/CD-агентов может быстро увеличить их число до десятков.

Точная цифра здесь не так важна. Важно, что агент начинает действовать через реальные полномочия (токен к почте, сервисную учетку в CRM, credential к базе, OAuth-доступ к GitHub, ключ к облаку).

OWASP в Non-Human Identities Top 10 отдельно выделяет ^[32] несколько рисков, которые напрямую влияют на расследуемость инцидента. NHI1 – некорректный офбординг, когда учетные данные остаются после завершения проекта или ухода владельца. NHI9 – переиспользование одной машинной идентичности разными приложениями или компонентами. NHI10 – использование машинной учетки человеком, из-за чего в аудит-логе невозможно нормально отделить действия автоматизации от ручных.

Если один сервисный токен используют два агента (разработчик для отладки и фоновый планировщик заданий cron), то запись «операцию выполнил service_account_17» мало что доказывает.

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

Чтобы доказать, почему это произошло: логи и воспроизводимость

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

Ответ зависит от версии модели, контекста, который собрал RAG, состояния памяти ^[33], системного промпта, доступных инструментов, результатов предыдущих вызовов и иногда от версии внешнего API. Даже одинаковый запрос при одинаковой температуре не гарантирует ^[34] побитово одинаковый результат.

Поэтому журналировать только финальный ответ недостаточно. Для расследования полезно сохранять идентификатор модели и провайдера, версию системных инструкций и политик, перечень использованных документов и их версии, доступные агенту инструменты, аргументы и результаты значимых вызовов, идентичность агента, цепочку делегирования и факт человеческого подтверждения действия.

Но здесь есть встречный риск. Записать весь контекст – опасная рекомендация, если внутри персональные данные, коммерческая тайна, содержимое документов и секреты. Логи агента быстро становятся отдельным чувствительным хранилищем. Поэтому нужен не максимальный объем логов, а достаточный для расследования набор с маскированием секретов, контролем доступа, правилами хранения и удалением лишних данных.

Еще один источник невоспроизводимости – внешняя модель. Если провайдер обновляет ее без возможности закрепить конкретную версию, поведение ^[35] системы может измениться без единого коммита в вашей кодовой базе. Там, где это критично, возможность pinning (закрепления) версии модели и история обновлений становятся частью требований к поставщику, а не удобной опцией.

Когда агенты начнут договариваться друг с другом

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

Агент поставщика формирует предложение. Агент покупателя проверяет условия и оформляет заказ. Агент логистической компании бронирует перевозку. Ошибка или вредоносная инструкция в одном контуре может стать входом для другого.

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

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

Определите владельца агента и владельца бизнес-решения. Это могут быть разные люди. Первый отвечает за работоспособность и границы системы, второй – за то, что результат агента можно использовать в конкретном процессе.

Опишите полномочия агента как полномочия сотрудника: что он может читать, что может изменять, какие действия выполнять самостоятельно, а какие – только после подтверждения. Чем тяжелее последствия, тем важнее, чтобы это было задано технически, а не только написано в регламенте.

Выдайте агенту собственную идентичность. Не используйте одни и те же креды для людей и разных агентов, применяйте минимально необходимые права и срок жизни токенов, предусмотрите офбординг и владельца каждой учетки.

Проверьте, где человек в контуре действительно принимает решение, а где только формально подтверждает поток готовых действий. Для решений, затрагивающих людей, отдельно проверьте применимость статьи 16 закона о персональных данных.

Заведите стабильный набор контрольных сценариев и регулярно прогоняйте его после изменений модели, промптов, RAG, инструментов и бизнес-логики. Добавьте red teaming и сценарии с редкими, но тяжелыми последствиями.

Логируйте состояние системы, достаточное для расследования: версии, источники контекста, инструменты, значимые вызовы, идентичности и подтверждения. Одновременно защищайте сами логи и не превращайте их в бесконтрольную копию всех данных, которые когда-либо видел агент.

Предусмотрите быстрый способ ограничить или остановить опасное поведение. Важно не только иметь «кнопку выключения», но и заранее определить, кто имеет право ей воспользоваться, что произойдет с незавершенными действиями и как система вернется в работу.

Зафиксируйте в договорах с поставщиками то, что понадобится при инциденте: идентификаторы и версии моделей, доступность журналов, уведомление об изменениях, сроки реакции ^[36], порядок расследования, ограничения использования и распределение договорных рисков.

И отдельно подумайте о квалификации людей, которые остаются последним уровнем контроля. Если всю учебную рутину забирает ИИ, нужно сознательно создавать другие механизмы набора экспертизы. Ответственный, который физически не способен распознать ошибку, превращает human-in-the-loop в декоративный элемент.

Вместо вывода

В первой части ^[1] моей статьи об ИИ-агентах общий принцип был таким: агентную систему нужно строить исходя из предположения, что модель когда-нибудь ошибется или ее удастся обмануть. 

У юридического и организационного контура есть симметричный принцип – нужно заранее исходить из того, что после серьезного инцидента кто-то спросит, почему система вообще могла это сделать.

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

Чем автономнее становятся агенты, тем важнее не пытаться сделать их «ответственными сотрудниками», а наоборот – очень четко оставить ответственность в мире людей, ролей, полномочий и доказуемых действий.

Как обычно, буду рад комментариям, особенно от тех, кто уже проходил согласование подобных внедрений с юристами и безопасниками. Практики здесь пока заметно меньше, чем вопросов.