Вопросы due diligence для AI-стартапов в командах акселератора

Почему сильные AI-демо всё равно скрывают слабый бизнес

Удачное демо доказывает только одно: команда умеет контролировать один момент. Оно не доказывает, что у них есть продукт, на который можно полагаться каждый день.

Этот разрыв особенно важен, когда команда акселератора или программы оценивает AI-стартап. Основатели могут показать быстрый результат на чистых данных, выверенном промпте и узком кейсе. Реальные клиенты так не делают. Они загружают грязные файлы, задают расплывчатые вопросы, пропускают инструкции и ждут, что продукт сам справится.

Первая задача в технической проверке — отделить демо от продукта. Демо идет по счастливому пути. Продукт должен переживать странные крайние случаи, слабые входные данные, медленные ответы модели и пользователей, которые нажимают не туда. Если стартап выглядит хорошо только тогда, когда команда заранее готовит всё, бизнес может быть гораздо слабее, чем кажется по питчу.

Скрытая ручная работа — частая причина этого разрыва. Команды иногда чистят данные перед встречей, переписывают промпты между шагами, повторяют запрос к модели, пока не получат лучший ответ, или исправляют результат до того, как его увидит кто-либо еще. На экране это выглядит впечатляюще, но на деле продукт все еще может зависеть от людей.

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

Маржа может исчезать так же быстро. Демо может обработать 20 запросов дешево. Реальный клиент может отправлять 20 000. Тогда экономика меняется. Вызовы модели, повторы, ручная проверка, время поддержки, логирование и обработка ошибок — всё это начинает иметь значение.

Стартап может выглядеть эффективным на экране и при этом терять деньги на каждом активном аккаунте. Если команде нужны люди в контуре для большинства результатов или если модель тратит слишком много вычислений на рутинные задачи, рост только усугубляет проблему.

Лучшие демо все равно выдерживают проверку, если подставить грязные входные данные, убрать помощь «за кадром» и спросить, сколько стоит одна завершенная задача при реальном объеме.

Вопросы, которые вскрывают продукт за питчем

Основатели могут сделать почти любой AI-продукт гладким на десять минут. Они знают правильный промпт, чистые примеры данных и единственный путь, который обходит крайние случаи. Это доказывает, что они умеют показывать продукт. Но не доказывает, что клиенты смогут пользоваться им в обычный вторник.

Некоторые из лучших вопросов для проверки нарочно очень простые. Спросите, что делает продукт, когда основателя нет в комнате. Потом попросите показать живой запуск, где продуктом пользуется другой член команды с грязными входными данными и без подсказок. Если продукт работает только под руководством основателя, возможно, перед вами услуга, спрятанная внутри красивого демо.

Начните с зависимости от модели. Спросите, какие провайдеры моделей сейчас питают продукт и какие функции завязаны на каждого из них. Затем спросите, что сломается первым, если вырастет цена API, провайдер изменит лимиты или обновление модели ухудшит качество. Многие команды говорят, что смогут сменить модель в любой момент. Часто они это никогда не проверяли.

Затем спросите, зачем клиенты возвращаются каждую неделю на самом деле. Размытый ответ вроде «они пользуются им каждый день» почти ничего не говорит. Вам нужен повторяющийся сценарий, человек, который его делает, и причина, почему это важно. Если команда не может ясно описать рутинное поведение, возможно, реального использования продукта пока нет.

Небольшой пример хорошо показывает смысл. Стартап показывает AI-инструмент, который пишет follow-up-письма для продаж. Демо выглядит отлично. Но лучше спросить, открывают ли менеджеры по продажам его каждую неделю, доверяют ли черновику, правят ли одну-две строки и отправляют ли текст в своем обычном процессе. Если менеджеры копируют текст в другое приложение, переписывают половину и перестают пользоваться им через несколько дней, продукт все еще очень тонкий.

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

Что происходит, когда модель ошибается

Хорошая техническая проверка фокусируется на сбоях, а не на блеске. Удачное демо мало говорит о том, как продукт ведет себя в плохой день.

Попросите основателей показать реальные ошибки: неправильные ответы, небезопасные результаты, медленные отклики и случаи, когда модель отказалась от задачи, с которой должна была справиться. Если они показывают только лучшие сценарии, воспринимайте это как предупреждение. Сильные команды держат небольшую библиотеку сбоев и могут объяснить, что вызвало каждый из них. Слабые команды говорят, что модель «обычно точная», и идут дальше.

Также нужно понимать, кто ловит ошибки до того, как их увидят клиенты. Некоторые стартапы полагаются на человека для проверки каждого ответа. Другие проверяют только рискованные случаи. Оба подхода могут работать, но вам нужны цифры. Если один человек проверяет половину всех результатов, бизнес может сломаться по мере роста объема.

Попросите несколько конкретных деталей. Какие плохие или небезопасные результаты они видели в недавних тестах или в проде? На каком именно шаге кто-то или что-то проверяет результат? Что делает продукт, если модель тормозит или не отвечает вовремя? Какие логи команда хранит и кто получает уведомления, когда растет частота сбоев?

Задержка ответа важнее, чем многие основатели признают. Когда время отклика растет с 3 секунд до 20, пользователи повторяют запрос, бросают задачу или отправляют работу в поддержку. Внимательные команды к этому готовы. Они могут перейти на более простую модель, вернуть частичный результат, поставить задачу в очередь или передать ее человеку с понятным сроком.

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

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

Куда исчезает маржа

Один вопрос быстро приводит к расплывчатым ответам: «Сколько стоит одна завершенная задача?» Слайд с выручкой этого не покажет. Просите стоимость одной выполненной задачи, а не просто ежемесячные расходы на облако и не усредненный прогноз.

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

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

Попросите валовую маржу в двух точках: при текущем объеме и при реалистичном объеме клиента. Разница важна. Продукт, который выглядит дешевым при 50 задачах в день, может стать некрасивым при 5 000, если задержки вынуждают делать повторы или длинные входные данные переводят модель на более дорогой тариф.

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

Допустим, стартап берет $3 за краткое резюме документа. На сцене стоимость модели выглядит как $0.30, и юнит-экономика кажется нормальной. После запуска 20% документов требуют второго прохода, 10% — человека, который исправит результат, а длинные файлы запускают еще один вызов модели. Маржа может сжаться от приемлемой почти до нуля.

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

Вам нужна небольшая таблица, а не красивая история: цена за задачу, средняя стоимость модели, среднее время человека, доля повторов и валовая маржа при низком и нормальном объеме. Это скажет больше, чем любое сильное демо.

Сколько ручной проверки стартапу на самом деле нужно

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

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

Один вопрос работает особенно хорошо: «Кто трогает результат до того, как его увидит клиент?» Продолжайте, пока не получите имена, затраченное время и объем в день. Если ответ остается расплывчатым, вероятно, стартап плохо измеряет нагрузку на проверку.

Основатели часто делают эту работу сами на раннем этапе. Это нормально, но это скрывает реальную стоимость. Если CEO и CTO до сих пор проверяют большую часть ответов по ночам, компания еще не выстроила повторяемый процесс. При отборе в акселератор это должно снизить уверенность в текущей марже и скорости.

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

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

Представьте стартап, который продает AI-ответы для поддержки. Каждый агент проверяет 120 черновиков в день, но 35% требуют правок, а 10% — полного переписывания. Если новые клиенты добавят 2 000 черновиков в день в следующем квартале, команде почти сразу понадобятся новые проверяющие.

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

Короткий сценарий проверки для команд программы

Большинство первичных проверок слишком быстро уходят в абстракции. Лучший подход прост: выберите одно обещание стартапа клиентам, а затем разберите один реальный рабочий процесс, который это обещание выполняет.

Если основатель говорит: «Мы превращаем обращения в поддержку в готовые ответы за 30 секунд», держитесь за это утверждение. Пока не переходите к размеру рынка или длинной дорожной карте. Попросите их провести вас через одно обращение от сырого входа до финального результата.

Хорошо работает пятишаговый сценарий проверки:

1. Начните с действия пользователя. Что клиент загружает, вводит или нажимает и какой результат ожидает в конце?
2. Проследите весь путь. Спросите, что происходит до вызова модели, во время него и после него, включая правила, поиск, форматирование и доставку.
3. Посчитайте каждый вызов модели и каждое касание человеком. Одно отполированное демо может скрывать три фоновых промпта, ручного проверяющего и основателя, который исправляет крайние случаи за кадром.
4. Проверьте стоимость, скорость и обработку сбоев. Спросите, что будет, если модель медленная, ошибается, заблокирована политикой или становится слишком дорогой в загруженный день.
5. Запишите один красный флаг и один вопрос для следующего раунда до конца встречи. Так команда уйдет с конкретной проблемой, а не с расплывчатым ощущением.

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

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

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

Простой пример из проверки акселератора

Стартап предлагает AI-инструмент, который дает отделам продаж мгновенные резюме контрактов. В демо менеджер загружает чистый PDF, ждет несколько секунд и получает аккуратное резюме с условиями оплаты, датами продления и рисками, которые выделены правильно.

На встрече это выглядит хорошо. Но это почти ничего не говорит о ежедневном использовании.

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

Стартап все равно выдает неплохие результаты, потому что за продуктом сидят два человека и исправляют крайние случаи до того, как что-то дойдет до клиента. Этот ручной слой легко не заметить во время живого демо. Основатели могут называть это контролем качества, но на самом деле это часть стоимости продукта.

При низком объеме цифры все еще могут выглядеть нормально. Если команда обрабатывает 20 контрактов в день, два проверяющих могут справляться. Если после удачного пилота нагрузка вырастет до 200 контрактов в день, те же двое станут узким местом. Компании теперь нужны больше сотрудников, более медленная доставка или ниже точность. Любой из этих вариантов может убить маржу.

Три дополнительных проверки обычно вскрывают разрыв. Попросите команду прогнать продукт на случайных клиентских файлах, а не на подготовленном наборе для демо. Спросите, какая доля результатов нуждается в ручных правках перед отправкой. Затем спросите, как меняется время проверки, когда объем удваивается или утраивается.

Этот пример простой, но он ловит распространенную проблему. Гладкое демо может скрывать слабую работу с документами, скрытый труд и бизнес-модель, которая работает только пока использование остается маленьким.

Ошибки, которые команды совершают, когда оценивают AI-стартапы

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

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

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

Ручная работа тоже исчезает в отполированных встречах. Результат выглядит мгновенным, но кто-то мог очистить данные, повторно запустить неудачные попытки, исправить плохие ответы или проверить каждый результат до звонка. Если стартапу нужен человек в контуре для большинства клиентских задач, продукт может быть услугой в одежде софта.

Бенчмарки создают еще одну ловушку. Команда может показать 90% точности на одном внутреннем тесте и все равно разочаровать клиентов. Покупателей волнует, экономит ли инструмент время, избегает ли дорогих ошибок и работает ли на грязных входных данных. AI-помощник для поддержки, который хорошо выглядит в лаборатории, может после запуска все равно завалить человеческих агентов эскалациями.

Нагрузке на поддержку уделяют меньше внимания, чем следует. Многие AI-продукты дешево продаются, а потом становятся дорогими в сопровождении, потому что пользователям нужна помощь с неверными ответами, крайними случаями и непонятными настройками. Основатели должны сказать, кто решает эти проблемы, как часто они возникают и как меняется показатель по мере роста использования.

Чаще всего лучше работают простые вопросы: юнит-стоимость, участие проверяющих, повторное использование, удержание клиентов и объем обращений в поддержку после запуска. Эти ответы важнее одного идеального демо.

Короткий чек-лист перед тем, как делать предложение

Прежде чем отправлять условия, пройдите пять проверок. Они ловят большую часть неприятных сюрпризов.

• Попросите основателей показать, что происходит, когда входные данные расплывчаты, неполны или явно неверны. Хорошие команды знают свои случаи отказа и могут объяснить, что видит пользователь, когда модель не уверена.
• Попросите реальные цифры стоимости одной задачи сегодня, включая стоимость модели, время ручной проверки и любую дорогую обработку вокруг модели.
• Проверьте, сможет ли один оператор со временем проверять больше работы. Если каждому новому клиенту нужен тот же объем ручной проверки, маржа останется тонкой.
• Проверьте, насколько они завязаны на одну модель. Команды, которые могут переключать модели или хотя бы направлять разные задачи к разным моделям, лучше контролируют цену, скорость и доступность.
• Ищите повторное использование, а не разовые тесты. Дюжина впечатляющих пилотных пользователей значит меньше, чем меньшая группа, которая возвращается каждую неделю.

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

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

Что делать после первого технического прохода

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

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

Цифры быстро меняют разговор. «Мы проверяем 12% случаев и тратим около 6 минут на каждую проверку» — это полезно. «Мы в основном автоматизировали процесс» — нет.

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

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

Если ответы все еще кажутся слишком тонкими, поможет внешний разбор. Oleg Sotnikov на oleg.is работает как Fractional CTO и стартап-консультант по ПО и инфраструктуре с AI-first подходом, и именно в таких проверках опытные технические операторы особенно полезны. Они могут заметить скрытую ручную работу, хрупкую архитектуру и облачные расходы, которые не выдержат роста использования.

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

Не относитесь ко всем AI-стартапам одинаково. Поддерживайте команды, которые могут объяснить свои цифры и выдержать столкновение с реальными пользователями.