Такое чувство, что все в AI помешаны на выборе. Куда бы этот AI правильно запихнуть. Вот все кругом запихивают не туда, а мы найдем тот самый. Процесс, на котором AI-агент заработает нам миллиарды.
Про это делают курсы, пишут статьи большие консалтинговые фирмы и проводят стратсессии лучшие преподаватели MBA. И в этом, на самом деле, не очень много пользы.
Я могу легко назвать два очень дорогих процесса: разработка кода и поддержка клиентов. Если хорошо подумать — ещё несколько: продажи, маркетинг, финансовый бэк-офис, обработка документов. Дальше список резко кончается.
И это не потому, что у меня плохая фантазия. Так устроена работа. Несколько больших процессов, которые есть в каждой компании, и тысячи маленьких, которые есть только у вас. «Сверка отгрузок с таможенными декларациями». «Расчёт бонусов дилерам сельхозтехники». «Учёт возвратной тары у пивоварни». Каждый такой процесс по отдельности — копейки. А все вместе они сопоставимы с головой, а может, и больше.
McKinsey в своём известном отчёте о генеративном AI разобрали 63 сценария применения в 16 функциях. Около 75% их ценности пришлось на четыре области: работа с клиентами, маркетинг и продажи, разработка и R&D. Это голова. Эти 63 сценария дают $2,6–4,4 трлн в год. Но дальше McKinsey добавляют эффект от применения AI во всей остальной работе знаниевых сотрудников — и общая оценка вырастает до $6,1–7,9 трлн. То есть почти половина ценности лежит за пределами тех сценариев, которые аналитики смогли назвать поимённо. Это хвост.
Масштаб хвоста хорошо видно в американской базе профессий O*NET: 923 профессии и больше 19 000 описанных рабочих задач. А ещё лучше — в ваших собственных счетах за софт. По данным Zylo, большая компания (10 000+ сотрудников) в среднем использует 660 SaaS-приложений. Шестьсот шестьдесят. Каждое закрывает свой кусочек процессов, потому что ни одна большая система не может закрыть всё.
А теперь посмотрите, где AI используется сейчас. По данным Anthropic Economic Index, около 44% корпоративного API-трафика Claude — это разработка ПО. А на нижние 80% категорий задач приходится всего 10,5% трафика. AI сегодня используется только для крупных функций. Хвост почти не тронут.
Почему? Потому что хвост нельзя автоматизировать так же, как голову. На поддержку можно посадить команду из десяти сильных инженеров, полгода строить агента, и это быстро окупится. На «учёт возвратной тары» — нельзя. Проект не окупится. А главное — центральная AI-команда про этот процесс даже не узнает.
Так кто же тогда должен внедрять AI в корпорацию? Короткий ответ: не одна команда, а три роли. Центральная команда строит платформу. FDE (Forward Deployed Engineers) — инженеры, которые сидят рядом с бизнесом, — встраивают агентов в реальные процессы. А руководитель AI-трансформации решает, куда направить усилия. Завтра к ним присоединится каждый сотрудник. Дальше разберём, почему всё устроено именно так и откуда берутся эти роли. Но начнем мы с истории. Эта технологическая революция не первая, которая происходит с человечеством.
Мы это уже проходили
Примерно раз в 10–15 лет в бизнес приходит технология, из-за которой приходится перестраивать процессы. Персональные компьютеры в 80-е. ERP-системы и интернет в 90-е. Данные и облака в 2010-е. Сейчас AI.
И каждый раз история развивается по одному сценарию. Технология действует с двух сторон.
Сверху вниз идёт инфраструктура. Кто-то строит платформу, выстраивает правила, собирает лучшие практики и учит людей ими пользоваться. Эта сила закрывает голову и создаёт условия для всего остального.
Снизу вверх идут реальные внедрения. Люди, которые знают свою работу, видят конкретную проблему и решают её. Эта сила закрывает хвост — просто потому, что только внизу знают, где он. И она уже работает: по тем же данным Zylo, 70% трат на SaaS в компаниях идут через бизнес-подразделения и только 26% — через IT.
А между ними всегда есть петля: удачные решения снизу поднимаются наверх, становятся стандартом и раздаются всем.
Посмотрим, как это работало в трёх волнах.
Компьютеры и таблицы
70-е годы. У компании есть один большой компьютер. Стоит в отдельном зале, работать с ним умеют только программисты из отдела обработки данных.
Финансист-новатор хочет автоматизировать свой ежемесячный прогноз. Сам он этого сделать не может. Он пишет заявку, к нему приходит системный аналитик, разбирается, как он считает, пишет техническое задание. Программист пишет программу. Проходят месяцы.
Понятно, что до нашего несчастного финансиста очередь не доходит никогда. Автоматизируют голову: зарплату, бухгалтерский учёт, склад. Остальное на калькуляторе. Или на счетах.
В 1979 году выходит VisiCalc — первая программа электронных таблиц, для Apple II. Её покупают бизнесмены, бухгалтеры, финансисты. Причём покупают так: когда клиенту говорили, что для программы за $100 нужен Apple II за $2 000, он просто добавлял компьютер к заказу. Журнал InfoWorld в 1982 году писал, что компьютер продают как «аксессуар к VisiCalc».
Дальше — Excel. К 1996 году у Excel больше 30 миллионов пользователей. Финансист собирает свой прогноз сам, без заявок и без программистов. Хвост закрыли сами пользователи.
Обратите внимание: это не случилось за один вечер. От VisiCalc до Excel в каждом офисе прошло почти 15 лет. Платформе нужно было дозреть.
А системные аналитики никуда не исчезли. Они ушли в сложные системы: ERP, банковские ядра, всё то, что таблицей не соберёшь.
ERP-системы
90-е. Компании массово переходят на ERP. Это единая система на всю компанию: бухгалтерия, продажи, закупки, склад, производство и кадры живут в одной базе, а не в десятке разрозненных программ. Главный продукт эпохи — SAP R/3, вышедший в 1992 году.
ERP нельзя просто установить. Под каждую компанию её нужно настраивать, а процессы компании часто приходится переделывать под систему. Поэтому вокруг ERP выросла целая индустрия консультантов по внедрению. Консультант приходил в компанию, месяцами разбирался, как устроены закупки или склад, и настраивал систему под них.
А что бывает, когда технологию внедряют в спешке, без подготовки процессов и людей, хорошо показала Hershey. В 1999 году компания сжала рекомендованный срок внедрения с 48 до 30 месяцев и запустила ERP, систему управления цепочками поставок и CRM одновременно — в июле, перед самым горячим сезоном. Заказы начали теряться, и перед Хэллоуином клиенты не получили продукции примерно на $100 млн. Продажи в третьем квартале упали на 12,4%.
Внедрение ERP до сих пор хлеб с маслом консалтинговых машин вроде Accenture и Deloitte. Но после того как консультанты уходят, у компании остаётся платформа и своя команда, которая умеет с ней работать. Новый отчёт, изменение процесса, автоматизация очередного шага — это компания дальше делает сама. Мосты нужны, чтобы построить платформу, а жить на ней компания учится без них. Консультанты возвращаются только на большие перестройки.
Облака
2010-е. Компании переезжают в облака: AWS, Azure, Google Cloud. Это не просто замена серверов. В облаке команда за минуты поднимает себе инфраструктуру, которую раньше месяцами ждала от отдела эксплуатации. Меняется то, как IT работает с бизнесом.
Типичный путь выглядел так. Сначала компания создаёт центральную команду сильных инженеров — Cloud Center of Excellence. Она делает эталонные архитектуры, готовые шаблоны, инструменты автоматизации, правила безопасности, учит остальных. Классическая сила сверху вниз.
А дальше случается то, что сейчас повторяется с AI. В блоге AWS есть разбор трансформации Dow Jones. Центральная команда сделала всё правильно: шаблоны, эталонные архитектуры, автоматизацию. И через какое-то время обнаружила, что сама стала узким местом для всей организации. Все проекты стояли в очереди к одной команде.
Решение: компетенции распределили. Внутри каждой продуктовой команды вырастили своих людей, которые умеют работать с облаком, а центральная команда сосредоточилась на платформе и стандартах. Сегодня этот подход оформился в отдельное направление — platform engineering: центральная команда делает внутреннюю платформу, продуктовые команды сами ей пользуются.
Общий паттерн
В этих историях повторяется одно и то же:
- Сначала технологией владеет узкий круг специалистов. К ним выстраивается очередь, и до хвоста она не доходит. Так было с программистами больших ЭВМ и с центральной облачной командой Dow Jones.
- Пока платформа незрелая, нужны люди-мосты. Специалисты, которые приходят к бизнесу и встраивают технологию в его процессы. Так было с консультантами по внедрению ERP. А Hershey показала, чем кончается спешка на этом этапе.
- Когда платформа созревает, компетенции распределяются ближе к бизнесу. Финансисты сами собирают таблицы, продуктовые команды сами поднимают облачную инфраструктуру. Хвост закрывается снизу с помощью платформы, а специалисты уходят в сложные задачи и в доработки самой платформы.
Если наложить это на картинку с двумя силами: сверху — платформа, снизу — пользователи. А люди-мосты временно заменяют силу снизу, пока пользователи не могут закрыть хвост сами. Они сидят рядом с бизнесом, но владеют технологией.
Кто такие Forward Deployed Engineers
С AI большинство компаний сейчас на первой стадии и только переходят ко второй (почти везде, кроме разработки: там, похоже, уже третья). Да, чат-ботом пользуется каждый: сотрудники сами пишут с ним письма и отчёты. Но встроить агента в процесс так, чтобы он сам принимал решения и действовал в ваших системах, сегодня могут только инженеры. Здесь мы в эпохе больших ЭВМ, когда к компьютеру был доступ только у программистов.
Нельзя дать бухгалтеру агента так же, как дали ему Excel. Таблица ошибается предсказуемо: не та формула — не та цифра. Агент ошибается непредсказуемо, а ещё он умеет действовать: отправлять письма, менять данные, принимать решения. Чтобы довести агента до продакшена, нужно понимать контекст-инжиниринг, уметь строить оценку качества, ставить guardrails, продумывать, где человек должен подтвердить решение. Об этом я подробно писал в статье «Реальная автоматизация». Требовать этого от бухгалтера сегодня — примерно как требовать от него в 1975-м писать программы для большой ЭВМ.
Поэтому силу снизу вверх сейчас, как и раньше, приходится заменять людьми-мостами. И для этого появилась профессия — Forward Deployed Engineer, FDE.
FDE — это инженер, которого «выдвигают» к бизнесу. Он не сидит в центральной команде и не ждёт техзадание. Он садится рядом с людьми, разбирается в их процессе изнутри и встраивает туда автоматизацию. Ближайшие исторические аналоги — консультант по внедрению ERP и облачный инженер внутри продуктовой команды. Не системный аналитик из центрального отдела, к которому стоит очередь, а человек, который сам приходит туда, где живёт процесс.
История профессии
Придумали эту роль в Palantir в начале 2010-х. Внутри компании их называли «Delta» и противопоставляли обычным разработчикам, «Dev». Формулировка у Palantir очень точная: у Dev — «одна возможность, много клиентов», у Delta — «один клиент, много возможностей». До 2016 года FDE в Palantir было больше, чем обычных инженеров.
А теперь самое интересное. В 2016 году Palantir выпускает платформу Foundry — и многие FDE переходят в обычную разработку. Повторяющиеся решения, которые Delta делали руками у клиентов, стали частью платформы. Та самая петля снизу вверх в чистом виде.
Сейчас FDE переживает второе рождение. В июне 2025 года a16z назвали FDE самой горячей профессией в стартапах. Их объяснение мне очень нравится: компании, которые покупают AI, — как бабушка покупает новый iPhone (какой сейчас уже по счету?). Пользоваться хочет, но настроить должен кто-то другой. По данным Indeed, к апрелю 2026 года число вакансий FDE росло больше чем на 700% в год.
А в мае 2026-го OpenAI запустила отдельную компанию — OpenAI Deployment Company. С начальными инвестициями $4 млрд от TPG, Bain Capital, Brookfield и других. И сразу договорилась о покупке компании Tomoro, которая с первого дня приносит примерно 150 опытных FDE и специалистов по внедрению.
Задумайтесь. Компания, которая делает одни из лучших моделей в мире, покупает людей, которые умеют эти модели внедрять. Потому что иначе клиенты не поставят GPT в свой процесс. И OpenAI не получит их денег. Лучшее доказательство того, что модель — это ещё не автоматизация.
Только учтите: всё это FDE вендоров, которые приходят к клиенту снаружи. Для старта это хорошо: они приносят опыт десятков внедрений. Но хвост так не закрыть. Знание про «возвратную тару» живёт внутри вашей компании, и внешнему инженеру каждый раз придётся добывать его с нуля. Поэтому корпорации нужны свои FDE. Вендорские помогают запуститься и перенести практики, а дальше эту силу надо растить внутри. Ну или просить FDE строить платформу, которой уже могут пользоваться ваши сотрудники (это как раз переход на стадию 3). Так, кстати, и продают большие контракты Palantir. Про это и поговорим дальше.
А что с платформой?
FDE без платформы — это дорогой заказной разработчик. Каждый проект с нуля, опыт остаётся в голове конкретного инженера, масштабироваться нечему. Через год у вас 20 агентов, написанных 20 разными способами, и никто не знает, как они работают.
И именно платформа решает проблему, с которой мы начали. Посадить команду инженеров на полгода ради «учёта возвратной тары» — не окупится. Но если у FDE под рукой готовый доступ к моделям, интеграции, шаблоны агентов и контур контроля качества, агент для небольшого процесса собирается не за полгода, а за недели. Стоимость каждого внедрения падает, и хвост становится экономически оправданным. А найти такие процессы FDE может потому, что сидит рядом с бизнесом, а не ждёт заявок в центральной очереди. Платформа делает хвост дешёвым, FDE делает его видимым. Поэтому нужны обе силы сразу.
Что именно строить сверху: доступ к моделям, интеграции с данными, безопасность, наблюдаемость, библиотеку шаблонов и лучших практик. Задача центральной команды — чтобы каждый следующий агент собирался быстрее предыдущего. Из каких слоёв складывается такая инфраструктура — оркестраторы, LLM-шлюзы, безопасность, observability — я подробно разбирал в статье «Архитектура надёжных AI-агентов».
Библиотека лучших практик окупается ещё и потому, что AI хорошо их тиражирует. В исследовании Бриньолфсона и соавторов AI-ассистент для сотрудников поддержки поднял производительность в среднем на 14%, а у новичков — на 34%. Объяснение авторов: модель распространяет практики сильных сотрудников. Соберите лучшие решения в платформу — и агенты разнесут их по всей компании.
Откуда вам брать FDE
FDE — это технарь, которому интереснее внедрять AI в реальный процесс, чем делать технологию ради технологии. Ему должно быть интересно не «какую модель взять», а «почему этот процесс работает именно так».
Таких людей сейчас мало на рынке. Для них требуется 2 вещи: техническая грамотность и заряженность на результат, а не на саму технологию. Так что и вырастить их можно с двух концов.
Из продакт-менеджеров с техническим образованием. Многие PM всю карьеру мечтают сделать что-то своими руками, а не только писать требования. У них уже есть главное — умение разговаривать с бизнесом и понимать, где у процесса боль. И жгучее желание эту боль полечить. Сегодня им не нужно становиться senior-разработчиками: агента можно собрать без знаний математического анализа. Но нужно научиться инженерной дисциплине: разработке кода, оценке качества агентов, написанию промптов, работе с рисками.
Из инженеров: бэкендеров, ML-щиков, аналитиков. Тех, кому надоело просто писать код по задаче. Им хочется видеть, как их работа меняет процесс, а не просто развивать технологию. Технический фундамент у них уже есть. Нужно научить их разговаривать с бизнесом и понимать его боли. И научиться решать эту боль: выйти из роли обычного инженера и лидить весь процесс целиком.
Как правило, инженера проще научить языку бизнеса, чем PM инженерным навыкам. Но инженеров, которые хотят разбираться в кишках бизнес-процессов, реально немного. Еще отлично вырастает FDE из PM, который изначально имел техническое образование. Тогда дело быстро идет в гору.
В любом случае, на рынке готовых кандидатов на эту роль не существует. Проще всего растить внутри компании. Любым доступным образом.
Руководитель AI-трансформации
Теперь давайте заглянем вперёд.
Платформы будут развиваться. Работа FDE будет становиться проще. Так уже было с таблицами и облаками: то, что раньше делали только специалисты, стали делать сами пользователи. В пределе любой человек в любой профессии сможет сам развернуть себе AI — так же, как сегодня собирает себе таблицу.
Но одна роль останется ценной всегда. Человек, который видит, как новая технология меняет бизнес, и управляет его перестройкой. Он разбирается в технологии достаточно, чтобы понимать, что она реально может. Находит точки, где она даст эффект. Направляет усилия FDE туда, где они окупятся. И управляет ожиданиями стейкхолдеров, которые одновременно боятся AI и ждут от него чуда к следующему кварталу.
Я называю эту роль руководителем AI-трансформации. Если вернуться к картинке с двумя силами, это человек, который управляет обеими сразу: решает, что строить в платформе, куда отправить FDE и какие процессы перестраивать первыми.
И вот такая роль технологического трансформатора никогда не исчезнет. Как бы ни менялась технология. Лучше всего это объяснить через историю электрификации заводов. Её в 1990 году рассказал экономист Пол Дэвид в работе «The Dynamo and the Computer».
В 1899 году на электромоторы приходилось меньше 5% механической мощности американских фабрик. Электрификация шла медленно: только к 1920-м — через четыре десятилетия после первой электростанции — электрическими стали чуть больше половины приводов. И всё это время рост производительности был разочаровывающе маленьким.
Причина простая. Сначала фабрики просто меняли паровую машину на большой электромотор. Он крутил те же длинные валы, которые через ремни раздавали энергию станкам. Фабрика оставалась той же — многоэтажной, построенной вокруг вала. Эффекта почти не было.
Эффект пришёл, когда поняли, что можно поставить свой мотор на каждый станок. Тогда не нужны валы. Можно строить одноэтажные цеха, расставлять оборудование по ходу движения материалов, а не по близости к валу. Фабрику спроектировали заново — и производительность наконец пошла вверх. Самый известный пример перестройки производства той эпохи — конвейер Форда: в 1913 году на заводе в Хайленд-Парке сборка Model T сократилась с 728 до 93 минут.
Подключить электромотор со временем мог любой электрик. Технология стала общедоступной. А вот увидеть, что фабрику теперь можно построить иначе, и перестроить её — это умели единицы. И эффект получили именно они.
Бизнес, кстати, каждый раз интуитивно нащупывал эту роль. В 1981 году впервые описали должность CIO — директора по информационным технологиям. В 2010-е распространились Chief Digital Officer: к 2016 году они были у 19% из 2 500 крупнейших компаний мира. Сейчас очередь Chief AI Officer: по опросу IBM 2026 года, такая должность есть у 76% опрошенных компаний.
Название должности будет меняться. Суть — нет. Кто-то должен видеть, какой будет фабрика после перестройки. А перестройку может запустить любая технология.
Заключение
Так кто же должен внедрять AI в корпорацию? Точно не несколько гениальных инженеров. У автоматизации слишком длинный хвост, и огромная часть ценности лежит в процессах, о которых снаружи никто даже не знает.
Инвестируйте с двух сторон.
Сверху вниз стройте платформу: доступ к моделям, интеграции, безопасность, наблюдаемость, библиотеку практик. Так, чтобы каждый следующий агент собирался быстрее предыдущего.
Снизу вверх растите FDE — из инженеров, которые хотят видеть результат своей работы в реальных процессах, и из продактов, которые хотят наконец делать руками. Сегодня они — ваша сила снизу. Завтра, когда платформа созреет, этой силой станет каждый сотрудник.
И не забудьте про ключевую роль: людей, которые понимают, куда направить усилия FDE и как перестроить бизнес вокруг новой технологии. Инструменты становятся проще с каждым годом. Умение перестроить фабрику — нет.
Если после прочтения остались вопросы, как выстроить AI-трансформацию, — пишите в личные сообщения. Вместе разберёмся.