Операционная модель AI: ответственность, данные, контроль и отслеживание эффектов

1. Управляйте системой уровня предприятия, а не набором инструментов AI

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

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

Принципы ОЭСР по AI требуют подотчётности, прослеживаемости и систематического управления рисками на протяжении всего жизненного цикла AI [1]. NIST организует управление рисками в области AI вокруг функций Govern, Map, Measure и Manage [3][4]. ISO/IEC 42001 описывает управление AI как систему политик, целей и постоянно совершенствуемых процессов [7]. Эти источники поддерживают практический корпоративный вывод: управление AI должно находиться внутри операционной модели, а не рядом с ней в виде приложения по комплаенсу.

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

У каждого слоя есть назначенный владелец, набор доказательств, право принятия решений и периодичность проверки.

2. Сформируйте корпоративный реестр до приоритизации портфеля

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

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

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

Реестр также поддерживает экономику портфеля. Можно выявить дублирующиеся лицензии, пересекающиеся пилоты и несовместимые конвейеры данных. Общая возможность может обслуживать несколько сценариев использования, тогда как дорогая специализированная модель может иметь одного узкого владельца. После этого руководство может распределять общие затраты, вести переговоры с поставщиками и решать, какие платформы заслуживают масштабирования.

Таблица 1. Минимальный корпоративный реестр AI

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

3. Спроектируйте операционную модель исходя из шести зон ответственности

Программе AI нужно нечто большее, чем руководящий комитет. Шесть зон ответственности должны быть четко видны. Совет директоров утверждает риск-аппетит, существенные инвестиции и надзор. Исполнительный спонсор отвечает за инвестиционный тезис портфеля. Бизнес-владелец отвечает за внедрение рабочих процессов и операционный результат. Технический владелец отвечает за архитектуру, реализацию и показатели сервиса. Независимые контрольные функции критически проверяют данные по рискам, конфиденциальности, безопасности, правовым вопросам и комплаенсу. Финансовая функция контролирует базовый уровень выгод и подтверждает фактически реализованную ценность.

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

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

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

Таблица 2. Права на принятие решений в операционной модели AI

R означает ответственный, A — подотчётный, C — консультируемый, I — информируемый; точное распределение должно отражать размер организации и применимые требования.

4. Превратите стратегию в контролируемый устав сценария использования

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

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

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

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

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

Критерии выхода не менее важны. Руководство может остановить сценарий использования, когда проблема исчезла, вмешательство не может достичь своего порога, экономика поставщика изменилась, нагрузка на контроль превышает ценность или более простое улучшение процесса работает лучше. Устав должен определять, как будут закрыты доступ, данные, записи, контракты и последующие зависимости. Запланированный маршрут выхода укрепляет капитальную дисциплину в начале инвестиции.

5. Классифицируйте сценарии использования по уровням на основе последствий, автономности, подверженности риску и обратимости

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

Уровень должен присваиваться сценарию использования в контексте. Одна и та же модель может иметь низкое воздействие при внутреннем мозговом штурме и высокое воздействие, когда её результат влияет на найм, кредитование, ценообразование, безопасность или здоровье. Такой взгляд на сценарий использования соответствует подходам на основе риска в Законе ЕС об AI [9][10], RMF NIST AI [3], обзоре ASIC в отношении управления лицензиатами [27] и структуре модельного риска OSFI [29].

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

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

Матрица — это управленческий инструмент; правовые классификации требуют отдельного анализа.

Таблица 3. Иллюстративные триггеры уровней и минимальные меры контроля

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

6. Рассматривайте права на данные и происхождение данных как обязательные операционные условия.

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

Права на данные могут быть не менее важны, чем качество данных. Технически полезный набор данных может быть недоступен для обучения модели, поиска или обработки поставщиком. Клиентские соглашения, условия трудовых договоров, права на базы данных, интеллектуальная собственность, правила конфиденциальности и отраслевые обязательства могут ограничивать использование. Юридическое одобрение должно привязываться к конкретной цели и потоку данных, а не к широкому обозначению AI.

Происхождение данных должно прослеживаться от источника через подготовку, поиск, контекст промпта, взаимодействие с моделью, хранение выходных данных и дальнейшее решение. Это обеспечивает воспроизводимость, анализ инцидентов, удаление, проверку доступа и атрибуцию выгод. ОЭСР связывает подотчётность AI с прослеживаемостью по наборам данных, процессам и решениям [1][2]. Итоговое руководство OSFI E-23 аналогичным образом подчёркивает пригодность, происхождение и корпоративное управление данными для моделей [29].

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

7. Контролируйте всю цепочку зависимостей модели и поставщика

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

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

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

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

Таблица 4. Доказательства по цепочке зависимостей AI

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

8. Принимайте решения о создании, покупке и конфигурировании с учётом совокупной операционной экономики

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

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

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

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

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

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

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

Руководство NIST предлагает действия в области управления, картирования, измерения и менеджмента [4]. Профиль NIST для генеративного AI дополнительно уделяет внимание таким рискам, как конфабуляция, целостность информации, конфиденциальность, безопасность и интеллектуальная собственность [5]. Контрольная точка жизненного цикла должна превращать такие соображения в доказательства для сценария использования.

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

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

10. Валидируйте систему в контексте, в котором она будет работать

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

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

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

Генеративные системы нуждаются в качественной и состязательной оценке, а также в оценках по бенчмаркам. Тестирование может охватывать необоснованные утверждения, инъекции промптов, утечку конфиденциальных данных, вредоносный контент, неправомерное использование инструментов, непоследовательные ответы и поведение отказов. Профиль NIST для генеративного AI и руководство по безопасной разработке от CISA и международных партнёров дают соответствующие ориентиры [5][17][18].

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

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

11. Определите человеческий надзор как проектирование принятия решений

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

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

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

Полномочия должны соответствовать последствиям. Пользователь может исправить черновик. Функциональный руководитель может приостановить рабочий процесс. Владелец риска может потребовать контроля. Совет директоров или комитет по зарезервированным вопросам может отозвать существенный сценарий использования. Действие должно оставаться возможным во время сбоя или инцидента.

12. Развёртывайте с использованием контролируемой производственной среды и управления изменениями

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

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

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

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

13. Мониторинг производительности, дрейфа, инцидентов и эффективности контроля

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

Пороговые значения требуют действий. Жёлтая граница может требовать расследования и ограниченного масштабирования. Красная граница может требовать приостановки, отката или ручного резервного режима. Владелец, время реагирования и маршрут эскалации должны быть задокументированы. Панель без логики действий — это наблюдение, а не контроль.

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

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

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

14. Сделайте безопасность и устойчивость частью проектирования продукта

Системы AI создают привычные риски программного обеспечения и данных наряду с путями атак, специфичными для моделей. Угрозы могут включать инъекцию промптов, отравление данных, небезопасный доступ к инструментам, кражу модели, раскрытие конфиденциальных данных, состязательные входные данные, небезопасные выходные данные и компрометацию зависимостей. Поэтому безопасность должна начинаться с архитектуры и предполагаемого использования.

Модель угроз должна определять активы, субъектов, границы доверия, интерфейсы и потенциальное недобросовестное использование. Меры контроля могут включать одобренные среды, минимальные привилегии, обработку входных и выходных данных, управление секретами, сетевые ограничения, разрешения на извлечение данных, белые списки инструментов, контроль содержимого, журналирование, обнаружение аномалий, red teaming и реагирование на инциденты. Правильный набор зависит от последствий и подверженности.

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

Руководство по принципу secure-by-design от CISA, NCSC Великобритании и международных партнёров подчёркивает безопасность на всех этапах проектирования, разработки, развёртывания и эксплуатации [17][18]. Операционная модель должна превратить это в доказательства для контрольных точек и назначить ответственного владельца безопасности.

15. Интегрируйте конфиденциальность, интеллектуальную собственность и записи в рабочий процесс

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

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

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

Закон ЕС в области AI, связанные с ним руководства по прозрачности, руководство Великобритании по защите данных, UAE, а также этические рамки Саудовской Аравии и материалы Сингапура по управлению иллюстрируют растущую важность прослеживаемости, прозрачности и подотчётного использования [9][11][15][20][21][22][25][26]. Применимость и юридическая сила зависят от конкретной системы, роли и юрисдикции.

16. Стройте обоснование выгод на контролируемой базовой линии и контрфактическом сценарии

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

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

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

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

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

Выгоды могут быть финансовыми, а также относиться к обслуживанию, рискам или возможностям. Их не следует принудительно сводить к денежной оценке, когда доказательства не поддерживают такую оценку. Контролируемое сокращение вариативности реагирования или улучшение прослеживаемости может иметь значение для совета директоров, даже когда финансовая функция не может подтвердить немедленный эффект на P&L. Реестр может показывать операционный результат и его значимость для принятия решений, сохраняя границу вокруг финансовой ценности.

Руководство по выгодам в государственном секторе предлагает полезный общий принцип: выгоды должны выявляться, определяться, отслеживаться, реализовываться и поддерживаться на протяжении жизненного цикла, с подотчётными владельцами и обеспечением уверенности [31][32]. Та же дисциплина улучшает распределение капитала в частных компаниях.

Таблица 5. Контролируемый реестр выгод AI

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

17. Преобразуйте операционные данные в мост по P&L, денежным средствам и стоимости

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

Бухгалтерский учёт следует отделять от измерения управленческой выгоды. МСФО (IAS) 38 содержит критерии признания нематериальных активов, а IASB продолжает рассматривать вопросы, связанные с данными и решениями в области AI [33]. Руководство должно получить консультацию по бухгалтерскому учёту, а не исходить из того, что внутренне описанные инвестиции или выгода определяют порядок отражения в финансовой отчётности.

Мост выгод должен использовать представления за период, накопленное и run-rate. Сценарий использования может создавать разовую нагрузку от внедрения, повторяющиеся затраты и более позднюю повторяющуюся выгоду. Сроки денежных потоков могут отличаться от бухгалтерских расходов. Совету директоров нужны все три измерения для распределения капитала.

Уверенность в прогнозе должна быть явно выражена. Диапазон с определёнными драйверами полезнее для принятия решений, чем одно точное число, основанное на слабых допущениях о внедрении. Анализ чувствительности может показывать принятие пользователями, объём задач, цену поставщика, частоту ошибок и время до масштабирования.

Значения являются гипотетическими управленческими допущениями и не отражают результат для клиента или прогноз.

18. Рассматривайте внедрение и реорганизацию рабочих процессов как часть инвестиции

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

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

Обучение должно учитывать конкретные роли и сценарии использования. Пользователям нужны цель, границы, правила работы с данными, ожидания по проверке, эскалация, примеры и известные ограничения. Руководители должны уметь интерпретировать данные мониторинга и доказательства выгод. Техническим и контрольным командам нужны обязанности по жизненному циклу. Членам совета директоров нужны экономика портфеля и существенная подверженность риску.

План по персоналу должен касаться наращивания потенциала, а не предполагать немедленное сокращение затрат. Высвобожденное время может способствовать росту объёмов, обслуживанию, качеству или отказу от увеличения численности. Реализованный экономический эффект зависит от действий руководства. Также могут применяться консультации с сотрудниками и требования к местной занятости.

19. Распределяйте капитал через портфельные гейты

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

Финансирование может быть поэтапным. Этап Discovery получает небольшой бюджет на сбор доказательств. Этап Validation получает ресурсы после того, как базовые показатели и архитектура признаны убедительными. Финансирование Production следует за успешными тестами и готовностью контрольных механизмов. Финансирование Scale следует за внедрением и доказательствами ранней выгоды. Это снижает эскалацию невозвратных затрат.

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

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

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

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

20. Применяйте юрисдикционные и отраслевые надстройки, не фрагментируя ядро

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

Закон ЕС о AI использует риск-ориентированную систему с обязательствами, которые различаются в зависимости от системы и субъекта; правоприменение и сроки применения продолжали развиваться [9][10][11][12]. Органы Великобритании используют межотраслевые принципы наряду с существующими регуляторами, тогда как PRA применяет ожидания в отношении модельного риска к определённым фирмам [14][16]. Источники в США включают добровольные рамки NIST, отраслевые правила и правоприменение в отношении необоснованных заявлений [3][5][19].

UAE и Саудовская Аравия публикуют руководящие указания по этике и управлению, подчёркивающие подотчётность, прозрачность, конфиденциальность, безопасность и ответственное внедрение [20][21][22][23]. Работа RBI FREE-AI в Индии посвящена ответственному AI в финансах [24]. Сингапурские рамки управления и программа AI Verify поддерживают практическое тестирование и ответственное развёртывание [25][26]. ASIC выявил пробелы между внедрением AI и управлением у проверенных лицензиатов [27]. Канадское OSFI завершило разработку широкого руководства по модельному риску на протяжении жизненного цикла с учётом AI и датой вступления в силу в 2027 году [29][30].

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

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

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

21. Протестировать методику на гипотетическом кейсе сервисной операционной деятельности

Рассмотрим гипотетическую портфельную компанию, обрабатывающую 240 000 запросов в службу поддержки клиентов ежегодно. Руководство предлагает ассистента, который извлекает утверждённые знания, готовит проект ответа и рекомендует код маршрутизации. Сотрудники по-прежнему отвечают за проверку и отправку. Компания ожидает сокращения времени обработки и снижения объёма переделок.

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

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

Первоначальный пилот показывает гипотетическое сокращение времени обработки на 24% для подходящих запросов. Только 58% запросов являются подходящими, а уровень внедрения достигает 70% подходящего объёма. Поэтому руководство избегает применения 24% ко всей базе затрат. Финансы моделируют реализованную мощность исходя из фактического подходящего объёма, внедрения, переделок и дополнительных эксплуатационных затрат.

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

22. Предоставить совету директоров пакет для принятия решений, а не отчёт о деятельности AI

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

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

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

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

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

Информация для совета директоров должна развиваться вместе с портфелем. Ранние пакеты могут делать акцент на полноте реестра, аппетите к риску и дизайне контрольных точек. Масштабирующийся портфель должен делать акцент на производственной эффективности, инцидентах, концентрации и валидированной ценности. Зрелый портфель также должен показывать вывод из эксплуатации, эффективность контроля и то, снижает ли совместно используемая возможность предельные затраты. Архитектура информации должна меняться, когда меняются решения совета директоров.

Таблица 6. Скоркарта операционной модели AI для совета директоров

Каждая строка должна вести к решению, эскалации или подтверждённому операционному действию.

23. Внедрите операционную модель за сто дней

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

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

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

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

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

Источники

1. ОЭСР, Принципы ОЭСР по AI, обновлено в 2024 г., https://www.oecd.org/en/topics/ai-principles.html
2. ОЭСР, AI, управление данными и конфиденциальность: синергия и области международного сотрудничества, 2024, https://www.oecd.org/content/dam/oecd/en/publications/reports/2024/06/ai-data-governance-and-privacy_2ac13a42/2476b1a4-en.pdf
3. Национальный институт стандартов и технологий, Система управления рисками искусственного интеллекта 1.0, 2023, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
4. Национальный институт стандартов и технологий, практическое руководство по RMF для AI, обновлено в 2026 г., https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
5. Национальный институт стандартов и технологий, Система управления рисками искусственного интеллекта: профиль генеративного искусственного интеллекта, 2024, https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
6. Национальный институт стандартов и технологий, Ресурсный центр по надежному и ответственному AI, 2026, https://airc.nist.gov/
7. Международная организация по стандартизации, ISO/IEC 42001:2023 Система менеджмента искусственного интеллекта, 2023, https://www.iso.org/standard/42001.html
8. Международная организация по стандартизации, ISO/IEC 23894:2023 Управление рисками искусственного интеллекта, 2023, https://www.iso.org/standard/77304.html
9. Европейская комиссия, Закон AI: нормативно-правовая база для искусственного интеллекта, обновлено в 2026 г., https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
10. Европейская комиссия, Механизм правоприменения Закона AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act
11. Европейская комиссия, Руководящие указания по обязательствам о прозрачности для поставщиков и внедряющих организаций отдельных систем AI, 2026, https://digital-strategy.ec.europa.eu/en/policies/guidelines-ai-transparency-obligations
12. Европейская комиссия, Руководящие указания по обязательствам поставщиков AI общего назначения, 2025, https://digital-strategy.ec.europa.eu/en/faqs/guidelines-obligations-general-purpose-ai-providers
13. EUR-Lex, Регламент (ЕС) 2016/679, Общий регламент по защите данных, 2016, https://eur-lex.europa.eu/eli/reg/2016/679/oj
14. Правительство Великобритании, Реализация регуляторных принципов AI в Великобритании: руководство для регуляторов, 2024, https://assets.publishing.service.gov.uk/media/65c0b6bd63a23d0013c821a0/implementing_the_uk_ai_regulatory_principles_guidance_for_regulators.pdf
15. Управление комиссара по информации, Руководство по AI и защите данных, обновлено в 2023 г., https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/
16. Банк Англии, Управление пруденциального регулирования, SS1/23 Принципы управления модельными рисками для банков, обновлено в 2026 г., https://www.bankofengland.co.uk/prudential-regulation/publication/2023/may/model-risk-management-principles-for-banks-ss
17. Агентство по кибербезопасности и безопасности инфраструктуры и Национальный центр кибербезопасности Великобритании, Руководство по безопасной разработке систем AI, 2023, https://www.cisa.gov/news-events/alerts/2023/11/26/cisa-and-uk-ncsc-unveil-joint-guidelines-secure-ai-system-development
18. Агентство по кибербезопасности и безопасности инфраструктуры, Выбор безопасных и проверяемых технологий, 2024, https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies
19. Федеральная торговая комиссия, Искусственный интеллект: правоприменение и рекомендации для бизнеса, обновлено в 2026 г., https://www.ftc.gov/industry/technology/artificial-intelligence
20. UAE Офис государственного министра по искусственному интеллекту, цифровой экономике и приложениям для удаленной работы, UAE Позиция по политике в области AI, 2024, https://ai.gov.ae/wp-content/uploads/2024/10/UAE-Guiding-on-ai-policy-EN-V3.pdf
21. Офис UAE по искусственному интеллекту, Принципы и руководящие положения по этике AI, 2022, https://ai.gov.ae/wp-content/uploads/2023/05/MOCAI-AI-Ethics-EN.pdf
22. Управление данных и искусственного интеллекта Саудовской Аравии, Принципы этики AI, https://sdaia.gov.sa/en/SDAIA/about/Documents/ai-principles.pdf
23. Управление данных и искусственного интеллекта Саудовской Аравии, Нормативные положения и политики, обновлено в 2026 г., https://sdaia.gov.sa/en/SDAIA/about/Pages/RegulationsAndPolicies.aspx
24. Резервный банк Индии, Доклад комитета FREE-AI: Рамки ответственного и этичного внедрения искусственного интеллекта, 2025, https://www.rbi.org.in/Scripts/PublicationReportDetails.aspx?UrlPage=&ID=1299
25. Комиссия Сингапура по защите персональных данных, Типовая модель управления искусственным интеллектом, 2020, https://www.pdpc.gov.sg/help-and-resources/2020/01/model-ai-governance-framework
26. Управление развития инфокоммуникаций и медиа Сингапура, Типовая модель управления AI для генеративного AI, 2024, https://www.imda.gov.sg/resources/press-releases-factsheets-and-speeches/press-releases/2024/model-ai-governance-framework-for-generative-ai
27. Австралийская комиссия по ценным бумагам и инвестициям, REP 798 Остерегайтесь разрыва: механизмы управления перед лицом инноваций в области AI, 2024, https://asic.gov.au/regulatory-resources/find-a-document/reports/rep-798-beware-the-gap-governance-arrangements-in-the-face-of-ai-innovation/
28. Австралийское управление пруденциального регулирования, CPS 230 Управление операционным риском, обновлено в 2026 г., https://www.apra.gov.au/standards/cps-230
29. Управление суперинтенданта финансовых учреждений Канады, Руководство E-23 Управление модельным риском, 2025, https://www.osfi-bsif.gc.ca/en/guidance/guidance-library/guideline-e-23-model-risk-management-2027
30. Управление суперинтенданта финансовых учреждений Канады и Агентство по защите прав потребителей финансовых услуг Канады, Использование и риски AI в финансовых учреждениях, регулируемых на федеральном уровне, 2024, https://www.osfi-bsif.gc.ca/en/about-osfi/reports-publications/osfi-fcac-risk-report-ai-uses-risks-federally-regulated-financial-institutions
31. Управление по инфраструктуре и проектам Великобритании и Кабинет министров, Руководство по эффективному управлению выгодами в крупных проектах, 2017, https://www.gov.uk/government/publications/guide-for-effective-benefits-management-in-major-projects
32. Правительство Великобритании, Рамочная программа повышения эффективности правительства, 2025, https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2
33. Фонд МСФО, Нематериальные активы: другие потенциальные тестовые примеры, включая ресурсы данных, а также данные и решения, связанные с искусственным интеллектом, 2026, https://www.ifrs.org/content/dam/ifrs/meetings/2026/january/iasb/ap17d-other-potential-test-cases-data-ai.pdf

Источники и дополнительная литература

1. ОЭСР, Принципы ОЭСР по AI, обновлено в 2024 г., Официальный источник
2. ОЭСР, AI, управление данными и конфиденциальность: синергия и области международного сотрудничества, 2024, Официальный источник
3. Национальный институт стандартов и технологий, Система управления рисками искусственного интеллекта 1.0, 2023, Официальный источник
4. Национальный институт стандартов и технологий, практическое руководство по RMF для AI, обновлено в 2026 г., Официальный источник
5. Национальный институт стандартов и технологий, Система управления рисками искусственного интеллекта: профиль генеративного искусственного интеллекта, 2024, Официальный источник
6. Национальный институт стандартов и технологий, Ресурсный центр по надежному и ответственному AI, 2026, Официальный источник
7. Международная организация по стандартизации, ISO/IEC 42001:2023 Система менеджмента искусственного интеллекта, 2023, Официальный источник
8. Международная организация по стандартизации, ISO/IEC 23894:2023 Управление рисками искусственного интеллекта, 2023, Официальный источник
9. Европейская комиссия, Закон AI: нормативно-правовая база для искусственного интеллекта, обновлено в 2026 г., Официальный источник
10. Европейская комиссия, Механизм правоприменения Закона AI, 2026, Официальный источник
11. Европейская комиссия, Руководящие указания по обязательствам о прозрачности для поставщиков и внедряющих организаций отдельных систем AI, 2026, Официальный источник
12. Европейская комиссия, Руководящие указания по обязательствам поставщиков AI общего назначения, 2025, Официальный источник
13. EUR-Lex, Регламент (ЕС) 2016/679, Общий регламент по защите данных, 2016, Официальный источник
14. Правительство Великобритании, Реализация регуляторных принципов AI в Великобритании: руководство для регуляторов, 2024, Официальный источник
15. Управление комиссара по информации, Руководство по AI и защите данных, обновлено в 2023 г., Официальный источник
16. Банк Англии, Управление пруденциального регулирования, SS1/23 Принципы управления модельными рисками для банков, обновлено в 2026 г., Официальный источник
17. Агентство по кибербезопасности и безопасности инфраструктуры и Национальный центр кибербезопасности Великобритании, Руководство по безопасной разработке систем AI, 2023, Официальный источник
18. Агентство по кибербезопасности и безопасности инфраструктуры, Выбор безопасных и проверяемых технологий, 2024, Официальный источник
19. Федеральная торговая комиссия, Искусственный интеллект: правоприменение и рекомендации для бизнеса, обновлено в 2026 г., Официальный источник
20. UAE Офис государственного министра по искусственному интеллекту, цифровой экономике и приложениям для удаленной работы, UAE Позиция по политике в области AI, 2024, Официальный источник
21. Офис UAE по искусственному интеллекту, Принципы и руководящие положения по этике AI, 2022, Официальный источник
22. Управление данных и искусственного интеллекта Саудовской Аравии, Принципы этики AI, Официальный источник
23. Управление данных и искусственного интеллекта Саудовской Аравии, Нормативные положения и политики, обновлено в 2026 г., Официальный источник
24. Резервный банк Индии, Доклад комитета FREE-AI: Рамки ответственного и этичного внедрения искусственного интеллекта, 2025, Официальный источник
25. Комиссия Сингапура по защите персональных данных, Типовая модель управления искусственным интеллектом, 2020, Официальный источник
26. Управление развития инфокоммуникаций и медиа Сингапура, Типовая модель управления AI для генеративного AI, 2024, Официальный источник
27. Австралийская комиссия по ценным бумагам и инвестициям, REP 798 Остерегайтесь разрыва: механизмы управления перед лицом инноваций в области AI, 2024, Официальный источник
28. Австралийское управление пруденциального регулирования, CPS 230 Управление операционным риском, обновлено в 2026 г., Официальный источник
29. Управление суперинтенданта финансовых учреждений Канады, Руководство E-23 Управление модельным риском, 2025, Официальный источник
30. Управление суперинтенданта финансовых учреждений Канады и Агентство по защите прав потребителей финансовых услуг Канады, Использование и риски AI в финансовых учреждениях, регулируемых на федеральном уровне, 2024, Официальный источник
31. Управление по инфраструктуре и проектам Великобритании и Кабинет министров, Руководство по эффективному управлению выгодами в крупных проектах, 2017, Официальный источник
32. Правительство Великобритании, Рамочная программа повышения эффективности правительства, 2025, Официальный источник
33. Фонд МСФО, Нематериальные активы: другие потенциальные тестовые примеры, включая ресурсы данных, а также данные и решения, связанные с искусственным интеллектом, 2026, Официальный источник