Проблема AI Wrapper: почему «мы используем ИИ» не значит то, что думают покупатели

Почему заявления об ИИ становятся частью тезиса приобретения, и почему почти ничто в стандартном процессе сделки реально их не проверяет.

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

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

ЗАЯВЛЕНИЕ

Заявление

«На основе ИИ» теперь появляется в pitch deck и CIM для огромного числа технологических бизнесов, и это редко ложное заявление. Большинство этих компаний реально используют ИИ, где-то. Что фраза не говорит покупателю, это насколько глубоко это использование реально заходит, дифференцированная ли это, защищённая возможность, или тонкий слой, обёрнутый вокруг вызова общего API.

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

ПРОБЛЕМА

Проблема

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

Это не история про обман. Это проблема измерения. Ничто в стандартном питче или стандартном финансовом или юридическом обзоре не заставляет эту разницу выйти на поверхность до закрытия сделки.

ГЛУБИНА РЕАЛИЗАЦИИ

Различие: глубина реализации ИИ

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

Фреймворк глубины реализации ИИ

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

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

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

РИСК

Риск: что реально стоит тонкий слой после закрытия

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

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

СЛЕПАЯ ЗОНА

Слепая зона

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

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

ЧЕМ НЕ ЯВЛЯЕТСЯ

Чем этот аудит не является

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

Это конкретная, доказательная оценка того, из чего реально состоит заявленная ИИ-возможность, от чего она зависит, и что случится, если эти зависимости изменятся.

ЧТО ПРОИЗВОДИТ АУДИТ

Что реально производит аудит

Результат не вердикт, хороший бизнес или плохой. Это конкретный набор deliverable, построенный ответить на вопрос, на который остальной процесс сделки не был построен отвечать.

Что реально получает покупатель

КТО СПРАШИВАЕТ

Кто реально спрашивает

«Покупатель» преуменьшает, насколько по-разному этот вопрос ложится в зависимости от того, кто спрашивает. Покупатель хочет знать, что он реально приобретает. Продавец, что готовится к процессу, хочет знать, что он может достоверно обосновать до того, как заявления станут частью CIM. Операционная команда PE хочет знать, сколько зависимость будет стоить после закрытия, когда это уже их баланс. M&A-советник хочет знать, какие риски могут сорвать тезис или изменить число до подписания сделки. Базовая архитектура, что изучается, та же. Что каждая сторона нуждается из выводов, нет.

СЛЕДСТВИЕ ДЛЯ ОЦЕНКИ

Следствие для оценки

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

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

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

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

Это и есть разница между покупкой ИИ-бизнеса и покупкой истории о нём.

Что такое AI due diligence?

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

Что такое AI wrapper?

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

Является ли использование OpenAI, Anthropic, или другой фундаментальной модели автоматически риском в приобретении?

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

Как зависимость от ИИ реально влияет на оценку компании?

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

Что должен включать технический AI due diligence?

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