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

Гораздо интереснее другой вопрос:

Что произойдет, если ИИ станет не дополнительной функцией приложения, а одним из основных механизмов реализации его поведения?

Именно вокруг этого вопроса возникает концепция AI-native applications.

Она принципиально отличается как от классической разработки, так и от AI Integration — добавления ИИ-возможностей в уже существующее приложение.

Три подхода

Классическое приложение

В традиционной разработке поведение системы заранее определяется кодом.

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

ввод > заранее определенный рабочий процесс > бизнес-логика > результат

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

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

Но есть и цена: разнообразие реального мира приходится последовательно превращать в программный код.

AI Integration

Второй подход — встроить ИИ в существующую архитектуру.

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

Код по-прежнему определяет, что и когда должно произойти, а ИИ выполняет отдельную интеллектуальную функцию.

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

AI-native

AI-native приложение строится иначе.

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

Например, пользователь сообщает бухгалтерской системе: «Купили для офиса ноутбук за 180 тысяч рублей, оплатили с расчетного счета. Вот УПД».

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

После этого формируется каноническое бизнес-событие:

приобретение актива:
 > поставщик 
  > объект 
   > стоимость 
    > дата 
     > документы 
      > оплата

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

ИИ работает со смыслом, неопределенностью и контекстом, а код работает с тем, что должно быть точным, воспроизводимым и проверяемым.

В чем принципиальная разница? Различие трех подходов можно свести к одному вопросу: где находится рабочий процесс:

	Классическое приложение	AI Integration	AI-native
Основной рабочий процесс	В коде	В коде	Частично формируется ИИ
Роль ИИ	Нет или минимальна	Отдельная функция	Один из основных механизмов поведения
Новый сценарий	Обычно требует разработки	Обычно требует разработки	Иногда может быть собран из существующих способностей
Интерфейс	Формы, меню, операции	Формы + ИИ-функции	Может быть основан на намерениях пользователя
Работа с неизвестным входом	Ограничена	Локально возможна	Является частью архитектуры
Детерминизм	Высокий	Высокий вокруг ИИ-функции	Требует специальных границ и контроля
Основной источник сложности	Код и рабочий процесс	Код + ИИ	Доменная модель, знания, способности (tools), оценка, политики

Если сформулировать совсем кратко:

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

Меняется сама единица разработки

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

Например:

Если пользователь получил документ X, выполни A, затем B, потом C.

AI-native разработка смещается в сторону создания capabilities — доступных системе способностей.

Например:

• прочитать документ;
• найти банковскую операцию;
• определить контрагента;
• проверить договор;
• классифицировать событие;
• обратиться к нормативной базе;
• запросить недостающую информацию;
• произвести расчет.

ИИ может комбинировать их в зависимости от конкретной ситуации. Разработчик мог никогда не реализовывать специальный сценарий:

«Пользователь прислал чек через три недели после покупки, оплата прошла корпоративной картой, а поставщик отдельно прислал УПД». Но система потенциально способна самостоятельно построить цепочку:

прочитать чек > определить поставщика > найти платеж > найти УПД > сопоставить документы > определить событие > запросить недостающую информацию

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

Стоимость разнообразия

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

В AI-native архитектуре часть этого разнообразия может поглощаться способностью модели понимать смысл, а не конкретную форму представления. Если система уже знает хозяйственное событие «приобретение услуги», новый внешний вид документа не обязательно требует нового рабочего процесса. AI может распознать в незнакомом представлении уже известный смысл. Это свойство можно назвать смысловое обобщение (semantic generalization). Именно здесь появляется потенциально принципиальная экономическая разница:

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

Меняется пользовательский интерфейс

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

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

В результате основной интерфейс может становиться существенно проще. Вместо:

меню > документ > вид операции > форма > поля > проведение

пользователь сообщает: «Вот что произошло». Система самостоятельно обрабатывает нормальный сценарий и обращается к человеку только при возникновении неопределенности. Хороший AI-native интерфейс поэтому может быть основанным на исключениях (exception-driven):

Обработано автоматически: 283 операции.
Требуют внимания: 3.

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

Меняется жизненный цикл

AI-native не обязательно делает создание продукта дешевым. Сложность скорее меняет форму.

В классической системе значительную часть затрат создают:

• бизнес-логика;
• frontend;
• многочисленные рабочие процессы;
• интеграции;
• тестирование.

В AI-native появляются другие статьи:

• модель предметной области (domain model);
• база знаний (knowledge base);
• управление контекстом (context management);
• оркестровка агентов (agent orchestration);
• реестр способностей (tool registry);
• маршрутизация запросов к множеству моделей (model routing);
• система ограничений (guardrails);
• управление доверием (confidence management);
• наблюдаемость (observability);
• оценка достоверности (evaluations).

Особенно сильно меняется тестирование.

Классический код можно проверять привычными модульными и интеграционными тестами. ИИ-компонент необходимо проверять еще и на большом наборе реальных ситуаций (eval corpus). Фактически версия продукта начинает определяться не только кодом, а сочетанием: версия кода + версия модели + версия промпта + версия знаний + версия правил + версия способностей.

После изменения любого из этих компонентов необходимо убедиться, что поведение системы не ухудшилось.

Меняется экономика продукта

Классическое ПО обычно имеет высокую стоимость разработки, но очень низкую стоимость выполнения отдельной операции. После того как бизнес-логика написана, ее выполнение процессором стоит практически ничего. AI-native переносит часть затрат из разработки в среду исполнения (runtime). Каждое обращение к модели имеет стоимость.

Поэтому упрощенно:

• Классическое приложение — высокие затраты на разработку, низкие затраты во время исполнения (runtime cost).
• AI-native — потенциально меньшие затраты при изменениях, но более высокие затраты во время исполнения.

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

Где накапливается ценность вендора?

Может показаться, что главным активом AI-native компании является используемая LLM.

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

Предметная модель

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

Формализованные правила

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

База знаний

Не просто документы для RAG, а структурированное знание о предметной области, связанное с типами ситуаций, правилами и условиями их применения.

Корпус реальных ситуаций

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

• исходные данные;
• правильная интерпретация;
• ожидаемый результат;
• потенциальные ошибки;
• вопросы, которые следовало задать.

Такой набор становится одновременно показателями для сравнения (benchmark), набором регрессионных тестов (regression suite), данными для обучения (training data) и инструментом оценки новых моделей. Конкурент может получить ту же LLM. Но он не сможет мгновенно получить накопленный за годы корпус реальных пограничных ситуаций.

История исправлений

Особенно ценны ситуации, в которых AI ошибся, а специалист исправил решение. Именно они показывают границу способности системы. Возникает накопительный цикл:

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

Это уже способно формировать устойчивое технологическое преимущество.

Где стоит искать задачи для AI-native

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

1. Есть много вариантов одной и той же задачи.
2. Входные данные плохо структурированы.
3. Между реальным миром и информационной системой сегодня стоит человек, который занимается интерпретацией.
4. При этом результат его работы можно проверить формальными правилами или объективными данными.

Хорошими кандидатами выглядят:

• бухгалтерский и налоговый учет;
• обработка первичных документов;
• договорная работа;
• закупки;
• страховые случаи;
• кредитный анализ;
• проверка на соответствие (compliance);
• внутренний аудит;
• техническая поддержка;
• обработка клиентских обращений;
• регламентированная отчетность;
• типовые юридические процессы;
• анализ корпоративных документов.

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

Именно этот слой смыслового преобразования (semantic translation layer) ИИ способен во многих случаях взять на себя.

Где AI-native применять не стоит

Обратная сторона принципа тоже важна.

Если задача:

• полностью формализована;
• имеет небольшое количество вариантов;
• легко реализуется алгоритмом;
• требует строгого детерминизма;
• очень дешева в вычислении,

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

AI—native оболочка поверх детерминированного ядра.

ИИ интерпретирует реальный мир. Детерминированное ядро выполняет то, что должно быть гарантированно правильным.

Заключение

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

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

Поэтому хороший вопрос для поиска AI-native продукта звучит не так: «Куда в нашей системе можно встроить AI?». А так: «Где сегодня мы вынуждены поддерживать огромное количество сценариев только потому, что программное обеспечение не способно понять смысл происходящего?»

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