AI-native стратегия: позиционирование продуктов на базе нейросетей

AI-native стратегия: когда AI — это не feature, а ядро ценности и цифровая рабочая сила

Рынок программного обеспечения B2B проходит стадию фальшивой интеллектуализации. Начиная с 2023 года, подавляющее большинство SaaS-продуктов спешно интегрировали вызов API к базовым языковым моделям (LLM), добавили кнопку «Сгенерировать текст», внедрили сайдбар с чат-ботом и громко объявили себя ИИ-компаниями. На деле это классический софт, где искусственный интеллект выступает лишь как маркетинговая надстройка, так называемый “AI-wrapper”, не меняющая фундаментальную архитектуру и бизнес-модель решения. Когда базовая языковая модель (GPT-4, Claude, Gemini) в очередной раз обновится, подешевеет или станет доступна через open-source аналоги, такая компания потеряет свое эфемерное конкурентное преимущество за один день.

AI-native стратегия в реалиях 2025–2026 годов — это принципиально иной, структурный подход. Это создание продукта, который физически и экономически не может существовать без искусственного интеллекта. В таких системах нейросеть — это не инструмент внутри пользовательского интерфейса, а само ядро бизнес-логики. Она принимает решения, управляет процессами, маршрутизирует задачи и автономно взаимодействует с внешним миром, превращая программное обеспечение из пассивного инструмента (software) в активного цифрового агента (agentic workflow).

Происходит фундаментальный сдвиг парадигмы: от продажи доступа к софту (SaaS) рынок переходит к продаже выполненной работы (Software-as-Labor).

Этот материал предназначен для CEO, руководителей продуктов, стратегов и маркетологов, которые пытаются найти твердое позиционирование на перегретом рынке ИИ. Вы поймете, как спроектировать продукт с настоящим защитным рвом (Data Moat), почему синтетические данные не спасают от конкурентов, как радикально перестроить ценообразование, когда ИИ лишает смысла подписку за рабочие места (смерть per-seat и переход к per-outcome), и как B2B-маркетинг должен адаптироваться к продаже не интерфейса, а гарантированного и измеримого бизнес-результата.

Суть сдвига: чем AI-native отличается от AI-as-a-feature

AI-native продукт перестраивает саму причину использования программного обеспечения. Если традиционный SaaS отвечает на вопрос «как пользователю удобнее и быстрее сделать свою работу?», то AI-native продукт отвечает на вопрос «как полностью исключить пользователя из цепочки выполнения этой работы?».

Разница между подходом AI-as-a-feature (ИИ как функция) и AI-as-a-core (ИИ как ядро) — это пропасть между эволюцией и революцией бизнес-процесса.

Модель AI-as-a-feature (Тупиковая ветвь для стартапов)

• Архитектура: Классическая реляционная база данных и CRUD-интерфейс, куда сбоку или поверх прикручен вызов LLM.
• Ценность: Незначительное ускорение рутинных операций. Например, автозаполнение полей в CRM-системе, суммаризация длинного треда в таск-трекере или генерация шаблона ответа в почтовом клиенте.
• Интерфейс: Много кнопок, сложных форм, дашбордов и настроек. ИИ прячется за одной из кнопок (условной “волшебной палочкой”) или живет в изолированном окне чата.
• Бизнес-модель: Классическая подписка за пользователя (per-seat).
• Заменяемость: Если серверы OpenAI или Anthropic упадут и ИИ отключится, продукт продолжит работать. Он просто станет менее удобным для человека, но базовый бизнес-процесс клиента не остановится.

Модель AI-as-a-core / AI-native (Архитектура агентов)

• Архитектура: Языковая модель (или ансамбль узкоспециализированных моделей) находится в самом центре маршрутизации. Она работает как оркестратор. Модель сама решает, какие традиционные функции (калькуляторы, базы данных, API внешних сервисов) вызвать для решения поставленной глобальной задачи.
• Ценность: Полное делегирование процесса. Продукт не «помогает» написать письмо. Он сам изучает контекст сделки в CRM, анализирует историю общения, пишет письмо, отправляет его в нужный момент, дожидается ответа, анализирует его и двигает сделку по воронке, подключая человека только в нештатной ситуации.
• Интерфейс: Зачастую невидимый (headless/zero-UI). Продукт работает в фоне, выдавая только конечный результат в привычные каналы связи (Slack, Telegram, email) или требуя согласования (Human-in-the-loop) через push-уведомления.
• Бизнес-модель: Оплата за бизнес-результат (Per-Outcome) или за потребление мощностей (Usage-based).
• Заменяемость: Без ИИ продукта не существует. Если отключить модели, продукт превращается в неработоспособный кусок кода.

Смежное понятие, от которого нужно бежать — LLM-wrapper (тонкая обертка над ИИ). Это продукты, которые вроде бы построены вокруг генеративного ИИ, но не имеют собственной ценности и proprietary-данных, кроме передачи промпта пользователя в API. Их легко скопировать за выходные силами двух Junior-разработчиков. Чтобы AI-native продукт стал устойчивым многомиллионным бизнесом, ему жизненно необходим защитный ров — Data Moat, который невозможно купить на открытом рынке.

Data Moat: Информационный защитный ров в 2025 году

В 2024–2026 годах концепция “Data Moat” эволюционировала от простого принципа «чем больше данных, тем лучше» к сложной стратегии, ориентированной на проприетарные результаты, глубокую интеграцию в рабочие процессы и замкнутые циклы обратной связи.

Поскольку базовые фундаментальные модели (foundation models) неизбежно коммодитизируются (становятся общедоступным сырьем, как электричество или облачный хостинг), конкурентное преимущество сместилось от самой модели к уникальным данным, которые используются для ее тонкой настройки (fine-tuning) или обеспечения контекста (RAG).

Формула защитного рва

Защитный ров AI-native продукта сегодня описывается формулой: Устойчивость бизнеса = (Проприетарные данные + Entity Resolution) × (Цикл обратной связи / HITL)²

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

4 типа защитимых данных в B2B SaaS

1. Business Outcomes Data (Данные о бизнес-результатах): Это золотой стандарт Data Moat. Это захват результата действия ИИ. Например, не просто текст сгенерированного sales-письма, а метрика: привело ли именно это письмо к назначенной встрече или продаже (Closed/Won)? Эти данные генерируются только как побочный продукт реальной экономической деятельности внутри вашего приложения. Пример: Gong анализирует миллионы часов реальных звонков сейлзов, связывая паттерны речи с итоговым закрытием сделок в CRM.

Human-in-the-Loop (HITL) Corrections (Корректировки экспертами): Каждый раз, когда профессионал (старший юрист, врач-диагност, опытный DevOps-инженер) исправляет галлюцинацию или ошибку вашего ИИ-агента, он предоставляет высокоценные данные “наземной истины” (ground truth), которых по определению нет в публичных моделях. Чем больше экспертов работает в вашем продукте, тем умнее он становится для всех остальных. 3. Workflow “Sawdust” (“Опилки” рабочих процессов): Анонимизированные, агрегированные паттерны использования, которые выявляют отраслевые бенчмарки и негласные правила.

Как долго обычно согласовывают договор аренды в ритейле? Какие пункты вызывают больше всего правок? Эта мета-информация позволяет ИИ предлагать предиктивные решения. 4. Entity Resolution (Разрешение сущностей): Способность системы глубоко связывать разрозненные точки корпоративных данных, которые общие модели не видят. Понимание того, что ООО “Ромашка”, “дочка Газпрома”, клиент ID-4421 и email roman@company.ru — это одна и та же экономическая сущность в контексте конкретного предприятия.

От “Big Data” к “Deep Data”

Тренд 2025 года — переход к “Vertical AI”. Небольшие, но гипер-специализированные наборы данных (например, исключительно судебная практика по арбитражным спорам в строительстве РФ) сейчас ценятся выше, чем петабайты общих текстов из интернета.

Агентам также требуется Process Moat — понимание того, как устроены внутренние согласования в конкретной отрасли. Модель может написать идеальный договор, но если она не знает, что в компании клиента этот тип договора сначала должен уйти в службу безопасности, а только потом финдиректору — агент бесполезен. Захват этих workflow-графов и есть часть рва.

Экономическая революция: Смерть Per-Seat и переход к Per-Outcome pricing

Десятилетиями SaaS-продукты продавались по модели «за рабочее место» (per-seat или per-user). Чем больше у клиента нанятых сотрудников, тем больше он платит вендору за CRM, ERP или таск-трекер.

Здесь возникает “Парадокс ИИ”. AI-native продукт выполняет работу сотрудников, автоматизируя целые отделы. Если вы продаете ИИ-агента, который заменяет 15 сотрудников первой линии поддержки, и берете плату «за 1 место агента» или «подписку 200$ в месяц», вы уничтожаете собственную выручку. Клиент уволит людей, сократит количество лицензий с 15 до 1, и ваша выручка упадет, хотя ценность (Value), которую вы принесли бизнесу, колоссально выросла (сэкономленный ФОТ).

В 2024-2026 годах мы наблюдаем масштабный переход индустрии от продажи “доступа к софту” к продаже “выполненной работы”.

Новые модели ценообразования:

1. Per-Outcome Pricing (Оплата за бизнес-результат): Клиент платит только за успешно выполненную задачу.
   • Примеры с рынка: Intercom запустил своего агента “Fin” с тарифом $0.99 за каждое успешно разрешенное обращение клиента без участия человека. Zendesk внедрил “Automated Resolution” (AR) с ценой около $1.50 - $2.00 за тикет. Стартап Chargeflow, автоматизирующий оспаривание чарджбеков, берет процент (например, 25%) только от успешно возвращенных продавцу денег.
2. Per-Action / Usage-Based (Оплата за действие): Оплата за вызов сложного агентного workflow. Например, Salesforce Agentforce переходит на тарификацию в $2 за каждое автономное действие агента, независимо от количества пользователей в системе.
3. Hybrid Agreements (Гибридная модель 2025 года): Большинство крупных enterprise-контрактов переходят на гибрид. Клиент платит фиксированную SaaS-подписку (Platform Fee) для покрытия расходов на хостинг и поддержку платформы + Outcome-based Fee (переменную часть) за работу ИИ-агентов.

Проблема атрибуции и OMA

Главный вызов модели Per-Outcome — доказать, что именно ваш агент добился результата. В 2025 году стандартом становятся Outcome Measurement Agreements (Соглашения об измерении результатов). Компании тратят месяцы на юридическое определение “успеха”. Например, для ИИ-поддержки успехом считается, если после ответа агента клиент не открывал новый тикет по этой же теме в течение 72 часов. Без четкого трекинга метрик переходить на эту модель нельзя.

Проблема доверия: Explainability и маркетинг гарантий

Ключевой барьер при продаже AI-native продукта в Enterprise-сегменте — не цена, а страх. Клиент (особенно корпоративный) панически боится отдать управление бизнес-процессами «черному ящику», который склонен к галлюцинациям. Маркетинг AI-native продукта — это на 90% маркетинг доверия и управления рисками.

Чтобы продукт покупали, архитектура, интерфейс и позиционирование должны строиться вокруг концепции Explainability (Объяснимость):

• Audit Trail (Журнал аудита цепочки рассуждений): Клиент должен иметь возможность кликнуть на любое действие агента и увидеть “Chain of Thought”. Почему агент предложил именно 15% скидки этому контрагенту? Система должна показать ссылку: «Основание: регламент продаж от 12.04.2024, раздел 3.1 + объем закупок клиента за год превысил 5 млн руб (ссылка на запись в 1С)».
• Confidence Scores (Индексы уверенности): ИИ не должен быть самоуверенным глупцом. Если запрос выходит за рамки обучающей выборки, система должна сигнализировать: «Уверенность в ответе 42%. В договоре выявлена нестандартная формулировка форс-мажора. Требуется эскалация на Senior-юриста».
• Guardrails (Жесткие программные ограничения): Нельзя позволять LLM принимать любые решения. Архитектура должна содержать детерминированные (if/else) ограничители. Например, «независимо от того, что сгенерировала нейросеть, скидка в API биллинга не может превышать 20%».
• Human-in-the-loop (HITL) интерфейсы: На критических узлах агент обязан формировать только черновик (Draft). Руководитель открывает дашборд риска, просматривает 10 подготовленных ИИ контрактов и нажимает “Approve all” или вносит правку в один из них (которая тут же улетает в базу для дообучения модели — тот самый цикл Data Moat).

Сквозной кейс: ИИ-агент для B2B-продаж сложного оборудования (Российские реалии)

Рассмотрим гипотетическую компанию «ПромСелл», создающую AI-native систему для первичных холодных продаж промышленного оборудования.

Традиционный подход (SaaS + AI-feature): «ПромСелл» делает классическую CRM. Недавно они добавили кнопку «Сгенерировать письмо с помощью ИИ». Менеджеры (SDR) всё так же руками ищут контакты ЛПР на Rusprofile, копируют ИНН, нажимают волшебную кнопку. ИИ пишет банальное: «Уважаемый Иван, мы лидеры рынка…». Менеджер копирует это в WhatsApp. Скорость отправки выросла, но конверсия упала до 0.5%, ЛПРы начали банить за шаблонный спам. ФОТ компании не сократился. Это провал.

AI-native стратегия (Агентный подход 2025 года): «ПромСелл» полностью пересобирает бизнес. CRM становится просто невидимым бэкендом. Интерфейс для пользователя — это мессенджер постановки задач и дашборд апрувов.

1. Архитектура и Data Moat: Загружена закрытая база из 200 000 успешных и провальных диалогов с главными инженерами заводов РФ за 10 лет. Агент обучен специфике возражений («работаем только по постоплате 90 дней», «нужен сертификат РМРС»). 2. Агентный RAG-процесс:
   • Агент №1 (Research) ежедневно автономно парсит ЕГРЮЛ, Контур.Фокус и площадки госзакупок. Находит сигналы: “Завод А вчера выиграл тендер на постройку цеха”. - Агент №2 (Enrichment) через сторонние API находит мобильный телефон технического директора.

• Агент №3 (Copywriter), учитывая Data Moat, пишет персонализированное сообщение. Не шаблон, а контекст: «Иван, добрый день. Вижу ваш завод взял подряд на цех в Туле. У нас на складе в Подольске есть фрезерные станки под ваши допуски по тендеру, можем отгрузить до 15 числа. Интересно?»
  • Сообщение уходит автоматически. Если ЛПР просит прайс, Агент №4 (Database) лезет в 1С, вытаскивает актуальные остатки, генерирует PDF спецификацию, отправляет и ставит в календарь Senior-менеджеру задачу “Позвонить клиенту, он горячий”. 3.

Outcome-based Pricing: «ПромСелл» больше не берет 2000 рублей за место в CRM. Они берут 15 000 рублей за каждого квалифицированного лида (SQL), которому агент успешно отправил спецификацию и согласовал созвон. Бизнес перевел постоянные затраты на младших сейлзов в понятный CAC (Customer Acquisition Cost).

Пошаговое внедрение AI-native стратегии в ваш продукт

Трансформация продукта под AI-native не делается за один-два спринта. Это стратегический пивот всего бизнеса.

Шаг 1: Поиск “Золотых сигналов” и аудит болей

Не пытайтесь автоматизировать всё подряд. Ищите процессы с высокой стоимостью рутинного человеческого труда и неструктурированными данными (документы, аудио, неформализованные переписки). Вопрос для старта: Где наши клиенты держат целые отделы людей только для того, чтобы читать текст, принимать бинарное решение и перекладывать данные из одной системы в другую?

Шаг 2: Проектирование Data Flywheel (Маховика данных)

До написания кода агентов, решите, как вы будете собирать данные для рва.

• Начните с создания бесплатного тула или SaaS с низкой ценой, единственная цель которого — заставить людей размечать данные.
• Очистите корпоративные базы от персональных данных (строгое соблюдение 152-ФЗ / GDPR).
• Разверните инфраструктуру Entity Resolution, чтобы ваши будущие агенты понимали связи внутри данных клиента.

Шаг 3: Мультиагентная архитектура и RAG

Современные системы не строятся на одном гигантском промпте. Используйте микросервисный подход для агентов: один агент планирует, второй ищет факты во внутренней векторной БД (Retrieval-Augmented Generation), третий пишет ответ, четвертый (агент-критик) проверяет ответ третьего на соответствие корпоративным политикам. Такая архитектура снижает вероятность галлюцинаций в десятки раз.

Шаг 4: Внедрение «Предохранителей» (Human-in-the-Loop)

Разработайте интерфейс согласования. Выкатывайте продукт в режиме “Copilot” (помощник, требующий подтверждения каждого шага), затем переводите в режим “Autopilot with oversight” (агент делает сам, человек смотрит логи), и только доказав надежность — в полный “Agentic” режим. Захватывайте каждую ручную правку пользователя для дообучения.

Шаг 5: Переход на Value-Based Pricing

Смените метрику, за которую вы выставляете счет. Перестаньте продавать функции, начните продавать измеримый ROI. Ваш маркетинг должен системно отрабатывать страхи: публикуйте whitepapers о том, как вы изолируете данные (on-premise решения для энтерпрайза), как работают ваши guardrails и какую финансовую ответственность вы несете за ошибки агента.

Метрики контроля AI-native продукта

Стандартные метрики эпохи Web 2.0 и SaaS (MAU, DAU, Session Length) здесь вредны. Если ваш AI-агент работает безупречно, показатель “Время, проведенное в приложении” (Session Length) должен стремиться к нулю. Пользователь поручил работу и ушел пить кофе.

Новые ключевые метрики (2025+):

1. Task Success Rate (Коэффициент успешности задач): Главная метрика (North Star). Процент сложных многошаговых задач, которые система выполнила от триггера до финального результата без вмешательства человека.
2. Cost per Outcome (Себестоимость результата): Юнит-экономика агента. Сколько токенов (LLM API costs), серверного времени и запросов к внешним базам было потрачено на выполнение одной задачи. Если ИИ тратит $3 на решение тикета, за закрытие которого клиент платит вам $1.50 — продукт убыточен, несмотря на рост выручки. Необходима постоянная оптимизация промптов, кэширование (semantic routing) и переход на более дешевые локальные SLM (Small Language Models) для рутинных шагов.
3. Time to First Action (TTFA): Скорость, с которой агент начинает приносить реальную пользу после интеграции в контур компании. AI-native решения должны давать отдачу в первый же день.
4. Human Intervention Rate (HIR / Коэффициент ручного вмешательства): Частота, с которой система вынуждена запрашивать помощь человека из-за низкой уверенности (Confidence Score) или фактической ошибки.
5. Data Flywheel Velocity (Скорость маховика данных): Сколько новых уникальных, размеченных человеком корректировок (HITL) ваша система собирает в неделю. Это измеритель глубины вашего конкурентного рва.

Типовые ошибки и антипаттерны

• Игнорирование приватности и безопасности. Отправка коммерческой тайны, финансовых отчетов и персональных данных B2B-клиентов через публичные API западных моделей (OpenAI) без анонимизации — прямой путь к потере контракта, штрафам регуляторов и репутационному уничтожению. Для серьезного Enterprise требуется использование локальных LLM (Llama 3, Qwen, Saiga) в закрытом контуре заказчика (on-premise).
• Использование LLM для детерминированных задач. Не заставляйте генеративную нейросеть считать налоги, применять формулы биллинга или извлекать ИНН по регулярному выражению (Regex). ИИ плох в точной математике. LLM должна быть оркестратором, который просто передает параметры в классический Python-скрипт калькулятора, а не пытается “сгенерировать” правильную сумму.
• Отсутствие финансовой ответственности (Accountability). Когда ИИ ошибается и выдает клиенту промокод на 90% скидки, стартап не может оправдаться фразой “ну это же нейросеть сгаллюцинировала”. Корпорации не покупают отговорки. Вы обязаны программно ограничить радиус поражения агента и прописать юридическую ответственность.
• Интерфейс ради интерфейса. Создание красивого дашборда с настройкой “температуры” генерации, выбора системного промпта и длины ответа — это перекладывание работы инженера на конечного бизнес-пользователя. B2B-клиенту нужны решенные проблемы, а не пульт управления андронным коллайдером. Скрывайте сложность под капотом.

Что почитать дальше

• Стратегия ценообразования: от SaaS к Per-Outcome
• Как построить устойчивое конкурентное преимущество (Moat)
• Маркетинг доверия: как продавать сложные B2B продукты энтерпрайзу
• Unit-экономика агентов: считаем Cost per Outcome и LLM-нагрузку

FAQ

Чем AI-native продукт фундаментально отличается от SaaS с интеграцией ChatGPT? SaaS использует ИИ как фичу для ускорения работы человека внутри интерфейса. AI-native продукт использует ансамбль ИИ-агентов как ядро (core) для полного замещения человека в конкретном процессе. Модель сама маршрутизирует задачи, пишет планы и дергает API. Без ИИ SaaS просто потеряет удобную кнопку, а AI-native продукт физически перестанет существовать.

Почему инвесторы требуют Data Moat и что это такое? Data Moat — это проприетарные данные и отраслевой контекст, накопленные вашим продуктом, которых нет у базовых моделей OpenAI или Google. Если продукт состоит только из красивого интерфейса и вызовов чужого API, его скопируют за месяц. Устойчивость дает замкнутый цикл (Flywheel): пользователи работают в системе, исправляют ошибки агентов, эти правки мгновенно улучшают RAG и дообучают локальные модели, делая продукт недосягаемым для новичков.

Как тарифицировать AI-native продукты, если клиенты увольняют сотрудников? Необходимо срочно отказываться от модели per-seat (оплата за пользователя). Если ваш софт сокращает персонал клиента, подписка за рабочие места убивает вашу выручку. Рынок переходит на Per-Outcome (оплата за результат: $1.5 за закрытый тикет, % от возвращенного долга) или Usage-based модели (оплата за количество действий агента). Вы продаете не доступ к софту, а выполненную работу (Software-as-Labor).

Как решить проблему галлюцинаций нейросетей в корпоративном секторе? Полностью искоренить их в генеративных моделях невозможно, но риск блокируется архитектурно. 1) Использование RAG: запрет модели “выдумывать” факты из головы, принудительная генерация ответа только на основе закрытой корпоративной базы. 2) Внедрение Guardrails: жестких алгоритмических лимитов на действия агента. 3) Human-in-the-Loop: обязательное участие человека-эксперта для апрува критических транзакций и решений агента.

Какие метрики использовать вместо MAU/DAU для оценки AI-продукта? Главная метрика — Task Success Rate (процент автономно выполненных задач без ручного вмешательства). Метрика юнит-экономики — Cost per Outcome (стоимость LLM-токенов на успешную задачу). Важно понимать, что метрика Session Length (время в приложении) в AI-native продуктах должна падать: идеальный агент решает проблему бизнеса без необходимости для пользователя долго сидеть в интерфейсе.