Фреймворк управления ИИ: как построить план ответственного использования ИИ

Фреймворк управления ИИ представляет собой набор владельцев, политик, средств контроля и проверок, которые определяют, как организация использует ИИ и что происходит, когда система ошибается. Строится он так: перечислите все системы, которые автоматизируют решения, ранжируйте их по степени влияния, назначьте каждой одного именованного владельца и масштабируйте средства контроля по уровню риска. Если вы работаете в ЕС, сроки задаёт Закон об ИИ. Его правила для систем высокого риска, таких как найм и кредитный скоринг, теперь вступают в силу со 2 декабря 2027 года.

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

Это управленческий сбой, а не технический. Большинство компаний не могут ответить на три базовых вопроса:

1. Кто утверждает, как используется ИИ?
2. Кто проверяет, что он работает как ожидается?
3. Что происходит, когда он ошибается?

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

1. 01Перечислите все системыЕсли система автоматизирует решение, она входит в область применения
2. 02Ранжируйте по влияниюСначала найм, кредитование, ценообразование и скоринг клиентов
3. 03Назначьте одного владельцаЧеловек, а не комитет
4. 04Масштабируйте контроль по рискуТесты, точки проверки человеком и оповещения
5. 05Проверяйте по фиксированному циклуЕжемесячно для критичных систем, ежеквартально для остальных

Сбои и пограничные случаи возвращаются в средства контроля

Команды, которые считают, что соответствие требованиям обеспечивают поставщики ПО, обычно ошибаются. По Закону ЕС об ИИ у организации, которая внедряет систему, есть собственные обязанности.

Документ	Где действует	Статус и что требуется
Закон ЕС об ИИ	Европейский союз	Действует как закон с августа 2024 года. Основан на оценке риска: запрещает одни виды использования, устанавливает обязанности для систем высокого риска и правила прозрачности для остальных
GDPR	Европейский союз	Правовое основание, минимизация данных и права в связи с автоматизированными решениями, которые затрагивают людей
ISO/IEC 42001	Весь мир	Сертифицируемый стандарт системы менеджмента ИИ, опубликован в декабре 2023 года
NIST AI RMF	США	Добровольная рамка, построенная на функциях Govern, Map, Measure и Manage
Законы штатов США	США	Комплексного федерального закона об ИИ нет; растёт число законов штатов, при этом на федеральном уровне пытаются их вытеснить
Singapore Model AI Governance Framework	Сингапур	Добровольные рекомендации по объяснимости и подотчётности
Принципы ОЭСР по ИИ	Страны ОЭСР	Необязательные международные принципы

Предложенный в Канаде закон Artificial Intelligence and Data Act утратил силу из-за пророгации парламента в январе 2025 года, поэтому в этот список он больше не входит.

Сроки Закона ЕС об ИИ после Digital Omnibus 2026 года

В июле 2026 года ЕС изменил Закон об ИИ через Digital Omnibus on AI, Регламент (ЕС) 2026/1744, который отодвинул правила для систем высокого риска. Ниже актуальные даты из графика внедрения Закона об ИИ Европейской комиссии:

Дата	Что вступает в силу
1 августа 2024 года	Закон об ИИ вступает в силу
2 февраля 2025 года	Запрещённые практики и обязанности по обеспечению грамотности в области ИИ
2 августа 2025 года	Правила для моделей ИИ общего назначения; национальные органы и штрафы
2 августа 2026 года	Большинство остальных правил, включая обязанности по прозрачности по статье 50; начинается правоприменение
2 декабря 2026 года	Новые запреты на сексуальные дипфейки без согласия и материалы с сексуальным насилием над детьми
2 декабря 2027 года	Правила для систем высокого риска по приложению III, например в сфере занятости, кредитного скоринга и основных услуг
2 августа 2028 года	Правила для систем высокого риска, встроенных в продукцию, на которую распространяется законодательство ЕС о безопасности продукции (приложение I)

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

1. Область применения и политика

Прежде всего выясните, где системы принимают решения. Большинство команд пропускает этот шаг или считает, что список есть в ИТ. Обычно его там нет.

Идите по подразделениям. Посмотрите на инструменты, которые отсеивают кандидатов, одобряют транзакции или оценивают клиентов. Если система автоматизирует решение, она входит в область применения, называет её кто-нибудь ИИ или нет. Если вы работаете на SAP, включите ИИ-функции, которые вы активировали, например Joule и встроенные предиктивные сценарии.

Затем напишите политики простым языком, которому люди будут следовать. «Мы отдаём приоритет этичному использованию ИИ» политикой не является.

2. Владение

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

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

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

3. Оценка рисков и средства контроля

У каждой системы есть риск. Важно, виден ли он.

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

4. Мониторинг и аудит

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

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

5. Прозрачность

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

6. Обучение

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

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

1. Система и назначение: что она решает или рекомендует и для кого.
2. Владелец: один именованный человек и его заместитель.
3. Уровень риска: например, высокий (влияет на работу людей, их деньги или доступ к услугам), средний или низкий, а также категория по Закону ЕС об ИИ, если она применима.
4. Используемые данные: источники, задействованные персональные данные, согласие и сроки хранения.
5. Поставщик или собственная разработка: и какую документацию предоставляет поставщик.
6. Средства контроля: тесты перед запуском, точки проверки человеком, оповещения.
7. Цикл проверки: ежемесячный, ежеквартальный или ежегодный и дата последней проверки.
8. Порядок действий при инциденте: кого уведомляют, кто может приостановить систему, как информируют пользователей.

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

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

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

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

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

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

Автоматизированные решения без надзора могут давать сбои быстро и дорого. В 2012 году автоматический маршрутизатор ордеров Knight Capital, работавший с дефектным кодом, отправил более 4 миллионов ордеров за 45 минут, и фирма потеряла более 460 миллионов долларов (SEC). Amazon отказалась от экспериментального инструмента для подбора персонала, обнаружив, что он занижал оценку резюме, в которых упоминались женские организации. Тихие сбои встречаются чаще: система месяцами дрейфует, пока жалоба или аудит её не выявят.

ISO/IEC 42001 является сертифицируемым стандартом системы менеджмента ИИ, опубликованным в декабре 2023 года. Фреймворк NIST по управлению рисками ИИ (AI RMF) служит добровольным ориентиром для большинства организаций США. Для специалистов самой известной квалификацией остаётся сертификация Artificial Intelligence Governance Professional (AIGP) от IAPP.

Существуют специализированные инструменты, например IBM watsonx.governance, Fiddler AI и панель Responsible AI в Azure Machine Learning. Для большинства организаций практичный старт проще: реестр, описанный выше, журналирование, контроль доступа и циклы проверки. Об оценке рисков подробнее читайте в моём руководстве по фреймворку управления рисками ИИ. Если ваш ИИ работает внутри SAP, моя статья об управлении ИИ при внедрении SAP описывает средства контроля, специфичные для SAP, а на странице о фреймворке управления ИИ я рассказываю, как помогаю организациям его внедрить.

Что такое фреймворк управления ИИ?

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

Когда вступают в силу правила Закона ЕС об ИИ для систем высокого риска?

После Digital Omnibus on AI (Регламент (ЕС) 2026/1744) правила для систем высокого риска по приложению III, например для ИИ в сфере занятости, кредитного скоринга и основных услуг, вступают в силу со 2 декабря 2027 года. Правила для систем высокого риска, встроенных в продукцию, на которую распространяется законодательство ЕС о безопасности продукции, действуют с 2 августа 2028 года. Запреты действуют с февраля 2025 года, обязанности по прозрачности с августа 2026 года.

Почему управление ИИ важно в средах SAP?

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

Кто отвечает за управление ИИ?

Это межфункциональная задача: соответствие требованиям, ИТ и безопасность, команды по данным, юристы и риск-менеджмент, руководство. Самое важное структурное решение: один именованный владелец на каждую систему ИИ. Человек, а не комитет.

Какие сертификации существуют в области управления ИИ?

Для организаций это ISO/IEC 42001, сертифицируемый стандарт системы менеджмента ИИ. NIST AI RMF является добровольным фреймворком, а не сертификацией. Для специалистов самая известная квалификация в области управления ИИ: сертификация AIGP от IAPP.

Что происходит, если игнорировать управление ИИ?

Заметные сбои: Amazon отказалась от инструмента подбора персонала, который ставил женщин в невыгодное положение, а Knight Capital потеряла более 460 миллионов долларов за 45 минут из-за неисправной автоматической торговой системы. Чаще сбой тише: система месяцами дрейфует, и никто не замечает этого до жалобы или аудита.