Forward-deployed engineers от AI-вендоров: риски, издержки и vendor lock-in при внедрении ИИ

IT-руководители все чаще обращаются к forward-deployed engineers от AI-вендоров за помощью во внедрении ИИ. Вот что нужно учитывать перед тем, как идти на этот шаг.

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

«Очень немногих реальных выгод можно добиться, просто купив AI-продукт и отдав его сотрудникам. Вендоры продвигали этот миф последние три года», — сказал Nader Henein, вице-президент и аналитик Gartner.

«На практике сильная ценность ИИ и стабильный ROI почти всегда возникают как результат глубокой и осмысленной интеграции возможностей ИИ в существующие рабочие процессы. Для этого нужны специализированные команды, а они недешевы, и организации нанимают такие команды разными способами», — сказал Heinen.

Среди вариантов, доступных IT-руководителям, которые ищут помощь во внедрении ИИ, — традиционные IT-консалтинговые компании, специализированные AI-консалтинги и независимые подрядчики. Крупные компании с большими бюджетами могут рассмотреть покупку AI-фирмы с последующим включением ее технологий и экспертов в свою структуру. Поверх всех этих вариантов можно использовать open source, чтобы снизить vendor lock-in, — именно такой подход использовала, например, Capital One.

Но больше всего внимания в последнее время привлекает привлечение forward-deployed engineers (FDEs) — команд экспертов AI-вендора, которые встраиваются в работу внутренних инженеров клиента и помогают контролировать развертывание ИИ в корпоративной среде. Например, OpenAI и Anthropic недавно объявили о FDE-предложениях, а Microsoft партнерится с консалтинговым гигантом EY в новой FDE-программе для agentic AI-развертываний.

Инженерные команды AI-вендоров обладают важными преимуществами: они лучше других понимают собственные модели, имеют опыт интеграции этих моделей в разные корпоративные среды и заранее знают о будущих возможностях моделей до их официального анонса. Но у них есть и очевидный недостаток — vendor lock-in. Даже если будущие развертывания не входят в их контрактные обязательства, такие сотрудники вендора могут незаметно влиять на будущие AI-инициативы клиента.

Flavio Villanustre, CISO компании LexisNexis Risk Solutions, советует IT-руководителям осторожно подходить к программам FDE.

FDE «финансово мотивированы расширять использование AI-продуктов конкретного вендора и делать его сервисы более “липкими” для клиента», — сказал он. «Хотя FDE могут быть разумной сервисной надстройкой со стороны AI-вендора, клиентам всегда стоит искать другие, независимые экспертные мнения, которые могут оценить конкурентные решения у нескольких поставщиков».

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

Аналитики, консультанты и другие отраслевые эксперты, с которыми поговорил Computerworld о FDE, поддержали осторожную позицию Villanustre и указали на риски скрытых затрат, конфиденциальности, observability и vendor lock-in.

Долгосрочные издержки и vendor lock-in

Ключевой вопрос, который должны учитывать IT-руководители, — как долго потребуется команда FDE. Вероятно, предприятию понадобится непрерывная серия AI-развертываний, синхронизированных с текущей моделью или моделями ИИ. Если помощь нужна сегодня, почему это изменится завтра?

Предприятия часто недооценивают эти долгосрочные издержки, сказал John Sangyeob Kim, AI-инженер в компании-разработчике Solidroad.

«Развертывание — это, возможно, 20% общей стоимости. Остальные 80% — это поддержание системы в рабочем состоянии через обновления моделей, data drift и крайние случаи, которые проявляются только спустя месяцы в продакшене», — сказал Kim. «Большинство контрактов оценивают первую часть и предполагают, что остальное как-то само собой сложится. Развертывание больше не самое сложное место в enterprise AI. Следующие восемнадцать месяцев — вот что важно».

И намеренно или нет, FDE естественным образом будут отдавать предпочтение собственному продуктному портфелю — это то, что они знают лучше всего.

«FDE из model labs хорошо умеют заставлять собственные модели работать в вашей среде. Они хуже подходят для мультимодельных систем, потому что их стимул — удержать вас внутри своей экосистемы», — сказал Kim.

Sanchit Vir Gogia, главный аналитик Greyhound Research, считает, что IT-руководителям следует рассматривать модель FDE как стратегию, связанную с постоянной операционной властью.

«Тот, кто формирует шаблон развертывания, формирует будущую мышечную память предприятия. Тот, кто владеет evaluation layer, владеет truth layer. Тот, кто контролирует логику интеграции, контролирует карту зависимостей», — сказал Gogia. «Вот почему модель FDE важна. Это не просто еще один вариант поставки. Это то, как frontier AI-вендор подходит ближе к рабочему процессу клиента, операционной модели и архитектуре принятия решений».

Это сближение работает в обе стороны, отметил Gogia. «FDE встроены в [среду] клиента, но они также связаны с коммерческим центром притяжения вендора. Их естественный импульс — строить вокруг семейства моделей, предположений по tooling, шаблонов развертывания и дорожной карты продукта, которые они знают лучше всего. Это совершенно естественно. И именно поэтому CIO должны быть осторожны», — сказал он.

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

«FDE могут одновременно ускорять развертывание и усиливать зависимость», — сказал Gogia. «Frontier AI-вендоры больше не хотят просто продавать доступ к моделям. Все чаще они хотят определять, как предприятия разворачивают интеллект. Это куда более крупный приз».

Что происходит, когда команда FDE уходит?

Риски после ухода FDE серьезны и часто недооцениваются, по словам Justin Greis, CEO консалтинговой компании Acceligence и бывшего руководителя североамериканской практики кибербезопасности в McKinsey.

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

«Полученные знания совершенно точно будут переноситься от клиента к клиенту», — сказал Greis. «Тот, кто помогает внедрять ИИ, узнает гораздо больше, чем указано в statement of work. Они узнают реальные workflows, незадокументированные исключения, пробелы в качестве данных, узкие места согласования, обходы в сфере безопасности и те места, где бизнес зависит от нескольких людей, знающих, что делать, когда процесс ломается. Это знание может быть столь же чувствительным и ценным, как и сами данные».

Еще одна критически важная, но часто упускаемая из виду проблема — насколько реальный контроль сохранит IT над проектом, если и когда команда FDE уйдет.

«Опасность не в том, чтобы использовать внешнюю помощь. Большинству компаний она нужна», — сказал Greis. «Опасность в том, чтобы использовать внешнюю помощь так, что после завершения работы предприятие станет менее самостоятельным и более зависимым».

Именно такие операционные решения IT часто упускает из виду, сказал Kim из Solidroad.

«Лучший предиктор успеха — не вендор. Важно, понимает ли систему по-настоящему хотя бы один внутренний инженер до ухода внедренца. Главное — кто владеет evaluation loop после демо», — сказал Kim.

«Что будет с нашими prompts, scorers и guardrails, когда изменится версия модели? Если мы приостановим это взаимодействие завтра, что именно перестанет работать — по замыслу или случайно?» — спросил Kim. «Где вы хотите, чтобы после завершения работ оказались обучение ИИ, контроль и зависимость предприятия?»

Kim утверждает, что observability — способность понимать и управлять всеми элементами сложной корпоративной среды — это критически важная функция, которой IT часто уделяет недостаточно внимания. Важно определить, использует ли проект стек observability предприятия или стек observability вендора.

«Если внедренец использует свой стек observability, это нормально на этапе сборки, но вам нужен план перевести все на то, чем владеете вы, до его ухода; иначе видимость уйдет вместе с ним», — сказал Kim. «Если они используют ваш стек, это лучший вариант. Это значит, что они работают внутри системы, которой ваша команда будет управлять в долгую».

Серьезная проблема возникает, когда не используется ни стек observability предприятия, ни стек observability вендора. «Neither означает, что они строят систему вообще без production observability layer, и вы получаете систему, внутрь которой не можете заглянуть. В первый же раз, когда что-то ломается в продакшене, у вас нет traces, нет истории отказов и нет способа понять, это model regression, проблема данных или ошибка кода», — сказал Kim.

«Если observability не была приоритетом во время сборки, то evals и regression testing, как правило, тоже не были. В итоге вы получаете систему, которую не можете измерить и безопасно менять. Это худший возможный вариант передачи», — сказал он.

Сравнение альтернатив

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

Разрыв в доступности особенно заметен за пределами США, где onsite FDE встречаются реже, сказал Henein из Gartner. «Где именно происходит разработка? В этом регионе FDE может просто не оказаться», — сказал он.

У предприятий есть и другие варианты, куда можно обратиться за помощью с ИИ. Ishraq Khan, CEO компании Kodezi, разрабатывающей инструменты для повышения продуктивности кодинга, советует IT-руководителям рассматривать широкий спектр вариантов, но отмечает, что у всех подходов есть серьезные недостатки.

«Традиционные консалтинговые компании обычно сильнее в governance, процессах, compliance и организационной координации. Они понимают, как крупные предприятия устроены политически и структурно. Минус в том, что многие из них медленнее и часто не обладают глубокой специализацией в frontier AI», — сказал Khan.

Gogia из Greyhound Research сказал это еще красочнее: традиционные IT-консультанты «умеют собрать legal, risk, security, finance, HR и business units в одной комнате так, чтобы никто не поджег ковер. Для регулируемых предприятий это важно», — сказал он.

У специализированных AI-консалтингов есть другой набор сильных сторон, сказал Khan. «AI-native consultancies двигаются гораздо быстрее и часто лучше успевают за технологией, но многие из них все еще организационно незрелые. Некоторые могут делать впечатляющие демо, не до конца понимая долгосрочную сопровождаемость, governance или надежность в продакшене».

Greis из Acceligence прокомментировал еще два варианта привлечения внешней AI-помощи. Независимый подрядчик «может отлично подойти для дизайна evals, архитектурных ревью, red teaming, проектирования agent design или чтобы сдвинуть с места команду, которая застряла», — сказал он, но это может увеличить риск key-person dependency, когда только один внешний человек понимает систему.

Что касается покупки AI-фирмы и найма ее сотрудников в рамках сделки acquihiring, Greis сказал, что это может сработать хорошо, если AI-компетенции и экспертиза действительно стратегически важны для покупателя. Но есть риск, что поглощенная команда будет задушена бюрократией материнской компании: «Вы покупаете speedboat, прикручиваете его к aircraft carrier и потом удивляетесь, почему он перестал двигаться», — сказал он.

Наконец, open-source стратегия может дать компаниям гибкость и снизить зависимость от вендора, но «многие компании недооценивают операционную нагрузку, которая с этим приходит», — сказал Khan из Kodezi. «Open source помогает только если у организации есть внутренние таланты и дисциплина, чтобы нормально это поддерживать».

Итог: предприятиям нужно определить свои настоящие цели до выбора подхода. Khan предложил CIO несколько ключевых вопросов: «Кто владеет развертыванием после внедрения? Можем ли мы позже сменить поставщика, не перестраивая все заново? Что будет, если отношения с вендором изменятся или исчезнут? Мы оптимизируемся под краткосрочную скорость внедрения или под долгосрочную операционную устойчивость?»

В любой ситуации, когда внешние компании получают прямой доступ к корпоративным системам, IT должно быть полностью в курсе. «Худший исход — когда предприятие успешно внедряет ИИ, но больше не понимает, как под капотом работают его собственные системы», — сказал Khan.

Внешняя помощь во внедрении ИИ: 6 вариантов

Связанное чтение:

• Вот одна из профессий, появившихся на волне перехода к ИИ: forward-deployed engineers
• Forward-deployed engineer: почему именно дефицит талантов, а не технологий, — главное узкое место enterprise AI
• Новый AI lock-in

Материал — перевод статьи с английского.

Оригинал: AI vendor FDEs: Key considerations and concerns