AI governance — это система правил, ролей и проверок, которая помогает компании безопасно использовать искусственный интеллект без запрета экспериментов. Она определяет, кому доступны данные и модели, кто отвечает за результат, как проверяются ответы и что делать при ошибке. Начинать стоит не с комитета, а с реестра сценариев и уровней риска.
С искусственным интеллектом в компаниях сейчас происходит забавная вещь. Официально его иногда ещё «изучают». Неофициально менеджер уже загрузил в чат договор, маркетолог — клиентскую базу, а аналитик собрал бота, который рекомендует скидки. Все хотели ускориться. Получилась скорость без приборной панели.
Запретить AI целиком — решение простое, строгое и почти бесполезное. Люди продолжат пользоваться удобными инструментами, только уже без правил и следов. Разрешить всё — тоже не стратегия. Поэтому задача руководителя не в том, чтобы выбрать между тормозом и газом. Нужен руль.
Что такое AI governance простыми словами
AI governance, или управление искусственным интеллектом, — это не один регламент и не должность «главного по нейросетям». Это рабочая система, которая связывает бизнес-цели, людей, данные, модели, контроль качества и реакцию на инциденты.
У NIST AI Risk Management Framework эта логика собрана в четыре функции: управлять, описывать контекст, измерять и обрабатывать риски — Govern, Map, Measure, Manage. Важно, что это не одноразовая проверка перед запуском. Управление продолжается весь жизненный цикл AI-системы.
ISO/IEC 42001 смотрит на задачу похожим образом: компании нужна система менеджмента AI, которую устанавливают, поддерживают и постоянно улучшают. Перевожу с языка стандартов на человеческий: правила должны пережить первую презентацию и продолжать работать, когда поменялась модель, сотрудник или поставщик.
Хороший AI governance отвечает на семь вопросов:
- где и для чего компания использует AI;
- какие данные разрешено передавать модели;
- кто может подключать новые инструменты;
- кто владеет бизнес-результатом и риском;
- как проверяется качество ответа;
- что журналируется и сколько хранится;
- как остановить сценарий и разобрать ошибку.
Если на эти вопросы нет ясного ответа, AI в компании уже управляется. Просто управляют им случайность, личные привычки сотрудников и настройки внешнего сервиса.
Почему управление AI нельзя отдать только ИТ-отделу
ИТ может проверить интеграцию, доступы и инфраструктуру. Информационная безопасность — оценить утечки и атаки. Юристы — ограничения по данным и ответственности. Но никто из них вместо коммерческого директора не решит, допустимо ли отправить клиенту предложение, собранное моделью на неполных данных.
AI действует внутри бизнес-процесса. Поэтому ответственность тоже должна проходить через бизнес.
Типовая ситуация: маркетинг запускает генерацию карточек товаров. Технически всё работает. Но модель придумывает свойства, которых нет в документации. Это не «ошибка нейросети где-то в облаке». Это риск конкретного процесса, конкретного владельца и конкретного клиента.
Главный принцип: AI может готовить решение, но ответственность не переезжает в модель. У каждого сценария должен быть человек, который отвечает за его цель, качество и допустимый уровень риска.
Начните с реестра, а не с большого положения
Первый практический шаг — собрать реестр AI-сценариев. Не надо ждать идеальной инвентаризации. За несколько встреч с руководителями функций можно получить первую рабочую карту.
Для каждого сценария достаточно зафиксировать:
- название и бизнес-цель;
- владельца процесса;
- пользователей и затронутых людей;
- модель, сервис или поставщика;
- входные данные и источник данных;
- выход модели и его влияние на решение;
- способ человеческой проверки;
- уровень риска и дату следующего пересмотра.
Такой реестр быстро показывает две неприятные вещи: неизвестные руководству инструменты и сценарии, где у результата нет хозяина. И это полезная неприятность. Невидимый риск наконец становится управляемой задачей.
Разделите AI-сценарии по уровню риска
Проверять каждый запрос к нейросети советом директоров не нужно. Управление без градации риска превращается в бюрократию, а бюрократия учит сотрудников обходить управление.
Я бы начал с трёх уровней.
Низкий риск: можно экспериментировать быстро
Черновик внутреннего текста, варианты заголовков, суммаризация открытого материала, идеи для встречи. Здесь достаточно утверждённого инструмента, запрета на чувствительные данные и обязанности проверить результат перед использованием.
Средний риск: нужен владелец и контрольная процедура
Анализ обращений клиентов, подготовка коммерческого предложения, прогноз спроса, генерация материалов для внешней публикации. Нужны описанные данные, выборка для проверки качества, журнал изменений и человек, который утверждает результат.
Высокий риск: запуск только после отдельного согласования
Решения, влияющие на деньги, права, безопасность, персонал или доступ к услугам; работа с чувствительными и персональными данными; автономные действия от имени компании. Здесь нужны юридическая и техническая оценка, тестирование, ограничение полномочий, мониторинг и понятный способ остановки.
Уровень риска зависит не только от модели. Один и тот же сервис может безобидно переписать абзац и опасно принять решение о клиенте. Оценивайте сценарий целиком: данные, цель, людей, последствия и степень автономности.
Распределите ответственность без коллективной безответственности
Комитет по AI может быть полезен, но комитет не должен становиться местом, где ответственность растворяется в протоколе. Для каждого сценария нужны четыре понятные роли.
- Владелец бизнеса отвечает за цель, пользу и последствия применения.
- Технический владелец отвечает за модель, интеграцию, версии, доступность и ограничения.
- Контрольные функции проверяют данные, безопасность, право и соответствие внутренним правилам.
- Пользователь или проверяющий понимает, что именно он обязан проверить перед действием.
Для небольшого бизнеса один человек может совмещать роли. Это нормально. Ненормально, когда роли вообще не названы и после ошибки начинается корпоративная игра «я думал, это проверил кто-то другой».
Установите правила доступа к данным и моделям
Правило «не загружать ничего секретного» звучит убедительно до первого рабочего дедлайна. Сотруднику нужна не абстрактная осторожность, а понятная классификация.
Минимальный вариант:
- Открытые данные — можно использовать в утверждённых публичных инструментах.
- Внутренние данные — только в корпоративных сервисах с согласованными условиями хранения и обучения.
- Конфиденциальные и персональные данные — только в отдельно разрешённых сценариях с контролем доступа, минимизацией данных и юридической проверкой.
- Критичные данные — запрет на передачу внешней модели, если нет специально построенного защищённого контура.
Доступы выдавайте не «к AI вообще», а по роли и задаче. Маркетологу не нужен тот же набор данных и полномочий, что аналитику или разработчику. Для внешних моделей отдельно фиксируйте, сохраняются ли запросы, используются ли они для обучения, где обрабатываются данные и как удалить историю.
Выбирайте модель под задачу, а не по громкости бренда
В реестре моделей полезно хранить не рейтинг «кто умнее», а карточку пригодности:
- для каких задач модель разрешена;
- какие данные принимает;
- как устроены хранение и доступ;
- какие ограничения качества уже обнаружены;
- есть ли нужные журналы, договорные гарантии и возможность отключения;
- сколько стоит полный сценарий, а не один запрос.
Новая версия модели — это изменение системы. После смены версии стоит повторить ключевые тесты: точность, устойчивость инструкций, формат ответа, обработку отказов и поведение на опасных запросах. Красивое обновление в интерфейсе не является актом приёмки.
Проверяйте не AI вообще, а конкретный результат
Фраза «человек остаётся в контуре» часто звучит как заклинание. Но человек, который за минуту подтверждает сто ответов, в контуре присутствует примерно как декоративный фикус.
Проверка должна быть связана с риском:
- для текста — факты, обещания, тональность, права на материалы;
- для аналитики — полнота данных, методика, выбросы и воспроизводимость;
- для рекомендаций — ошибки по важным группам и стоимость неверного решения;
- для автоматических действий — лимиты полномочий, подтверждение и аварийная остановка.
Соберите небольшой набор контрольных примеров и прогоняйте его перед запуском и после значимых изменений. NIST отдельно подчёркивает необходимость тестировать AI до внедрения и регулярно во время эксплуатации. А OWASP Top 10 for LLM Applications напоминает: у генеративных систем есть специфические угрозы — от манипуляции инструкциями до раскрытия чувствительной информации и чрезмерных полномочий.
Журналирование: записывайте достаточно, но не всё подряд
Без журналов невозможно понять, какая версия модели дала ответ, какие данные использовались и кто одобрил действие. Но бессмысленное сохранение всех запросов тоже создаёт риск: вы строите склад чувствительной информации, который придётся защищать.
Для значимых сценариев журналируйте:
- дату, пользователя и идентификатор сценария;
- версию модели и системной инструкции;
- источники данных или их безопасные идентификаторы;
- результат автоматических проверок;
- решение человека — принято, исправлено или отклонено;
- выполненное системой действие;
- ошибку или инцидент.
Срок хранения и состав логов определяйте заранее. Не записывайте секреты «на всякий случай». Журнал нужен для расследования и улучшения, а не для коллекционирования цифровой пыли.
Как не остановить эксперименты правилами
Самая рабочая конструкция — две полосы движения.
Быстрая полоса предназначена для низкорисковых экспериментов: заранее разрешённые инструменты, открытые или тестовые данные, ограниченный срок пилота, простой шаблон описания результата.
Контролируемая полоса — для сценариев с клиентскими данными, внешними коммуникациями, финансовыми последствиями или автономными действиями. Здесь больше проверок, но и решение принимается по понятному маршруту, а не ходит месяц по кабинетам.
Полезно установить срок рассмотрения пилота и стандартный пакет документов на одну-две страницы: цель, данные, модель, риск, метрика качества, владелец, способ остановки. Тогда governance ускоряет хорошие эксперименты, потому что команда заранее понимает правила игры.
План внедрения AI governance на 30 дней
Первая неделя: увидеть реальность
Назначьте координатора, соберите известные AI-инструменты и опросите функции о фактическом использовании. Создайте первый реестр. Не устраивайте охоту на виноватых: иначе получите красивую таблицу, в которой нет половины реальности.
Вторая неделя: определить границы
Утвердите три уровня риска, классификацию данных и список разрешённых инструментов. Назовите владельцев текущих сценариев. Отдельно запретите очевидно опасные действия: передачу критичных данных во внешние сервисы и автономные решения без лимитов.
Третья неделя: построить проверки
Для приоритетных сценариев создайте контрольные примеры, критерии качества и форму человеческого подтверждения. Настройте минимальные журналы. Проверьте, можно ли остановить интеграцию без героизма разработчиков в три часа ночи.
Четвёртая неделя: запустить цикл улучшения
Проведите разбор двух-трёх сценариев, а не аудит всей вселенной. Зафиксируйте найденные ошибки, владельцев действий и дату пересмотра. Опубликуйте сотрудникам короткие правила и маршрут согласования нового эксперимента.
Через месяц у компании не будет идеальной системы. Зато появится управляемый контур: видно, где работает AI, кто отвечает, что проверяется и куда сообщать о проблеме. Это гораздо ценнее толстого положения, которое никто не открывал после согласования.
Что руководителю проверить уже сегодня
Откройте любой действующий AI-сценарий и задайте пять вопросов:
- Кто владелец результата?
- Какие данные уходят в модель?
- Как мы обнаружим убедительную, но неверную рекомендацию?
- Где сохранилась история решения?
- Как остановить систему, если что-то пошло не так?
Если на три вопроса нет ответа, начинать надо не с покупки ещё одной модели. Начните с управления той, которая уже работает.
Подписывайтесь: здесь разбираем маркетинг, AI и управленческие процессы без культа волшебной кнопки. Волшебных кнопок у меня нет. Зато есть неудобная привычка спрашивать, кто отвечает за результат.
Вопросы и ответы об AI governance
Что входит в AI governance?
Реестр AI-систем и сценариев, классификация рисков и данных, роли и ответственность, правила выбора моделей, тестирование, человеческий контроль, журналирование, мониторинг и порядок реакции на инциденты.
Нужен ли AI governance небольшому бизнесу?
Да, но в лёгкой форме. Малому бизнесу достаточно реестра сценариев, трёх уровней риска, списка разрешённых инструментов, правил работы с данными и назначенных владельцев. Масштаб контроля должен соответствовать последствиям.
Кто должен отвечать за управление искусственным интеллектом?
Общую систему обычно координирует руководитель или кросс-функциональная группа, но за каждый сценарий отвечает конкретный владелец бизнеса. ИТ, безопасность и юристы помогают контролировать риски, не подменяя владельца результата.
Как контролировать качество ответов AI?
Заранее определить критерии, собрать контрольный набор примеров, тестировать до запуска и после смены модели, проверять ошибки на реальных выборках и фиксировать решения человека. Формальная кнопка «подтвердить» сама по себе не является контролем.
Как внедрить AI governance и не задушить инновации?
Разделить сценарии по риску. Для безопасных экспериментов дать быстрый маршрут и утверждённые инструменты, а усиленную проверку применять только там, где затронуты чувствительные данные, клиенты, деньги, права или автономные действия.
Дополнительные материалы: NIST AI Risk Management Framework, NIST AI RMF Playbook, обзор системы менеджмента AI от ISO, профиль NIST для генеративного AI.
Материал подготовил Директор по маркетингу Виктор Клищенко
