AI-native компания: как устроен бизнес на базе ИИ

AI-native компания меняет сразу 2 вещи: то, что обещает клиентам, и то, как выполняет работу. Модели и агенты изначально заложены в её устройство, а ответственность за результат остаётся у людей. Покупка подписок на ИИ-сервисы или добавление чат-бота сами по себе такого перехода не обеспечивают.

Практический смысл AI-native — в принципе проектирования бизнеса: прежде чем выстраивать компанию, нужно решить, какую работу может выполнять программа, на какие данные она должна опираться и в каких случаях обязан вмешаться человек.

Проверка источников: примеры компаний и технические рекомендации сверены с их собственными публикациями 25 октября 2026 года. Примеры сервиса обработки возвратов ниже — условные схемы организации работы, а не описания реальных внедрений.

Что такое AI-native компания и на чём она строится

AI-native компания с самого начала строит своё основное предложение для клиентов и операционную модель вокруг ИИ. Модель — это обученная система, которая по новым входным данным выдаёт прогнозы или другие результаты. Агент использует модель, чтобы выбирать шаги и выполнять действия через подключённые инструменты. Вместе они меняют и возможности компании, и организацию работы людей.

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

Contrary Research, исследовательское подразделение венчурной компании Contrary, относит к AI-native продукты, в которых ИИ играет центральную роль и в самом предложении, и в поддерживающей его инфраструктуре. Это взгляд инвестора на устройство продукта. В используемом здесь операционном определении есть дополнительное требование: как сам бизнес делегирует, проверяет и совершенствует работу. Подробный разбор Contrary Research

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

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

Для сравнения: магазин, сотрудники которого готовят ответы с помощью ИИ, вполне мог добиться полезного улучшения, не меняя при этом свою бизнес-модель.

Если ИИ лежит в основе продукта, это говорит об устройстве продукта. Это ещё не доказывает, что все подразделения компании строят работу вокруг агентов. Для такого вывода нужны отдельные сведения о внутренних процессах, полномочиях и порядке проверки результатов.

Как действующему бизнесу перейти к модели AI-native

Существующая компания может принять такую модель работы, не делая вид, что появилась вчера. «С самого начала» здесь означает с момента проектирования новой операционной модели. IBM прямо включает в своё определение действующие предприятия, которые существенно перестраивают бизнес вокруг данных и ИИ. Определение IBM

Чем AI-native отличается от AI-first

Эти термины полезны как рабочий словарь, но за ними нужно искать конкретные изменения. Harvard Business School Online разделяет приоритетное внедрение ИИ и построение бизнес-модели вокруг него. Такая терминология имеет смысл, только если помогает увидеть реальные решения. Объяснение HBS Online

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

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

Как устроить команду: за каждый результат должен кто-то отвечать

Полезное организационное изменение — это более чёткая ответственность за работу целиком. Начинать с предположения, что штат обязательно сократится на определённую величину, не стоит.

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

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

Инженер в AI-native компании связывает систему с реальной работой

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

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

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

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

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

Архитектура AI-native начинается с процесса, который можно проверить

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

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

В условном сервисе возвратов процесс мог бы выглядеть так:

1. 1

   Получить данные в пределах разрешённого доступа

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

2. 2

   Подготовить действие в заданных пределах

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

3. 3

   Назначить проверку с учётом последствий

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

4. 4

   Зафиксировать результат и обработать сбой

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

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

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

Если вы выбираете готовую платформу, после определения этих границ контроля переходите к руководству по ИИ-агентам для предприятий.

Когда компания продаёт выполненную работу, меняется бизнес-модель

Когда программа выполняет работу, оплата может взиматься уже не за доступ, а за использование или принятый результат. Это вариант устройства бизнеса, а не обязательное условие для названия AI-native.

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

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

Sierra, платформа агентов для взаимодействия с клиентами, описывает агентов, подключённых к данным компании и способных выполнять такие задачи, как возврат заказа. Это возможность продукта, заявленная поставщиком; для этой статьи её не тестировали. Описание продукта Sierra

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

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

Затраты на инференс входят в экономику оказания услуги

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

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

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

В руководстве по стоимости ИИ-агентов подробно разобрано планирование бюджета. Для нашего определения главное другое: с ростом использования могут расти и расходы на оказание услуги. Сокращение числа ручных шагов само по себе не повышает маржинальность.

Данные и оценка качества позволяют улучшать систему целенаправленно

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

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

Anthropic рекомендует начинать с 20–50 простых задач, составленных на основе реальных сбоев, а затем поддерживать этот набор по мере развития системы. Это рекомендуемая отправная точка для тестирования, а не универсальный размер выборки и не порог, после которого система считается готовой к промышленной эксплуатации. Рекомендации Anthropic по оценке качества

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

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

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

Храните только те данные, которые имеете право сохранять, ограничивайте доступ и обеспечьте пригодность записей для разбора инцидентов. Устойчивое преимущество даёт набор релевантных случаев с достоверными результатами и процесс, который превращает их в улучшения. Один лишь объём данных такого преимущества не создаёт.

Какие ожидания от AI-native компаний завышены

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

Маленькая команда ещё не означает эффективный бизнес

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

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

Зависимость от поставщика не ограничивается API модели

Программный интерфейс, или API, — это способ, которым одна программа обращается к другому сервису. Использовать распространённый формат взаимодействия полезно, но это не гарантирует, что другая модель будет вести себя так же.

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

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

Чтобы построить AI-native бизнес, не обязательно обучать фундаментальную модель — модель, рассчитанную на широкий круг задач. Но необходимо понимать, какие части продукта зависят от поставщика и что остаётся под вашим контролем при его смене.

Надёжность не сводится к убедительному ответу

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

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

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

С чего начать основателю, руководителю и разработчику

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

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

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

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

Частые вопросы об AI-native компаниях

Что такое AI-native компания?

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

Какие AI-native компании можно назвать ведущими?

Для слова «ведущие» нужен критерий. Собственные страницы Sierra показывают продукт, построенный вокруг агентов, и оплату за результат; собственные отчёты Anthropic — внутреннее делегирование задач агентам и контроль их работы. Это разные виды подтверждений, а не сравнительный аудит всей операционной модели этих компаний.

Что такое AI-native организация?

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

Какие 7 компаний лидируют в сфере ИИ?

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

В какую ИИ-компанию лучше инвестировать?

Этот термин описывает организацию работы и не помогает выбрать лучшую инвестицию. Он говорит о том, как устроен бизнес, а не о том, насколько привлекательна оценка его акций и устойчивы финансовые результаты.

Кто входит в «большую 4» в сфере ИИ?

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

Акции какой ИИ-компании резко вырастут?

По характеристике AI-native нельзя предсказать цену акций. Заявления о продукте и устройство операционной работы не дают оснований для такого прогноза.

Кто сейчас лидирует в области ИИ?

Сначала уточните задачу и критерий оценки. Возможности моделей, распространённость среди клиентов и надёжность работы — разные вопросы. Успех в одном из них не доказывает лидерство в остальных.

Какие 5 профессий сохранятся после внедрения ИИ?

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

За практическими рекомендациями по внедрению ИИ в бизнес подписывайтесь на рассылку.

Чек-лист: насколько ваша компания близка к AI-native

Используйте этот список для проверки подтверждений, а не для подсчёта баллов. Выберите основной рабочий процесс и для каждого утверждения отметьте: подтверждено, подтверждено частично или не подтверждено. Набор инструментов при неизменной организации работы тоже может быть полезным внедрением. Движение к операционной модели AI-native становится заметно, когда вместе меняются обещание клиенту, делегирование, экономика и процесс улучшений.

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

• Основное предложение: Мы можем назвать обещание клиенту, выполнение которого зависит от моделей или агентов, и объяснить, что придётся перестроить, если их убрать.
• Организация работы: Мы изменили распределение и выполнение задач, а не просто разрешили каждому пользоваться ИИ по своему усмотрению.
• Ответственность: За принятый результат отвечает конкретный человек, в том числе за исключения, общение с клиентом и восстановление после сбоев.
• Доступ к данным: Процесс получает актуальные данные, к которым разрешён доступ, а при их отсутствии останавливается или передаёт задачу на дальнейшее рассмотрение.
• Границы действий: Мы можем показать, какие действия выполняются автоматически, какие требуют одобрения и как права доступа обеспечиваются вне инструкций для модели.
• Проверка человеком: Проверяющие получают нужные данные и полномочия, а кто-то отслеживает нерешённые случаи и время ожидания.
• Правила оплаты: Единица тарификации соответствует тому, что мы можем измерить; порядок учёта неудачной, повторно открытой или оспариваемой работы задан явно.
• Экономика оказания услуги: Мы сопоставляем потребление ресурсов моделей, вспомогательные инструменты, проверки и доработки с принятыми результатами, учитывая и неудачные попытки.
• Оценка качества и изменения: Мы поддерживаем набор характерных случаев, проверяем предлагаемые изменения и превращаем разобранные сбои в конкретные улучшения.
• Непрерывность работы: Мы сохраняем пригодные к использованию правила, тесты и записи и можем объяснить, как продолжится критически важная работа, если модель или поставщик станут недоступны.