Проблема 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?

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