50 стартапов с ИИ

- -
- 100%
- +

50 стартапов с ИИ
Сергей Степанов
От автора
Первого клиента интересует прежде всего то, как ваш продукт поможет его бизнесу, а не то насколько он красивый, аккуратный и многофункциональный. Ему нужно быстрее обработать заявки, разобраться в документах, подготовить товарный каталог или снизить число ошибок. Он оценивает срок, качество и стоимость результата. Поэтому начинать бизнес с выбора самой мощной нейросети неудобно: можно несколько месяцев собирать красивую систему, которой никто не собирается пользоваться.
В этой книге мы пойдём от работы покупателя. Вы увидите пятьдесят бизнесов, в которых ИИ выполняет существенную часть производства: распознаёт, классифицирует, ищет, прогнозирует, генерирует или проверяет. Для каждой идеи описаны первая версия, расчётная экономика, способ привлечения клиентов и условия, при которых запуск разумно остановить. Книга рассчитана на человека, который хочет открыть дело в России и готов проверить предположения до крупных вложений.
Слово «стартап» здесь используется в практическом смысле: новый бизнес, который ищет повторяемую модель продаж. Часть идей можно начать как услугу одного специалиста. Некоторые потребуют разработчика и отраслевого партнёра. Успешная услуга впоследствии может стать подписным продуктом, однако программная платформа не обязательна для первого заказа.
Я предлагаю читать книгу с листом для заметок. Отмечайте идеи, для которых у вас уже есть доступ к покупателям, понимание предмета или подходящие исходные данные. Эти преимущества обычно полезнее, чем умение составлять эффектные запросы к нейросети. Выберите несколько направлений для интервью, затем одно для платной проверки. Пятьдесят попыток одновременно быстро превращаются в пятьдесят незавершённых проектов.
Ситуации первых заказов и сметы бизнесов в книге учебные. Они показывают способ рассуждения. От них отдельно обозначены проверенные сведения об инструментах и тарифах, а также опубликованный поставщиком кейс реальной компании. Ссылки позволяют проверить происхождение этих сведений. Цены являются гипотезами для проверки, а бюджеты обозначают предел эксперимента при указанных условиях. Они не подтверждают, что покупатель в вашем городе согласится платить такую сумму.
Источники по инструментам и условиям запуска проверялись 12–13 октября 2026 года. Сервисы, тарифы и правила меняются. В книге есть ссылки на источники, которые следует открыть перед запуском, и отдельное сравнение с готовыми решениями. Для конкретной схемы обработки данных, договора и налогового режима понадобятся проверки применительно к вашему бизнесу.
Как читать эту книгу
Сначала прочитайте общую часть. Она поможет отличить бизнес от полезного эксперимента и понять расчёты в пятидесяти разборах. Затем переходите к направлениям, близким вашему опыту. Для всех пятидесяти идей приведены схемы первой версии; пятнадцать разборов дополнены подробным запуском. Последняя часть посвящена продажам, эксплуатации и плану запуска. К ней стоит вернуться после выбора идеи.
Разборы устроены одинаково, чтобы их можно было сравнивать. В каждом названы покупатель и оплачиваемый результат, объяснена роль ИИ, описан минимальный продукт, приведены предположения о расходах и предложена проверка. Номер идеи используется в указателях и рабочих примерах. Он не означает место в рейтинге доходности.
Предлагаемые бюджеты относятся к небольшому пилоту при наличии компьютера и необходимой квалификации у основателя. Покупка оборудования, постоянная команда, большой архив и сложные интеграции могут существенно увеличить расходы. Потраченное время основателя тоже стоит денег: в экономике заказов оно оценено отдельно.
Часть первая Как выбрать и проверить бизнес
Глава 1 За что покупатель платит
Представьте небольшую оптовую компанию. Сотрудники получают заявки в письмах, файлах и голосовых сообщениях. Одни покупатели указывают внутренние артикулы, другие пишут разговорные названия. Менеджер собирает заказ вручную и уточняет непонятные позиции. Идея «внедрить ИИ» слишком широка. Предложение «подготовить черновик заказа из входящего письма с указанием спорных позиций» уже можно проверить.
Работа покупателя имеет начало и конец. На входе находится письмо, фотография, таблица или разговор. На выходе должен появиться документ, решение или действие. Между ними есть задержка, стоимость труда и вероятность ошибки. Найдите этот промежуток. Чем яснее он описан, тем проще показать пользу пилота.
Покупатель и пользователь могут быть разными людьми. Менеджер хочет удобную форму, руководитель отдела оценивает скорость обработки, владелец оплачивает проект. Если обсуждать только интерфейс с менеджером, легко получить заинтересованность без договора. Узнайте, кто распоряжается бюджетом, кто отвечает за результат и кто будет пользоваться системой ежедневно.
Спрос следует отличать от интереса к технологии. Человек может охотно посмотреть демонстрацию и попросить доступ, потому что это любопытно. Готовность передать данные, согласовать критерии и оплатить небольшой эксперимент говорит больше. Самый полезный ранний вопрос: «Как вы решали эту задачу в последний раз?» Ответ раскрывает реальные действия, а не пожелания.
У идеи должны быть конкуренты. Это может быть другая программа, сотрудник, подрядчик или привычная таблица. Если покупатель сегодня спокойно обходится без решения, именно это и есть конкурент. В презентации объясните, что изменится по сравнению с текущей работой и сколько усилий потребуется для перехода.
Первая формулировка предложения может занимать одно предложение: «Помогаем [покупателю] получать [проверяемый результат] из [исходных материалов] за [срок] с [границей ответственности]». Для оптовика граница выглядит так: сотрудник утверждает заказ перед отправкой поставщику. Она снижает риск и делает пилот управляемым.
Упражнение. Опишите одну работу будущего покупателя, не используя слова «нейросеть», «автоматизация» и «инновация». Затем запишите объём за неделю, текущий способ выполнения и стоимость задержки. Если эти данные неизвестны, следующим действием будет интервью, а не разработка.
Глава 2 Три способа начать
Первый способ — выполнять услугу с помощью ИИ. Клиент передаёт материалы, вы обрабатываете их и проверяете результат. Так можно начать подготовку каталогов, расшифровку записей или анализ отзывов. Покупатель получает готовый результат, основатель наблюдает реальные ошибки и выясняет, что удаётся стандартизировать.
Недостаток услуги состоит в зависимости от труда исполнителя. Если каждый заказ требует нового согласования, исследования и большого количества правок, производительность быстро упирается в часы. До разработки платформы выделите повторяющийся шаг. Возможно, выгоднее специализироваться на одном типе документов, чем обслуживать любые запросы.
Второй способ — внедрять решение в работу компании. Вы берёте оплату за настройку, интеграцию и поддержку. Примеры: поиск по базе знаний, обработка звонков или подготовка заказов для учётной системы. Здесь важны права доступа, формат данных, обучение сотрудников и поведение системы при сбоях. Стоимость самой модели может оказаться небольшой частью проекта.
Внедрение удобно продавать по этапам. Сначала обследование процесса и тест на образцах. Затем ограниченный пилот. После приёмки — расширение и регулярная поддержка. Каждый этап имеет собственный результат. Такое деление позволяет заказчику остановиться, а исполнителю не финансировать большой проект на основании устного интереса.
Третий способ — создавать подписной продукт. Несколько клиентов пользуются общей системой, оплачивая месяц, пользователя или объём обработки. Преимущество возникает, когда подключение следующего покупателя требует меньше труда. Если каждый новый клиент нуждается в отдельной разработке, вы пока строите компанию по внедрению, хотя интерфейс может выглядеть как массовый сервис.
Подписка требует работы, которой не видно на демонстрации: выставления счетов, управления лимитами, восстановления данных, поддержки и отмены услуги. Появляются клиенты с разными объёмами и ожиданиями. Проверять такую модель следует на узком сегменте. «Для всех предпринимателей» плохо подходит для первого продукта.
Переход между способами полезно делать по фактам. Вы оказали десять похожих услуг, нашли повторяющиеся входные данные, договорились о качестве и получили повторные заказы. Теперь есть основания автоматизировать обработку. Если повторных заказов нет, программная оболочка обычно не исправляет причину.
Глава 3 Какие инструменты понадобятся
Языковая модель умеет работать с текстом: выделять сведения, группировать обращения, готовить черновики и объяснять найденные фрагменты. Она может ошибиться, даже когда отвечает уверенно. Поэтому продукт должен соединять модель с источниками, проверками и интерфейсом, в котором человек понимает происхождение ответа.
Для российских проектов можно рассматривать отечественные облачные сервисы. Документация Yandex AI Studio описывает создание приложений на генеративных моделях; GigaChat предоставляет API для интеграций. API — программный способ отправлять запросы из вашего продукта и получать результаты. Это отличается от ручной работы в пользовательском чате. Условия оплаты, доступа и использования нужно проверять для конкретного аккаунта. [2, 3]
Бесплатный режим GigaChat API по опубликованным условиям предназначен для личного некоммерческого использования; коммерческое применение связано с приобретением платного пакета. Наличие бесплатной демонстрации не подтверждает право продавать результаты. Проверяйте соглашение каждого выбранного сервиса, включая изображения, голоса и программные компоненты. [2]
Распознавание речи преобразует запись в текст. Синтез речи делает обратную работу. Эти технологии полезны для протоколов, анализа звонков и озвучивания учебных материалов. Документация SpeechKit описывает оба направления. Качество на шумной записи и профессиональной лексике следует проверить отдельно: название технологии не гарантирует нужную вам точность. [4]
OCR означает распознавание текста на изображениях. Оно позволяет извлечь сведения из сканов и фотографий. В документации Vision OCR есть отдельный сценарий распознавания таблиц. После распознавания всё равно нужны проверки чисел, единиц измерения и структуры: перепутанная колонка может оказаться дороже нескольких пропущенных слов. [5]
Поиск с последующим формированием ответа часто называют RAG. Сначала система находит фрагменты документов, затем передаёт их модели вместе с вопросом. Такой подход подходит для базы знаний и технических инструкций. В AI Studio описаны поиск по файлам и индексы для подобных сценариев. Ссылка на документ облегчает проверку, но сама по себе не подтверждает правильность вывода. [6]
Локальная модель запускается на вашей инфраструктуре. Это может быть полезно при особых требованиях к данным, но потребует настройки, оборудования и обслуживания. Проверяйте лицензию конкретной модели и конкретной версии. Например, карточка Qwen3-4B указывает лицензию Apache 2.0; переносить это условие на все модели с похожими названиями нельзя. [7]
Для прогнозов и компьютерного зрения часто понадобятся специализированные модели. Языковая нейросеть не заменяет систему учёта и статистический расчёт. Простая сезонная модель может оказаться сильнее сложной нейросети на небольшом наборе данных. Сравнение с простой альтернативой обязательно: покупатель оплачивает результат, и лишняя сложность увеличивает обслуживание.
Первый набор инструментов должен быть коротким. Хранилище исходных данных, способ обработки, таблица контроля результатов и средство выдачи клиенту. Чем больше внешних сервисов соединено, тем труднее искать причину ошибки. Для пилота особенно полезно сохранять исходник, результат и отметку проверяющего в одной понятной структуре.
Глава 4 Данные и российские условия работы
До получения первого файла выясните, что именно в нём содержится. В товарном каталоге могут быть сведения только о продуктах. В записи разговора — имена, телефоны, адреса и детали заказа. Корпоративная инструкция может содержать коммерческую тайну. Для разных материалов нужны разные правила обращения.
Российский закон о персональных данных устанавливает требования к обработке, а также отдельные правила для локализации и трансграничной передачи. Эти вопросы нельзя решить одним пунктом «клиент согласен». Определите роли сторон, основания обработки, используемые системы и необходимую документацию. Перед внедрением проверьте действующую редакцию закона и требования применительно к своему процессу. [8]
Практически это означает необходимость составить схему движения данных. Откуда они поступают, где сохраняются, кто имеет доступ, каким поставщикам передаются и когда удаляются. В схему включайте промежуточные файлы, резервные копии и журналы. Именно в этих местах сведения часто остаются после окончания пилота.
Обезличивание нужно проверять, а не объявлять по факту удаления фамилии. В документе могут остаться должность, адрес, редкое событие или номер договора, по которым человека можно определить. Для демонстрации на раннем этапе проще использовать специально подготовленные учебные материалы. Для проверки качества на реальном процессе потребуется отдельное согласованное основание.
Не обещайте клиенту, что отключение одной настройки исключает любое хранение данных. Например, политика AI Studio различает сервисные логи, аудит, трассировку и данные работы API. Отключение логирования для улучшения качества не отключает все остальные механизмы. Нужно читать условия выбранного сценария и проверить фактические настройки. [9]
У каждого клиента должен быть отдельный доступ и отделённые данные. Поиск по документам одной компании не должен выдавать фрагменты другой. Проверяйте этот случай специально. Разделение каталогов само по себе не помогает, если в программе перепутаны идентификаторы или общая база не фильтрует права.
Изображения, записи и тексты тоже требуют проверки прав. Клиент должен иметь основания передать их для обработки, а исполнитель — использовать выбранные инструменты. Для клонирования голоса или узнаваемого изображения человека получите необходимые разрешения и согласуйте область использования. Коммерческая лицензия сервиса не заменяет права на исходный материал.
В вопросах оформления бизнеса выбирайте режим под фактическую деятельность. ФНС описывает НПД с ограничением годового дохода 2,4 млн рублей и запретом на работников по трудовым договорам; существуют и другие ограничения. Поэтому пример «начните как самозанятый» не подходит автоматически для любого проекта из книги. Для команды, перепродажи и сложных договорных схем выбор следует проверять отдельно. [1]
Договор пилота должен определять материалы, объём работы, срок, критерии приёмки и обращение с данными. Укажите, какие решения остаются за человеком. Обещание полной замены специалиста может создать ответственность, которую продукт не способен обеспечить. Особенно осторожно формулируйте услуги в медицине, праве и финансах.
Глава 5 Как считать экономику
В каждом разборе есть расчётная единица: заказ, пакет, месяц обслуживания или пилот. Цена этой единицы является гипотезой. Прямые затраты включают обработку ИИ, связанные расходы и проверку человеком. Время основателя учитывается по условной ставке 1 000 рублей в час, если не указано иное. Это способ увидеть стоимость труда, а не рекомендация о зарплате.
Разность между ценой и прямыми затратами в книге называется вкладом в покрытие расходов. Из него ещё оплачиваются постоянные расходы, привлечение клиентов, налоги и другие обязательства. Поэтому его нельзя считать чистой прибылью. В технических проектах необходимо отдельно оплачивать обслуживание, даже если запросы к модели стоят немного.
Рассмотрим учебный заказ за 20 000 рублей. Обработка и хранение стоят 2 000 рублей, проверка занимает шесть часов, то есть 6 000 рублей по принятой ставке. Прямые затраты составляют 8 000 рублей, вклад — 12 000 рублей. При постоянных расходах 24 000 рублей два таких заказа покроют только эту статью. Для оплаты налогов, продаж и резерва понадобится дополнительный объём.
Если клиент просит ещё четыре часа правок без доплаты, вклад уменьшается до 8 000 рублей. Три заказа вместо двух потребуются для покрытия тех же 24 000 рублей. Поэтому границы пакета, формат исходников и число итераций — часть экономики. Они важнее небольшой экономии на токенах.
Токен — единица, которой сервис измеряет объём обработки текста. Точное количество зависит от текста и модели. Для бюджета полезнее сделать пробную обработку репрезентативной партии и посмотреть фактическое потребление. Длинные документы, повторные запросы и сохранённая история диалога могут изменить расход. Не переносите стоимость одного короткого запроса на весь будущий сервис.
Строки затрат в разборах — сценарные бюджеты, а не тарифные предложения поставщиков ИИ. В приложении 8 показано, как отделить расход модели от полной стоимости заказа.
Учитывайте одновременно деньги и время. Покупатель может оплатить счёт через месяц, а обработку и подрядчика придётся оплатить сегодня. На бумаге проект имеет положительный вклад, на счёте возникает нехватка средств. Для пилота согласуйте предоплату или этапы и держите запас на задержку платежа.
Стоимость привлечения клиента считайте по всему процессу. Если вы потратили 12 часов на поиск, переговоры и демонстрации и получили один заказ, труд продаж стоит 12 000 рублей по условной ставке. Первый заказ с вкладом 10 000 рублей эту работу не покрывает. Повторная продажа может улучшить результат, однако повторяемость нужно подтвердить.
Подписные проекты требуют другого расчёта. Из месячной оплаты вычитайте обслуживание конкретного клиента, инфраструктуру и обработку. Затем сравнивайте вклад за срок пользования с расходом на привлечение и подключение. Не закладывайте в план многолетнюю подписку, если пока знаете только результат первого месяца.
У пилотного бюджета есть предел. В разборах указаны ориентиры расходов на проверку, но ваши оценки могут отличаться. Составьте собственную смету и решите заранее, при каком результате эксперимент прекращается. Купленный сервер не является аргументом продолжать идею, если покупатель не получает ценности.
Глава 6 Как провести платную проверку
Сначала выберите узкий сегмент. «Компании с документами» слишком широко. «Поставщики строительных материалов, получающие заявки в таблицах и письмах» позволяет искать покупателей и готовить похожие демонстрации. Узкий старт упрощает разговор: вы понимаете словарь клиента и типовые затруднения.
Проведите восемь–двенадцать интервью с представителями сегмента. Это рабочий ориентир, который помогает увидеть различия; он не является статистическим доказательством спроса. Спрашивайте о последнем случае, частоте, последствиях и существующем способе решения. Попросите показать пример, если человек имеет право его передать.
После интервью подготовьте пилот с ограниченным объёмом. Для документов это может быть одна партия, для поиска — один раздел базы знаний, для прогноза — одна товарная группа. Опишите критерий полезности до обработки. Иначе после демонстрации обе стороны будут выбирать удобные цифры и спорить о результате.
У пилота должны быть исходная точка и сравнение. Сколько времени занимала ручная работа, какие ошибки встречались и как определяется готовность результата. Сравнивайте одинаковые объёмы и условия. Нельзя считать ускорение доказанным, если нейросеть обработала простые примеры, а человеку достались трудные.
Разделите материалы для настройки и материалы для итоговой проверки. Если вы многократно исправляли систему на одной партии, результат на ней будет выглядеть лучше. Отложенная партия показывает, что произойдёт на следующих заказах. Для сезонных прогнозов разделение проводят по времени, чтобы будущие данные не попадали в обучение.
Продавайте пилот с конкретным содержанием: объём, срок, цена, результат, число правок и способ остановки. Оговорите, что расширение не входит в стоимость. Покупатель должен понимать, что именно получит, а вы — сколько часов можно потратить. Бесплатная помощь знакомому может научить работе, но не подтверждает платёжеспособность рынка.
После выполнения спросите не только «понравилось ли», но и «что изменилось в процессе». Получите решение о следующем заказе. Иногда результат качественный, однако компании он нужен один раз в год. Это может быть хорошей проектной услугой и слабой подпиской. Меняйте модель оплаты под частоту задачи.
Остановить идею разумно, если материалы недоступны, ручная проверка съедает весь вклад или покупатель не готов выделить ответственного сотрудника. Можно сузить задачу и повторить эксперимент. Продолжать без изменения условий стоит лишь тогда, когда вы понимаете, какой новый факт хотите получить.
Упражнение. Составьте одностраничное описание пилота и покажите его человеку, который не участвовал в обсуждении. Попросите пересказать результат, срок и ограничения. Если он не смог, сначала исправьте предложение. Разработка не компенсирует непонятную продажу.
Часть вторая Пятьдесят бизнесов
Перед вами направления для проверки, а не готовые гарантии дохода. У каждого есть отдельная работа покупателя и собственный способ измерить результат. Расчётные цены и расходы в рублях приведены для описанного небольшого объёма; условия НДС, налоги, постоянные расходы и затраты продаж в них отдельно не рассчитаны. Учёт труда проверяющего позволяет сравнивать модели между собой.
Стартап 1 Подготовка товарных каталогов
Покупатель и результат
Поставщик получает прайс-листы от нескольких производителей и переносит товары в интернет-магазин. Названия, единицы измерения и характеристики написаны по-разному. Вы продаёте подготовленную партию карточек по согласованной структуре. Подходящий первый покупатель — компания с регулярным обновлением ассортимента и сотрудником, который сегодня исправляет сведения вручную.
Роль ИИ
Модель извлекает характеристики, приводит названия к принятому формату и предлагает категории. Правила проверяют обязательные поля, единицы и допустимые значения. Для каждой характеристики хранится источник. Если мощность отсутствует в прайсе, система оставляет поле пустым. Сгенерированное описание не должно добавлять свойства, которых поставщик не подтвердил.
Первая версия и бюджет
Начните со ста товаров одной категории. Получите образец правильной карточки и таблицу допустимых значений. Подготовьте результат в файле для загрузки, без интеграции в магазин. Лимит эксперимента 20–40 тысяч рублей предполагает готовый компьютер и самостоятельную настройку. Сложные документы и оплачиваемая помощь разработчика потребуют отдельной сметы.
Расчётная экономика
Гипотеза цены — 15 тысяч рублей за сто карточек. Обработка и сопутствующие расходы — 1 тысяча, проверка и согласование — шесть часов, или 6 тысяч. Вклад составляет 8 тысяч рублей. При двенадцати часах проверки он упадёт до 2 тысяч. Поэтому измеряйте труд на сложных товарах до обещания фиксированной цены.
Первые клиенты
Ищите поставщиков с большим числом неполных карточек и доступными деловыми контактами. Покажите небольшой пример на разрешённых исходниках и предложите оплачиваемую партию. Не оценивайте сотрудников клиента: обсуждайте задержку обновления каталога. Повторный заказ возникает, когда компания получает новые прайсы, а ваш формат уже совместим с её системой.
Проверка и рост
Заранее определите долю карточек, которые принимаются без исправлений, и отдельно проверяйте критические характеристики. Ошибка в размере или совместимости важнее красивого текста. Для роста сохраняйте словарь каждой категории и историю исправлений. Если исходники постоянно противоречат друг другу, предложите отдельную услугу сверки данных вместо ускоренного массового заполнения.
Схема первой версии
Создайте таблицу с полями «исходная строка», «артикул», «название», «единица», «характеристика», «источник», «статус проверки». Модель получает одну позицию и разрешённый словарь, возвращая заполненные поля или отметку «нет данных». Формулы проверяют единицы и обязательные размеры; редактор утверждает строку. Начните с ручного переноса ответа в таблицу, затем поручите разработчику повторяемую обработку. Проверочный набор включает разные обозначения одного размера, пустую характеристику и противоречивые источники. Сравнивайте время до принятой карточки, включая исправления, с обычным вводом.



