6.1 Стратегия и готовность к ИИ

Обзор и мотивация

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

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

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

Ключевые принципы

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

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы	Лучше всего, когда
Промпт для размещённой модели	Быстро, дёшево, нет инфраструктуры, легко сменить	Меньше контроля, цена за вызов, вопросы обмена данными	Прототипы, широкие задачи, неопределённые требования
Дополнение поиском	Заземляет ответы в ваших данных, обновляемо	Качество поиска трудно, добавляет инфраструктуру	Задачи с большим объёмом знаний
Дообучение меньшей модели	Контроль, меньшая цена за вызов в масштабе, вариант локального размещения	Нужны MLOps, данные и сопровождение	Стабильные, большого объёма, специализированные задачи
Покупка продукта	Проверено, поддерживается, быстро к ценности	Цена лицензии, привязка, ограниченное соответствие	Чётко определённые рядовые проблемы
Построение базовой модели	Максимальный контроль и дифференциация	Огромная цена, редкие таланты, высокий риск	Почти никогда, вне передовых лабораторий

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

Вопросы для обсуждения с командой

Где каждый из наших трёх главных кандидатных случаев использования стоит на лестнице «промпт, затем поиск, затем дообучение, затем покупка, затем построение» и какие свидетельства подвинули бы его на ступень? Это важно, потому что большая часть напрасных расходов на ИИ идёт от старта на ступень выше: обучения модели, когда сработал бы тщательный промптинг. Для большой команды согласование лестницы как общего умолчания не даёт каждой группе изобретать дорогой конвейер заново. Принесите одностраничное описание проблемы для каждого кандидата, текущее базовое значение и честную оценку того, пробел это знания (поиск), согласованность (дообучение) или решённая рядовая задача (покупка). В корпоративной и государственной среде добавьте цену закупок и аудита каждой ступени, поскольку дообученная модель тянет за собой бремя MLOps, которого нет у размещённого вызова. Ответ должен позволить вам убить или понизить по крайней мере один чрезмерно раздутый проект прямо в комнате.
Каков наш конкретный план выхода для поставщика или модели, от которых мы зависим больше всего, и тестировали ли мы его на самом деле? Привязку дёшево принять и дорого распутать, а в государстве у вас могут быть многолетние обязательства по выходу, которые вы не сможете выполнить, если ни разу не репетировали. Принесите список проприетарных функций, на которые вы опираетесь, переносимы ли промпты и наборы оценки и как модель сидит за внутренним интерфейсом (или не сидит). Сигнал, за которым стоит следить: запускал ли кто-либо ваш набор оценки против второго провайдера; если нет, ваш план выхода надежда, а не план. Если честный ответ в том, что переключение займёт месяцы и потребует переписать основной код, воспринимайте это как проектный дефект для исправления сейчас, а не мост, который пересекать позже.
Что честная карта готовности говорит о наших правах на данные и какие случаи использования она сегодня дисквалифицирует? Пропуск готовности данных отказ, тихо топящий пилоты: модель работает, но у вас никогда не было правового основания для использования данных, или они не размечены и без происхождения. Для большой организации персональные и сторонние данные поднимают ограничения согласия и договорные, различающиеся по юрисдикции и набору данных. Принесите аудит доступности, качества, разметки, происхождения и правового основания для каждого кандидата и будьте готовы пометить некоторые случаи использования заблокированными, пока не существуют фундаменты данных. В регулируемой и публичной среде непригодное правовое основание не задержка, а жёсткая остановка, а финансирование работы по готовности должно быть явной строкой в плане, а не запоздалой мыслью.
Как мы узнаем, что живой случай использования ИИ действительно работает, и какие свидетельства заставили бы нас его убить? Большинство портфелей ИИ накапливают зомби: пилоты, которые были выпущены, кого-то впечатлили и теперь работают вечно, и никто не проверяет, оправдывают ли они ещё свою цену. Согласуйте базовое значение и метрику успеха до запуска, затем задайте явный порог убийства, чтобы решение остановиться принималось заранее, а не защищалось в моменте. Принесите текущую метрику, цену человеческого надзора на результат и дрейф, который вы видели с запуска. Для корпоративных и государственных портфелей назовите, кто рассматривает каждую систему с установленной периодичностью и у кого полномочия её вывести; случай использования, за рецензирование которого никто не отвечает, тот, который никто никогда не выключит.
Где человек остаётся в контуре, сколько стоит этот надзор и заложили ли мы его в бюджет на самом деле? Дешёвые на вид случаи использования ИИ те, что тихо предполагают полную автоматизацию, а затем теряют деньги на рецензии, исправлении и эскалации, которые реальность возвращает. Решите намеренно, какие решения человек должен подтверждать, какие модель может принимать одна и какие не может никогда, затем оцените человеческое время, которое это подразумевает. Принесите объём случаев с низкой уверенностью, цену неверного ответа и текущий путь эскалации. В регулируемой и публичной среде привязывайте каждое автоматизированное решение к подотчётному должностному лицу и пути апелляции, потому что надзор, который вы не можете описать, надзор, которого у вас нет.
Есть ли у нас таланты и платформа для эксплуатации того, что мы предлагаем, или мы тихо допускаем мощность, которой нет? Амбициозные планы ИИ проваливаются меньше на модели, чем на непривлекательных фундаментах: некому сопровождать конвейер, никто не может оценивать выводы, нет платформы для развёртывания. Сопоставьте каждый кандидатный случай использования с навыками и инфраструктурой, которые ему действительно нужны, и будьте честны, где пробел это найм, партнёр или причина не строить. Принесите опись того, кто может владеть каждой системой в эксплуатации, на какой платформе она будет работать и какие возможности вам пришлось бы купить. Для большой или публичной организации добавьте сроки закупок и найма, поскольку план, зависящий от талантов, которых вы не можете нанять в нужное окно, план недопоставки.

Взгляд по секторам

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

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

Крупная организация. Проблема управление портфелем по многим командам: общая лестница «построить или купить», согласованные оценки готовности и анализ привязки и совокупной стоимости, чтобы группы перестали изобретать дорогие конвейеры заново. Бюджетируйте бремя MLOps и человеческого надзора явно, стандартизируйте слой интерфейса, чтобы провайдеры оставались заменяемыми, и управляйте случаями использования ИИ как портфелем с ясными метриками и критериями убийства, а не россыпью пилотов.

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

Примеры

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

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

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

Антипаттерны и ловушки

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

Модель зрелости

Начальный. Стихийные эксперименты, нет общей стратегии, решения управляются шумом и энтузиазмом отдельных людей.
Развитие. Формулировка проблемы существует для некоторых проектов; появляется первая платформенная база; «построить или купить» обсуждается, но непоследовательно.
Стандартизация. Портфель случаев использования ИИ с ясными метриками, документированное дерево решений, оценки готовности и анализ привязки и совокупной стоимости, применяемые последовательно по командам.
Управление. Портфель измеряется: готовность, ROI, TCO и цена человеческого надзора отслеживаются относительно базовых значений; критерии убийства принуждаются по свидетельствам; влияние на поставку и качество управляет каждым решением «пускать или нет».
Оркестрация. Стратегия ИИ интегрирована с бизнес- и рисковым планированием; готовность поддерживается непрерывно; организация регулярно выводит, заменяет и пересматривает системы ИИ по свидетельствам, перебалансируя портфель по мере сдвигов рынка и картины рисков.

Идеи для обсуждения

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

Главные выводы

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

Источники и дополнительное чтение

Ajay Agrawal, Joshua Gans, and Avi Goldfarb, Prediction Machines: The Simple Economics of Artificial Intelligence.
Eric Siegel, The AI Playbook: Mastering the Rare Art of Machine Learning Deployment.
Andriy Burkov, The Hundred-Page Machine Learning Book.
National Institute of Standards and Technology, AI Risk Management Framework (AI RMF 1.0).
Organisation for Economic Co-operation and Development, OECD AI Principles.
Thomas H. Davenport, The AI Advantage: How to Put the Artificial Intelligence Revolution to Work.

6.1 Стратегия и готовность к ИИ

Обзор и мотивация

Ключевые принципы

Рекомендации

Формулируйте проблему до выбора технологии

Используйте дерево решений «построить, купить, дообучить или написать промпт»

Установите предпосылки по данным, талантам и платформе

Обращайтесь с регулируемым и государственным контекстом намеренно

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