AI Governance: как управлять ИИ в компании

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

ISO/IEC 42001:2023 задаёт требования к созданию и постоянному улучшению системы менеджмента ИИ. Практическую структуру Govern, Map, Measure и Manage даёт NIST AI RMF Playbook.

Создайте реестр ИИ-систем

В контуре управления этот раздел отвечает за единый список моделей, функций, поставщиков и интеграций.

• Опишите единый список моделей, функций, поставщиков и интеграций одним предложением без названия продукта.
• Зафиксируйте риск: теневой сервис работает без владельца.
• Сохраните подтверждение: карточка системы с версией и назначением.
• Назначьте роль «координатор AI Governance» и дату повторной проверки.

Без него возникает теневой сервис работает без владельца.

Для области «единый список моделей, функций, поставщиков и интеграций» сравните правила отделов и устраните несовместимые решения.

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

Роль координатор AI Governance получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется реестр, который сверяется с закупками и доступами. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «карточка системы с версией и назначением» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

Раз в квартал сопоставляйте карточку «единый список моделей, функций, поставщиков и интеграций» с закупками, журналами доступа и рабочими интеграциями.

Расхождения превращайте в задачи, ведущие к результату «реестр, который сверяется с закупками и доступами».

Назначьте владельцев решений

В контуре управления этот раздел отвечает за бизнес-результат, техническую работу, данные и риск.

Без него возникает ответственность растворяется между отделами.

Для области «бизнес-результат, техническую работу, данные и риск» сравните правила отделов и устраните несовместимые решения.

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

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

Роль руководитель направления получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется одно имя у каждого критичного решения. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «матрица ролей с правом остановки» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «одно имя у каждого критичного решения».

Классифицируйте сценарии по риску

В контуре управления этот раздел отвечает за влияние на человека, деньги, права и операции.

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

Без него возникает чат для идей и автоматический отказ клиенту проверяются одинаково.

Для области «влияние на человека, деньги, права и операции» сравните правила отделов и устраните несовместимые решения.

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

Роль риск-менеджер получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

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

Свяжите контроль «шкала последствий и вероятность» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «уровень риска до выбора набора контролей».

Установите ворота перед запуском

В контуре управления этот раздел отвечает за обязательные согласования и испытания.

Без него возникает релиз проходит по календарю при открытых дефектах.

Для области «обязательные согласования и испытания» сравните правила отделов и устраните несовместимые решения.

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

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

Роль релизный комитет получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

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

Свяжите контроль «чек-лист допуска и подписи владельцев» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «решение запускать, ограничить или вернуть на доработку».

Управляйте поставщиками

В контуре управления этот раздел отвечает за модель, API, данные, обновления и прекращение сервиса.

• Опишите модель, API, данные, обновления и прекращение сервиса одним предложением без названия продукта.
• Зафиксируйте риск: внешнее изменение ломает внутренний контроль.
• Сохраните подтверждение: договор, уведомления и план замены.
• Назначьте роль «закупки и архитектура» и дату повторной проверки.

Без него возникает внешнее изменение ломает внутренний контроль.

Для области «модель, API, данные, обновления и прекращение сервиса» сравните правила отделов и устраните несовместимые решения.

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

Роль закупки и архитектура получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется понятные обязательства и путь выхода. Его пересматривают после смены модели, данных, поставщика или назначения системы.

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

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «понятные обязательства и путь выхода».

Свяжите контроль с риском

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

Без него возникает команда собирает длинный универсальный чек-лист.

Для области «конкретная мера для конкретного нежелательного события» сравните правила отделов и устраните несовместимые решения.

• Опишите конкретная мера для конкретного нежелательного события одним предложением без названия продукта.
• Зафиксируйте риск: команда собирает длинный универсальный чек-лист.
• Сохраните подтверждение: таблица риск — контроль — доказательство.
• Назначьте роль «владелец контроля» и дату повторной проверки.

Для контроля нужен артефакт: таблица риск — контроль — доказательство. В нём должны быть дата, владелец, область действия и ссылка на принятое решение.

Роль владелец контроля получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется каждая мера имеет проверяемую причину. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «таблица риск — контроль — доказательство» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «каждая мера имеет проверяемую причину».

Следите за изменениями

В контуре управления этот раздел отвечает за новая версия модели, промпта, базы и инструмента.

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

Без него возникает система после обновления считается прежней.

Для области «новая версия модели, промпта, базы и инструмента» сравните правила отделов и устраните несовместимые решения.

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

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

На выходе появляется своевременный возврат к проверке. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «журнал изменений и порог повторной оценки» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «своевременный возврат к проверке».

Организуйте сообщения об инцидентах

В контуре управления этот раздел отвечает за ошибки, обход ограничений и утечки.

Без него возникает сотрудники скрывают сбой из-за неясного канала.

Для области «ошибки, обход ограничений и утечки» сравните правила отделов и устраните несовместимые решения.

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

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

Роль владелец инцидентов получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется быстрая фиксация без поиска виновного. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «форма события, сроки и правило эскалации» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

Раз в квартал сопоставляйте карточку «ошибки, обход ограничений и утечки» с закупками, журналами доступа и рабочими интеграциями.

Расхождения превращайте в задачи, ведущие к результату «быстрая фиксация без поиска виновного».

Отчитывайтесь понятными показателями

В контуре управления этот раздел отвечает за покрытие реестра, контролей и открытых рисков.

• Опишите покрытие реестра, контролей и открытых рисков одним предложением без названия продукта.
• Зафиксируйте риск: руководство получает число запросов вместо картины риска.
• Сохраните подтверждение: панель статусов и просроченных действий.
• Назначьте роль «координатор governance» и дату повторной проверки.

Без него возникает руководство получает число запросов вместо картины риска.

Для области «покрытие реестра, контролей и открытых рисков» сравните правила отделов и устраните несовместимые решения.

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

Роль координатор governance получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется решения о ресурсе и допустимом остаточном риске. Его пересматривают после смены модели, данных, поставщика или назначения системы.

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

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

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

Расхождения превращайте в задачи, ведущие к результату «решения о ресурсе и допустимом остаточном риске».

Планируйте вывод системы

В контуре управления этот раздел отвечает за остановку, экспорт, удаление и замену.

Без него возникает зависимость от модели обнаруживается после закрытия API.

Для области «остановку, экспорт, удаление и замену» сравните правила отделов и устраните несовместимые решения.

• Опишите остановку, экспорт, удаление и замену одним предложением без названия продукта.
• Зафиксируйте риск: зависимость от модели обнаруживается после закрытия API.
• Сохраните подтверждение: план выхода и тест восстановления процесса.
• Назначьте роль «владелец непрерывности» и дату повторной проверки.

Для контроля нужен артефакт: план выхода и тест восстановления процесса. В нём должны быть дата, владелец, область действия и ссылка на принятое решение.

Роль владелец непрерывности получает право остановить запуск при отсутствии обязательного контроля. Такое право заранее записывают в процессе согласования.

На выходе появляется контролируемое прекращение без потери данных и услуги. Его пересматривают после смены модели, данных, поставщика или назначения системы.

Свяжите контроль «план выхода и тест восстановления процесса» с бюджетом и календарём изменений.

Без ресурса мера остаётся пожеланием, а без владельца изменение проходит мимо оценки.

Раз в квартал сопоставляйте карточку «остановку, экспорт, удаление и замену» с закупками, журналами доступа и рабочими интеграциями.

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

Карта ответственности

Что изучить дальше

• политика использования ИИ
• безопасность ИИ-агентов
• тестирование AI-чат-бота
• база знаний компании
• prompt injection
• галлюцинации нейросетей
• обезличивание документа

Чек-лист