Управление искусственным интеллектом: практическая основа для организаций (в свете NIST AI RMF, ISO/IEC 42001 и закона о защите персональных данных)

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

Основополагающие стандарты

• NIST AI Risk Management Framework (AI RMF 1.0): Предлагает ориентированный на риски подход с функциями управления, картирования, измерения и администрирования (govern, map, measure, manage).
• ISO/IEC 42001:2023: Стандарт системы менеджмента искусственного интеллекта; переносит логику системы управления, аналогичную ISO 27001, на сферу ИИ.
• Регламент искусственного интеллекта Европейского союза (AI Act): Классифицирует сценарии использования по степени риска и может налагать обязательства на организации, работающие с ЕС.
• Законодательство о персональных данных: GDPR в ЕС и аналогичные законы; хотя они не созданы специально для ИИ, любое применение ИИ подпадает под эти правила.

Эти стандарты кажутся масштабными, но их суть сводится к четырем вопросам: Что мы используем? С какими данными? Кто несет ответственность? Что делать в случае ошибки?

1. Инвентаризация: что мы используем?

Первый шаг — перечислить все случаи использования ИИ в организации: официальные проекты, встроенные в ПО функции и инструменты, используемые сотрудниками индивидуально. Каждая запись включает цель использования, тип входных данных, место применения результата и ответственное лицо. Эта инвентаризация является аналогом инвентаризации активов в стандарте ISO 27001.

2. Классификация данных: какие данные могут поступать в какой инструмент?

Для большинства организаций достаточно простой трехуровневой классификации: общедоступные, внутренние и конфиденциальные (персональные данные, финансовые данные, договоры). Пример правила: данные конфиденциального уровня могут передаваться только во внутренние (локальные) модели; внутренние данные могут направляться сервисам с четкими условиями обработки данных; для общедоступных данных ограничений нет. Донесение этого правила до сотрудников с помощью одностраничного руководства эффективнее объемных политик.

3. Классы использования и одобрение человеком

Классифицируйте каждый сценарий использования в зависимости от его воздействия:

1. Поддерживающий: Черновики текста, резюме, предложения кода. Окончательное решение принимает человек; одобрение заложено в саму структуру процесса.
2. Поддержка принятия решений: Финансовый анализ, оценка рисков, предварительный отбор кандидатов. Результат не передается в обработку без проверки человеком, указание первоисточника обязательно.
3. Автоматизированная операция: Результат модели напрямую инициирует действие. Для большинства организаций этот класс не должен использоваться без четкой оценки рисков и механизма отката.

Цель управления заключается не в замедлении работы ИИ, а в заблаговременном определении того, какой сценарий использования должен быть быстрым, а какой — осторожным.

4. Ответственность и аудит

У каждого применения ИИ должен быть владелец процесса — не техническая команда, а владелец бизнес-процесса, в котором используется результат. Системы должны фиксировать, кто, с какими данными и какой результат получил. Без аудита невозможен ни анализ ошибок, ни подотчетность перед регуляторами.

5. Управление ошибками и инцидентами

Модели могут выдавать неверные, предвзятые или вымышленные результаты. Модель управления определяет не то, что этого «не произойдет», а то, «что делать, если это случится»: порядок сообщения пользователями об ошибке, пересмотр затронутых решений и, при необходимости, временная приостановка использования. Это расширение управления инцидентами информационной безопасности на сферу ИИ.

6. Оценка поставщиков

При использовании внешних сервисов в договоре должны быть даны ответы на следующие вопросы: используются ли входные данные для обучения моделей? В какой стране обрабатываются данные? Каков срок хранения? Кто субподрядчики? Эти вопросы имеют ту же логику, что и контракты с обработчиками данных в рамках GDPR.

Стартовый пакет для небольших команд

• Одностраничное руководство по использованию (разрешенные инструменты, классы данных, запреты).
• Таблица инвентаризации (инструмент, назначение, данные, владелец).
• Правило «укажи источник и подтверди» для сценариев поддержки принятия решений.
• Совещание по пересмотру раз в квартал.

Пример руководства по использованию (одна страница)

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

Разрешенные инструменты: Внутренний ассистент (все классы данных); внешний контрактный сервис X (только общедоступные и внутренние данные).

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

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

Источник: Каждое утверждение о фактах, поступающее от ИИ, проверяется по первоисточнику.

Уведомление: Заметив ошибочный, предвзятый или сомнительный результат, сообщите на адрес ...; уведомление не является поводом для наказания.

Пример таблицы инвентаризации

ИспользованиеИнструментКласс данныхКласс использованияВладелец процесса Суммаризация заметок совещанийВнутренний ассистентВнутренниеПоддерживающийОперационный отдел Поиск пунктов договораВнутренний RAGКонфиденциальныеПоддержка принятия решенийЮридический отдел Черновик для социальных сетейВнешний сервис XОбщедоступныеПоддерживающийОтдел маркетинга Прогноз движения денежных средствВнутренняя модельКонфиденциальныеПоддержка принятия решенийФинансовый отдел

Технический контроль: увязка политики с кодом

Управление не ограничивается документацией; системы должны обеспечивать соблюдение политик:

• Доступ с фильтрацией прав: Ассистент не видит данные, которые пользователю недоступны (на уровне базы данных).
• Журналирование: Каждый запрос и ответ сохраняются с информацией о пользователе и времени; определены права доступа и срок хранения.
• Шлюз одобрения: Результаты класса поддержки принятия решений не продвигаются в рабочем процессе без отметки человека об «одобрении».
• Шлюз внешних сервисов: Запросы к внешним сервисам проходят через единый шлюз; конфиденциальные данные блокируются на этом шлюзе и фиксируются в журнале.

Измерение: за чем следить?

Функция «измерения» в NIST AI RMF может быть сведена к трем простым показателям для организации: количество и тип сообщаемых ошибок, доля результатов, отклоненных при проверке человеком (не числовая цель, а тенденция), и выявление случаев использования вне инвентаризации. Эти показатели рассматриваются на квартальном пересмотре; цель состоит не в наказании, а в улучшении правил и инструментов.

Часто задаваемый вопрос: «Разве это нас не замедлит?»

Правильно спроектированная модель управления практически не ограничивает поддерживающие сценарии использования; сценарии, требующие внимания, определяются заранее. Замедляет работу не управление, а неопределенность правил: сотрудник, не знающий, какой инструмент можно использовать, либо не использует его вовсе, либо использует неправильно. Четкость — обязательное условие скорости.

В разрабатываемых нами в Cy Logic системах искусственного интеллекта мы рассматриваем верификацию, авторизацию и аудиторский след в качестве обязательных компонентов; модель управления представляет собой их корпоративную сторону и должна проектироваться вместе с технической архитектурой.