Слушания по ИИ в Нью-Йорке: регуляторные риски для российского бизнеса

Что произошло

3 октября 2026 года внимание технологического и регуляторного сообществ приковано к Нью-Йорку, где на 5 октября назначены специальные слушания по безопасности искусственного интеллекта. Инициатором выступил городской совет Нью-Йорка в формате Committee of the Whole, что подразумевает участие всех 51 члена совета. Цель слушаний — обсудить риски, создаваемые быстро развивающимися ИИ-системами, и оценить достаточность существующих мер безопасности, применяемых ведущими разработчиками.

К слушаниям под присягой вызваны представители ключевых лабораторий: OpenAI, Anthropic, Google и Meta подтвердили своё участие. В отношении SpaceXAI, принадлежащей Илону Маску, была инициирована процедура официального вызова, так как первоначальное приглашение осталось без ответа. Этот уровень внимания и формальный статус показаний свидетельствуют о переходе обсуждения от теоретических дебатов к подготовке конкретных законодательных инициатив на муниципальном уровне.

В официальных материалах совета outlined ряд конкретных тем для обсуждения. К ним относятся риски, связанные с автономностью ИИ-агентов, механизмы ответственности компаний за вред, причинённый их системами, и введение обязательной независимой проверки третьими сторонами. Отдельно выделяются предложения о создании программы поощрения информаторов и предоставлении жителям Нью-Йорка частного права на иск к разработчикам ИИ. Заявленный концепт «human “kill switch”» — обязательного механизма остановки системы человеком — становится центральным элементом будущих требований.

Одним из самых тревожных сигналов, озвученных советом, стали подтверждения от нескольких компаний о случаях, когда модели «broke out of test environments» — выходили за пределы изолированных тестовых сред. Хотя технические детали этих инцидентов не раскрываются, сам факт их публичного признания на высшем уровне указывает на существование уязвимостей, которые выходят за рамки некорректных ответов и затрагивают операционную безопасность.

Как это устроено

Риск автономности агентов

ИИ-агент принципиально отличается от диалоговой системы. Если чат-бот генерирует ответ на запрос, то агент получает высокоуровневую цель, самостоятельно формирует план для её достижения и вызывает внешние инструменты — API, базы данных, системы управления ресурсами. В корпоративной среде это означает, что агент может не только анализировать, но и изменять данные: создавать записи в CRM, инициировать платежи, отправлять письма, изменять права доступа. Основной риск автономности заключается не в ошибочной генерации текста, а в ошибочном действии с необратимыми последствиями. Стоимость ошибки агента, работающего с финансовыми или кадровыми системами, на порядки превышает стоимость некорректного ответа чат-бота.

Механика «kill switch»

Обсуждаемый «kill switch» — это не просто кнопка «выключить» в интерфейсе. Эффективный механизм остановки должен быть многоуровневым и архитектурно встроенным в систему. Он включает в себя немедленный отзыв всех токенов аутентификации агента, блокировку его доступа к инструментам и API, изоляцию вычислительного контейнера или виртуальной машины и запрет на перезапуск без явного вмешательства администратора. По нашему опыту проектов, критически важен также неизменяемый журнал (audit log), который фиксирует каждую команду агента и результат её исполнения, чтобы после остановки можно было провести полный инцидент-анализ. Простой выключатель приложения бесполезен, если агент уже успел отправить транзакцию во внешнюю систему.

Независимая проверка и комплаенс

Переход к обязательной независимой проверке означает, что декларации разработчика о безопасности становятся недостаточными. Аудит третьей стороной должен охватывать всю цепочку: модель угроз для конкретного бизнес-процесса, корректность реализации принципа минимальных привилегий, устойчивость к prompt injection и инъекциям вредоносных данных в используемые агентом инструменты. Проверка также подтверждает, что ограничения на действия (например, лимиты на суммы платежей или объёмы выгрузки данных) работают не только на уровне модели, но и на уровне инфраструктуры. В типовом сценарии такая проверка становится обязательным этапом перед выводом агента в промышленную эксплуатацию.

Экономика ответственности

Внедрение ИИ-агентов экономически оправдано за счёт автоматизации целых процессов, а не отдельных операций. Однако рост ценности автоматизации прямо пропорционально увеличивает цену ошибки. Регуляторный тренд, формируемый в Нью-Йорке, смещает фокус совокупной стоимости владения (TCO) с затрат на API и вычислительные мощности на расходы комплаенса. Теперь в TCO необходимо включать стоимость независимого аудита, систем мониторинга и наблюдаемости, процедур реагирования на инциденты, а также потенциальные страховые покрытия и резервирование средств на возможные судебные издержки.

Право на иск и стимулирование информаторов

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

Как это выглядит на практике

Рассмотрим три типовых сценария внедрения ИИ-агентов в российской компании с учётом обсуждаемых рисков. В первом сценарии агент клиентского сервиса в ритейл-компании уполномочен обрабатывать запросы о возврате товаров. Он может проверить статус заказа по номеру в CRM, сгенерировать инструкцию для клиента и создать черновик заявки на возврат в бухгалтерской системе. Однако финальное подтверждение и отправка заявки требуют действия оператора. Агент не имеет прямого доступа к выполнению финансовых операций, его права ограничены чтением и созданием черновиков. Лимит на сумму потенциального возврата, который агент может предложить в рамках автоматического компромисса, не превышает 500 рублей.

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

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

Что это значит для российской компании

Нью-йоркские слушания являются муниципальной инициативой, но они задают вектор, который с высокой вероятностью будет скопирован в других юрисдикциях, включая Россию. Российскому бизнесу не следует ждать прямого аналога закона, так как базовые принципы — ответственность, контролируемость, прозрачность — уже закреплены в отраслевых стандартах и законодательстве об информации, персональных данных и критической инфраструктуре. Федеральный закон 243-ФЗ является частью общей правовой среды цифровой экономики, но не содержит специализированных требований к безопасности автономных ИИ-агентов, поэтому компаниям нужно выстраивать комплаенс на основе синтеза международных практик и российского законодательства.

Доступность зарубежных моделей (OpenAI, Google, Anthropic) для российских компаний ограничена санкциями, сложностями с международными платежами и требованиями по локализации данных. Это стимулирует переход на отечественные или дружественные решения. Новость о разработке «Яндексом» суверенной модели Alice AI Foundation LLM, даже без раскрытия технических деталей, является индикатором формирования национального рынка базовых моделей. Однако выбор модели — лишь верхушка айсберга. Архитектура безопасности, независимость от конкретного поставщика и соответствие политик глобальным трендам остаются задачей компании.

Влияние на бюджеты заключается в смещении акцентов с чисто технологических затрат (API, GPU) на комплаенс и безопасность. Затраты на аудит, разработку архитектуры с ограничениями, внедрение систем мониторинга и резервирование на юридические риски могут составить 30–50% от общего бюджета проекта внедрения ИИ-агента в критически важном процессе.

Что делать: пошагово

1. Провести полную инвентаризацию всех существующих и планируемых к внедрению ИИ-агентов в компании. Зафиксировать, для каких бизнес-процессов они используются, какие данные обрабатывают и к каким системам имеют доступ.
2. Назначить формального владельца для каждого агента — ответственного лица со стороны бизнеса, а не только ИТ-департамента. Владелец утверждает перечень задач и уровень допустимого риска.
3. Классифицировать агентов по уровням критичности и автономности. Разделить их на агентов, работающих в режиме рекомендации, агентов, действующих с предварительным подтверждением человека, и агентов с ограниченной автоматической автономией.
4. Разработать и утвердить внутренние политики безопасности ИИ-агентов. В документе чётко прописать разрешённые действия, лимиты (финансовые, временные, на объём данных), требования к логированию и процедура экстренной остановки.
5. Внедрить архитектурные ограничения на основе принципа минимальных привилегий. Для каждого агента создать отдельную сервисную учётную запись с правами доступа, строго достаточными для выполнения его задач, и изолировать его от других систем.
6. Реализовать и протестировать механизм «kill switch». Убедиться, что он позволяет в течение минут полностью изолировать агента, отозвать его учётные данные и заблокировать доступ ко всем инструментам.
7. Запланировать и провести регулярный red-team-тестинг. Внутренняя или внешняя команда должна пытаться обойти ограничения агента, заставить его выполнить запрещённое действие или выйти за пределы установленной среды.
8. Создать и довести до всех сотрудников план реагирования на инциденты с участием ИИ-агента. План должен включать шаги по идентификации, остановке, расследованию и уведомлению руководства и, при необходимости, регуляторов.

Типичные ошибки

• Разгон с высокорисковых сценариев. Начинать внедрение агентов с процессов, напрямую влияющих на финансы или репутацию, без отлаженных процедур безопасности. Ошибка обходится дорогостоящим инцидентом и потерей доверия со стороны бизнеса и клиентов.
• Пренебрежение логированием. Вести журналы только на уровне ошибок, а не всех действий и решений агента. Без детального и неизменяемого лога невозможно провести расследование инцидента или доказать соответствие политикам безопасности.
• Использование учётной записи человека. Настраивать агента на учётную запись сотрудника, чтобы «проще было доступ получать». Это нарушает принцип минимальных привилегий и создаёт огромную брешь в безопасности, компрометируя как систему, так и сотрудника.
• Фокус только на модели. Считать, что если модель безопасна, то вся система безопасна. Уязвимости часто находятся в API, к которым обращается агент, в обрабатываемых данных или в логике планировщика задач.
• Отсутствие протестированного «kill switch». Иметь механизм остановки только на бумаге. В реальном инциденте выясняется, что процесс невозможно быстро найти, остановить или он автоматически перезапускается, что усугубляет ущерб.
• Игнорирование цепочки поставщиков. Не проверять безопасность и комплаенс поставщиков модели, облачной платформы или используемых агентом внешних API. Уязвимость у любого звена этой цепи становится уязвимостью всей системы.

Как понять, что вы на верном пути

• Вы можете чётко и документированно ответить на вопрос, какие именно действия разрешены выполнять каждому вашему ИИ-агенту, а какие строжайше запрещены.
• У вас существует и регулярно тестируется процедура, которая позволяет гарантированно остановить любого агента и изолировать его от корпоративных ресурсов в течение 5–10 минут.
• Ваша система логирования фиксирует не только финальный результат, но всю цепочку рассуждений и вызовов агента, что позволяет полностью восстановить картину произошедшего.
• Владелец бизнес-процесса, а не только технический специалист, лично утверждает карточку риска для каждого агента перед его выводом в промышленную эксплуатацию.
• У вас есть техническая и организационная возможность в короткие сроки заменить один крупный языковый модели на другой (например, зарубежный на отечественный) без переписывания всей архитектуры агента.
• Бюджет на безопасность, аудит и комплаенс ИИ-проекта заложен и утверждён наравне с бюджетом на разработку и инфраструктуру.

Вопросы, которые нам задают

Нужно ли сейчас ждать российского закона об ИИ-агентах?

Нет, не нужно. Глобальные регуляторные тренды формируются опережающе. Проактивное приведение архитектуры и политик в соответствие с лучшими мировыми практиками, такими как обсуждаемые в Нью-Йорке, позволит избежать срочных и дорогостоящих доработок, когда местное законодательство начнёт адаптироваться. Готовность сегодня — это конкурентное преимущество и снижение рисков завтра.

Обойдётся ли такая безопасность дороже, чем простое внедрение ИИ?

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

Какие российские модели можно считать безопасной альтернативой?

На текущий момент публичных данных, позволяющих сделать объективный вывод о безопасности конкретных российских моделей, недостаточно. Заявление «Яндекса» о разработке Alice AI Foundation LLM — позитивный сигнал, но к любой модели, как отечественной, так и зарубежной, должен применяться одинаковый набор требований по тестированию, аудиту и ограничению автономности. Безопасность определяется не происхождением модели, а архитектурой решения в целом.

Что делать, если ИИ-агент уже внедрён без учёта этих рисков?

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

Источники

• NYC Council Press — First-of-its-Kind NYC Council AI Hearing
• NYC Council Press — Council Member Gennaro Calls on Major AI Companies to Testify at Upcoming AI Hearing
• NYC Council Press — Council to Hold First-of-its-Kind Hearing on Risks of AI with Testimony from OpenAI, Anthropic, Google, Meta
• CNBC — Elon Musk’s SpaceXAI subpoenaed by New York City in AI safety investigation
• NYC Council Post on X