Microsoft перестраивает Responsible AI под эпоху агентов: контроль важнее обещаний

Третий ежегодный Responsible AI Transparency Report Microsoft фиксирует смену объекта управления. Если прежняя дискуссия об ответственном ИИ в основном вращалась вокруг свойств модели и ответа на отдельный запрос, то теперь риск возникает в связке из моделей, инструментов, данных, приложений и людей. Агент способен помнить контекст, обращаться к сервисам и выполнять многошаговые действия от имени пользователя. Поэтому обычной проверки перед релизом уже недостаточно: нужны ограничения во время исполнения, журналирование и возможность вмешаться после запуска.

От модели — к траектории действий

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

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

Новый Responsible AI Standard

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

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

Процесс соотнесён с функциями NIST AI Risk Management Framework: Govern, Map, Measure и Manage. К ним Microsoft добавляет централизованный надзор перед выпуском. За отчётный год компания обновила таксономии рисков, ввела моделирование угроз для агентного ИИ, расширила оценки и защиту от prompt injection, увеличила покрытие классификаторов безопасности и усилила механизмы управления агентами. Это не разовая сертификация продукта, а заявка на цикл: определить риск, измерить его, применить меры, принять решение о релизе, а затем продолжить наблюдение.

Runtime-контроль как новая точка ответственности

В блоге, сопровождающем отчёт, Microsoft описывает набор инструментов, переводящих политику в инженерные проверки. AI Red Teaming Agent должен ускорять поиск рисков; специализированные evaluators — измерять качество, безопасность и эффективность агентных приложений; RAMPART — превращать результаты red teaming в повторяемые тесты. ASSERT и Agent Control Specification предназначены для проверки поведения агентов относительно заданных политик, размещения контрольных точек внутри рабочего процесса и мониторинга исполнения.

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

Показательный пример — Copilot Cowork, которому Microsoft приписывает выполнение рабочих задач в Microsoft 365. В отчёте его защита описана как сочетание пользовательских подтверждений, доступа на основе разрешений, защитных ограничений и поэтапного внедрения. Это разумный шаблон для корпоративного агента: не выдавать универсальные полномочия, запрашивать подтверждение для чувствительных действий и сначала проверять систему на ограниченной аудитории. Однако отчёт не раскрывает метрики ошибок или частоту блокировок, поэтому кейс показывает архитектуру контроля, а не независимое доказательство её эффективности.

Ответственность внедряющей стороны

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

Масштаб программы Microsoft иллюстрирует цифрами: при обновлении стандарта были рассмотрены более 100 принятых и предложенных законов, а к работе привлекли свыше 80 сотрудников из более чем 30 команд. Для проверки Copilot Health компания консультировалась более чем с 250 лицензированными клиницистами из более чем двух десятков стран и с обычными пользователями. Партнёрство External Red Team Alliance объединило 18 университетов на шести континентах.

Эти показатели демонстрируют охват, но не заменяют результативность. Transparency Report остаётся самоотчётом Microsoft: он подробно описывает процессы, инструменты и инвестиции, но не даёт внешнему читателю полной картины инцидентов, ложных срабатываний или эффективности конкретных ограничений. Сертификация ISO 42001 для широкого портфеля, включая Microsoft 365 Copilot, Foundry и GitHub Copilot, добавляет формальную проверяемость системы менеджмента, но также не равна гарантии безошибочности каждого агента.

Что меняется для рынка

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

Microsoft предлагает достаточно цельную модель: правила по слоям стека, риск-ориентированные требования, предрелизный контроль и runtime-механизмы. Следующий уровень прозрачности — публикация измеримых результатов: какие агентные сценарии чаще нарушают политику, насколько хорошо сдерживается prompt injection, сколько опасных действий остановлено до исполнения и как быстро устраняются инциденты. В эпоху автономных действий доверие будет зависеть не от заявления о принципах, а от способности показать, где именно система остановит агента и что произойдёт, если она этого не сделает.