AI Управление капитальными затратами для советов директоров: от портфеля экспериментов к бизнес-кейсам инвестиционного уровня

1. Рассматривать расходы на AI как управляемый портфель

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

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

Официальные раскрытия показывают, почему важна дисциплина обязательств. Alphabet сообщила о капитальных расходах в размере USD 91.4 billion за 2025 год, главным образом на техническую инфраструктуру, и заявила, что ожидает значительного увеличения инвестиций в 2026 году в серверы, сетевое оборудование и дата-центры.[4] В годовом отчёте Microsoft за 2026 год указано, что инвестиции AI осуществляются в значительном масштабе и опережают полностью сформированные потоки выручки.[5] Meta сообщила о капитальных расходах в размере USD 72.22 billion за 2025 год, включая платежи в счёт основной суммы по финансовому лизингу, и ожидает капитальные расходы от USD 115 billion до USD 135 billion в 2026 году для поддержки инициатив AI и основного бизнеса.[6] Amazon сообщила о денежных капитальных расходах в размере USD 96.3 billion за первые шесть месяцев 2026 года, главным образом на технологическую инфраструктуру, поддерживающую рост AWS и мощности фулфилмента.[7] Эти показатели имеют разные определения и смешанные бизнес-цели. Их значимость определяется масштабом, длительными сроками реализации и неопределённостью спроса, описанными в раскрытиях.

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

2. Наделите совет директоров чётко определённым мандатом по управлению

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

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

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

Таблица 1. Права принятия решений и ответственность за обоснования в портфеле AI

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

3. Сделайте сценарий использования единицей ценности

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

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

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

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

4. Требуйте бизнес-кейс инвестиционного уровня

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

«Зелёная книга» Казначейства Великобритании (HM Treasury) на 2026 год описывает пять взаимосвязанных измерений: стратегическое, экономическое, коммерческое, финансовое и управленческое. Она также требует оценки вариантов и соразмерности.[17] Соответствующие рекомендации по бизнес-кейсам развивают предложения через стратегический контур, контур и полный бизнес-кейс.[18] Эти рамки государственного сектора не являются корпоративными правилами утверждения. Их ценность для советов директоров заключается в разделении стратегического обоснования, ценности, договорённостей с поставщиками, ценовой доступности и доказательств реализации.

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

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

Таблица 2. Минимальные доказательства для бизнес-кейса AI

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

5. Сегментируйте портфель до его ранжирования

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

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

Сегментация рисков должна влиять на путь утверждения. Структура управления рисками NIST для AI организует деятельность вокруг функций руководства, картирования, измерения и управления, при этом управление осуществляется на протяжении всего жизненного цикла AI.[10] Её профиль генеративного AI определяет действия в отношении рисков, которые могут быть новыми или усиливаться генеративными системами.[11] Структура подотчётности GAO группирует практики вокруг управления, данных, результативности и мониторинга.[12] Эти структуры поддерживают единый реестр, допуская при этом вариативность мер контроля в зависимости от сценария использования, контекста и последствий.

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

6. Постройте карту портфеля сценариев использования

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

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

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

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

[/FIGURE]

7. Продвигайте выгоды по лестнице уверенности

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

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

Исследование ОЭСР о внедрении AI сообщает, что неопределённость в отношении рентабельности инвестиций и недостаточная зрелость данных являются важными барьерами, а руководители могут недооценивать общеорганизационные последствия для процессов и культуры.[8] Отдельный обзор ОЭСР экспериментальных исследований показывает, что производительность зависит от задачи и пользовательского опыта, тогда как долгосрочные организационные доказательства остаются ограниченными.[9] Эти выводы поддерживают осторожный перенос от экспериментов с отдельными задачами к заявлениям о денежных потоках на уровне предприятия.

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

Эта лестница определяет зрелость доказательств. Она не закрепляет за уровнем уверенности универсальную вероятность или прирост оценки.

[/FIGURE]

8. Определите базовый и контрфактический сценарии

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

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

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

Британская методика оценки выгод от цифровых и данных (UK Digital and Data Benefits framework) была разработана для количественной оценки выгод от цифровых и данных программ и предназначена для использования вместе с рекомендациями Green Book.[19] Government Efficiency Framework также связывает выявленную экономию с управлением выгодами и более широкими механизмами управления.[20] Их контекст государственного сектора отличается от корпоративного портфеля. Общая дисциплина остаётся полезной: определить типы выгод, методы измерения, ответственность и взаимосвязь между операционными изменениями и стоимостью.

9. Сделайте готовность данных критерием допуска капитала

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

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

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

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

Оценки являются гипотетическими допущениями моделирования: 1 означает отсутствие или неприемлемость, 3 означает ограниченное устранение недостатков, а 5 означает доказательства, достаточные для прохождения критерия допуска.

[/FIGURE]

10. Согласование экономики полного жизненного цикла

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

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

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

Таблица 3. Гипотетическая экономика сценария использования от пилота до масштабирования

Значения являются гипотетическими и приведены в миллионах USD. NPV рассчитывается с использованием 11-процентной номинальной ставки дисконтирования за пять лет без терминальной стоимости; итоговые суммы округлены и не представляют собой прогноз.

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

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

11. Явно учитывать в цене инфраструктуру, мощности и энергию

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

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

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

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

12. Проектируйте контроли как часть инвестиции

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

Пропорциональность контролей имеет значение. Концепция NIST является добровольной и не привязана к конкретному сценарию использования; она подчёркивает непрерывное управление рисками на протяжении жизненного цикла.[10] ISO/IEC 42001 определяет систему менеджмента AI для организаций, предоставляющих или использующих AI, и использует структуру постоянного улучшения.[13] Пересмотренное руководство Федеральной резервной системы по рискам моделей 2026 года подчёркивает подход на основе риска, адаптированный к профилю моделей, размеру и сложности банковской организации.[14] Банковское руководство применяется в пределах заявленной регуляторной сферы. Его более широкий урок для корпоративного управления состоит в том, что валидация, ограничения, надзор и контроли должны быть пропорциональны существенному использованию.

Правовые обязанности требуют анализа с учётом конкретной юрисдикции. Закон ЕС об AI использует риск-ориентированную структуру и применяется поэтапно; Европейская комиссия сообщила, что правоприменительные полномочия и отдельные обязательства по прозрачности применяются с августа 2026 года, а другие положения о высоком риске подлежат более поздним срокам.[15][16] Документ для совета директоров должен указывать роль организации, местоположение, классификацию сценария использования и юридическую консультацию. Общего обозначения «соответствует AI» недостаточно.

Таблица 4. Проектирование контролей в увязке с инвестиционными доказательствами

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

13. Используйте контрольные ворота, чтобы соотносить полномочия с обязательствами

Ворота должны санкционировать определённое следующее обязательство. Ворота 0 принимают проблему в этап исследования. Ворота 1 одобряют ограниченный эксперимент после того, как исходные показатели, доступ к данным и план тестирования определены. Ворота 2 одобряют пилот, когда процесс, пользователи, средства контроля и методика оценки выгод готовы. Ворота 3 одобряют выпуск в производственную эксплуатацию после успешного прохождения сквозной проверки производительности и доказательств контроля. Ворота 4 одобряют масштабирование после подтверждения внедрения и юнит-экономики. Ворота 5 завершают этап получения выгод и определяют расширение, поддержку или вывод из эксплуатации.

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

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

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

[/FIGURE]

14. Проверяйте внедрение, прежде чем заявлять о ценности масштабирования

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

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

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

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

15. Сделайте решения «остановить или масштабировать» явными

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

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

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

Таблица 5. Матрица решений «остановить или масштабировать»

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

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

[/FIGURE]

16. Контроль поставщиков, концентрации и выхода

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

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

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

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

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

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

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

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

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

18. Мобилизуйте систему управления в течение девяноста дней

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

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

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

Таблица 6. Мобилизация системы управления капитальными затратами AI на 90 дней

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

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

Заключение

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

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

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

Приложение A. Вопросы совета директоров по существенному обязательству AI

1. Какая операционная проблема и какой затрагиваемый процесс входят в область охвата?
2. Что происходит в обычном режиме, и какие варианты, не связанные с AI, были проверены?
3. Какие выгоды представляют собой денежные поступления, дополнительную мощность, выручку, улучшение сервиса или результаты по рискам?
4. Каков текущий уровень уверенности в отношении каждой выгоды и какие доказательства его повышают?
5. Каковы денежные, ресурсные и договорные обязательства на весь жизненный цикл?
6. Какие условия в отношении прав на данные, качества, происхождения данных, безопасности и мониторинга остаются открытыми?
7. Какие человеческие решения, затронутые стороны и юрисдикции при этом задействованы?
8. Какие средства контроля требуются до пилота, промышленной эксплуатации и масштабирования?
9. Какие пороги внедрения и качества запускают масштабирование, приостановку или остановку?
10. Каково следующее необратимое обязательство и каков план выхода до его наступления?

Приложение B. Минимальный пакет доказательств для решения об остановке или масштабировании

1. Текущее определение сценария использования и история версий.
2. Метод измерения базового уровня, контрфактического сценария и выгод.
3. Фактические и прогнозные расходы, обязательства и годовая стоимость эксплуатации.
4. Результаты пилота или промышленной эксплуатации по репрезентативным пользователям и условиям.
5. Доказательства внедрения, приемки, доработки, переопределения и резервных сценариев.
6. Статус готовности данных и открытые меры по устранению недостатков.
7. Результаты тестирования средств контроля, инциденты, ограничения и принятие остаточного риска.
8. Показатели эффективности поставщиков, концентрация, продление и позиция по выходу.
9. Экономика сценариев, значения переключения и денежные средства под риском до следующей контрольной точки.
10. Рекомендация менеджмента с условиями, ответственным лицом, датой и последствиями.

Источники

1. Банк международных расчётов, «Финансирование бума AI: от денежных потоков к долгу», BIS Bulletin No. 120, опубликовано 7 января 2026 г. https://www.bis.org/publ/bisbull120.htm
2. Банк международных расчётов, «Гонка инвестиций в AI», исследовательская работа BIS № 1367, опубликовано 14 июля 2026 г. https://www.bis.org/publ/work1367.htm
3. Международное энергетическое агентство, «Ключевые вопросы по энергии и AI», опубликовано в 2026 г. https://www.iea.org/reports/key-questions-on-energy-and-ai
4. Alphabet Inc., годовой отчёт по форме 10-K за год, закончившийся 31 декабря 2025 г., подан 5 февраля 2026 г. https://www.sec.gov/Archives/edgar/data/1652044/000165204426000018/goog-20251231.htm
5. Microsoft Corporation, годовой отчёт по форме 10-K за год, закончившийся 30 июня 2026 г., подан 30 июля 2026 г. https://www.sec.gov/Archives/edgar/data/789019/000119312526323660/msft-20260630.htm
6. Meta Platforms, Inc., годовой отчёт по форме 10-K за год, закончившийся 31 декабря 2025 г., подан 29 января 2026 г. https://www.sec.gov/Archives/edgar/data/1326801/000162828026025534/meta-12312025x10kars.htm
7. Amazon.com, Inc., квартальный отчёт по форме 10-Q за квартал, закончившийся 30 июня 2026 г., подан 31 июля 2026 г. https://www.sec.gov/Archives/edgar/data/1018724/000101872426000026/amzn-20260630.htm
8. ОЭСР, Boston Consulting Group и INSEAD, «Внедрение искусственного интеллекта в компаниях: новые данные для формирования политики», опубликовано 2 мая 2025 г. https://doi.org/10.1787/f9ef33c3-en
9. ОЭСР, «Влияние генеративного AI на производительность, инновации и предпринимательство», OECD Artificial Intelligence Papers No. 39, опубликовано 20 июня 2025 г. https://doi.org/10.1787/b21df222-en
10. Национальный институт стандартов и технологий, «Рамки управления рисками искусственного интеллекта 1.0», опубликовано 26 января 2023 г. https://doi.org/10.6028/NIST.AI.100-1
11. Национальный институт стандартов и технологий, «Рамки управления рисками искусственного интеллекта: профиль генеративного искусственного интеллекта», опубликовано 26 июля 2024 г. https://doi.org/10.6028/NIST.AI.600-1
12. Управление подотчётности правительства США, «Искусственный интеллект: рамки подотчётности для федеральных агентств и других организаций», GAO-21-519SP, опубликовано 30 июня 2021 г. https://www.gao.gov/products/gao-21-519sp
13. Международная организация по стандартизации, ISO/IEC 42001:2023 «Информационные технологии — Искусственный интеллект — Система менеджмента», опубликовано в декабре 2023 г. https://www.iso.org/standard/81230.html
14. Совет управляющих Федеральной резервной системы, Пересмотренное руководство по управлению модельным риском, SR 26-2, опубликовано 17 апреля 2026 г. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
15. Европейская комиссия, Закон AI: нормативно-правовая база для искусственного интеллекта, обновлено 3 августа 2026 г. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
16. Европейский союз, Регламент (ЕС) 2024/1689, устанавливающий гармонизированные правила в отношении искусственного интеллекта, опубликован 12 июля 2024 г. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
17. Казначейство Его Величества, «Зелёная книга 2026», опубликована 5 февраля 2026 г. https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government/the-green-book-2026
18. Казначейство Его Величества, Руководство по разработке бизнес-кейсов, обновлено 30 июня 2026 г. https://www.gov.uk/government/publications/guidance-on-developing-business-cases
19. Департамент науки, инноваций и технологий и Государственная служба цифровых технологий, Методика оценки выгод в области цифровых технологий и данных, опубликована 7 апреля 2026 г. https://www.gov.uk/government/publications/digital-and-data-benefits-framework
20. Канцелярия Кабинета министров и Казначейство Его Величества, Методика повышения эффективности государственного сектора, опубликована в 2025 г. https://www.gov.uk/government/publications/the-government-efficiency-framework/the-government-efficiency-framework--2