Единая AI-платформа умерла, не успев появиться
Заголовок нарочно резкий, поэтому сразу уточню: умерла не идея наводить порядок в AI-контуре. Умерло конкретное представление о том, как этот порядок выглядит.
Два трека, которые не встречаются
В этом году я заметно больше общаюсь с клиентами про AI-платформы и внедрение агентов в реальные процессы. И почти в каждой крупной компании вижу одну и ту же картину: два параллельных трека, которые движутся навстречу друг другу, но узнают об этом поздно.
ИТ и AI-команды не хотят потерять контроль над новым контуром — желание совершенно здравое. Решают задачу привычным способом: единая AI-платформа, AI-стратегия, централизация функции внедрения и управления. Логика понятная, аргументы сильные.
Бизнес в это время уже пользуется всем доступным. Часто вообще не обращая внимания на «лишние» ограничения. Ценность получает быстро — и вне периметра: без контроля данных, затрат и качества.
Когда эти два трека наконец встречаются на одной встрече, разговор редко получается конструктивным. ИТ видит теневое внедрение и риски. Бизнес видит попытку затормозить то, что уже приносит пользу. Оба правы.
Почему централизация проигрывает гонку
Дело не в том, что платформа — плохая идея. Дело в скорости.
Проектирование единой платформы занимает месяцы: собрать требования, выбрать стек, согласовать бюджет, построить, обкатать. За это время сценарии применения успевают смениться дважды. К моменту готовности платформа отвечает на вопросы, которые задавали в начале пути.
Есть и вторая причина, менее очевидная. Единая платформа предполагает, что мы заранее знаем список задач. В случае с AI это не так: самые ценные сценарии обычно находят не архитекторы, а люди на местах, пробуя инструмент на своей работе. Платформа, спроектированная до этого перебора, оптимизирует не то.
Почему полная децентрализация — тоже не ответ
Здесь важно не свалиться в противоположную крайность, потому что «пусть каждый пользуется чем хочет» ломается ровно так же предсказуемо.
Через год без общих правил компания получает набор несовместимых решений. Данные уходят наружу без понимания, какие именно и куда. Счета за модели приходят из разных мест и не сводятся. Одни и те же сценарии реализованы трижды в трёх подразделениях, причём с разным качеством. А когда автор удачного решения увольняется, вместе с ним уходит и решение — потому что оно нигде не описано и держалось на нём одном.
Так что вопрос не «централизовать или нет». Вопрос в том, что именно централизовать.
Слой управления вместо платформы
Вывод, к которому мы приходим почти на каждом таком проекте: нужен не единый инструмент на все задачи, а единый слой управления поверх множества инструментов, моделей и агентов — вне зависимости от того, из каких кубиков контур собран.
Это не продукт, который можно купить. Это набор договорённостей и небольших инструментов вокруг них. Обычно он состоит из шести элементов.
Реестр сценариев и агентов
Что где работает, кто владелец, какую задачу решает, на каких данных и моделях. Самый скучный элемент и самый недооценённый: без реестра невозможно ни оценить риск, ни переиспользовать удачное решение. Начинать почти всегда стоит с него — уже первая инвентаризация обычно даёт руководству неожиданную картину.
Правила доступа к данным
Какие данные можно передавать наружу, какие только во внутренний контур, что обезличивается. Ключевое требование к этим правилам — выполнимость. Правило, которое мешает работать, не соблюдается, а нарушается тихо.
Контроль затрат
Учёт потребления по сценариям и подразделениям, лимиты, понимание стоимости одного обращения. Без этого счёт становится сюрпризом в конце квартала, а разговор о ценности сценария — беспредметным.
Оценка качества
Как измеряется польза сценария и как ловятся деградации. Специфичная для агентов метрика — доля ответов, которые пришлось исправлять человеку. Если её не считать, оценка сведётся к впечатлению.
Границы решений
Где агент решает сам, где предлагает, а где обязателен человек. Это управленческое решение, а не техническая настройка, и принимать его должен владелец процесса.
Дешёвый вход в эксперимент
Понятный путь для сотрудника, который хочет попробовать сценарий: как получить доступ и что можно делать без длинных согласований. Элемент, о котором забывают чаще всего, — а именно он определяет, будут эксперименты внутри контура или в обход него.
С чего начинать
Не со стратегии и не с платформы. С инвентаризации того, что уже используется, — включая неофициальное. Дальше — несколько пилотов с заранее оговорённым критерием успеха, и параллельно с ними сборка слоя управления по мере появления сценариев.
Порядок именно такой. Если начать со стратегии, к моменту её готовности сценарии поменяются. Если ограничиться пилотами, через год получится тот самый набор несовместимых решений без контроля данных и затрат.
Единая платформа как ответ на вопрос управления AI действительно не состоялась. Но задача, которую она пыталась решить, никуда не делась — просто решается она иначе: не одной платформой для всего, а одним управляемым контуром поверх многого.
Помогаем выстроить такой контур: от инвентаризации того, что уже используется, до реестра сценариев и правил работы с данными. Подробнее — AI-агенты и governance.