Если AI-пузырь лопнет: почему обёртки умрут, а устойчивые продукты выживут
Расходы на AI сильно обгоняют доходы от него. Чем бы это ни кончилось — резкой коррекцией или медленным сжатием, — больше всего рискуют продукты, сделанные тонким слоем поверх чужой модели. У них нет ни своего интеллекта, ни своих данных, а поставщик может повторить их одним релизом.
Эта статья для продуктовых дизайнеров и менеджеров, которые решают, что строить поверх AI. Разберём, почему тонкие обёртки хрупкие, как устойчивая архитектура выглядит со стороны продукта и почему управлению рисками место в интерфейсе, а не в PDF с регламентом.
§ 01
Разрыв в доходах, о котором молчит хайп
В июне 2024 года Дэвид Кан из Sequoia сделал простой расчёт. Берём годовую выручку Nvidia от дата-центров и удваиваем её, чтобы учесть энергию, здания и прочие расходы вокруг видеокарт. Потом удваиваем ещё раз, чтобы оставить 50% маржи тем, кто сдаёт эти мощности в аренду. Получаем выручку, которую должны заработать AI-продукты, чтобы инвестиции окупились. Своё эссе AI's $600B question он подытожил одной фразой: вопрос на 200 миллиардов превратился в вопрос на 600.
Чтобы отнестись к этому серьёзно, не нужно предсказывать обвал. Такой разрыв закрывается одним из двух способов: либо выручка дорастает до расходов, либо расходы падают до выручки. В обоих случаях компании, которые продают вычисления и модели, будут изо всех сил забирать больше денег себе, и это давление ляжет на продукты, построенные поверх них.
Для дизайнера это меняет само понятие хорошей AI-функции. Функция, которая работает, только пока доступ к модели дешёвый, а вендор не замечает вашу нишу, — это функция с таймером.
§ 02
Почему тонкие обёртки хрупкие
Тонкая обёртка — это интерфейс поверх API универсальной модели, под которым почти ничего своего нет. Классический пример — «поговорите со своим PDF». Это выглядело как продукт, пока поставщики моделей не научили свои приложения принимать файлы.
У обёрток две проблемы, которые один дизайн не решит. Первая — поглощение. Когда поставщик модели выпускает вашу главную функцию галочкой в настройках, ваше отличие исчезает за ночь. Вторая — маржа. Обёртка покупает интеллект по розничной цене поставщика и перепродаёт его, поэтому каждое снижение цен у конкурентов бьёт прямо по её марже.
Выживают продукты, в которых модель — двигатель, а не сам продукт. Отраслевой софт под конкретную работу — урегулирование страховых случаев, запись к стоматологу, расчёт стоимости перевозок — владеет процессом, интеграциями и данными, которые копятся по мере использования. Модель делает такой софт быстрее, но платят за него не из-за неё.
Мой тест простой. Если завтра поставщик модели выпустит ваш главный экран, зачем вы останетесь нужны пользователям? Если ответ «ни зачем», пора проектировать этот ответ.
§ 03
Проектируйте под несколько моделей
Один поставщик моделей — единая точка отказа. Цены меняются, модели снимают с поддержки, лимиты срабатывают в самый неподходящий момент, случаются сбои. Архитектурный ответ — слой маршрутизации между продуктом и моделями, и внедрить его проще, чем кажется. Маршрутизаторы вроде OpenRouter принимают список моделей по приоритету и автоматически переключаются, если первая выдала ошибку, упёрлась в лимит или упала, а платите вы за ту, которая в итоге ответила.
Это решение не только инженерное, но и продуктовое, потому что пользователь его чувствует. Проектируйте это явно. Решите, каким задачам нужна лучшая модель, а какие можно отдать подешевле. Решите, что показывает интерфейс, когда отвечает более медленный запасной вариант. Напишите текст «Это занимает больше времени, чем обычно» заранее.
Запасной вариант безопасен, только если вы уверены, что он справится. Держите небольшой набор реальных задач из вашего продукта — для начала хватит нескольких десятков — и прогоняйте через него каждую модель, прежде чем добавить её в список. Оценивайте ответы так, как оценили бы ваши пользователи, а не по публичному бенчмарку. Когда вендор меняет модель под тем же названием, прогоняйте набор снова. Иначе слой маршрутизации незаметно поменяет надёжность на сюрпризы, и пользователи заметят это раньше вас.
Модели с открытыми весами дают ещё один вариант. Если запустить модель внутри инфраструктуры клиента, вы сразу отвечаете на вопрос, который корпоративные покупатели задают первым: куда уходят наши данные? Для некоторых продуктов это превращает приватность из возражения в продажах в причину выиграть сделку.
§ 04
Управление рисками — часть интерфейса
Регулирование переходит от разговоров к срокам. По Закону ЕС об искусственном интеллекте поставщики моделей общего назначения с системным риском с 2 августа 2025 года обязаны по статье 55 оценивать модели и проводить состязательное тестирование, оценивать и снижать системные риски, сообщать о серьёзных инцидентах и надёжно защищать модели.
Большинство продуктовых команд — не поставщики моделей, но давление спускается и к ним. Покупатели из найма, кредитования, медицины и страхования уже спрашивают, как продукт принимает решения и кто может их отменить. Ответ на этот вопрос — в интерфейсе. Проверка человеком там, где решение важное. Понятные пометки о том, что сгенерировала модель. Журнал, который может прочитать юрист клиента. Способ исправить систему, который действительно срабатывает.
Считайте это функциями, а не бюрократией. Очередь на проверку, которую можно быстро разобрать, — задача для дизайнера. Как и панель с объяснением решения, которую кредитный специалист действительно читает. Команды, которые хорошо это спроектируют, будут продавать в регулируемые отрасли. Команды, которые прикрутят это в последний момент, будут такие сделки проигрывать.
§ 05
Что вознаграждает фаза внедрения
Экономист Карлота Перес делит технологические революции на две половины. Сначала идёт период установки: на рынок приходят большие деньги, инфраструктуру строят с избытком, и часто надувается пузырь. После перелома наступает внедрение: технология расходится по всей экономике, а полезные продукты строятся на ставшей дешёвой инфраструктуре. Так было с железными дорогами и с оптоволокном времён доткомов.
Если AI пойдёт тем же путём, после коррекции возможностей у дизайнеров станет больше, а не меньше. Вычисления и доступ к моделям подешевеют, а выиграют продукты, которые превратят эти мощности в надёжную работу под конкретную задачу.
Так что стройте для этого мира уже сейчас. Коротко:
- Владейте тем, что поставщик модели не сможет выпустить сам: процессом, интеграцией или данными, которые становятся лучше от использования.
- Поставьте слой маршрутизации между продуктом и моделями и спроектируйте состояния для запасных вариантов.
- В сценариях с важными решениями делайте проверку, отмену и объяснение полноценными функциями.
- Оценивайте AI-функции по тому, какую работу они доводят до конца, а не по тому, какую модель вызывают.
Ничто из этого не требует угадывать, будет ли коррекция и когда. Такой продукт вам нужен в любом случае.