# Temadev Notes — Full Corpus **Publication:** Temadev Notes (https://notes.temadev.org) **Language:** Russian (ru) **Total notes:** 36 **Total words:** 86,105 **Last updated:** 2026-07-03 **Coverage:** AI agents, operating-layer architecture, B2B AI economics in Russia This file contains the complete published corpus of Temadev Notes. Intended for long-context AI ingestion and citation. --- ## Note 1: Telegram и WhatsApp как первичный B2B-интерфейс: что это меняет в архитектуре AI-контура **URL:** https://notes.temadev.org/2026/07/telegram-whatsapp-pervichnyy-b2b-interfeys-arkhitektura-ai.html **Published:** 2026-07-02 **Genre:** concept-piece **Tags:** telegram, whatsapp, b2b, ai-agents, russia, messenger-first, architecture, automation **Words:** 2123 **Summary:** Когда переписка в Telegram решает больше, чем CRM, архитектура AI-автоматизации должна это учитывать — и три ключевых узла в ней меняются принципиально. # Telegram и WhatsApp как первичный B2B-интерфейс: что это меняет в архитектуре AI-контура По данным Magnetto.pro, [44% малого и 32% среднего бизнеса в России](https://b2bpress.ru/telegram-dlya-b2b-trendi-instrumenti-i-luchshie-praktiki/) используют Telegram для коммуникации с клиентами — мессенджер входит в топ-3 инструментов B2B-продвижения в стране. Но статистика каналов — не главное. Главное — что в большинстве сегментов переписка в Telegram ведёт сделки конца в конец: обращение приходит туда, коммерческое предложение согласовывают там же, статус исполнения передают голосовым сообщением в тот же чат. CRM получает данные постфактум, если получает вообще. AI-контур, спроектированный вокруг CRM как первичной точки входа, описывает не ту реальность. Он предполагает, что клиент заполнил форму, форма ушла в CRM, CRM создала карточку, и уже оттуда всё начинается. Этот путь существовал до 2020 года. Сегодня он — частный случай, а не правило: большинство операционных B2B-взаимодействий начинается в мессенджере и там же остаётся. Это не просто изменение в канальной картине — это требование другой архитектуры. Когда мессенджер стал первичным операционным интерфейсом, проектировать AI-контур как надстройку над CRM — значит строить поверх не той точки входа. ## Рабочий интерфейс сместился, архитектура за ним не пошла Для значительной части российского B2B Telegram сегодня выполняет функцию, которую теоретически должна выполнять CRM: именно там живёт актуальный контекст отношений с клиентом. Там — история обсуждения условий сделки. Там — прикреплённые материалы и документация, отправленные в ходе переговоров. Там — голосовые сообщения с уточнениями, которые ни один менеджер не будет транскрибировать в карточку вручную. Там — финальная договорённость, зафиксированная двумя строчками текста вместо поля «Статус: Закрыто/Выиграно». [Разбор 25 российских B2B-каналов в Telegram](https://sdelaem.agency/blog/kak-vesti-telegram-kanal-v-b2b-25-primerov-iz-rossijskogo-biznesa/) описывает устойчивую картину как «полные циклы коммуникации внутри мессенджера без переключения на email или CRM»: компании ведут полные циклы коммуникации внутри мессенджера, не переключаясь на email или CRM как основное рабочее пространство. CRM получает данные для отчётности — туда вносят итоги после того, как решение уже принято. Это не означает, что CRM избыточна. Это означает, что она перестала быть первичным операционным слоем. Для автодилера сделка по конкретному автомобилю — обсуждение комплектации, согласование цены, договорённость о визите — происходит в том же чате, куда потом придёт ссылка на договор. Для логистической компании статус отправки и изменение условий согласовываются голосом в одном треде. CRM узнаёт об этих событиях позднее — если узнаёт. Проблема обнаруживается ровно тогда, когда компания начинает встраивать AI-автоматизацию. Стандартный подход звучит так: «настроим AI-агента, который будет работать с CRM». Агент смотрит в карточки, триггерится на смену статусов, формирует ответы на основе полей. Это разумная схема при одном условии: если CRM является источником правды о том, что происходит с клиентом. Если источник правды — тред в Telegram, агент смотрит не туда. ## Мессенджер в российском B2B: уже не маркетинговый канал, а операционная плоскость Кейс компании uForce — российский AI-сервис в B2B-сегменте — даёт конкретное измерение: [персонализированный аутрич к 1100 контактам в Telegram дал 303 ответа](https://workspace.ru/cases/b2b-lidogeneraciya-v-telegram-36-vstrech-za-4-mesyaca-dlya-rossiyskogo-ii-servisa/) (28,8% конверсии в ответ) и 36 встреч за четыре месяца. Примечателен не только результат, но и то, что весь цикл — от первого касания до назначения встречи — прошёл внутри мессенджера без переключения в email или звонок. Telegram стал не каналом первого контакта перед тем, как «настоящая сделка» переходит в другой инструмент, а самостоятельным пространством, где она разворачивается от начала до конца. [Обзор 12 B2B-каналов лидогенерации на vc.ru за 2025 год](https://vc.ru/marketing/2167607-12-osnovnyh-b2b-kanalov-dlya-privlecheniya-lidov-v-2025-godu) отмечает то же самое с другого угла: Telegram упоминается не только как рекламный инструмент, но и как пространство для голосовых переговоров, демонстраций через шеринг экрана, согласования документов. Весь цикл продажи умещается в одном мессенджере — это уже не исключение для нескольких прогрессивных команд, а описание операционной нормы. WhatsApp добавляет второй пласт: в дистрибуции, региональной торговле, среди небольших партнёров значительная часть обращений идёт именно там. [WhatsApp Business Cloud API](https://developers.facebook.com/docs/whatsapp/cloud-api) с 2022 года открыт для интеграций — бизнес принимает и отправляет сообщения через API так же, как обрабатывает HTTP-запросы. Технический порог для автоматизации там не выше, чем у email. Важное архитектурное ограничение: WhatsApp поддерживает 24-часовое клиентское окно — отвечать произвольным сообщением можно, пока клиент написал первым не более суток назад. После этого доступны только утверждённые шаблонные сообщения. Для AI-контура это означает другую логику: критично реагировать в нужное окно, иначе ответ становится формальным шаблоном, а не живым диалогом. Косвенный сигнал масштаба — рекламный рынок: [Forbes сообщал о росте стоимости рекламы в Telegram для IT-сегмента на 120%](https://www.forbes.ru/tekhnologii/544969-reklama-v-telegram-dla-it-biznesa-podorozala-na-120) за 2025 год. Когда рекламные бюджеты B2B растут такими темпами в конкретном канале, это сигнал не только о маркетинге — это сигнал о том, что туда переехали серьёзные операционные потоки, которые создают аудиторию. ## Три архитектурных узла, которые меняет мессенджер-первая схема Переход от CRM-first к messenger-first (архитектуре, ориентированной на мессенджер как первичную операционную плоскость) затрагивает три конкретных узла: точку приёма, модель контекста и логику маршрутизации. | Узел архитектуры | CRM-first | Messenger-first | |---|---|---| | Точка приёма | Форма / email → карточка | Вебхук мессенджера (JSON-событие в реальном времени) | | Время реакции | Часы (пока менеджер откроет CRM) | Секунды (триггер — само сообщение) | | Модель контекста | Структурированные поля карточки | Тред как рабочий контейнер (текст + голос + PDF) | | Логика маршрутизации | По полям (тип, регион, статус) | По содержанию (классификация намерения до карточки) | | Роль CRM | Операционное ядро | Backend-хранилище и учёт | **Точка приёма: вебхук вместо формы.** В CRM-ориентированной схеме обращение попадает в систему через форму или email: клиент заполняет поля, данные структурируются, создаётся карточка. В схеме, ориентированной на мессенджер, точка приёма — это вебхук. [Telegram Bot API](https://core.telegram.org/bots/api) транслирует каждое входящее сообщение как JSON-событие в реальном времени. AI-контур должен быть подписан на этот поток как на первичный источник, а не ждать, пока менеджер перенесёт переписку в карточку. Это техническое различие имеет прямой операционный эффект: время реакции сжимается с часов до секунд, потому что событие-триггер — не «менеджер открыл CRM» и не «кто-то нажал кнопку», а сам факт входящего сообщения. Для агентств недвижимости, торговых компаний, SaaS-поддержки, где скорость первого ответа прямо влияет на конверсию, разница ощутима. **Модель контекста: тред как рабочий контейнер.** В CRM-ориентированной схеме контекст клиента живёт в структурированных полях карточки: имя, статус, история задач, записанные примечания. В мессенджере контекст — это тред. Он неструктурирован, содержит смешанный контент (текст, голосовые сообщения, изображения, PDF), может тянуться несколько недель и отражает реальную историю принятия решений, которая редко попадает в поля CRM-карточки. AI-агент, работающий в мессенджер-первой схеме, должен уметь читать тред как единый рабочий контейнер: извлекать ключевые сущности (контакт, бюджет, срок, суть запроса), отслеживать, что уже обсуждалось, и не задавать клиенту вопрос, на который он ответил три сообщения назад. Это принципиально другая задача, чем работа со структурированными полями CRM-карточки. **Логика маршрутизации: по содержанию, а не по полю.** В CRM-ориентированной схеме маршрутизация определяется полями карточки: тип обращения → ответственный, регион → команда, статус → следующее действие. В мессенджере поля не заполнены — есть только текст. Маршрутизация должна происходить по содержанию сообщения: «хочу уточнить стоимость» → обработка ценового обращения; «вопрос по документам» → операционная поддержка; «когда свяжется менеджер» → постановка задачи на звонок. Это означает, что классификация намерения происходит до того, как создана CRM-карточка — на основе первых сообщений в треде. AI-слой между вебхуком и backend-системами несёт ответственность за это решение. Спроектировать его как надстройку над CRM не получится: CRM здесь появляется позже, как результат записи, а не как источник сигнала для агента. ## Что остаётся за CRM, когда мессенджер стал первичным? Архитектурный сдвиг к мессенджеру как первичной операционной плоскости не делает CRM избыточной — он меняет её функцию. В мессенджер-первой схеме CRM остаётся: — хранилищем исторических данных о клиенте: всё, что AI-слой извлёк из треда и структурировал, попадает туда на хранение; — системой учёта и отчётности: итог каждого взаимодействия фиксируется в карточке для руководителя и аналитики; — источником контекста для исходящих коммуникаций: перед автоматическим follow-up или плановым звонком агент поднимает историю именно из CRM; — интеграционной точкой с учётными системами и документооборотом — там, где нужна структура и доказательный след. Это разделение — хранилище фактов отдельно, слой понимания отдельно — мы разбирали отдельно в заметке [CRM хранит факты. Слой понимания живёт отдельно](https://notes.temadev.org/2026/05/ai-over-crm-intelligence-layer-pattern.html). Но CRM перестаёт быть первой точкой, через которую проходит обращение. Это место теперь занимает AI-слой на вебхуке мессенджера: принимает, классифицирует, обогащает контекстом из треда — и только затем записывает результат в CRM. Именно этот порядок и описывает мессенджер-первую схему: мессенджер → AI-слой → CRM/backend, а не обратный маршрут. Платформы автоматизации, встающие в эту логику — такие как [n8n](https://n8n.io) с его вебхук-триггерами или специализированные bot-фреймворки типа BotHelp — проектировались именно под этот поток: вебхук как стартовая точка, интеграции с CRM и backend-системами как исходящие, а не входящие. ## Три теста для тех, кто проектирует AI-контур Разрыв между CRM-first и messenger-first схемой проявляется в трёх прикладных проверках, которые полезно пройти до начала проектирования. **Тест первый: где фактически появляется обращение?** Отследите последние двадцать событий, которые стали реальными сделками или рабочими задачами. Откуда они пришли? Если больше двух третей из них начались с сообщения в Telegram или WhatsApp — первичная точка входа в AI-контуре должна быть там, а не в форме на сайте и не в email-интеграции CRM. Проектировать агента «под CRM» при таком распределении означает строить в стороне от реального потока. **Тест второй: где принимается решение?** Это отдельный вопрос. Даже если обращение пришло через мессенджер, решение может согласовываться в другом канале — на звонке, по email, на встрече. Но если и обращение, и согласование условий, и финальное «да» происходят в одном треде, AI-агент, не читающий этот тред, слеп к операционной реальности компании. Он работает с архивом, а не с живым контекстом. **Тест третий: как сейчас маршрутизируется входящий поток?** Если ответ — «менеджер читает и сам решает, куда переслать» — это не маршрутизация, это ручной процесс. AI-контур должен взять эту функцию: читать входящее сообщение, классифицировать намерение, направить в нужный сценарий или к нужному сотруднику. Реализуется это только тогда, когда AI стоит на вебхуке мессенджера и видит каждое сообщение как событие, а не ждёт, пока данные появятся в CRM-карточке. [Анализ B2B-контент-стратегий на Хабре](https://habr.com/ru/articles/943526/) формулирует деталь, применимую и к AI-контурам: «в B2B работают не просмотры, а доверие и глубина взаимодействия». Агент, встроенный в то пространство, где уже идёт живая коммуникация, создаёт значительно меньше трения, чем агент, требующий от клиента переключиться на новый канал или заполнить форму. Агент, встроенный в то пространство, где уже идёт живая коммуникация, создаёт значительно меньше трения, чем агент, требующий от клиента переключиться на новый канал или заполнить форму. Мессенджер-первая схема — это не техническое предпочтение, это следование за тем, где уже находится операционный поток. ## Сигналы 2026 года Два сигнала покажут, с какой скоростью мессенджер-первая схема станет операционным стандартом. Первый — темп развития API: Telegram [последовательно расширяет возможности для интеграций](https://core.telegram.org/bots/api), включая работу с бизнес-аккаунтами и обработку входящих в мультиагентных схемах. Если этот темп сохранится, техническая база для мессенджер-первой автоматизации к концу 2026 года станет ещё зрелее. Второй сигнал — появятся ли на рынке продукты, которые открыто позиционируют себя как «операционный слой для мессенджера», а не «интеграция мессенджера с CRM». Разворот в формулировке означает разворот в архитектурной логике. Когда такие продукты появятся массово, проектировочная норма сместится — и компании, выстроившие CRM-first AI-контуры, начнут перестраиваться. ## Главное - В российском B2B Telegram и WhatsApp стали первичным операционным интерфейсом: 44% малого бизнеса использует Telegram для B2B-коммуникации, и для большинства сегментов именно там разворачивается полный цикл сделки — от первого обращения до согласования условий. - AI-контур, ориентированный на CRM как первичную точку входа, отстаёт от операционной реальности: CRM получает данные постфактум, тогда как актуальный контекст сделки находится в треде мессенджера. - Мессенджер-первая схема меняет три узла: точку приёма (вебхук вместо формы), модель контекста (тред как рабочий контейнер вместо структурированных полей карточки) и логику маршрутизации (по содержанию сообщения, а не по заполненному полю). - CRM в этой схеме остаётся backend-хранилищем истории и учётной системой, но перестаёт быть операционным ядром: правильный маршрут — мессенджер → AI-слой → CRM, а не наоборот. - Три теста для проверки собственной архитектуры: где фактически появляются обращения, где принимаются решения, как маршрутизируется входящий поток — если ответ на все три «в мессенджере», первичная точка AI-контура должна стоять именно там. ## FAQ **Чем messenger-first архитектура отличается от CRM-first?** В CRM-first обращение проходит через форму или email и попадает в карточку, откуда триггерится агент; время реакции измеряется часами. В messenger-first точка приёма — вебхук мессендженра, который транслирует каждое входящее сообщение как JSON-событие в реальном времени; время реакции сжимается до секунд. CRM при этом не исчезает — она становится backend-хранилищем, а не операционным ядром. **Почему AI-агент «над CRM» не видит реальный контекст сделки?** Потому что для большинства B2B-сегментов актуальный контекст живёт в треде мессенджера: история обсуждения условий, голосовые уточнения, прикреплённые PDF. CRM получает только итог постфактум. Агент, который смотрит в поля карточки, работает с архивом, а не с живым диалогом. **Что меняет 24-часовое окно WhatsApp для архитектуры?** WhatsApp Business Cloud API разрешает отвечать произвольным сообщением только в течение 24 часов после сообщения клиента; дальше доступны лишь утверждённые шаблоны. Для AI-контура это означает приоритет на реакцию внутри окна — иначе диалог вырождается в формальный шаблон. **Какие три узла архитектуры перестраивает мессенджер-первая схема?** Точку приёма (вебхук вместо формы), модель контекста (тред как рабочий контейнер вместо структурированных полей) и логику маршрутизации (классификация намерения по содержанию сообщения до создания карточки, а не по заполненным полям). --- ## Note 2: AI-подписка через год: почему стоимость замены растёт быстрее цены **URL:** https://notes.temadev.org/2026/07/ai-subscription-switching-cost-12-months.html **Published:** 2026-07-01 **Genre:** concept-piece **Tags:** ai-подписка, переключательные издержки, b2b-ai **Words:** 2359 **Summary:** Покупатель платит ту же сумму, но к 12-му месяцу выкупает контур стоимостью в несколько месячных платежей — на этом стоит NRR 120%+ AI-нативных B2B. # AI-подписка через год: почему стоимость замены растёт быстрее цены В отчётах Harvey, AI-сервиса для юридических фирм, за 2025 год прозвучала цифра, которая обычно остаётся за периметром AI-дискуссий: net revenue retention 167% при firmwide adoption 90%+ у клиентов уровня Am Law 100. Это не история про рост клиентской базы — это история про одних и тех же клиентов, которые через год платят почти в 1.7 раза больше. Базовая цена подписки у Harvey, по [публичному разбору тезиса service-as-software у Foundation Capital](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) и в собственной коммуникации фирмы, при этом не выросла. Выросла стоимость замены: к 12-му месяцу клиент уже не может вынуть Harvey из рабочего контура, не переписав часть процессов. Это и есть структурный сюжет AI-сервиса по подписке. Цена остаётся прежней — стоимость воссоздания того же эффекта у другого поставщика к 12-му месяцу вырастает в 3–5×. Не потому, что исполнитель что-то поднял, а потому что внутри клиентского контура накопились три слоя, каждый из которых стоит времени и денег при попытке выйти. Эти слои — данные цикла «решение → исход», доменная схема представления вертикали и вшитые операционные регламенты — растут с накопительным эффектом (compounding): каждый следующий месяц добавляет к ним больше, чем предыдущий. ## Цена подписки и стоимость её замены — это разные кривые Классический разговор о подписке исходит из того, что цена и ценность контракта со временем должны сходиться. Поставщик берёт фиксированную сумму, клиент за неё получает фиксированный объём — оба знают условия. В AI-сервисе по подписке это допущение не работает уже на третий месяц. Поставщик берёт ту же сумму, но получает доступ к контуру, в котором накапливаются данные, а вместе с ними — структурная зависимость клиента от настроек агента, доступов и регламентов. Foundation Capital в [тезисе service-as-software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) формулирует это так: AI-услуга, встроенная в операционный поток клиента, переоценивается не по затратам поставщика и не по стоимости разработки, а по стоимости воссоздания того же эффекта другим контуром. Это сдвигает экономику подписки в сторону, которая редко обсуждается на этапе подписания. Покупатель платит за месяц работы. Через год он платит за месяц работы плюс невыплачиваемый, но реальный депозит — годовую историю контура, который к моменту попытки уйти стоит замены в несколько раз больше своей месячной цены. Фред Райхельд, автор классической работы Bain об экономике удержания, формулирует общий принцип: «Increasing customer retention rates by 5% increases profits by 25% to 95%». В AI-сервисе по подписке эта арифметика работает агрессивнее, потому что эффект удержания накладывается на эффект накопления данных. Каждый удержанный месяц не только продлевает контракт — он делает следующий месяц структурно более ценным для клиента. SaaStr в [разборе четырёх уровней prompt portability](https://www.saastr.com/the-4-levels-of-prompt-portability-why-some-ai-agents-will-hold-retention-and-most-wont/) показывает обратную сторону: AI-сервисы, у которых ценность сидит только в промпте, теряют клиентов быстрее, чем средний SaaS, потому что промпт мигрирует копированием. Удержание держится на том, что промпт скопировать можно, а накопленный контур — нет. ## Данные цикла «решение → исход»: чего нельзя унести Решение → исход — это пара записей о том, какое решение приняли (агент или человек после подсказки агента) в конкретной операционной ситуации, и какой исход это решение дало в течение часов или дней после. Это не лог транзакций и не история запросов — это связка «выбранное действие → измеренный результат», привязанная к контексту бизнеса. У такого слоя две особенности, которые отличают его от любых других «корпоративных данных». Во-первых, он возникает только в режиме реальной работы — его нельзя восстановить из CRM, из выгрузки 1С или из переписки. Во-вторых, он становится полезен только после нескольких сотен записей: ниже этого порога паттерн не отличается от шума. В практике B2B AI-агентов, которые работают как часть операционного контура, а не как ассистенты на стороне, первый порог переключательных издержек начинается около 50–100 записей таких пар — этого хватает, чтобы калибровка модели под клиента уже не была переносимой через простое копирование промпта. Второй порог — около 1000 событий в течение 90 дней — превращает накопленное в структурное преимущество: новый поставщик не сможет получить эквивалентный набор данных быстрее, чем за тот же квартал реальной работы. a16z в [разборе vSaaS как новой формы вертикального ПО](https://a16z.com/vsaas-vertical-saas-ai-opens-new-markets/) фиксирует тот же сдвиг с другой стороны: устойчивая защита в AI-native B2B появляется не на уровне модели, а на уровне накопленных операционных данных конкретной вертикали, и она растёт по мере того, как агент работает в реальном потоке. К 12-му месяцу клиент сидит на полугоде-году таких данных. Их нельзя ни перенести в другой контур одной кнопкой, ни воссоздать. Это первый слой, который никто не оплачивает явно — но при попытке уйти оплачивается дважды: один раз потерей точности нового агента, второй раз временем, нужным на накопление эквивалентной истории заново. ## Схема представления вертикали: чего нельзя пересобрать за квартал Второй слой не про данные, а про структуру, в которой они хранятся и обрабатываются. У каждой вертикали — будь то аренда оборудования, оптовая дистрибуция или сетевой ритейл — есть свой набор сущностей и связей: что считается операцией, что событием, что объектом, как они соединяются. Это и есть доменная схема — внутренняя модель данных, в которой агент представляет реальность клиента. В первые недели работы эта схема всегда выглядит как «общая» — то, что поставщик принёс с собой как стартовый шаблон. Через два-три месяца она перестаёт быть общей: в неё вшиваются особенности конкретной отрасли, конкретного формата работы, конкретных партнёров клиента. К полугоду схема знает, как у этого клиента считается смена, что такое «закрытый расчёт», какие три типа возвратов он различает, чем «спорный» отличается от «отменённого». Через год эта схема — отдельный продукт, который клиент не покупал, но получил. McKinsey в [последнем State of AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) фиксирует, что компании, которые сообщают о EBIT-эффекте от AI, чаще остальных ссылаются на переработку структуры данных как на ключевой шаг. Этот шаг не делается одной миграцией — он делается итеративно, по мере того как агент работает с реальными ситуациями и поднимает на поверхность неучтённые сущности. У AI-сервиса по подписке это происходит автоматически: каждая новая исключительная ситуация добавляет в схему один узел или одну связь, которых в начале года там не было. Стоимость воссоздания этого слоя у другого поставщика — это не цена разработки. Это срок: 4–6 месяцев работы в реальном контуре, чтобы накопить ту же глубину представления. На этот срок клиент в момент замены остаётся с менее точным агентом, который ошибается там, где предыдущий уже не ошибался. Это и есть скрытая часть цены, которую никто не пишет в коммерческом предложении. ## Вшитые операционные регламенты: то, что нужно перепродавать заново Третий слой — самый малозаметный и самый дорогой. Когда AI-агент в течение года работает внутри контура клиента, вокруг него постепенно складывается набор регламентов: кто что отвечает, в каких случаях агент решает сам, в каких эскалирует, какие шаги делает автоматически, какие требуют подтверждения. Часть этих регламентов записывается в документы. Большая часть — нет: они становятся неявным знанием команды, тем самым «у нас так принято». HBR в [разборе того, как B2B-продажи перестают быть линейными](https://hbr.org/2022/02/traditional-b2b-sales-and-marketing-are-becoming-obsolete) фиксирует общий факт: значительная часть операционных знаний в зрелом процессе хранится не в документации, а в практике команд. В AI-сервисе по подписке это знание перераспределяется: часть его уходит в настройки агента и в инструкции, часть остаётся у команды, но обе части начинают работать как одно целое. Через год клиент уже не помнит, какой триггер срабатывает в каком случае — потому что не нужно помнить. Контур работает. В материале Anthropic о паттернах построения агентов ([Building effective agents](https://www.anthropic.com/news/building-effective-agents)) Anthropic описывает этот сдвиг прямо: «The most successful implementations use simple, composable patterns rather than complex frameworks» — то есть ценность накапливается не в архитектуре, а в том, как простые блоки вживляются в конкретный процесс. Это и есть переход от инструмента к роли. Инструмент можно заменить — нужно найти аналог и настроить. Роль заменить нельзя — нужно перепродать её внутри организации, заново согласовать границы ответственности, заново обучить команду тому, кому что отдавать и в какой форме. Foundation Capital в [более жёстком тезисе о том, как поставщики моделей съедают рынок снизу](https://foundationcapital.com/ideas/when-model-providers-eat-everything-a-survival-guide-for-service-as-software-startups), отмечает: единственная защита от вытеснения — то, что не вынимается из клиента вместе с подпиской, а остаётся внутри контура как часть процесса. Регламенты — это и есть та часть. ## Три слоя рядом: что растёт и сколько стоит воссоздать Три слоя переключательных издержек отличаются не только природой, но и скоростью накопления и ценой выхода. Одна таблица показывает, почему суммарная стоимость замены к 12-му месяцу вырастает в 3–5×. | Слой | Что накапливается | Порог ценности | Стоимость воссоздания у другого поставщика | |------|------------------|----------------|--------------------------------------------| | Данные «решение → исход» | Пары «действие → результат» из реальной работы | 50–100 записей — первый порог; ~1000 за 90 дней — структурный | Квартал реальной работы (нельзя ускорить) | | Доменная схема вертикали | Сущности и связи конкретной отрасли и клиента | ~3 месяца — схема перестаёт быть общей | 4–6 месяцев менее точного агента | | Вшитые регламенты | Неявные правила эскалации и автономии агента | Складываются к концу первого года | Перепродажа роли внутри организации заново | Этот разбор продолжает линию предыдущей заметки [Подписка против проекта: три класса экономики B2B-агентов](https://notes.temadev.org/2026/05/retainer-vs-project-b2b-ai-subscription-economics.html): там разделялись классы экономики, здесь — механика того, почему один из этих классов удерживает клиента структурно. ## Что это значит для основателя и руководителя Для основателя AI-сервиса арифметика этих трёх слоёв означает, что ценообразование «за месяц работы» к концу года занижает реальную ценность контракта. Если подписка выставлена на «месяц работы», к 12-му месяцу клиент платит за месяц, но фактически выкупает доступ к контуру, который к этому моменту стоит замены 3–5 месячных платежей. Это создаёт асимметрию, на которой и строится NRR: либо клиент остаётся и платит больше за то же, что у него уже есть, либо уходит и платит ту же или большую сумму на восстановление эквивалента у другого поставщика. Прагматический тест для основателя: на каждый месяц работы посчитать, сколько часов команды клиента ушло на использование агента — и сколько часов другого поставщика потребуется, чтобы воспроизвести эту же интеграцию с нуля. Если второе число превышает первое в 3 раза и больше — у подписки есть структурная защита, и её цену можно индексировать без сопротивления. Если нет — поставщик строит услугу, а не повторяемый сервис, и через год её удержать не получится. На [тех же данных у SaaStr](https://www.saastr.com/the-4-levels-of-prompt-portability-why-some-ai-agents-will-hold-retention-and-most-wont/) это формулируется короче: при низком уровне prompt portability подписка живёт, при высоком — рано или поздно мигрирует к более дешёвому поставщику. Для руководителя в роли покупателя AI-сервиса арифметика обратная. Через 6 месяцев цена выхода из контракта перестаёт быть равна цене входа в новый. Это значит, что выбор поставщика к этому моменту нужно делать не на основе сравнения месячного прайс-листа, а на основе оценки того, как быстро и насколько точно текущий контур накапливает три слоя выше. Бенчмарки рынка показывают, что компании с NRR выше 120% в B2B AI — это всегда компании с глубокой интеграцией в операционный поток клиента, а не с широкой и поверхностной воронкой. Это не маркетинговый сигнал — это сигнал того, что покупатели этих сервисов через год не могут уйти без потерь. Конкретный шаг: на 90-й и 180-й день работы с подпиской запросить у поставщика три показателя по своему контуру — накопленный объём пар «решение → исход», изменения в схеме данных за период, список регламентов, которые были вшиты в работу агента. Если на эти вопросы нет ответа в цифрах и списках — поставщик доставляет не повторяемый сервис, а услугу, и через год отказ от неё ничего не стоит. Если ответ есть и накопление видно — это и есть то, за что стоит платить дальше, не сравнивая месячную цену с альтернативами, потому что альтернатив на этом сроке уже нет. ## Как понять, в чью сторону смещается асимметрия? Сигналы того, что эта механика разворачивается в сторону покупателя или поставщика, появятся в двух местах. Первое — публичные NRR-цифры AI-нативных B2B-компаний. Если медианный NRR в категории остаётся выше 120% на горизонте 18–24 месяцев, это означает, что три слоя выше работают как защита и поставщики научились их защищать. Второе — рост числа интеграционных партнёров и стандартов экспорта данных. Чем больше появляется готовых каналов вынимания истории «решение → исход» из одного контура в другой, тем быстрее размывается первая стенка выхода. Пока второго не видно — асимметрия в пользу поставщиков с накопленным контуром. ## Главное - Цена AI-сервиса по подписке может не меняться 12 месяцев, но стоимость воссоздания того же эффекта у другого поставщика к этому моменту вырастает в 3–5×. - Три слоя переключательных издержек растут с накопительным эффектом: данные цикла «решение → исход», доменная схема представления вертикали и вшитые операционные регламенты. - Bain показывает, что рост удержания на 5% даёт +25–95% к прибыли; в AI-сервисе по подписке этот эффект усиливается, потому что удержание и накопление данных работают в одну сторону. - Для основателя: цена «за месяц работы» к концу года занижает реальную ценность контракта; NRR 120%+ возможен только при глубокой интеграции, а не при широкой воронке. - Для руководителя: на 90-й и 180-й день нужно мерить накопление трёх слоёв в цифрах; если их нет — подписка ничего не защищает, если есть — заменить её через год будет дороже, чем продлить. ## FAQ **Чем «стоимость замены» отличается от цены подписки?** Цена подписки — это сколько клиент платит в месяц; она может не меняться весь год. Стоимость замены — это сколько стоит воссоздать тот же эффект у другого поставщика; к 12-му месяцу она вырастает до 3–5 месячных платежей. Это две разные кривые. **Почему нельзя просто скопировать промпт и переехать к дешёвому поставщику?** Промпт скопировать можно, но он даёт лишь верхний слой. Накопленные данные «решение → исход», доменная схема и вшитые регламенты не мигрируют копированием — их нужно накапливать заново кварталами реальной работы. **Как понять, что поставщик строит реальный контур, а не разовую услугу?** На 90-й и 180-й день запросить три показателя: объём пар «решение → исход», изменения в схеме данных и список вшитых регламентов. Если ответа в цифрах нет — это услуга, от которой через год можно отказаться без потерь. **Почему NRR выше 120% — это сигнал глубины, а не маркетинга?** Потому что высокий net revenue retention в B2B AI достигается не широкой воронкой, а глубокой интеграцией в операционный поток: клиенты таких сервисов через год не могут уйти без потерь, поэтому остаются и расширяются. --- ## Note 3: AI-native organization — это не «маленькая команда с ChatGPT». Тест на 9 пунктов **URL:** https://notes.temadev.org/2026/06/ai-native-org-9-point-test.html **Published:** 2026-06-30 **Genre:** contrarian-take **Tags:** ai-native, организации, операционная-модель, агенты, b2b **Words:** 1973 **Summary:** Как отличить AI-native организацию от команды, которая просто пользуется AI-инструментами. Тест на 9 структурных признаков. # AI-native organization — это не «маленькая команда с ChatGPT». Тест на 9 пунктов В первом квартале 2026 года сразу три публичных письма от CEO — Block, Shopify и Duolingo — потребовали от своих компаний стать «AI-native». Каждое разлетелось по деловым изданиям, и каждое вызвало одинаковую реакцию: тысячи компаний обновили слайды с позиционированием, добавив два слова в описание. К марту 2026-го ярлык обесценился до состояния, когда он ничего не различает. Команда из пяти человек, которая использует ChatGPT для рерайта писем, и компания, где агенты без участия людей обрабатывают тысячи клиентских событий в сутки, — в обоих случаях PR-отдел напишет «AI-native organization». Это не только проблема маркетинга. В B2B-продажах и переговорах с инвесторами ярлык «AI-native» несёт конкретные ожидания. Когда фаундер произносит его, а собеседник понимает буквально, разрыв в ожиданиях быстро становится операционным или репутационным риском: клиент ждёт скорости и автономии агентов, а получает «мы используем Copilot в Word». Нужен рабочий тест, который работает не как декларация, а как диагностика — до того, как разрыв проявит себя в реальности. ## Чем «маленькая команда с ChatGPT» отличается от AI-native? «Маленькая команда с ChatGPT» — это digitally-assisted organization, а не AI-native. Различие здесь не оценочное, а функциональное. Digitally-assisted означает, что AI-инструменты ускоряют или улучшают работу людей, которые остаются операционными центрами всех процессов. AI-native означает нечто принципиально иное: AI-компоненты встроены в операционную модель как первоклассные участники — с собственными полномочиями в определённом диапазоне, с памятью, с триггерами, которые не зависят от того, сидит ли кто-то за компьютером. Проверочный вопрос простой: если вы уберёте AI-компоненты из системы — что произойдёт? В digitally-assisted организации люди продолжат работать, просто медленнее и с большими усилиями. В AI-native организации часть процессов просто некому исполнять: они были спроектированы под агентов, и у людей нет ресурса подхватить их вручную в том же темпе. Это различие проходит не по тому, какие продукты куплены. Оно проходит по девяти структурным признакам, которые поддаются прямой диагностике — без маркетинговой интерпретации. И это именно то, что позволяет использовать тест в двух направлениях: для самооценки и для оценки партнёров, поставщиков, кандидатов. ## Тест на 9 пунктов Для каждого пункта зафиксируйте честный ответ: где реально находится ваша организация, не где вы хотите быть. Ответы «да», «частично», «нет» дают рабочую картину. ### 1. Полномочия принятия решений В digitally-assisted организации человек одобряет каждое действие AI: прочитал результат, нажал кнопку, действие выполнено. В AI-native организации у агентов есть чётко определённый диапазон автономии — класс решений, которые они принимают самостоятельно без участия человека. Для другого класса решений предусмотрена эскалация к человеку. Граница между классами зафиксирована явно и письменно, а не существует имплицитно в форме «агент предлагает, человек решает». Anthropic [claude-3-5-sonnet](https://www.anthropic.com/news/claude-3-5-sonnet) и последующие модели впервые сделали полностью автономный диапазон принятия решений практически реализуемым без значительного инженерного оверхеда — что и сделало разговор об AI-native из теоретического практическим. Тест: есть ли в вашей компании хотя бы один операционный процесс, где агент принимает финальное решение без человека в цикле? Если нет — вы в digitally-assisted модели независимо от того, сколько AI-инструментов используете. ### 2. Архитектура памяти В digitally-assisted организации знания живут в документах, которые люди создают и читают для людей: Google Docs, Confluence, Notion. В AI-native организации у агентов есть структурированные контекстные файлы, которые они читают нативно при каждом запуске: специфика компании, история принятых решений, текущий операционный статус. Эти файлы не просто «документы в облаке» — они спроектированы под то, как агент их потребляет: формат, гранулярность, триггеры обновления. Практический маркер: если новый агент может начать работу в вашей компании, прочитав набор файлов, без onboarding-сессии с человеком — это признак AI-native памяти. Если без объяснений от живого сотрудника агент не понимает контекст — память не адаптирована под машину. Почему структурированная память вытесняет документную, мы разбирали отдельно в заметке [Память больше документа: что заменяет Notion в ИИ-нативной команде](https://notes.temadev.org/2026/05/memory-beats-document-ai-native-team.html). ### 3. Инициация работы В digitally-assisted организации работа начинается, когда человек ставит задачу: написал сообщение, открыл тикет, провёл встречу. В AI-native организации значительная часть работы инициируется событиями и расписанием: наступило определённое время — процесс запустился, пришли новые данные — агент начал их обрабатывать, изменился статус объекта — сработал триггер. Anthropic в руководстве [Building Effective Agents](https://www.anthropic.com/research/building-effective-agents) описывает это как переход от «человек как диспетчер задач» к «агент как самостоятельный исполнитель в событийной архитектуре». Тест: какой процент дневной работы ваши агенты делают без того, чтобы конкретный человек сегодня их об этом попросил? Если ответ — менее 20%, операционная модель остаётся человеко-центричной. ### 4. Поведение при ошибке Это самый информативный пункт теста, потому что его сложнее всего сфабриковать. В digitally-assisted организации ошибка агента — это всегда «пойди к человеку, он разберётся». В AI-native организации есть явная иерархия уровней: агент справляется сам через retry или альтернативный путь, агент эскалирует к другому агенту, агент эскалирует к человеку. Третий уровень зарезервирован для ситуаций, которые действительно требуют человеческого суждения, — а не для всего, что вышло за рамки ожидаемого сценария. Отсутствие этой иерархии — признак того, что система была автоматизирована, а не спроектирована. Автоматизация снимает часть ручного труда. AI-native архитектура строит другую операционную модель. ### 5. Масштабирование мощности В digitally-assisted организации «нам нужно больше ресурсов для обработки объёма» означает нанять человека. В AI-native организации первым вопросом становится другое: какой агент можно развернуть, с каким контекстом, за какое время, и что это даст? Доля новых задач, закрываемых развёртыванием агентов против найма, — прямой измеримый показатель степени AI-native. CEO Shopify Тоби Лютке в [служебной записке сотрудникам](https://www.theverge.com/2025/4/7/24325072/shopify-employees-prove-ai-cant-do-their-job-before-hiring) в 2025 году зафиксировал именно этот принцип письменно: прежде чем запросить новых сотрудников, команда должна доказать, что AI не справится с этой задачей. Масштабирование через агентов — приоритет по умолчанию; человеческий найм — обоснованное исключение. Это не просто риторика: запрос на новую позицию без анализа AI-альтернативы в Shopify с 2025 года не проходит согласование. ### 6. Непрерывность контекста В digitally-assisted организации контекст накапливается в головах людей и восстанавливается через встречи, переписку и синхронизации. Когда ключевой человек уходит — контекст частично пропадает, и все это знают. В AI-native организации контекст хранится в структурированных поверхностях, которые агенты читают между сессиями. Это не «записи встречи в Notion» — это файлы с историей решений, операционными статусами и текущими приоритетами, которые обновляются после каждого значимого события и доступны агенту немедленно. Практический тест: если ключевой человек уходит в отпуск на две недели, насколько деградирует работа агентов? В AI-native организации ответ — «незначительно, контекст не в голове человека». ### 7. Кодификация процессов В digitally-assisted организации процесс живёт в голове исполнителя или в документе, который человек читает и самостоятельно интерпретирует. Передача процесса нового сотрудника — это обучение: объяснения, примеры, вопросы. В AI-native организации операционные процессы записаны в форматах, которые машина может напрямую исполнять или валидировать: скрипты, конфигурации, явные правила с проверяемыми условиями. Маркер: если вы не можете показать описание процесса агенту так, чтобы он воспроизвёл его без дополнительных объяснений от человека, — процесс не кодифицирован в AI-native смысле. Это не значит, что процесс плохой; это значит, что для AI-native модели он ещё не адаптирован. ### 8. Операционная активность без людей В digitally-assisted организации работа останавливается или существенно замедляется, когда люди уходят с работы. В AI-native организации это другой режим, а не простой. Агенты продолжают работать по расписанию, обрабатывать накопленные очереди, готовить данные и черновики для утреннего старта команды. McKinsey в [The State of AI 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) выделил асинхронную операционную модель — способность организации выполнять работу вне зависимости от расписания людей — как один из ключевых дифференциаторов компаний с реальным, измеримым AI-эффектом. Тест: сколько процессов в вашей организации завершат полезную работу этой ночью без участия людей? ### 9. Аудируемость решений AI-native организации сталкиваются с вопросом, которого практически нет у digitally-assisted: как восстановить, почему агент принял то или иное решение шесть недель назад. Это не академический вопрос — это операционный, когда клиент спрашивает почему с его заказом так поступили, или когда что-то пошло не так и нужно найти первопричину, а не симптом. AI-native организация закладывает аудит-трейл в архитектуру изначально: логи решений с контекстом, версионирование конфигурационных файлов, история эскалаций с явными причинами. Отсутствие аудируемости — «тихий технический долг», который не мешает запуститься, но превращает масштабирование в болезненный процесс: добавить логирование к уже работающей агентной системе значительно сложнее, чем заложить его в архитектуру с первого спринта. Anthropic в [документации по инструментам агентов](https://www.anthropic.com/news/tool-use-ga) подчёркивает, что прозрачность решений агента — не опциональная фича, а архитектурное требование для production-систем. Для компании, которая называет себя AI-native в разговоре с крупным B2B-клиентом, аудируемость нередко становится первым пунктом проверки. ## Как использовать этот тест Девять пунктов — не чеклист для сертификации и не повод для гордости или стыда. Это диагностический инструмент для трёх конкретных ситуаций. **Для фаундера перед питчем.** Если вы собираетесь называть компанию AI-native, пройдите тест и зафиксируйте по каждому пункту честный ответ. Результат 4/9 не дисквалифицирует вас — он даёт точный нарратив: «мы перестроили полномочия и память, следующий этап — кодификация процессов и overnight-операции». Это сильнее, чем расплывчатое «мы AI-native», которое несёт информацию ровно до тех пор, пока собеседник не начнёт уточнять. **Для руководителя операций перед трансформацией.** Тест показывает, где именно стоит граница между digitally-assisted и AI-native в вашей организации прямо сейчас. Аналитики Foundation Capital в эссе [AI leads a service-as-software paradigm shift](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) описывают это как постепенный переход, не одновременный: организации перестраивают один слой за другим, начиная с наиболее кодифицируемых процессов. Тест помогает выбрать, с чего начать. **Для CTO при оценке команды или поставщика.** Когда кандидат или поставщик называет себя AI-native, три пункта теста работают как быстрый фильтр: полномочия (пункт 1), поведение при ошибке (пункт 4) и аудируемость (пункт 9). Ответы на них либо конкретны — тогда за ними стоит реальная архитектура, — либо размыты в сторону «мы смотрим по ситуации». Второй вариант означает: хорошо автоматизированная digitally-assisted организация, не более. Sam Altman в посте [«Planning for AGI and Beyond»](https://openai.com/index/planning-for-agi-and-beyond) описывал AI-native как принципиально иную организационную логику, а не просто новый стек инструментов. Когда он говорил о перспективе «компании из одного человека с выручкой миллиард», он имел в виду именно операционную модель — не инструменты в арсенале одного сотрудника, а способность одного человека оркестрировать агентную организацию, где каждый из девяти пунктов этого теста даёт положительный ответ. В 2026 году это стало практически проверяемым — не теоретически, а через конкретные операционные признаки. Команда с девятью ChatGPT-аккаунтами и компания с агентной архитектурой, которая выполняет работу ночью без людей, — это не одна и та же модель с разным маркетингом. Это разные операционные реальности, которые можно измерить и зафиксировать. ## Главное - **AI-native ≠ digitally-assisted.** Первое — про операционную модель, второе — про инструменты, которые используют люди. Различие функциональное, не маркетинговое. - **Ключевой проверочный вопрос:** если убрать AI-компоненты, продолжает ли работать операционная модель? В AI-native организации — нет, часть процессов некому исполнять. - **Самый показательный пункт теста** — поведение при ошибке: если ответ всегда «эскалация к человеку», перед вами автоматизация, а не AI-native архитектура. - **Тест работает как честный нарратив** для питчей: «4 из 9, следующий этап — X» сильнее и достовернее, чем расплывчатое «мы AI-native». - **Аудируемость — системная задолженность**, которую значительно дешевле заложить в архитектуру в начале, чем добавить к работающей системе позже. ## FAQ **Чем AI-native отличается от digitally-assisted организации?** Digitally-assisted — это когда AI-инструменты ускоряют работу людей, которые остаются операционными центрами всех процессов. AI-native — это когда агенты встроены в операционную модель как первоклассные участники — с полномочиями, памятью и триггерами. Проверка: уберите AI-компоненты — в digitally-assisted люди продолжат работать медленнее, в AI-native часть процессов просто некому исполнять. **Какой пункт теста самый показательный?** Поведение при ошибке (пункт 4). Его сложнее всего сфабриковать: если любая ошибка агента сразу эскалируется к человеку, перед вами автоматизация. AI-native архитектура имеет явную иерархию: retry → эскалация к другому агенту → эскалация к человеку, и третий уровень зарезервирован только для ситуаций, требующих человеческого суждения. **Нужно ли набрать 9 из 9, чтобы называться AI-native?** Нет. Тест — диагностика, а не сертификация. Результат 4/9 не дисквалифицирует — он даёт точный нарратив для питча: «перестроили полномочия и память, следующий этап — кодификация процессов и overnight-операции». Это сильнее расплывчатого «мы AI-native». **Какие три пункта работают как быстрый фильтр при оценке поставщика?** Полномочия (пункт 1), поведение при ошибке (пункт 4) и аудируемость (пункт 9). Ответы на них либо конкретны — тогда за ними стоит реальная архитектура, либо размыты в сторону «мы смотрим по ситуации» — что означает digitally-assisted организацию, хорошо автоматизированную, но не более. --- ## Note 4: Почему ваш AI-пилот умрёт тихо **URL:** https://notes.temadev.org/2026/06/pochemu-vash-ai-pilot-umret-tikho.html **Published:** 2026-06-24 **Genre:** pattern-essay **Tags:** ai, b2b, pilots, buying-committee **Words:** 1974 **Summary:** Пилоты не отклоняют — они стихают. Разбор механики тихой смерти со стороны закупочного комитета и того, что решает её исход. # Почему ваш AI-пилот умрёт тихо Ваш последний AI-пилот не отклонили с обоснованием. Никто не написал «мы решили не продолжать». Переписка просто стала реже: ответы приходили через день, потом через три, потом чемпион проекта сослался на «период согласований» — и замолчал. Через месяц вы узнали, что бюджет ушёл на другое. Решение приняли давно, и приняли не с вами в комнате: по данным [Forrester](https://www.forrester.com/blogs/thereismorethanonebtobbuyersjourney/), в типовой корпоративной закупке технологий участвуют от шести до десяти человек, и у большинства из них нет причины поддерживать сделку дольше двух-трёх недель без видимого результата. Это и есть характерная смерть AI-пилота — тихая, и по данным MIT именно так заканчивается подавляющее большинство: 95% корпоративных AI-инициатив не доходят до измеримой отдачи. Она почти никогда не выглядит как «нет». Она выглядит как затухание сигнала, и именно поэтому её так трудно вовремя заметить и почти невозможно отыграть назад. ## Отказ, которого не было Большинство поставщиков AI-решений строят свою картину сделки вокруг одного человека — того, кто пришёл на демо, загорелся, попросил пилот. Назовём его чемпионом: он искренне хочет, чтобы проект состоялся. Проблема в том, что чемпион почти никогда не принимает решение единолично. По расчётам [Forrester](https://www.forrester.com/blogs/three-realities-about-b2b-buying-networks/), 73% покупок технологий затрагивают три и более департамента, а в среднем в решение вовлечено около 13 человек внутри организации покупателя и ещё 9 снаружи — итого до 22 участников на одну сделку. Исследование Gartner той же группы покупателей даёт схожий порядок: типичный закупочный комитет — от 6 до 10 человек. Более ранняя работа [Harvard Business Review](https://hbr.org/2022/02/traditional-b2b-sales-and-marketing-are-becoming-obsolete) формулирует следствие прямо: «Чем больше участников вовлечено в B2B-покупку, тем труднее группе прийти к согласию о чём-либо, кроме как ничего не делать». Цифра у неё скромнее — по [опросу трёх тысяч участников корпоративных закупок](https://goconsensus.com/blog/its-not-you-its-them-5-4-stakeholders-create-group-buying-dysfunction) в среднем 5,4 человека на сделку, — но вектор тот же: каждый дополнительный участник снижает вероятность покупки, а не повышает. Логика контринтуитивна, но устойчива: чем больше людей за столом, тем выше вероятность, что согласие не достигается вовсе — группа скорее замирает в неопределённости, чем приходит к общему «да». Чемпион был на демо. Остальные пять, девять, тринадцать — не были. Они узнают о вашем продукте из пересказа, из одного слайда в общем чате, из реплики на планёрке, где обсуждали восемь других вопросов. Для них ваш пилот — не «прорыв, который надо защищать», а строка в списке инициатив, конкурирующих за один и тот же бюджет, внимание и политический капитал. И когда наступает момент перераспределения ресурсов — а он наступает в любой компании раз в квартал, — голос за вас может подать только тот, у кого на руках есть доказательства. У чемпиона их нет. Есть энтузиазм, который не конвертируется в аргумент для тех, кто на демо не приходил. Поэтому отказ не оформляется как отказ. Никто не голосует против — просто никто не голосует за. Пилот не убивают, его перестают защищать. А поставщик ещё две недели пишет письма в тишину, потому что в его модели мира «нет ответа» означает «думают», тогда как на стороне покупателя это уже означает «решили». Асимметрия здесь жестокая. Поставщик видит сделку как линию: демо, пилот, контракт. Покупатель видит её как параллельный процесс, в котором ваш проект — один из десятка, и его судьба решается не на ваших звонках, а на внутренних обсуждениях, куда вас не зовут. К моменту, когда вы замечаете тишину, на той стороне уже прошло два-три совещания без вас, и на каждом ваш пилот проигрывал не конкуренту, а отсутствию аргумента в свою защиту. ## Что говорят данные о масштабе провала Тихая смерть — не редкий сбой, а доминирующий исход. Исследование MIT, разошедшееся летом 2025 года, зафиксировало, что 95% корпоративных AI-инициатив не приносят измеримой отдачи; до стадии пилота доходит около 20% проектов, а до production — лишь 5% [(Fortune)](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/). Иначе говоря, из каждых 100 запущенных инициатив до реальной эксплуатации доживают 5. Разбирая ту же работу, [Forbes](https://www.forbes.com/sites/andreahill/2025/08/21/why-95-of-ai-pilots-fail-and-what-business-leaders-should-do-instead/) формулирует вывод без обиняков: «Проблема не в том, что AI не работает, — проблема в том, как компании его внедряют». Проваливаются не алгоритмы, а внедрения — на стыке между технически работающим прототипом и организацией, которая так и не признала его своим. Эту же механику с другой стороны — со стороны выживших 5% — я разбирал в [«95% AI-пилотов проваляются. Что общего у выживших»](https://notes.temadev.org/2026/06/ai-pilot-failure-95-percent-survivors.html): там речь о том, куда вшивать AI, здесь — о том, как пережить первые две недели. В отраслевом жаргоне для этого застревания есть название — pilot purgatory, чистилище пилотов. Аналитики описывают его как состояние, в котором инициатива технически жива, но не движется: демонстрирует обещание и не доходит до реальной пользы для бизнеса. По прогнозу Gartner, к концу 2026 года около 60% AI-проектов будут свёрнуты из-за того, что под ними не оказалось готовых к работе данных, а значительная доля пилотов отбраковывается именно на переходе от proof of concept к эксплуатации. Цифры разнятся от исследования к исследованию, но вектор один: между «впечатляющим демо» и «системой, которой пользуются каждый день» лежит провал, в который проваливается подавляющее большинство проектов. Важно, что этот провал не информационный. Покупатель не «не понял ценность» — чаще он просто не получил её доказательства в форме, которую можно предъявить комитету. Демо показывает потенциал. Комитет принимает решения по фактам. А факт — это не «продукт умеет», а «у нас уже стало лучше, вот на сколько и вот где это видно». ## Почему всё решается в первые четырнадцать дней? Между подписанием пилота и его тихой смертью есть короткое окно, в котором исход ещё подвижен. По практике B2B-консалтинга и корпоративных внедрений это примерно первые две недели. Быстрый измеримый результат принято показывать на пятый-седьмой день, а первый существенный осязаемый итог — не позже четырнадцатого. Не потому что это красивая круглая цифра, а потому что ритм внутреннего комитета задаёт именно такой темп: между двумя планёрками, на которых ваш проект может всплыть, обычно проходит две-три недели. Если к этому моменту чемпиону нечего положить на стол, на стол не ляжет ничего — и пилот начинает гаснуть ровно по описанному сценарию. Содержание этих двух недель почти всегда выбрано неверно. Поставщик тратит их на инфраструктуру: подключает источники данных, настраивает доступы, выстраивает конвейер. Работа реальная и необходимая, но невидимая для тех, кто не был на демо. К четырнадцатому дню у поставщика есть «мы многое настроили», а у чемпиона по-прежнему нет ответа на простой вопрос коллеги из соседнего отдела: «и что, стало лучше?». Объём проделанной работы и наличие доказательства ценности — это разные оси, и комитет смотрит только на вторую. Сильное раннее доказательство для AI-проекта — это не «мы развернули систему». Это одно из трёх: заказчик впервые увидел собственный процесс в структурированном виде; заказчик увидел свои реальные данные в работающем интерфейсе; один конкретный сценарий уже автоматизирован и экономит время или снижает потери. Любое из трёх можно показать человеку, который не приходил на демо, за тридцать секунд — и в этом вся суть. Доказательство ценно не тем, что оно впечатляет чемпиона, а тем, что чемпион может передать его дальше без вас в комнате. ## Онбординг как производство доказательств Из этой механики следует смена самой задачи онбординга. Обычно его понимают как передачу продукта: научить пользоваться, подключить, настроить, сдать. В мире, где решение принимает невидимый комитет, онбординг — это производство видимых доказательств для людей, которых вы никогда не увидите. Продукт передаётся одному, а решение защищают перед десятью, и онбординг должен снабжать чемпиона боеприпасами для этой защиты. Практически это значит фиксировать состояние «до» ещё до начала работ — иначе к концу второй недели нечего сравнивать и нечем доказывать улучшение. Это значит вести по дням то, что появилось: что было на первый день, что на третий, что на седьмой, что на четырнадцатый — простая хронология, которую чемпион пересылает одним сообщением. Это значит собирать короткие достоверные следы использования: скриншоты реальной работы, а не маркетинговые, первые статусы, первый кейс «раньше это занимало час — теперь десять минут» с конкретными цифрами заказчика, а не вашими обещаниями. И это значит получить от заказчика одну короткую формулировку в стиле «было так — стало так», потому что в комитете чужая цитата весит больше, чем любой ваш слайд. Именно так — берём один измеримый процесс и собираем вокруг него AI-контур, который ведёт его сам и с первого дня оставляет видимый след пользы, — мы и строим как рабочую систему, а не как пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=pochemu-vash-ai-pilot-umret-tikho&utm_content=inprose). Здесь же кроется частая организационная ошибка на стороне покупателя, которую опытный поставщик распознаёт и закрывает заранее: если внутри компании не назначен человек, отвечающий за внедрение, согласования буксуют, а чемпион остаётся один против комитета без формального права голоса. Слабый онбординг этого не замечает. Сильный — делает назначение такого ответственного частью первой недели, потому что без него любые доказательства некому предъявить в нужный момент. ## Тесты, которые стоит прогнать Для поставщика AI-решений проверка одна и жёсткая: возьмите свой последний завершившийся пилот и спросите, что чемпион мог показать комитету на четырнадцатый день без вашего участия. Если ответ — «прислал бы нас на созвон» или «показал бы то демо», вы проиграли ещё до тишины: у вас не было доказательства, переживающего ваше отсутствие в комнате. Второй тест для основателя и руководителя продукта — посмотреть на структуру первых двух недель внедрения и честно ответить, сколько процентов этого времени уходит на невидимую инфраструктуру и сколько на производство того, что можно переслать одним сообщением. Если первое перевешивает второе вдвое, ваши пилоты будут гаснуть, и качество модели тут ни при чём. Для руководителя со стороны заказчика — того самого владельца или технического директора, который узнаёт себя в роли чемпиона, — тест зеркальный. Спросите себя, сможете ли вы на ближайшей планёрке объяснить ценность пилота коллегам, которых не было на демо, за одну минуту и с цифрой. Если нет — это не значит, что продукт плохой. Это значит, что поставщик не вооружил вас, и без этого вы защитите его проект ровно до первого перераспределения бюджета, после которого замолчите сами, не заметив, как это произошло. ## Что мы будем наблюдать Сигнал, на который стоит смотреть в ближайший год, — смещение конкуренции AI-поставщиков с качества демонстрации на качество первых четырнадцати дней. По мере того как доля проваленных пилотов остаётся около 95%, выигрывать будут не те, у кого ярче прототип, а те, кто превращает онбординг в машину доказательств для невидимого комитета. Второй сигнал — рост числа покупателей, которые сами требуют от поставщика baseline и хронологию пользы с первого дня, потому что обожглись на тихих смертях предыдущих пилотов. Когда это станет нормой закупки, тишина перестанет быть приговором — её научатся читать заранее, на той стороне, где решение пока ещё подвижно. ## Главное - AI-пилот почти никогда не отклоняют явным отказом — он гаснет, потому что решение принимает закупочный комитет из 6–10 человек, а по [Forrester](https://www.forrester.com/blogs/three-realities-about-b2b-buying-networks/) в среднем около 13 внутренних участников, большинство которых не были на демо. - 95% корпоративных AI-инициатив не приносят отдачи, до production доходит лишь 5% — провал лежит не в модели, а во внедрении, на стыке прототипа и организации [(Fortune)](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/). - Исход решается в окне первых ~14 дней: чемпиону нужно доказательство ценности, которое он покажет комитету без поставщика в комнате. - Сильное раннее доказательство — не «мы развернули систему», а структурированный процесс, реальные данные в работе или один автоматизированный сценарий с цифрой «до/после». - Онбординг стоит строить не как передачу продукта, а как производство видимых доказательств для людей, которых поставщик никогда не увидит. ## Вопросы и ответы **Почему AI-пилоты чаще всего проваливаются тихо, а не явным отказом?** Потому что решение принимает не чемпион с демо, а закупочный комитет из 6–10 человек (по Forrester — до 13 внутренних участников и ещё 9 внешних). Большинство из них не были на демо и не имеют причины голосовать за проект без видимого результата. Пилот не убивают — его перестают защищать. **Сколько AI-пилотов доходит до production?** По данным исследования MIT 2025 года — около 5%. До стадии пилота доходит примерно 20% проектов, а 95% корпоративных AI-инициатив не приносят измеримой отдачи. Причина в подавляющем большинстве случаев — не качество модели, а провал внедрения. **Что считается сильным ранним доказательством ценности?** Не «мы развернули систему», а одно из трёх: заказчик впервые увидел свой процесс в структурированном виде; увидел свои реальные данные в работающем интерфейсе; либо один сценарий уже автоматизирован и экономит время с конкретной цифрой «до/после». Критерий один: чемпион может показать это коллеге за 30 секунд без вас в комнате. **Почему именно четырнадцать дней?** Потому что ритм внутреннего комитета задаёт именно такой темп: между двумя планёрками, на которых ваш проект может всплыть, обычно проходит две-три недели. Быстрый результат показывают на 5–7-й день, первый существенный итог — не позже 14-го. Если к этому моменту чемпиону нечего положить на стол — пилот начинает гаснуть. --- ## Note 5: Почему в России никто не продаёт AI за результат — и что строить, пока окно открыто **URL:** https://notes.temadev.org/2026/06/rf-ai-outcome-pricing-pochemu-nikto-ne-prodaet-za-rezultat.html **Published:** 2026-06-22 **Genre:** market-deep-dive **Tags:** outcome-pricing, b2b-ai, russia, smb, vertical-ai **Words:** 2307 **Summary:** В России никто не продаёт AI за результат. Барьер — не нежелание, а три недостающих компонента: точка отсчёта, атрибуция и зрелый договор. В апреле 2026 года университет «Зерокодер» открыл первый в России венчурный фонд, который инвестирует именно в бизнесы, где AI-агенты — ядро операционной модели, а не вспомогательный инструмент; чеки 5–100 млн ₽, стадии pre-seed и seed ([FrankMedia/Forbes](https://frankmedia.ru/269498)). В том же месяце MWS AI и Rocket Control оценили рынок корпоративных ИИ-ассистентов в России к концу 2026 года примерно в 30 млрд ₽ ([Kommersant](https://www.kommersant.ru/doc/8587035)). Деньги в категорию пришли, спрос растёт. Но если открыть сайты лидеров российского рынка AI-агентов и поискать ответ на простой вопрос — «за что именно я плачу?», — ответ везде будет одинаковый: за доступ, за подписку, за пакет токенов, за обещание «сэкономить до 15 часов в неделю». Ни один публичный игрок не продаёт результат. Оплата за результат (outcome-pricing) — это модель, при которой покупатель платит не за доступ к инструменту и не за потраченное время, а за подтверждённый бизнес-итог: за решённый тикет, за квалифицированный лид, за процент от сэкономленных или заработанных денег. На глобальном рынке вертикального AI это уже не экзотика, а норматив для зрелых игроков. В России на июнь 2026 года эта ниша публично пуста — и пуста она не случайно. ## Глобально за результат уже платят десятки тысяч долларов Чтобы увидеть масштаб разрыва, достаточно посмотреть на то, как зарабатывают ведущие вертикальные AI-компании за рубежом. Модель «оплата за решённый запрос» стала стандартом в поддержке клиентов: покупатель платит фиксированную сумму за каждое обращение, которое агент закрыл без участия человека. Это не подписка за «доступ к боту» — это счёт, привязанный к сделанной работе. Логика проста и для покупателя честна: если агент не решил вопрос, продавец не получил денег. Этот сдвиг — часть более широкого тренда, который венчурные фонды формулируют прямо: вертикальный AI конкурирует не за бюджет на программное обеспечение, а за бюджет на труд. Bessemer в своём разборе вертикальных приложений формулирует это афоризмом: «программное обеспечение перестаёт быть инструментом и становится работником» — и тогда продаётся оно против стоимости найма этого работника, а не против стоимости лицензии на другой инструмент ([Bessemer Venture Partners](https://www.bvp.com/atlas)). a16z в своих разборах рынка фиксирует ту же мысль ещё резче: фонд называет это переходом «от продажи софта к продаже работы» (selling work, not software) — клиент покупает выполненную задачу, а не доступ к возможности её выполнить ([a16z](https://a16z.com/)). Когда продаёшь исход, естественная единица цены — сам исход, а не место в системе и не час работы. То, за какую единицу вообще берёт деньги поставщик — за доступ, за объём или за результат — [мы разбирали отдельно как главное решение со стороны вендора](https://notes.temadev.org/2026/05/seat-pricing-unit-dead-outcome-based-ai). Числа здесь говорят сами за себя. Лидер поддержки на агентах берёт порядка 0,99 доллара за каждое решённое обращение — и при миллионах тикетов в месяц это складывается в выручку, которую ни одна подписка «за доступ» не даёт. Вертикальные игроки в юридике и продажах берут от десятков до сотен тысяч долларов в год за квалифицированный разговор или закрытую задачу, а не за место в системе. Разрыв с российским «экономьте до 15 часов в неделю» здесь не количественный, а качественный: там счёт выставлен за работу, здесь — за обещание. Важный нюанс: на Западе это работает, потому что покупатель и продавец заранее договорились, что считать результатом. Решённое обращение определено регламентом. Квалифицированный лид определён критериями. Сэкономленный час подтверждён журналом операций. Оплата за результат — это не маркетинговый ход, это договор о метрике, под которой стоят обе стороны. Именно эта часть в России и отсутствует. ## В России продают доступ, время и обещание — но не исход Российская карта монетизации на июнь 2026 года выглядит так: доминируют подписка и проектный фикс, есть медленный дрейф к оплате по использованию, и почти нет движения к чистой оплате за результат. Лидеры рынка контроля качества продаж, по [рейтингу Sostav](https://www.sostav.ru/blogs/289090/86563) от мая 2026 года, монетизируются через пакеты токенов и фиксированную подписку — это оплата за объём обработки, а не за рост конверсии, который этот анализ должен дать. Игроки с вертикальной глубиной в стройке и смежных нишах берут 55–95 тыс. ₽ в месяц за пакет модулей по фиксированной подписке: цена идёт, пока действует договор, и не зависит от того, сколько денег модули принесли. Для сравнения: западный аналог в той же нише за 12 месяцев вернёт клиенту часть денег, если заявленный результат не достигнут; российский пакет не возвращает ни рубля ни при каком исходе. Горизонтальные платформы обновляют лендинги под обещание «экономьте до 15 часов в неделю» — но это маркетинговый якорь, а не строка в счёте. Никто не возвращает деньги, если пятнадцать часов не сэкономились. Ближе всех к риторике оплаты за результат подошёл консалтинг. Компания ESSG в апреле 2026 года опубликовала разбор оплаты по результату на кейсе HubSpot, где описала схему «15% от экономии после трёхмесячного пилота» ([ESSG Consulting](https://essg.consulting/blog/2026/04/02/outcome-based-ai-pricing-hubspot-biznes-rezultat/)). Но это статья о чужой модели, а не собственный продукт с такой ценой; фокус — крупный бизнес, а не массовый малый. Параллельно на уровне отдельных консультантов появилась риторика «плачу за результат, не за часы» — но это предложение одного человека без продукта, без вертикали и без масштаба. Дискуссия об оплате за результат в России идёт. Продукта, который так продаёт, — нет. Получается странная асимметрия. Категория валидирована деньгами: профильный венчурный фонд готов вкладывать до 100 млн ₽ в «бизнес на агентах». Рынок растёт к 30 млрд ₽. Покупатели готовы. А самой честной для покупателя модели ценообразования — заплати за то, что реально получил — на рынке нет ни у кого. Объяснять это ленью или незрелостью продавцов было бы удобно и неверно. ## Почему же никто не продаёт за результат? Оплата за результат требует, чтобы результат можно было измерить и приписать конкретному внедрению. Это раскладывается на три компонента, и ни один из них у среднего российского малого бизнеса сейчас не готов. ### Точка отсчёта, которой нет до внедрения Чтобы продать «процент от экономии», нужно знать, сколько компания тратила до AI. Сколько заявок терялось на входящих, какой был средний срок ответа, какая доля обращений уходила без сделки, сколько часов уходило на ручную обработку. Эта цифра «как было», зафиксированная до старта, и есть точка отсчёта (в отрасли её часто называют baseline). Проблема в том, что большинство малых компаний не ведёт этих цифр. Процесс живёт в мессенджерах, телефонных звонках и таблицах, которые никто не сводит. Невозможно продать «минус 30% потерь», если никто не знает, сколько потерь было. Продавец, который попытается, либо завысит результат и потеряет доверие, либо занизит и потеряет деньги. На практике это значит, что первый месяц любого честного проекта с оплатой за результат уходит не на внедрение агента, а на восстановление точки отсчёта из разрозненных следов — и именно эту работу покупатель обычно не готов оплачивать отдельно, потому что не видит в ней «результата». ### Методика атрибуции, под которой подпишутся обе стороны Допустим, точка отсчёта есть. Тогда возникает второй вопрос: как доказать, что улучшение дал именно AI, а не сезон, не новый менеджер, не реклама. Атрибуция — это прозрачная методика, которая отделяет вклад внедрения от всего остального. На Западе её решают регламентом и журналами операций: обращение считается решённым агентом, если человек к нему не прикасался. В российском малом бизнесе, где половина шагов процесса не оставляет цифрового следа, такой регламент построить дорого и долго. А без него любой спор о сумме счёта превращается в спор о том, чья заслуга, — и обе стороны это понимают заранее, поэтому к договору об оплате за результат не идут. Самый коварный случай — когда внедрение действительно сработало, но доказать это нечем. Тогда честный продавец проигрывает дважды: он и результат дал, и денег за него не получил, потому что в договоре не было способа этот результат зафиксировать. Именно этот риск и толкает обе стороны обратно к подписке, где спорить не о чём. ### Контрактная зрелость, которой массовый сегмент ещё не достиг Оплата за результат — это сложный договор. В нём прописаны метрика, метод измерения, период замера, что считается форс-мажором, кто владеет данными, как разрешаются споры. Это юридическая и операционная зрелость, которую крупная компания тянет, а малый бизнес — редко. Покупателю проще понять и подписать фиксированную подписку: предсказуемо, привычно, не требует ни точки отсчёта, ни методики измерения. Поэтому рынок и оседает на подписке — это путь наименьшего сопротивления для обеих сторон, а не доказательство того, что подписка лучше. Есть и обратная сторона риска. Для поставщика договор об оплате за результат — это ставка собственным кэшем на процесс, который он контролирует лишь частично: если у клиента слабые менеджеры или сломанный процесс, агент сделает свою часть, а результата на выходе не будет — и продавец останется без денег за чужие ошибки. Поэтому зрелый договор об оплате за результат на Западе всегда содержит раздел о том, что клиент обязан обеспечить со своей стороны. В российском малом бизнесе такой раздел пока некому ни написать, ни исполнить. Из этих трёх барьеров складывается ответ на вопрос заголовка. Оплата за результат отсутствует не потому, что российский рынок не хочет или не способен. Она отсутствует, потому что её фундамент — измеримая точка отсчёта, честная атрибуция и зрелый контракт — у большинства покупателей пока не построен. Тот, кто решит инженерную задачу «как честно измерить результат в конкретной вертикали», получит не маркетинговое преимущество, а саму категорию. ## Что это значит для основателя и руководителя Разрыв между «никто не продаёт за результат» и «капитал уже финансирует тех, кто будет» — это и есть окно. Оно открыто, но сужается: как только первый вертикальный игрок публично привяжет контракт к метрике, окно начнёт закрываться, и переговорная позиция покупателя ухудшится. Конкретные действия зависят от роли. **Для основателя AI-продукта или агентства.** Не ждите, пока рынок «дозреет» до оплаты за результат сверху. Выберите одну узкую вертикаль и решите в ней задачу атрибуции первым: определите, какая одна цифра в этой нише и есть результат (потерянные заявки, простой ресурса, срок ответа, доля закрытых обращений), и постройте способ её честно мерить до и после. Это не про красивый лендинг — это про методику, под которой подпишется покупатель. Тест на готовность простой: можете ли вы за один разговор объяснить клиенту, как именно вы посчитаете его результат и что будете считать своей заслугой, а что — нет. Если объяснение занимает больше пяти минут или звучит как «доверьтесь нам» — методики ещё нет. **Для руководителя, который оценивает внедрение AI.** Главный риск сейчас — заплатить за подписку и через год не суметь сказать, что она дала. Не дожидаясь предложений с оплатой за результат, начните строить точку отсчёта своими руками уже сейчас. Зафиксируйте три-четыре цифры «как есть»: сколько обращений приходит, сколько теряется, какой средний срок реакции, какая доля доходит до сделки. Это дешёвая работа, которую можно сделать за месяц на текущих данных. Когда первый продавец придёт с договором об оплате за результат, у вас на руках будет своя точка отсчёта — и вы будете спорить о цене с позиции силы, а не верить чужим цифрам. Второй тест: спросите любого нынешнего поставщика, готов ли он привязать часть оплаты к измеримой метрике. Отказ — не приговор, но он показывает, уверен ли поставщик в собственном результате. Общая логика для обеих ролей одна. Сегодня преимущество у того, кто измеряет. Продавец, который умеет честно посчитать результат, первым сможет продавать его. Покупатель, который знает свою точку отсчёта, первым перестанет переплачивать за обещания. Атрибуция — это не бухгалтерская формальность, это рычаг, который сейчас лежит без хозяина. ## Сигналы, по которым окно начнёт закрываться Один сигнал стоит отслеживать прямо: первый публичный кейс, где вертикальный российский игрок — будь то существующий лидер ниши или свежепрофинансированный стартап — привяжет контракт к целевому показателю или гарантии уровня сервиса (KPI/SLA) с формулой «платите за результат». В разговорах о том, как зарабатывать на нейросетях в 2026 году, российские авторы уже обсуждают переход от подписки к оплате за исход как «следующую волну» ([vc.ru](https://vc.ru/ai/2945426-kak-zarabotat-na-neyrosetyakh)). Появление профильного венчурного фонда под бизнесы на агентах ускоряет этот момент: финансируемый игрок может позволить себе риск договора об оплате за результат, который не тянет компания на собственные средства. Стоит помнить и более широкий контекст, который сформулировал аналитик Бен Томпсон: «когда базовая технология становится доступна всем, ценность уходит вверх по стеку — к интеграции и отношениям с клиентом» ([Stratechery](https://stratechery.com/)). Оплата за результат — частный случай этого сдвига: она достаётся тому, кто владеет методикой измерения, а не тому, у кого лучше модель. Тот же принцип работает и внутри России: [прозрачная цена побеждает умную модель](https://notes.temadev.org/2026/06/prozrachnaya-cena-pobezhdaet-umnuyu-model), потому что покупатель всё чаще хочет понимать, за что именно платит. В России эта методика измерения пока ничья. Это и делает ближайшие месяцы важными — для тех, кто строит, и для тех, кто покупает. ## Главное - На глобальном рынке вертикального AI оплата за результат — норма для зрелых игроков; в России на июнь 2026 года эта ниша публично пуста. - Деньги и спрос в категории уже есть: профильный венчурный фонд с чеками до 100 млн ₽ и рынок ИИ-ассистентов около 30 млрд ₽ к концу 2026 года. - Лидеры рынка продают подписку, токены и обещание «сэкономить до 15 часов в неделю» — но не подтверждённый результат. - Барьер не в нежелании, а в трёх отсутствующих компонентах: измеримой точке отсчёта, честной атрибуции и контрактной зрелости малого бизнеса. - Преимущество сейчас у того, кто измеряет: продавец, умеющий честно посчитать результат, первым его продаст; покупатель, знающий свою точку отсчёта, первым перестанет переплачивать. ## FAQ **Что такое оплата за результат (outcome-pricing)?** Модель ценообразования, при которой покупатель платит не за доступ к инструменту или потраченное время, а за подтверждённый бизнес-итог — решённое обращение, квалифицированный лид, процент от сэкономленных или заработанных денег. **Почему её нет на российском рынке B2B AI?** Не из-за нежелания платить. Оплата за результат требует измеримой точки отсчёта до внедрения, прозрачной методики атрибуции и зрелого договора. У большинства российских малых компаний этих трёх компонентов пока нет, поэтому рынок оседает на подписке как пути наименьшего сопротивления. **Что делать покупателю прямо сейчас?** Строить свою точку отсчёта своими руками: зафиксировать три-четыре цифры «как есть» (объём обращений, доля потерь, срок реакции, конверсия) на текущих данных. Когда придёт первое предложение с оплатой за результат, у вас будет собственная точка отсчёта для переговоров. **Когда окно закроется?** Сигнал — первый публичный кейс, где вертикальный российский игрок привяжет контракт к целевому показателю или гарантии уровня сервиса с формулой «платите за результат». Появление венчурного капитала под бизнесы на агентах этот момент ускоряет. --- ## Note 6: 29% сотрудников саботируют AI — и они ведут себя рационально **URL:** https://notes.temadev.org/2026/06/ai-sabotage-rational-resistance-2026.html **Published:** 2026-06-19 **Genre:** contrarian-take **Tags:** ai-adoption, change-management, enterprise-ai, b2b, organizational-behavior **Words:** 2340 **Summary:** Сопротивление AI обычно трактуют как проблему персонала. Данные говорят, что это рациональный ответ на провал управления изменениями. # 29% сотрудников саботируют AI — и они ведут себя рационально ## Что именно показал опрос Writer В апреле 2026 года компания Writer и исследовательская фирма Workplace Intelligence [опубликовали](https://writer.com/blog/enterprise-ai-adoption-survey-results-press-release/) данные опроса об AI-внедрениях в крупных компаниях США. Главная цифра разошлась по деловым изданиям за сутки: 29% сотрудников признались, что намеренно мешают AI-стратегии своего работодателя — среди поколения Z доля доходит до 44%. «Саботаж» здесь — исследовательский термин самого опроса: под ним авторы понимают сознательные действия, от ввода заведомо некорректных данных в корпоративные модели до тихого отказа использовать внедрённые инструменты. [Fortune](https://fortune.com/2026/04/08/gen-z-workers-sabotage-ai-rollout-backlash/) и [Fast Company](https://www.fastcompany.com/91526107/nearly-a-third-of-workers-sabotage-their-companys-ai-strategy) подали это как историю о бунте младших сотрудников, которые боятся потерять работу. Это правдоподобно и совершенно недостаточно как объяснение. Тот же опрос содержит вторую половину картины, которую цитируют гораздо реже. В выборке руководителей высшего звена около 60% заявили, что готовы увольнять или не продвигать сотрудников, отказывающихся работать с AI. И значительная часть этих же руководителей признала, что их собственная AI-стратегия ближе к декларации, чем к работающей системе — то, что в деловой прессе закрепилось как «AI-washing»: публичная демонстрация AI-трансформации без реального изменения процессов. Если держать обе цифры в одном кадре, история про «сотрудники не доросли до технологии» рассыпается. Перед нами не дефицит грамотности, а рациональный расчёт людей, которые точно поняли, в какую игру их поставили. ## Почему скептицизм здесь — оптимальная стратегия Рассмотрим положение рядового сотрудника глазами теории решений, а не корпоративной риторики. Ему сообщают одновременно две вещи. Первая: компания внедряет AI, и отказ работать с ним угрожает его позиции — это явно сказали 60% руководителей. Вторая: внедряемый инструмент в большинстве случаев сырой, потому что сама организация не довела стратегию до рабочего состояния. Сотрудник оказывается в ситуации, где его просят добровольно ускорить процесс, исход которого для его роли в лучшем случае неясен, а в части сценариев прямо враждебен. В этой конфигурации скептицизм — это не иррациональное упрямство, а доминирующая стратегия. Активное участие в плохо спроектированном внедрении несёт два риска: помочь автоматизировать собственную функцию и при этом получить инструмент, который не работает, но за пользование которым теперь спрашивают. «Саботаж» — ввод мусорных данных, демонстративное игнорирование, тихий отказ — это способ снизить личный риск в системе, где сама система не дала никаких гарантий. Низкая цифровая грамотность — это неумение пользоваться инструментом. Здесь же сотрудники прекрасно понимают инструмент; они отказываются не от технологии, а от сделки, в которой все риски переложены на них. Особенно показателен возрастной перекос. То, что доля сопротивляющихся среди поколения Z вдвое выше средней (44% против 29%), деловая пресса прочитала как «молодёжь капризничает». Более точное прочтение обратное: младшие сотрудники сильнее всего чувствуют угрозу, потому что их функции — первичная обработка данных, черновые тексты, типовая коммуникация — это ровно те задачи, которые модели снимают первыми. Их сопротивление — не незрелость, а лучшая в выборке калибровка на собственный риск. Они саботируют активнее, потому что им есть что терять раньше остальных, и они это понимают точнее старших коллег, чьи функции пока вне зоны автоматизации. Это смещает диагноз. Проблема не в персонале и не в технологии. Проблема в том, что между «компания решила внедрить AI» и «сотрудник согласился в этом участвовать» нет ни одного звена, которое отвечало бы на единственный важный для сотрудника вопрос: что будет с моей ролью. Управление изменениями (change management) как раз должно строить это звено. Его отсутствие — управленческий провал, а сопротивление — его симптом, а не причина. ## Данные о провале внедрений подтверждают расчёт сотрудника Скепсис сотрудника был бы паранойей, если бы внедрения в среднем работали. Они в среднем не работают, и это хорошо измерено. Самая цитируемая цифра 2025 года пришла из исследования инициативы Nanda при MIT — отдельной программы лаборатории, которая изучала отдачу от корпоративных AI-проектов. По данным разбора, который [пересказал Forbes](https://www.forbes.com/sites/jasonsnyder/2025/08/26/mit-finds-95-of-genai-pilots-fail-because-companies-avoid-friction/), около 95% корпоративных пилотов генеративного AI не дали измеримого финансового результата — при совокупных вложениях в 30–40 миллиардов долларов значимую отдачу зафиксировали лишь около 5% проектов. Важна не сама цифра 95%, а причина, которую вывели авторы: проекты проваливались не из-за слабости моделей, а из-за того, что компании избегали трудной части — перестройки процессов и обучения системы на реальных рабочих сценариях. Один из исследователей программы сформулировал это прямо: разрыв проходит не по линии качества моделей, а по линии готовности организации менять то, как она работает. McKinsey в [исследовании «The State of AI»](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) за ноябрь 2025 года зафиксировала ту же трещину с другой стороны. AI в том или ином виде используют около 88% опрошенных организаций, но лишь 39% сообщают о заметном влиянии на прибыль на уровне предприятия, и только около 6% компаний McKinsey относит к «AI high performers» — тем, у кого эффект превышает 5% операционной прибыли. Разрыв между почти всеобщим внедрением и единичными случаями реального эффекта аналитики McKinsey описывают прямо: для большинства организаций использование AI пока не отразилось на показателе EBIT — операционной прибыли до вычета процентов и налогов — в масштабах компании. Сложите две цифры: 88% внедрили, 6% получили результат. Это и есть статистическое выражение «AI-washing» — внедрение состоялось как факт, но не как результат. И есть третья цифра, которая замыкает картину и идёт из первоисточника. В официальном [пресс-релизе опроса](https://www.businesswire.com/news/home/20260407140918/en/WRITER-Survey-Finds-60-of-Companies-Plan-to-Lay-Off-Employees-Who-Wont-Adopt-AI) Writer и Workplace Intelligence формулируют разрыв прямо: 69% руководителей высшего звена сообщили, что их компания уже проводит увольнения из-за AI, но 39% из них признались, что формальной AI-стратегии у них нет. Сокращают под лозунгом, который сами не довели до плана. Именно этот разрыв сотрудник и считывает безошибочно. Теперь вернёмся к сотруднику. Ему предлагают приложить усилия к инициативе, которая по объективным данным с вероятностью около девяти из десяти не даст бизнес-результата, но при этом несёт личный риск для его роли. Его отказ — не слепота, а корректная оценка базовых вероятностей. Он ведёт себя ровно так, как ведёт себя человек, которому предложили вложиться в проект с отрицательным ожидаемым исходом для него лично. Цифры провала внедрений и цифры сопротивления — это не два разных сюжета. Это одна и та же реальность, измеренная с двух концов. ## Что на самом деле покупает сотрудник, когда соглашается на AI? Если перевернуть оптику, видно, что неудачные внедрения совершают одну общую ошибку: они продают сотруднику технологию, тогда как купить он готов совсем другое. Сотрудник никогда не хотел «модель». Модель — это инфраструктура, и для него она так же абстрактна, как марка стали в перекрытиях офиса. Он готов отдать деньги — в валюте внимания, усилий и лояльности — за две конкретные вещи. Первая: избавление от рутины, которая отнимает часы и не требует его как профессионала. Вторая, и более важная: безопасность роли — гарантия, что после внедрения его работа станет лучше, а не исчезнет. Внедрение, которое начинается со слов «мы ставим AI» и заканчивается угрозой «не освоишь — уволим», не продаёт ни того, ни другого. Оно требует от сотрудника оплатить чужой риск его собственной безопасностью. | Что внедряет организация | Что сотрудник готов «купить» | Что происходит при разрыве | |---|---|---| | Доступ к модели и интерфейс | Избавление от рутины и безопасность роли | Формальное использование без вовлечённости | | KPI «процент сотрудников, использующих AI» | Понимание, что будет с его функцией | Накрутка метрики, «саботаж» данных | | Угроза увольнения за отказ | Гарантия улучшения, а не замены | Скрытое сопротивление, отток | | Презентация AI-трансформации совету | Видимый личный выигрыш в работе | Разрыв между декларацией и практикой | Эта таблица описывает механику провала точнее, чем «сотрудники сопротивляются переменам». Сотрудники не сопротивляются переменам — они сопротивляются переменам, в которых их роль превращена в переменную для оптимизации, а не в сторону, чьи интересы учтены. Там, где внедрение начинается с ответа на вопрос «что станет с твоей работой», и где этот ответ подкреплён практикой, сопротивление падает — потому что сделка наконец становится симметричной. ## Это не проблема персонала. Это провал проектирования У провала внедрений есть инженерная природа, и она роднит его с провалом любого недоспроектированного продукта. Инженеры Anthropic в [руководстве по построению агентных систем](https://www.anthropic.com/research/building-effective-agents) формулируют принцип, который выходит за рамки чистой техники: «самые успешные внедрения, — пишут они, — используют не сложные фреймворки, а простые, компонуемые паттерны», а рекомендация прямая — начинать с самого простого решения и наращивать сложность только по мере необходимости. Общий смысл: надёжные системы получаются там, где сложность вводится только под доказанную задачу, а каждый шаг прозрачен и проверяем человеком. Перенесите это на организацию — и «внедрение AI ради внедрения», без привязки к конкретному болезненному процессу и без прозрачности для исполнителя, нарушает оба принципа. Получается система, которая непрозрачна для того, кто в ней работает, и не привязана к задаче, которую он считает своей. Сопротивление такой системе — не баг персонала, а корректная реакция на плохой дизайн. Отсюда следуют конкретные проверки. Для исполнительного руководителя, ведущего внедрение: метрика «процент сотрудников, использующих AI» вредна, потому что она поощряет ровно то поведение, которое маскирует провал — формальное использование без результата. Полезная замена — две метрики, которые трудно накрутить: сколько часов рутины реально снято с конкретных ролей и сколько сотрудников могут назвать процесс, который стал для них лучше после внедрения. Если первая метрика растёт, а вторая — нет, перед вами AI-washing, и сопротивление, которое вы наблюдаете, заслуженно. Для основателя, который строит AI-продукт для бизнеса: цифра 29% — это не риск, а карта спроса. Она показывает, что покупатель внутри организации — не только подписавший контракт руководитель, но и сотрудник, чьё участие нельзя купить угрозой. Продукт, который продаёт сотруднику безопасность роли и снятие рутины напрямую — а не «мощь модели» через голову руководителя, — обходит главную причину провала конкурентов. Это, в свою очередь, требование к архитектуре: продукт должен встраиваться в конкретный болезненный процесс и показывать исполнителю личный выигрыш в первые дни, а не в годовой презентации совету директоров. Ровно так — берём один измеримый процесс и собираем вокруг него AI-контур, который ведёт его сам, — мы и строим такие контуры как рабочие системы, а не как пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=ai-sabotage-rational-resistance-2026&utm_content=inprose). Для основателя на стадии масштабирования: внедрение, прошедшее через сопротивление и выжившее, оставляет след — накопленные сценарии реальной работы, в которых видно, какие задачи система сняла, а какие нет. Этот след сам по себе становится активом и защитой, и эта логика подробно разобрана в разборе [«Вертикальный AI» уже не значит то, что вы думаете](https://notes.temadev.org/2026/05/vertical-operating-layer-beats-horizontal-product.html). Сопротивление, отработанное правильно, — это не потерянное время, а первый цикл сборки того, что потом нельзя скопировать. Есть и обратное следствие, неудобное для части рынка. Если 29% сопротивления — это сигнал о провале change management, то поставщик, продающий «AI-трансформацию» через презентацию совету директоров, продаёт ускорение этого провала. Угроза увольнения за отказ от AI, которую готовы применять 60% руководителей, — это попытка решить управленческую задачу административным насилием. Она работает на коротком горизонте как накрутка метрики использования и не работает на длинном: формально вовлечённый, но внутренне сопротивляющийся сотрудник производит ровно тот мусор в данных, на котором потом обучается негодная система. Принуждение здесь не обходит провал проектирования, а консервирует его, маскируя цифрой охвата. ## За чем стоит следить дальше Три сигнала покажут, движется ли рынок к зрелости или остаётся в фазе AI-washing. Первый — изменится ли формулировка корпоративных метрик: уход от «процента пользователей» к измерению снятой рутины будет означать, что организации признали разрыв. Второй — появится ли в продуктах для бизнеса явная адресация сотрудника как стороны сделки, а не только покупателя-руководителя. Третий, самый медленный, — разойдётся ли на двое рынок поставщиков: на тех, кто продаёт «трансформацию» совету директоров, и на тех, кто продаёт измеримый сдвиг в конкретном процессе исполнителю. Первые живут на бюджете пока он есть; вторые накапливают тот самый след реальной работы, который со временем нельзя скопировать. Пока коммуникация строится вокруг «модели», а не вокруг «что будет с твоей работой», цифра сопротивления будет держаться, и держаться она будет заслуженно. ## FAQ **Что такое «саботаж AI» в контексте этого опроса?** «Саботаж» — исследовательский термин самого опроса Writer и Workplace Intelligence. Под ним понимают сознательные действия сотрудников против AI-инициатив работодателя: ввод заведомо некорректных данных, игнорирование внедрённых инструментов, тихий отказ от обучения. Это не диверсия в юридическом смысле, а поведенческий паттерн снижения личного риска. **Почему сопротивление называют рациональным, а не иррациональным?** Потому что сотруднику одновременно сообщают две вещи: отказ работать с AI угрожает его позиции (это явно сказали 60% руководителей), но сам инструмент в большинстве случаев сырой. В такой конфигурации скептицизм — это доминирующая стратегия: сотрудник отказывается не от технологии, а от сделки, в которой все риски переложены на него. **Почему у поколения Z доля сопротивления вдвое выше?** 44% против 29% в среднем — не «молодёжь капризничает». Младшие сотрудники сильнее всех чувствуют угрозу, потому что их функции — первичная обработка данных, черновые тексты, типовая коммуникация — ровно те задачи, которые модели снимают первыми. Их сопротивление — не незрелость, а лучшая в выборке калибровка на собственный риск. **Что делать руководителю, чтобы снизить сопротивление?** Отказаться от метрики «процент сотрудников, использующих AI» — она поощряет формальное использование без результата. Заменить её двумя, которые трудно накрутить: сколько часов рутины реально снято с конкретных ролей и сколько сотрудников могут назвать процесс, который стал для них лучше после внедрения. Растёт первая, а вторая нет — перед вами AI-washing. ## Главное - Опрос Writer и Workplace Intelligence 2026 зафиксировал, что 29% сотрудников (44% среди поколения Z) намеренно мешают AI-внедрениям. Стандартное объяснение через «низкую цифровую грамотность» не выдерживает второй цифры из того же опроса: 60% руководителей готовы увольнять отказников. - В системе, где сотруднику угрожают за отказ, но дают сырой инструмент, скептицизм — оптимальная стратегия, а не дисфункция. Сотрудники понимают технологию; они отказываются от сделки, в которой все риски переложены на них. - Данные о провале внедрений подтверждают расчёт: около 95% пилотов генеративного AI (по разбору MIT) не дали финансового результата, и лишь 39% компаний (McKinsey) видят влияние AI на прибыль на уровне предприятия. - Организация продаёт сотруднику технологию, а купить он готов избавление от рутины и безопасность роли. Внедрение, которое не отвечает на вопрос «что будет с моей работой», получает сопротивление по построению. - Практический сдвиг: заменить метрику «процент использующих AI» на «снятые часы рутины» и «число ролей, которым стало лучше»; строить продукт вокруг исполнителя, а не через его голову. --- ## Note 7: Прозрачная цена побеждает умную модель **URL:** https://notes.temadev.org/2026/06/prozrachnaya-cena-pobezhdaet-umnuyu-model.html **Published:** 2026-06-16 **Genre:** contrarian-take **Tags:** b2b-ai, pricing, downside-risk, smb, sales, russia **Words:** 2406 **Summary:** Почему предложение с понятным потолком расходов обходит экономически более выгодное, и что покупатель на самом деле берёт в сделке вместо лучшего результата. # Прозрачная цена побеждает умную модель Российский вендор AI-чата для автобизнеса публично продаёт услугу по схеме «8 000 ₽ в месяц плюс 400 ₽ за целевой чат» — оплата срабатывает, когда клиент оставил телефон ([RECONNECT](https://cdplatform.ru/chat)). Экономически это близко к идеалу для покупателя: платишь за то, что действительно произошло, риск переплаты за пустую работу минимален. Рядом другой игрок просит фиксированные «28 000 ₽ в месяц за одного робота, плюс 14 000 ₽ за каждого следующего» ([ANDES AI](https://andescrm.ru/plan)) — без всякой привязки к результату. С точки зрения чистой экономики первая модель почти всегда выгоднее владельцу: он не платит за месяцы, когда лидов мало. И тем не менее в реальных переговорах нетехнический собственник раз за разом тянется ко второй. Это не иррациональность. Это разумное поведение покупателя, который оптимизирует не ту переменную, которую вендор считает главной. Поставщик продаёт лучший результат на единицу денег. Покупатель покупает предсказуемость худшего случая. И когда эти две оптимизации сталкиваются в одной сделке, выигрывает та, что снимает страх, а не та, что обещает выгоду. ## Что покупатель на самом деле берёт в сделке Начнём с определений, потому что в этой теме слова путаются чаще, чем цифры. **Оплата за результат (outcome-based)** — это модель, при которой поставщик берёт деньги только после того, как достигнут заранее оговорённый измеримый исход: закрытое обращение, назначенная встреча, удержанный клиент. **Прозрачная цена (фиксированная с потолком)** — это модель, в которой покупатель до подписания знает либо точную сумму, либо её верхнюю границу, выше которой счёт не уйдёт ни при каком сценарии. **Непрозрачная цена** — это любая схема, где итоговая сумма зависит от переменных, которые покупатель не может посчитать сам в момент решения: «зависит от объёма», «посчитаем по факту», «обсудим после пилота». Бизнес-логика отрасли последние два года толкает рынок в сторону первой модели. На стороне вендора оплата за результат выглядит честнее всего: ты берёшь деньги ровно за ту работу, которую сделал, и совпадаешь с ценностью клиента до копейки. Сам выбор единицы, за которую поставщик берёт деньги — потребление, процесс или результат — [мы разбирали отдельно как главное решение со стороны вендора](https://notes.temadev.org/2026/05/seat-pricing-unit-dead-outcome-based-ai). Но у сделки две стороны, и вторая ведёт себя ровно наоборот. Когда нетехнический владелец смотрит на оплату за результат, он видит не выравнивание интересов. Он видит открытую сумму. «400 ₽ за целевой чат» при неизвестном заранее числе чатов — это счёт, который он не может закрыть в голове до того, как подписал договор. А неспособность посчитать верхнюю границу расхода для собственника малого бизнеса — это не неудобство, это сигнал опасности. Он уже видел, как «по факту» превращается в сумму, которую он бы не утвердил, если бы увидел её заранее. ## Цифры, которые ломают логику «лучшая модель победит» Здесь полезно посмотреть на данные, потому что интуиция вендора и поведение покупателя расходятся не на проценты, а в разы. Boston Consulting Group в работе [Rethinking B2B Software Pricing in the Agentic AI Era](https://www.bcg.com/publications/2025/rethinking-b2b-software-pricing-in-the-era-of-ai) приводит результаты опроса покупателей: **47% не могут определить чёткий измеримый результат**, на который можно повесить оплату; **36% боятся непредсказуемости цены** при результат-модели; **24% признают, что результат зависит от факторов вне контроля поставщика** — сезонность спроса, качество входящего трафика, действия конкурентов. BCG формулирует это прямо: «переход к оплате за результат сложен потому, что покупатели и поставщики часто не могут согласовать, какой результат измерять и кто за него отвечает». Сложите эти три числа в один портрет, и оплата за результат рассыпается ещё до разговора о ставке. Почти половина покупателей физически не может назвать метрику, к которой её привязать. Треть боится, что счёт окажется выше ожидаемого. Четверть понимает, что даже идеальный поставщик не управляет исходом полностью — а значит, платить за исход означает платить за чужую погоду. Это не возражения, которые снимаются хорошей презентацией. Это структурные причины, по которым «самая честная» модель оказывается самой пугающей. С другой стороны воронки данные так же однозначны. По сводке отраслевой статистики B2B-покупок, **около 74% покупателей ждут чёткую и детальную цену заранее** ([Mixology Digital](https://mixology-digital.com/blog/must-know-stats-about-b2b-buying)). Доля тех, кто готов принять размытое ценообразование даже при отличном решении, исчезающе мала — единицы процентов. Это согласуется с тем, что фиксирует Gartner: 61% покупателей B2B предпочитают полностью самостоятельный, без продавца, процесс покупки ([Gartner](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-sales-survey-finds-61-percent-of-b2b-buyers-prefer-a-rep-free-buying-experience)). А пройти этот путь самостоятельно можно только там, где цена видна без звонка продавцу. А пройти путь самостоятельно можно только там, где цена видна. Схема «свяжитесь с нами, чтобы узнать стоимость» не просто раздражает — она выбивает поставщика из той части воронки, где покупатель принимает большинство решений в одиночку. Получается ножницы. Со стороны поставщика рынок движется к оплате за результат как к самой выгодной для клиента модели. Со стороны покупателя три четверти ждут заранее названную цифру, а почти половина не способна даже сформулировать результат, на котором эта оплата строится. Лучшая по экономике модель упирается в стену психологии раньше, чем дойдёт до сравнения ставок. ## Риск убытка — это и есть продукт Чтобы понять, почему так происходит, нужно перестать считать, что собственник максимизирует ожидаемую выгоду. Он минимизирует **риск убытка (downside)** — величину худшего исхода, который с ним может случиться, если сделка пойдёт не так. И это рационально для человека, у которого нет резерва на эксперименты. Эту асимметрию хорошо описал психолог Даниэль Канеман, получивший Нобелевскую премию за теорию перспектив: «потери маячат больше, чем равные им приобретения». Для собственника, у которого один кошелёк, переплата по открытому счёту бьёт сильнее, чем радует экономия в хороший месяц. Различие тонкое, но оно объясняет всё. Покупатель с большим балансом и портфелем поставщиков действительно выбирает по ожидаемой выгоде: на длинной дистанции выгодные ставки усредняются в его пользу. У собственника малого или среднего B2B нет длинной дистанции и нет портфеля. У него один кошелёк, один договор и одно «если не сработает, я потеряю деньги, которые планировал на другое». Для него каждая сделка — это не ставка в серии, а единичное событие, и проигрыш в нём ощущается несимметрично тяжелее, чем равный по размеру выигрыш. Поэтому он покупает не максимум вверху, а гарантию внизу. Прозрачная цена с потолком продаёт ровно эту гарантию. «Не больше такой-то суммы, что бы ни случилось» — это не строчка в прайсе, это снятый страх. Две модели различаются не ставкой, а тем, какую переменную они оставляют открытой для покупателя. | Параметр | Прозрачная цена (фиксированная с потолком) | Оплата за результат (outcome-based) | |---|---|---| | Что оптимизирует | предсказуемость худшего случая | ожидаемую выгоду на единицу денег | | Верхняя граница счёта | известна до подписания | открыта, зависит от объёма | | Кто несёт риск переменности | поставщик | покупатель | | Кому выгоднее в среднем | поставщику | покупателю | | Кому спокойнее | покупателю | поставщику | | Где продаётся лучше | нетехнический владелец, малый и средний бизнес | зрелый покупатель с измеримой метрикой | Таблица показывает главное: «лучше» у этих двух моделей — про разных людей. Оплата за результат «лучше» для того, кто играет в серии ставок; прозрачная цена «лучше» для того, у кого каждая сделка — единичное событие. Оплата за результат, наоборот, оставляет нижнюю границу открытой: в хорошем сценарии она дешевле, но в плохом — счёт может уйти куда угодно, и собственник это знает. Он выбирает модель, которая защищает его от худшего дня, а не ту, что выигрывает в средний. Это совпадает с тем, что владельцы говорят о себе в других опросах. По данным [QuickBooks](https://quickbooks.intuit.com/r/small-business-data/april-2025-survey/), собственники малого бизнеса формулируют ценность AI через сокращение собственной нагрузки и контроль над операцией, а не через абстрактную отдачу на вложение. Gallup в свою очередь показывает, что выгоды AI ощущаются [на уровне отдельных задач, а не как трансформация всей организации](https://www.gallup.com/workplace/699689/ai-use-at-work-rises.aspx) — то есть владелец мыслит конкретными, ограниченными изменениями, а не открытыми обещаниями. Человек, который ценит контроль выше технологии, не отдаст контроль над собственным счётом в обмен на статистически лучшую цену. Контроль над расходом для него и есть часть продукта. Стоит заметить ловушку, в которую тут попадает грамотный продавец. Чем убедительнее он доказывает, что оплата за результат выгоднее, тем сильнее подсвечивает, что выгода зависит от исхода, которым он не управляет полностью. Хорошая математика выгоды одновременно является хорошей математикой риска — и покупатель, который не дурак, читает второе. Поэтому презентация «смотрите, как вам это выгодно» нередко проваливает сделку, которую бы закрыла одна строчка «вот фиксированная цена, выше не будет». У этой асимметрии есть и второй, менее очевидный слой — репутационный. Собственник малого бизнеса принимает решение не в вакууме: за плохой выбор он отвечает перед партнёром, бухгалтером, иногда перед собственной семьёй. Объяснить «я взял фиксированный тариф и потратил ровно столько, сколько обещал» легко. Объяснить «счёт оказался втрое больше, потому что так лёгла модель» — значит признать, что подписал то, чего не понимал. Предсказуемый счёт защищает не только кошелёк, но и репутацию того, кто подписал. Для человека, который в одном лице и распоряжается бюджетом, и отвечает за него, это не второстепенный фактор. ## Как прозрачность цены проявляется на российском рынке прямо сейчас? Российский рынок AI-решений для B2B уже расставлен по этой оси, даже если игроки не формулируют её вслух. Конструкторы и продуктизированные ассистенты продают предсказуемость: «2 999 ₽ в месяц», «28 000 ₽ в месяц за робота» ([Salebot](https://salebot.pro/), [ANDES AI](https://andescrm.ru/plan)). Это цены, которые покупатель видит на странице и закрывает в голове за тридцать секунд. Гибридные и результат-модели существуют, но занимают узкую полосу — там, где исход действительно измерим и где у покупателя хватает зрелости его сформулировать. Характерно, что даже вендоры, которые продают по результату, страхуют покупателя снизу. Та же схема «8 000 ₽ в месяц плюс 400 ₽ за целевой чат» ([RECONNECT](https://cdplatform.ru/chat)) — это не чистая оплата за результат, а гибрид с фиксированной частью. Фиксированная часть здесь работает не как способ заработать, а как способ сделать счёт предсказуемым: покупатель знает минимум, который заплатит, и понимает логику переменной части. Рынок интуитивно нащупал то, что подтверждают опросы: чистая оплата за исход без понятного дна продаётся плохо, потому что оставляет покупателя наедине с открытой суммой. Из этого же следует, почему «свяжитесь с нами для расчёта» проигрывает странице с цифрами. В сегменте, где покупатель привык самостоятельно сравнивать поставщиков до первого звонка, отсутствие цены читается не как премиальность, а как «здесь будет дорого и непонятно». Непрозрачность не повышает воспринимаемую ценность — она повышает воспринимаемый риск. А риск, как мы видели, и есть та переменная, которую покупатель минимизирует в первую очередь. Диапазоны публичных российских вендоров интересны и тем, как они расположили предсказуемость по слоям. В нижнем сегменте цена проста и названа целиком — «990 ₽ в месяц», «2 999 ₽ в месяц» у конструкторов. В среднем появляется плата за настройку плюс ежемесячная поддержка, но всё равно с названными заранее числами — порядка нескольких десятков тысяч рублей за настройку и от десяти тысяч в месяц за поддержку у интеграторов amoCRM и Bitrix24. Слово «от» здесь — единственная трещина в прозрачности, и оно же — главная точка трения на переговорах: покупатель понимает, что «от» редко означает самую низкую цифру. Поэтому выигрывают те, кто умеет быстро превратить это «от» в конкретную верхнюю границу для конкретного покупателя, а не оставляют его висеть в воздухе. ## Что с этим делать двум разным людям Для нетехнического владельца B2B следствие практическое. Когда вы выбираете между двумя поставщиками, проверьте, не наказываете ли вы более выгодное предложение за то, что оно честнее показывает риск. Сделайте обратное тому, к чему тянет инстинкт: возьмите модель оплаты за результат и сами посчитайте её верхнюю границу в худшем для вашего кошелька сценарии — максимум обращений, максимум целевых действий за месяц. Если эта цифра вас устраивает, страх был о неизвестности, а не о деньгах, и его можно снять одним вопросом поставщику: «назови мне потолок». Хороший поставщик его назовёт. Тот, кто уходит от прямого ответа про верхнюю границу, продаёт вам не гибкость, а собственную неготовность отвечать за результат. Для основателя или агентства, которое упаковывает цену, следствие жёстче. Вы можете построить экономически безупречную модель оплаты за результат и проиграть сделку человеку с прайс-листом из трёх строк. Поэтому первый продаваемый артефакт — не ставка, а потолок. Назовите верхнюю границу расхода раньше, чем начнёте объяснять выгоду: сначала «выше этой суммы счёт не уйдёт», потом «а вот насколько он окажется ниже в хорошем сценарии». Этот порядок не косметический — он меняет то, что покупатель чувствует в момент решения. Если вы хотите продавать по результату, привяжите его к метрике, которую покупатель может посчитать сам, и поставьте под результат-частью фиксированное дно. Чистая оплата за исход без потолка — это продукт для зрелого покупателя, который умеет считать свой риск. Таких в нетехническом B2B меньшинство, и строить под них стандартное предложение — значит оптимизировать под клиента, которого у вас в воронке почти нет. ## Главное - Нетехнический владелец B2B минимизирует не цену, а риск убытка (downside) — величину худшего исхода. Поэтому фиксированная цена с понятным потолком выигрывает сделку у оплаты за результат, даже когда последняя в среднем дешевле. - Оплата за результат рассыпается до разговора о ставке: 47% покупателей не могут определить измеримый результат, 36% боятся непредсказуемости цены, 24% признают, что результат зависит от факторов вне контроля поставщика (BCG, 2025). - Около 74% покупателей B2B ждут чёткую цену заранее; схема «свяжитесь с нами для расчёта» выбивает поставщика из той части воронки, где покупатель решает в одиночку. - Первый продаваемый артефакт — не ставка, а потолок. Назовите верхнюю границу расхода раньше, чем начнёте объяснять выгоду. ## Вопросы и ответы **Почему владелец выбирает дороже, если результат-модель в среднем выгоднее?** Потому что он считает не средний месяц, а худший. У собственника малого и среднего бизнеса один кошелёк и нет портфеля сделок, чтобы усреднить риск. Открытая верхняя граница счёта для него — сигнал опасности, а не гибкость. **Значит ли это, что оплату за результат продавать нельзя?** Можно, но при двух условиях: результат привязан к метрике, которую покупатель посчитает сам, и под переменной частью есть фиксированное дно. Чистая оплата за исход без потолка — продукт для зрелого покупателя, умеющего считать свой риск; в нетехническом B2B таких меньшинство. **Почему страница без цены проигрывает странице с цифрами?** В сегменте, где покупатель сравнивает поставщиков самостоятельно до первого звонка, отсутствие цены читается не как премиальность, а как «здесь будет дорого и непонятно». Непрозрачность повышает не воспринимаемую ценность, а воспринимаемый риск. **Что спросить у поставщика, чтобы снять страх?** Один вопрос: «назови мне потолок». Хороший поставщик назовёт верхнюю границу расхода в худшем сценарии. Тот, кто уходит от прямого ответа про максимум, продаёт не гибкость, а собственную неготовность отвечать за результат. ## На что смотреть дальше Главный сигнал 2026 года будет в том, научатся ли вендоры оплаты за результат продавать потолок так же громко, как ставку. Пока что отрасль продаёт результат-модели через выгоду, и упирается в психологию риска. Тот, кто первым начнёт упаковывать оплату за исход как «фиксированный максимум плюс возврат, если получилось дешевле», снимет главный барьер — и заберёт ту часть рынка, которую сегодня по умолчанию забирают предсказуемые конструкторы. Второй сигнал — поведение покупателей по мере взросления рынка: если доля тех, кто умеет формулировать измеримый результат, начнёт расти быстрее 47-процентного барьера, окно для чистой оплаты за исход расширится. Если нет — прозрачная цена с потолком останется тем, что выигрывает сделку, даже когда проигрывает в калькуляторе. --- ## Note 8: Владелец покупает короткий день, а не AI **URL:** https://notes.temadev.org/2026/06/owner-pokupaet-korotkiy-den.html **Published:** 2026-06-11 **Genre:** concept-piece **Tags:** b2b-ai, sales, smb, ai-adoption, positioning, vertical-ai **Words:** 2360 **Summary:** Почему предложение, которое называет один измеримый сдвиг и понятный риск, обходит то, что показывает более умную модель. # Владелец покупает короткий день, а не AI В опросе Salesforce среди малого и среднего бизнеса [91% компаний, уже использующих AI, говорят, что он повышает выручку](https://www.salesforce.com/news/stories/smbs-ai-trends-2025/). В исследовании Reimagine Main Street, опубликованном в [пресс-релизе PayPal](https://newsroom.paypal-corp.com/2025-06-10-Beyond-Efficiency-Small-Businesses-Look-to-AI-for-Competitive-Edge,-New-Survey-Shows), 82% владельцев называют внедрение AI обязательным условием, чтобы остаться конкурентоспособными. Цифры выглядят как готовый рынок, который только ждёт продавца с правильным слайдом про модель. Но когда тех же владельцев спрашивают, что именно заставило их нажать на кнопку покупки, ответ редко звучит как «нам нужна более умная модель». Чаще звучит другое: «у меня перестал гореть вечер вторника». AI-трансформация — это управленческий нарратив о перестройке процессов компании вокруг искусственного интеллекта: новые роли, новые регламенты, новая структура работы. Для технологической компании это осмысленная рамка. Для владельца автосервиса, дистрибьютора стройматериалов или агентства недвижимости — это абстракция, за которую он не готов платить, потому что она не названа на языке его недели. Он платит за то, что у него есть имя: за упущенное обращение, которое вчера потеряли, за час, который ушёл на разнесение оплат вручную, за клиента, который ушёл к конкуренту, потому что ему не перезвонили за двадцать минут. ## Что владелец слышит, когда ему продают «трансформацию» Между двумя группами цифр зияет провал. С одной стороны — почти всеобщий оптимизм по поводу AI. С другой — данные о том, что этот оптимизм пока редко превращается в деньги на счёте. По данным McKinsey за 2025 год, лишь около 39% организаций сообщают о каком-либо влиянии AI на прибыль (EBIT), и у большинства из них это влияние ниже 5%. Boston Consulting Group в исследовании [Are You Generating Value from AI?](https://www.bcg.com/publications/2025/are-you-generating-value-from-ai-the-widening-gap) формулирует тот же разрыв жёстче: только 5% компаний извлекают из AI полную ценность в масштабе, 35% начинают её получать, а 60% видят минимальную отдачу или не видят её вовсе. Этот провал обычно объясняют техническими причинами: данные не готовы, модели не дотягивают, интеграции сложны. Но для нетехнического B2B-владельца причина проще и она лежит не в технике. Владельцу продают категорию, в которой он не живёт. «Трансформация», «автоматизация процессов», «AI-агенты» — это слова из мира поставщика, не из мира покупателя. У владельца нет проекта под названием «трансформация». У него есть день, который слишком длинный, маржа, которая тоньше, чем была год назад, и поток клиентов, который протекает в местах, которые он может перечислить по памяти. Та же BCG в работе [AI Adoption Puzzle](https://www.bcg.com/publications/2025/ai-adoption-puzzle-why-usage-up-impact-not) фиксирует характерный сдвиг: использование AI растёт, а влияние на бизнес — нет. Сотрудники применяют инструменты лично, точечно, для своих задач, но компания как система не меняется. Это и есть портрет покупки, сделанной по неправильной рамке: купили «инструмент» вместо того, чтобы закрыть конкретную операционную дыру. Инструмент работает, владелец доволен демонстрацией, а через квартал не может ответить на вопрос, что именно стало короче, дешевле или надёжнее. ## Триггер покупки — это потеря, у которой есть имя Решение о покупке у нетехнического владельца запускает не технология, а раздражение. Точнее — конкретная, повторяющаяся потеря, которую он уже научился терпеть, но которая каждую неделю напоминает о себе. Этих потерь, по сути, три типа, и они переводятся на язык, который владелец понимает без переводчика. ### Время: день, который не помещается в день Первый триггер — операционное время самого владельца или его ключевого человека. В малом бизнесе владелец часто остаётся самым дорогим и самым перегруженным узлом: он же продавец, он же координатор, он же контроль качества. [Опрос QuickBooks за апрель 2025 года](https://quickbooks.intuit.com/r/small-business-data/april-2025-survey/) показал, что 74% владельцев малого бизнеса, использующих AI, говорят о росте продуктивности — против 46% годом раньше. Но за словом «продуктивность» в голове владельца стоит не абстрактная метрика, а вполне физический образ: он уходит домой не в девять, а в семь. Покупка случается, когда поставщик называет именно этот сдвиг. Не «мы автоматизируем рутину», а «карточки клиентов и статусы по сделкам собираются сами, вы перестаёте сводить их руками по вечерам». Первое — категория. Второе — короткий день. Владелец платит за второе. ### Маржа: деньги, которые утекают между операциями Второй триггер — маржа, которую съедает ручной труд и ошибки на стыках. Здесь важно понимать структуру издержек малого бизнеса: она редко сосредоточена в одной большой статье, чаще размазана по десяткам мелких операций — перенос данных между системами, повторные звонки, исправление опечаток в документах, эскалации, которые не дошли вовремя. Каждая по отдельности ничтожна; в сумме они и есть разница между нормальной маржой и тонкой. Gallup в [исследовании применения AI на рабочем месте](https://www.gallup.com/workplace/699689/ai-use-at-work-rises.aspx) фиксирует рост частоты использования AI среди сотрудников в США, но та же серия отчётов показывает, что эффект концентрируется там, где инструмент встроен в ежедневный поток работы, а не лежит рядом с ним. Для владельца это переводится в прямой тест: помогает ли это конкретной операции, на которой бизнес теряет деньги, или это ещё одна вкладка, которую кто-то иногда открывает. Маржа — измеримая величина, и владелец, в отличие от инвестора, считает её каждый месяц. ### Клиенты: воронка, которая течёт в известных местах Третий триггер — потерянные клиенты. И это, как правило, самый острый из трёх, потому что владелец видит его лицом: вот лид, который написал ночью, а ответили ему в полдень следующего дня; вот клиент, который три раза просил счёт и ушёл к тому, кто выставил быстрее. В сервисных и торговых бизнесах скорость реакции — прямой денежный фактор, и владелец это знает на собственной шкуре, без отсылок к исследованиям. Когда поставщик говорит «вы перестанете терять входящие обращения ночью и в выходные», он попадает в нерв. Когда говорит «мы внедрим conversational AI поверх вашей воронки» — он промахивается мимо того же самого нерва, описывая ту же работу словом, которое для владельца пусто. Содержательно это одно и то же действие. Но первое предложение продано, а второе — нет. ## Почему «более умная модель» не выигрывает сделку? Поставщики AI инстинктивно соревнуются на оси, которая важна им и почти не важна покупателю: какая модель, какая архитектура, какой бенчмарк. Для нетехнического владельца все доступные на рынке модели находятся выше порога «достаточно умные» — он не отличит, да ему и не нужно. Его выбор делается на двух других осях. Первая ось — насколько точно названа потеря. Предложение, которое говорит «мы сократим ваш день на два часа за счёт автоматического сбора заявок из трёх каналов в одну ленту», выигрывает у предложения «мы внедрим интеллектуальную платформу», даже если за вторым стоит технически более мощное решение. Названная потеря создаёт доверие: владелец понимает, что поставщик видел его бизнес, а не пришёл с универсальным слайдом. Вторая ось — понятность риска. Владелец малого бизнеса живёт в режиме, где одна неудачная трата может стоить ему квартала. Поэтому его реальный вопрос звучит не «насколько это улучшит дела», а «сколько он теряет, если это не сработает». Предложение, которое честно очерчивает нижнюю границу — сколько стоит попробовать, как быстро видно результат, как откатиться, если не пошло, — обходит предложение, которое обещает только верх. Foundation Capital в [эссе про service-as-software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) описывает сдвиг от продажи инструмента к продаже готовой работы: клиент покупает результат, а не доступ. Для нетехнического владельца это и есть язык, на котором сделка вообще становится возможной — потому что результат у него уже измеряется, а «доступ к платформе» нет. Отсюда же — практический разрыв между демонстрацией и покупкой. Демонстрация модели впечатляет, но не двигает сделку, если она не привязана к одной названной потере. Владелец, посмотрев на умного агента, кивает и говорит «впечатляюще» — и не покупает, потому что не понял, какая именно его боль закрывается. Покупка случается на следующей фразе, когда поставщик переводит впечатление в конкретику: вот это уберёт вот этот ваш вечер. ## Как перевести названную потерю в рубли Названная потеря продаёт не потому, что она эмоциональна, а потому, что её можно посчитать при владельце за полторы минуты. Это ровно та работа, которую [McKinsey в обзоре The State of AI за 2025 год](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) называет условием отдачи: эффект на прибыль появляется там, где внедрение привязано к конкретной операции, а не к факту «внедрили AI». Именно арифметика, а не демонстрация, переводит «интересно» в «берём». Разберём на трёх типах потерь, чтобы было видно, как выглядит число, которое владелец узнаёт как своё. **Время.** Владелец, который каждый вечер тратит полтора часа на ручное сведение заявок и статусов, за месяц отдаёт этой рутине около 30 часов — почти четыре рабочих дня. Если час его времени как собственника-продавца стоит хотя бы 2000 рублей выручки, которую он не успевает сделать, рутина съедает 60 000 рублей в месяц. Это не «повышение продуктивности» — это конкретная строка, которую предложение обязано назвать. **Маржа.** Допустим, менеджер переносит данные между двумя системами вручную и ошибается в 2% случаев. На потоке в 500 документов в месяц это десяток ошибок, каждая из которых тянет за собой перевыставление счёта, извинения клиенту, иногда штраф или списание. Одна ошибка редко стоит меньше получаса чьего-то времени на разбор — и это без учёта репутационного хвоста. Предложение «перенос данных перестанет давать ошибки» бьёт точнее, чем «мы повысим точность операций», потому что первое называет именно ту операцию, на которой течёт маржа. **Клиенты.** Сервисный бизнес получает 100 обращений в месяц, из них 15 приходят ночью или в выходные, когда ответить некому. Если хотя бы треть из них уходит к тому, кто ответил быстрее, бизнес теряет пять сделок в месяц. При среднем чеке в 15 000 рублей это 75 000 рублей выручки, которая просто не случилась — каждый месяц. Владелец эту цифру не видит в отчёте, но он мгновенно узнаёт её, когда ему её посчитают вслух. Смысл этой арифметики не в точности цифр — они у каждого бизнеса свои. Смысл в том, что поставщик, который приходит с такой строкой, уже выиграл первый раунд доверия: он потрудился перевести своё предложение в единицы, в которых владелец и так считает свой бизнес. Поставщик, который остаётся на уровне «мы сделаем ваш бизнес эффективнее», этот раунд проиграл до начала разговора о модели. Берём один такой названный процесс — продажи, диспетчеризацию, операционку — и собираем вокруг него AI-контур, который ведёт его сам, как рабочую систему, а не как пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=owner-pokupaet-korotkiy-den&utm_content=inprose). ## Конкретные тесты для основателя и руководителя Для основателя AI-продукта, продающего нетехническому B2B, отсюда следует прямая проверка предложения. Прогоните своё текущее коммерческое предложение через один вопрос: названа ли в нём ровно одна потеря, которую владелец узнаёт как свою, на его словах, а не на ваших. Если в КП есть слова «трансформация», «платформа», «экосистема» и нет ни одной фразы про конкретный вечер, конкретный процент маржи или конкретный канал потерянных клиентов — предложение написано для другого покупателя. Второй тест: очерчена ли нижняя граница риска. Если клиент не может за тридцать секунд понять, во что ему обойдётся неудачная попытка и как из неё выйти, цикл сделки растянется на месяцы независимо от качества вашей модели. Для руководителя компании, которая оценивает покупку AI, тест зеркальный. Прежде чем смотреть на демонстрацию, выпишите на бумаге одну операционную потерю, которую вы хотите закрыть, и метрику, по которой через девяносто дней поймёте, закрылась ли она: часы, рубли маржи, доля удержанных обращений. Если поставщик не может привязать своё предложение к этой одной метрике — он продаёт вам категорию, а не результат, и почти наверняка вы окажетесь в тех 60% из данных BCG, у которых отдача минимальна. Покупка AI без названной потери — это покупка надежды, а не работы. Это согласуется с более широким сдвигом в том, [как AI-компания выбирает charge metric](https://notes.temadev.org/2026/05/seat-pricing-unit-dead-outcome-based-ai.html): счёт за доступ к инструменту постепенно проигрывает счёту за сделанную работу, и покупатель это чувствует раньше, чем формулирует. ## Сигналы 2026 года Два сигнала покажут, куда движется этот разрыв. Первый — будут ли поставщики массово переписывать свои предложения с языка технологии на язык операционной потери. Пока большинство публичных лендингов AI-продуктов для малого бизнеса всё ещё говорят про «возможности модели», а не про «вечер вторника» — окно для тех, кто говорит иначе, остаётся открытым. Второй сигнал — начнут ли владельцы требовать в договоре привязку к измеримому сдвигу, а не к факту внедрения. Как только это станет нормой переговоров, оптимизм из опросов начнёт конвертироваться в прибыль из отчётов McKinsey и BCG — и тогда разрыв между 91% довольных и 39% получивших эффект на прибыль начнёт сужаться. ## Главное - 91% малого бизнеса с AI говорят, что он повышает выручку (Salesforce), и 82% считают внедрение обязательным (Reimagine Main Street), но McKinsey фиксирует эффект на прибыль лишь у ~39% компаний — разрыв не технический, а в рамке покупки. - Non-tech владелец покупает не модель и не трансформацию, а сокращение одной названной потери: времени, маржи или клиентов. - BCG: только 5% компаний извлекают полную ценность AI, 60% — минимальную; типичная ошибка — купили инструмент вместо того, чтобы закрыть конкретную операционную дыру. - Сделку выигрывает не более умная модель, а предложение, которое точно называет потерю и честно очерчивает нижнюю границу риска. - Тест для обеих сторон: одна потеря, одна метрика, проверяемая за 90 дней. Нет метрики — покупается надежда, а не работа. ## FAQ **Что такое AI-трансформация и почему она плохо продаётся малому бизнесу?** AI-трансформация — это перестройка процессов компании вокруг искусственного интеллекта: новые роли, регламенты, структура работы. Для технологической компании это рабочая рамка. Для владельца нетехнического B2B это абстракция, не привязанная к его неделе: у него нет проекта «трансформация», у него есть длинный день, тонкая маржа и протекающая воронка. Поэтому предложение в терминах трансформации звучит для него как продажа категории, в которой он не живёт. **Почему более умная модель не гарантирует покупку?** Для нетехнического владельца все доступные модели находятся выше порога «достаточно умные», и он не выбирает по технике. Он выбирает по двум осям: насколько точно названа его потеря и насколько понятен риск неудачи. Предложение, которое называет конкретный сдвиг и нижнюю границу риска, обходит технически более сильное решение, описанное общими словами. **Когда этот фрейм неприменим?** Когда покупатель сам технологическая компания с внутренней экспертизой — там как раз разумно говорить про модели, архитектуру и масштабирование, потому что покупатель живёт в этой рамке. Фрейм «короткого дня» работает именно для нетехнического владельца, который измеряет бизнес часами, рублями и удержанными клиентами, а не бенчмарками. **Как измерить, что предложение названо правильно?** Простой тест: в коммерческом предложении должна быть ровно одна потеря, сформулированная словами покупателя, и одна метрика, проверяемая за 90 дней — часы, рубли маржи или доля удержанных обращений. Если в тексте есть «платформа» и «экосистема», но нет конкретного вечера, процента или канала, предложение написано для другого покупателя. **Сколько времени до первого видимого результата должен обещать поставщик?** Для нетехнического B2B горизонт первой пользы критичен: владелец живёт месячными циклами и не готов ждать кварталы без сигнала. Реалистичная привязка — измеримый сдвиг по одной метрике за 90 дней, с понятным способом откатиться, если результата нет. Это и есть очерченная нижняя граница риска, которая двигает сделку быстрее любой демонстрации. --- ## Note 9: Один человек, три проекта, пять агентов: как устроен solo AI-native контур **URL:** https://notes.temadev.org/2026/06/solo-founder-ai-native-kontur.html **Published:** 2026-06-10 **Genre:** field-note **Tags:** ai-agents, solo-founder, operating-model, attention, ai-native **Words:** 2080 **Summary:** Solo AI-native контур — это не «один человек плюс ChatGPT», а три сдвига в операционной модели и одно реальное узкое горло: циклы внимания. # Один человек, три проекта, пять агентов: как устроен solo AI-native контур ## Что на самом деле ограничивает одного оператора? Один человек ведёт три живых проекта одновременно: клиентский внедренческий проект, продуктовый прототип на ранней стадии и собственный research-контур, который каждую ночь производит десятки отчётов. Рядом с ним работают пять агентных ролей — research agent, ops monitor, code agent и две вспомогательные. Это не демонстрация и не эксперимент на выходные, а воспроизводимый операционный паттерн, который мы наблюдаем у нескольких практиков с конца 2025 года. Solo AI-native контур — это операционная модель, в которой один человек оркестрирует несколько специализированных агентных ролей, работающих по расписанию и производящих готовые артефакты. И первое, что становится видно вблизи: ограничивает такого оператора не мощность моделей и не объём генерации. Ограничивает количество циклов внимания — сколько раз за день один человек успевает закрыть петлю «задача → артефакт → ревью». «Задача → артефакт → ревью» — это минимальный цикл агентной работы: агент получает задание, производит проверяемый результат-файл, а оператор оценивает и решает, идёт ли он в дело. Симон Уиллисон, который публично описал свой режим работы с несколькими агентами параллельно, формулирует это прямо: к одиннадцати утра он умственно вымотан, хотя машинного времени получает больше ([Simon Willison](https://simonwillison.net/2025/Oct/5/parallel-coding-agents/)). ## Почему «один человек плюс ChatGPT» — неверная картинка Solo AI-native контур — это не «один человек плюс ChatGPT». «Один человек плюс ChatGPT» — это режим, в котором оператор вручную формулирует каждый запрос в чате и сам переносит ответы в работу, оставаясь бутылочным горлом каждого действия. Эта формулировка предполагает, что человек сидит в чате, задаёт вопросы и копирует ответы. Такой режим упирается в потолок очень быстро: оператор становится бутылочным горлом для каждого действия, потому что ничего не происходит без его реплики. Контур, который мы описываем, устроен иначе. Это три конкретных сдвига в операционной модели, и каждый из них убирает оператора из части цикла. Сдвиг первый: расписание вместо списка дел. В классической схеме человек держит to-do и сам решает, когда что делать. В AI-native контуре значительная часть работы запускается по расписанию, без участия оператора: research-контур собирает источники ночью, ops monitor проверяет здоровье систем каждые два часа, утренний прогон готовит сводку дня. Список дел — это очередь, которую кто-то должен разбирать. Расписание — это конвейер, который работает сам и кладёт на стол готовые результаты. Разница не косметическая: список требует постоянного решения «что дальше», расписание это решение снимает. Сдвиг второй: роли вместо мест. В команде из людей единица — это место (seat): человек, нанятый на позицию, с зарплатой и графиком. В агентном контуре единица — это роль: набор инструкций, памяти и инструментов, который выполняет функцию. Джек Дорси в письме о переходе Block к AI-first модели сформулировал ту же мысль: каждую функцию в компании можно усилить или заместить AI-native процессом, и мышление сдвигается от «сколько мест» к «какие роли» ([Block](https://block.xyz/)). Роль не уходит в отпуск, не теряет контекст между задачами и масштабируется копированием. Пять ролей рядом с одним человеком — это не пять «сотрудников», это пять стабильных функций, которые он оркестрирует. Сдвиг третий: артефакты вместо чат-треда. Это самый недооценённый из трёх. В чате знание живёт в треде: чтобы понять, что решено, нужно прокрутить переписку. Тред — плохая память: он линеен, не структурирован и теряется при переключении. В работающем контуре единица обмена — артефакт: файл с решением, отчёт, черновик, план. Агент не «отвечает в чате», а производит файл, который остаётся, версионируется и читается другими ролями. Эндрю Карпати в своём разборе LLM как новой операционной системы описывает память, инструменты и контекст как примитивы нового уровня абстракции — и именно артефакт, а не реплика в чате, становится носителем этой памяти ([Andrej Karpathy](https://karpathy.ai/)). Когда все три сдвига на месте, оператор перестаёт быть участником каждого микро-действия и становится тем, кто запускает циклы и принимает их результаты. ## Узкое горло — это циклы внимания Здесь и проходит главная линия. Когда генерация дешёвая, а ролей много, узким местом становится не производство, а проверка. Каждый артефакт, прежде чем попасть в дело, проходит через одного человека — единственную точку, где есть стратегический контекст и право решать. Это и есть петля «задача → артефакт → ревью», и количество таких петель в день конечно. Цифры здесь жёсткие. Исследование Глории Марк (Калифорнийский университет, Ирвайн) показало, что после прерывания человеку нужно в среднем около 23 минут, чтобы вернуться к исходной задаче. Для оператора, который держит три проекта и пять ролей, это означает: каждое переключение между контекстами стоит почти получаса восстановления. Поэтому контур, в котором агенты постоянно дёргают человека уточняющими вопросами, проигрывает контуру, где они производят законченные артефакты и приходят к оператору только на ревью. Параллелизм здесь когнитивный, а не технический: машина может вести десять задач одновременно, человек — одну в фокусе и несколько в фоне. Уиллисон описывает это честно: одна значимая петля в фокусе плюс несколько мелких в фоне, и быстрое истощение от переключений ([Simon Willison](https://simonwillison.net/2025/Oct/5/parallel-coding-agents/)). Из этого следует контр-интуитивный вывод: добавить шестую агентную роль не всегда увеличивает пропускную способность контура. Если новая роль генерирует артефакты быстрее, чем человек успевает их проверять, она не ускоряет систему, а забивает очередь на ревью. Бутылочное горло просто сдвигается ближе к человеку. Поэтому правильная метрика зрелости такого контура — не число агентов и не объём генерации, а доля артефактов, которые проходят ревью и идут в дело, против тех, что копятся непроверенными. ## Что отделяет работающий контур от витрины Те, кто реально ведёт несколько проектов в одиночку, сходятся на нескольких признаках, которые отделяют рабочий контур от красивой витрины. Первое — управление по исключениям. Оператор не читает весь поток. Системы спокойны по умолчанию и становятся заметны только там, где есть отклонение, риск или важный новый результат. Это прямой перенос логики mission-control в личный масштаб: если каждый сигнал красный и срочный, человек перестаёт воспринимать сигнал как значимый. Спокойный по умолчанию контур — это не эстетика, а способ не выжечь единственное узкое горло. Второе — health-петли для знания. Артефактов накапливается много, и без регулярной проверки на устаревание контур начинает тихо врать: ссылки ломаются, отчёты ссылаются на отжившие факты, агент действует на основе протухшего контекста. За одну неделю мы видели, как research-контур производит десятки отчётов — и без сильной связки между research, решениями и действиями количество начинает обгонять пользу. Поэтому freshness-проверки, контроль битых ссылок и периодический пересмотр — это часть операционной системы, а не вторичная гигиена. Третье — разделение потока и карты. Поток (входящие, уведомления, быстрые ответы) и карта (картина дня, приоритеты, состояние проектов) — это разные поверхности, и смешивать их вредно. Если карта живёт в том же месте, что и поток, она тонет в шуме. Управляющий слой для solo-оператора — это не BI-панель с сорока метриками, а навигационный слой поверх уже существующих поверхностей: что сейчас главное, где отклонение, какой следующий лучший переход вглубь. ## Где этот контур ломается Честность требует назвать границы. Solo AI-native контур выигрывает в скорости итерации и экономике — маржа на уровне 80–95% против отрицательной у команды до выхода на значимую выручку, как показывают разборы экономики solo+AI ([Foundation Capital](https://foundationcapital.com/)). Но он проигрывает команде в трёх конкретных местах. Первое — глубина в специализированной области. Там, где нужна экспертиза, в которой модель галлюцинирует, один человек с агентами не заменяет специалиста. Второе — операции в режиме 24/7. Человек спит, и ночной инцидент упирается в единственную точку отказа: оператора. Ops monitor может разбудить, но не может принять решение вместо него. Третье — корпоративные продажи и комплаенс, где требуется человеческое присутствие в комнате. Sam Altman, говоря о компаниях из десяти человек с миллиардной оценкой, описывает именно прорыв в производительности, а не отмену всех ограничений ([Every](https://every.to/napkin-math/the-one-person-billion-dollar-company)). Контур масштабирует производство и оркестрацию — он не масштабирует физическое присутствие и не закрывает дыру специализированной экспертизы. Есть и более тонкий риск. Anthropic в разборе построения эффективных агентов предупреждает: добавление автономии увеличивает не только возможности, но и стоимость ошибок, и многие задачи лучше решать предсказуемыми процессами, а не агентами ([Anthropic](https://www.anthropic.com/news/building-effective-agents)). Для solo-контура это означает: не каждую функцию стоит превращать в автономную роль. Там, где ошибка дорогая и тихая, лучше детерминированный сценарий с человеком на проверке, чем агент, которому дали свободу действовать. ## Следствия для трёх типов читателей Для solo-основателя проверочный вопрос один: где в вашем дне расписание уже заменило список дел? Если ответ «нигде» — вы ещё в режиме «человек плюс чат», и потолок близко. Начинать стоит не с того, чтобы добавить агентов, а с того, чтобы перевести хотя бы один повторяющийся процесс на расписание и научиться принимать его результат как артефакт, а не как реплику. Для оператора, который внедряет AI в существующую команду, главное следствие — перестать думать местами. Вопрос не «кого из людей заменит агент», а «какие роли стоит выделить как стабильные функции с памятью и инструментами». И сразу за этим — где в команде узкое горло ревью, потому что именно туда упрётся весь прирост генерации. Этот контур — наш рабочий режим, а не теория; если в команду нужен инженер, который доведёт такую систему до рабочего состояния, — [как я встроюсь в команду](https://temadev.org/hire/?utm_source=geo_referral&utm_medium=ai&utm_campaign=solo-founder-ai-native-kontur&utm_content=inprose). Для руководителя, который строит AI-native org-дизайн, вывод жёстче. Метрика, которую стоит ставить во главу, — не headcount и не объём вывода, а пропускная способность по ревью: сколько решений с настоящим контекстом организация может принять в единицу времени. Это и есть настоящий потолок AI-native структуры. McKinsey описывает переход от org-chart к агентной сети как смену самой единицы организации — но единицей внимания всё равно остаётся человек, и его циклов конечное число. ## Главное - Solo AI-native контур — это не «один человек плюс ChatGPT», а три сдвига операционной модели: расписание вместо списка дел, роли вместо мест, артефакты вместо чат-треда. - Узкое горло — не генерация кода или текста, а количество петель «задача → артефакт → ревью», которые один человек успевает закрыть за день; каждое переключение контекста стоит около 23 минут восстановления. - Добавить ещё одну агентную роль не всегда ускоряет контур: если она генерирует быстрее, чем человек проверяет, она забивает очередь на ревью, а не разгружает её. - Контур выигрывает в скорости и марже (80–95%), но проигрывает команде в специализированной глубине, операциях 24/7 и корпоративных продажах. - Правильная метрика зрелости — не число агентов, а доля артефактов, прошедших ревью и пошедших в дело. ## FAQ **Что такое solo AI-native контур и чем он отличается от «один человек плюс ChatGPT»?** Это операционная модель, где один оператор ведёт несколько проектов с помощью нескольких агентных ролей, работающих по расписанию и производящих готовые артефакты. Отличие от «человек плюс ChatGPT» в том, что оператор убран из части цикла: значительная часть работы запускается без его реплики, а он включается только на ревью. В чат-режиме человек — бутылочное горло для каждого действия; в контуре — только для проверки результатов. **Почему циклы внимания, а не генерация — это узкое горло?** Потому что генерация стала дешёвой и параллельной, а проверка осталась последовательной и привязанной к одному человеку с настоящим контекстом. Каждый артефакт проходит через одну точку принятия решения, и количество таких проверок в день конечно. Исследование Глории Марк даёт цену переключения — около 23 минут восстановления после прерывания, что делает беспорядочные переключения главным расходом внимания. **Когда этот паттерн неприменим?** Там, где нужна специализированная экспертиза, в которой модель галлюцинирует; в операциях 24/7, где человек как единственная точка отказа спит; и в корпоративных продажах с комплаенсом, где требуется присутствие человека в комнате. Контур масштабирует производство и оркестрацию, но не физическое присутствие и не глубину узкой области. **Сколько агентных ролей оптимально для одного оператора?** Универсального числа нет — потолок задаётся не количеством ролей, а пропускной способностью человека по ревью. Добавлять роль стоит только если человек успевает проверять её вывод; иначе она увеличивает очередь непроверенных артефактов, а не пропускную способность контура. **Как измерить, что контур работает, а не имитирует работу?** Главный показатель — доля артефактов, прошедших ревью и пошедших в дело, против накопленных непроверенными. Если очередь на ревью растёт быстрее, чем разбирается, контур производит видимость, а не результат, и узкое горло уже упёрлось в человека. --- ## Note 10: Uber выжег годовой AI-бюджет за четыре месяца: тормоза проектируют до запуска **URL:** https://notes.temadev.org/2026/06/ai-finops-token-burn-design-time-not-after.html **Published:** 2026-06-07 **Genre:** market-deep-dive **Tags:** ai-economics, finops, llm-routing, prompt-caching, b2b, unit-economics **Words:** 2249 **Summary:** Стоимость AI-контура в первый год определяется его архитектурой, а не прайс-листом провайдера — и решается на этапе проектирования. # Uber выжег годовой AI-бюджет за четыре месяца: тормоза проектируют до запуска В мае 2026 года технический директор Uber публично признал, что компания израсходовала весь свой годовой бюджет на AI-кодинг за четыре месяца. По разбору Forbes, средний инженер тратил 150–250 долларов в месяц, а у тех, кого внутри называли power-users, счёт доходил до 500–2000 долларов в месяц на человека — и при масштабе инженерной организации Uber это сложилось в перерасход, после которого компания, по словам её же CTO, вернулась «к чертёжной доске» ([Forbes](https://www.forbes.com/sites/janakirammsv/2026/05/17/uber-burns-its-2026-ai-budget-in-four-months-on-claude-code/)). История разлетелась по деловым лентам как анекдот про дорогие токены. Это неверное прочтение. Цена токена у Uber была ровно такой же, как у любой другой компании с тем же контрактом. Разъехалась не цена — разъехалась архитектура. Инженерам выдали мощный агент без квот, без маршрутизации задач по моделям разного тиража, без обязательного кэширования и без внутреннего учёта, кто сколько жжёт. В такой конфигурации расход — это не строка в смете, а открытый кран, и единственный сигнал о том, что кран открыт, приходит в виде месячного счёта. Проблема Uber не финансовая, а проектная: контроль расходов на AI (далее — FinOps) у них появился после прода, а должен был появиться до первой строки кода. ## Почему счёт приходит в виде шока Чтобы увидеть, что здесь сломано, полезно отделить цену модели от стоимости контура. Это разные величины, и путаница между ними и порождает шоковые счета. Цена модели — это публичный прайс-лист: сколько стоит миллион входных и выходных токенов. Она известна заранее и одинакова для всех. Стоимость контура — это сколько денег в год съест работающий агент с учётом объёма запросов, длины контекста, числа повторов, доли кэш-попаданий и количества людей, которые им пользуются без ограничений. Эта величина не лежит в прайс-листе. Она вытекает из того, как контур спроектирован, и именно поэтому её почти никто не считает до запуска. Порядок этой величины уже измерен на стороне. По оценке SearchUnify, совокупная стоимость владения одним корпоративным AI-агентом в первый год составляет 108–306 тысяч долларов: капитальные затраты на разработку 70–150 тысяч, операционные расходы 3,2–13 тысяч долларов в месяц, и сверх этого ежегодное обслуживание, которое съедает 15–25% от стоимости разработки. Последняя цифра — самая недооценённая: агент не строится один раз, он требует постоянной подгонки к меняющимся API, схемам данных и регламентам, и эта подгонка стоит как четверть исходной разработки каждый год. Команда, которая заложила в бизнес-план только цену токенов, не заложила три четверти реальной стоимости. Дальше работает простая арифметика без тормозов. Современный агент в задаче кодинга прогоняет через модель не один запрос, а десятки итераций: читает файлы, держит в контексте историю, перечитывает её на каждом шаге. Без кэширования каждая итерация оплачивает весь контекст заново по полной цене входного токена. Один инженер, гоняющий агент по крупной кодовой базе восемь часов в день, легко выходит на те самые 2000 долларов в месяц — не потому что токен дорогой, а потому что один и тот же контекст оплачивается сотни раз. Умножьте на масштаб организации, в которой, по данным того же разбора, заметная доля бэкенд-кода писалась агентами фактически без человека в цикле, — и годовой бюджет действительно сгорает к маю. ## Четыре тормоза, которые ставят на чертеже, а не после счёта FinOps как дисциплина — это не «следить за облачным счётом постфактум». FinOps Foundation определяет её как операционную модель, в которой видимость затрат, квотирование и unit-экономика встроены в принятие инженерных решений, а не приклеены сверху ([FinOps Foundation](https://www.finops.org/framework/technology-categories/ai/)). Для AI-нагрузок та же логика переносится почти дословно: фонд выделил отдельную категорию FinOps for AI именно потому, что у токенов сложность затрат, скорость роста и непредсказуемость выше, чем у классической облачной инфраструктуры. Четыре механизма из этой дисциплины проектируются вместе с агентом, а не докручиваются после. **Первый — квоты.** Лимит расхода на инженера, на команду, на проект в единицу времени. Это самый дешёвый тормоз и тот, отсутствие которого напрямую стоило Uber годового бюджета. Квота не обязана быть жёсткой отсечкой; достаточно мягкого потолка, после которого запрос уходит на согласование или на более дешёвую модель. Принципиально то, что квота — это архитектурное решение на входе: если её не заложили в шлюз доступа к модели с самого начала, добавить её после того, как все привыкли к безлимиту, — это уже не настройка, а отъём, на который команда реагирует так же болезненно, как на любое урезание привилегий. FinOps Foundation выносит политики и контроль в отдельную способность фреймворка не случайно: без них видимость затрат остаётся отчётом, который читают, но на который не реагируют ([FinOps Foundation](https://www.finops.org/framework/capabilities/governance-policy-risk/)). **Второй — маршрутизация по тиражам моделей.** Не каждая задача требует топовой модели. Классификация письма, извлечение полей из документа, простая правка — это работа для дешёвой быстрой модели, которая стоит в разы меньше. Разрыв в публичных прайс-листах огромен: между флагманской и компактной моделью одного и того же провайдера разница во входной цене легко достигает порядка ([OpenAI](https://platform.openai.com/docs/pricing)). Контур, который гонит всё через топовую модель, переплачивает за каждую тривиальную операцию. Маршрутизация — это слой, который смотрит на задачу и отправляет её на самую дешёвую модель, справляющуюся с ней; он либо встроен в архитектуру как явный компонент, либо его нет, и тогда «всё через флагман» становится дефолтом по умолчанию. Этот же сдвиг описан и для смешанных стеков: появление компактных моделей высокого качества и дешёвых альтернатив пограничного уровня сделало маршрутизацию архитектурным преимуществом, а не просто строкой экономии. **Третий — кэширование.** Главный рычаг, доступный бесплатно и почти всегда недоиспользованный. Когда агент перечитывает один и тот же системный промпт, ту же документацию, ту же историю на каждом шаге, кэширование позволяет не оплачивать этот повторяющийся контекст по полной цене. В документации Anthropic кэш-чтение стоит существенно меньше обычного входного токена — на типовых конфигурациях речь идёт о порядковой экономии на повторяющейся части контекста ([Anthropic](https://platform.claude.com/docs/en/build-with-claude/prompt-caching)). Для агента, который по своей природе крутит длинный стабильный контекст в цикле, это разница между жизнеспособной и сгорающей экономикой. Но кэширование требует, чтобы промпт был структурирован под кэш — стабильная часть отделена от изменчивой, — а это решение на этапе проектирования промпта, а не переключатель, который щёлкают после первого счёта. **Четвёртый — внутренний учёт.** Биллинг по командам и проектам, который превращает безличный общий счёт в персональную ответственность. Пока расход анонимен, он растёт: никто не оптимизирует то, за что не отвечает. Как только каждая команда видит свою строку и отвечает за неё, поведение меняется само — без квот и запретов, просто потому что появилась видимость. Именно это FinOps Foundation называет основой дисциплины: не урезание, а перенос экономической ответственности туда, где принимается техническое решение. Контур без внутреннего учёта узнаёт свою экономику единственным способом — когда приходит общий счёт, и уже поздно спрашивать, кто его наполнил. ## Что говорят данные о цене «всё через флагман» | Решение на этапе проектирования | Контур с FinOps на чертеже | Контур без тормозов | |---|---|---| | Квоты на инженера/команду | Заложены в шлюз доступа к модели | Появляются после шокового счёта как отъём привилегий | | Маршрутизация задач | Тривиальное уходит на дешёвую модель | Всё идёт через флагман по умолчанию | | Кэширование контекста | Промпт структурирован под кэш с первого дня | Повторяющийся контекст оплачивается заново каждый шаг | | Внутренний учёт расходов | Биллинг по командам, персональная ответственность | Анонимный общий счёт, никто не оптимизирует | | Когда команда узнаёт экономику | На этапе проектирования, в смете | В мае, когда сгорел годовой бюджет | Контр-аргумент в защиту моноархитектуры звучит разумно: на старте проще пустить всё через одну топовую модель, не строить маршрутизатор, не возиться с кэшем — и быстрее выйти на работающий прототип. Это правда, и на горизонте первого прототипа это даже рационально. Проблема в том, что эта простота берётся в долг. Прототип без тормозов незаметно переходит в прод без тормозов, а на масштабе долг гасится с процентами — в виде того самого счёта, после которого приходится возвращаться «к чертёжной доске» и встраивать FinOps в уже работающую систему, где каждая правка дороже, чем она была бы на чертеже. Эта же арифметика себестоимости определяет, какая модель оплаты контура вообще выживает на дистанции ([Подписка против проекта: три класса экономики B2B-агентов](/2026/05/retainer-vs-project-b2b-ai-subscription-economics.html)). Этот сюжет рифмуется с более широкой картиной корпоративного AI. Исследование MIT NANDA зафиксировало, что 95% корпоративных AI-пилотов не дали измеримого возврата через полгода, несмотря на 30–40 млрд долларов совокупных вложений ([MIT NANDA](https://nanda.media.mit.edu/ai_report_2025.pdf)). Среди причин — не слабость моделей, а то, что экономика контура ломается на архитектуре раньше, чем на модели. Кейс Uber — это та же болезнь в зеркальном отражении: там агент как раз работал и давал отдачу, но архитектура без экономических ограничений превратила рабочий инструмент в неуправляемую статью расходов. В обоих случаях граница между успехом и провалом проходит не по качеству модели, а по тому, что построено вокруг неё. Дополнительный сигнал того же порядка — движения крупных игроков по управлению доступом к агентным инструментам. Сообщалось, что Microsoft пересматривает внутренние лицензии на сторонние агенты для кодинга в пользу собственного стека к середине 2026 года. Независимо от деталей, направление читается одинаково: после первой волны безлимитного внедрения корпорации возвращают контроль над тем, кто, чем и в каком объёме пользуется. Это и есть запоздалый FinOps — дисциплина, которую дешевле было заложить в проект, чем вводить под давлением счёта. ## Что проверить инженеру и что — руководителю Из всего сказанного следуют два разных набора проверок — для того, кто строит контур, и для того, кто за него платит. **Инженеру, проектирующему агента.** Первый тест — на кэш: посмотрите долю кэш-попаданий в реальной нагрузке. Если стабильная часть контекста (системный промпт, документация, инструкции) не вынесена в кэшируемый префикс и доля попаданий низкая — вы оплачиваете один и тот же контекст десятки раз, и это первое, что чинится без потери качества. Второй тест — на маршрутизацию: пройдитесь по типам запросов и честно ответьте, какая доля из них реально требует флагманской модели; если простая классификация и извлечение полей идут через топовую модель, контур переплачивает на ровном месте. Третий — на квоты: существует ли в шлюзе доступа к модели хоть какой-то потолок на инженера или проект, и что произойдёт, если один пользователь за ночь упрётся в десятикратный обычный расход. Если ответ «ничего не произойдёт, кроме счёта» — тормоза не спроектированы. **Руководителю, который санкционирует бюджет.** Первый тест — потребовать в смете не цену токена, а годовую стоимость владения контуром: разработка плюс операционные расходы плюс 15–25% ежегодного обслуживания. Если в плане есть только цена API — план занижен в разы, и шоковый счёт уже заложен, просто ещё не пришёл. Второй тест — на видимость: может ли каждая команда увидеть свою строку расхода на AI отдельно от общей; если расход анонимен, оптимизировать его никто не будет, и рост счёта — вопрос времени. Третий — на обратимость решения «всё через флагман»: спросите, что будет стоить ввести маршрутизацию и квоты через полгода работы без них; если ответ «придётся переписывать ядро контура и ломать привычки команды» — значит, дешевизну взяли в долг, и пора отдавать до того, как набегут проценты. Такие AI-контуры с тормозами на чертеже — квотами, маршрутизацией и пер-командным учётом — мы и собираем как рабочие системы вокруг одного измеримого процесса, а не как пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=ai-finops-token-burn-design-time-not-after&utm_content=inprose). ## За чем смотреть в 2026 году Первый сигнал — появление в корпоративных AI-бюджетах отдельной защищённой строки на FinOps: квоты, маршрутизацию, учёт. Пока её нет, история Uber будет повторяться у каждого, кто проходит фазу безлимитного внедрения. Когда такая строка станет стандартом сметы, рынок усвоит урок про тормоза на чертеже. Второй сигнал — смещение разговора у поставщиков с «насколько умна наша модель» на «как контролировать расход на нашей модели»: появление встроенных квот, бюджетных лимитов и пер-командного биллинга в управляемых средах. Когда контроль расходов станет частью продукта, а не самодельной обвязкой клиента, это будет означать, что отрасль признала: экономика AI-контура решается архитектурой, а не прайс-листом — и решается до запуска, а не после счёта. ## Главное - Uber израсходовал годовой AI-бюджет за четыре месяца не из-за дорогих токенов, а из-за архитектуры без квот, маршрутизации, кэширования и внутреннего учёта; цена токена была у всех одинаковой. - Годовая стоимость владения одним агентом оценивается в 108–306 тысяч долларов, а обслуживание съедает 15–25% стоимости разработки ежегодно — три четверти этой суммы не видны тому, кто считает только цену API. - FinOps для AI — не пост-продакшн-оптимизация, а проектное ограничение: квоты, маршрутизация по тиражам моделей, кэширование и пер-командный биллинг встраиваются в архитектуру с первого дня или превращаются в шоковый счёт. - Дешевизна схемы «всё через топовую модель» берётся в долг: на прототипе она рациональна, на масштабе гасится с процентами в виде перерасхода и дорогой переделки уже работающего контура. ## FAQ **Что такое FinOps для AI и чем он отличается от обычного контроля облачных расходов?** FinOps — операционная модель, в которой видимость затрат и экономическая ответственность встроены в инженерные решения, а не приклеены постфактум. Для AI выделена отдельная категория, потому что у токенов выше сложность учёта, скорость роста расходов и непредсказуемость: один и тот же контекст может оплачиваться сотни раз, а безлимитный доступ масштабирует счёт быстрее любой классической инфраструктуры. **Почему кэширование называют главным рычагом экономики?** Агент по своей природе крутит в цикле длинный стабильный контекст — системный промпт, документацию, историю. Без кэша эта повторяющаяся часть оплачивается заново на каждом шаге по полной цене входного токена. Кэш-чтение стоит существенно дешевле обычного входа, поэтому при правильно структурированном промпте экономика на повторяющейся части сжимается в разы — без потери качества ответа. **Когда маршрутизация по моделям не нужна?** Если весь поток задач контура действительно требует максимального качества рассуждения — например, узкий контур только на сложном синтезе, — выигрыш от маршрутизации мал. Но в большинстве реальных нагрузок заметная доля запросов тривиальна (классификация, извлечение полей, простые правки), и для них флагманская модель — переплата. Чем разнороднее поток, тем сильнее окупается маршрутизация. **Сколько на самом деле стоит один агент в первый год?** По оценке SearchUnify — 108–306 тысяч долларов совокупной стоимости владения: 70–150 тысяч на разработку, 3,2–13 тысяч долларов в месяц операционных расходов и сверх этого 15–25% стоимости разработки ежегодно на обслуживание. Точная цифра зависит от объёма нагрузки и сложности контура, но порядок показывает: цена API — меньшая часть счёта. **Как измерить, что контур спроектирован экономно?** Три метрики: доля кэш-попаданий на повторяющемся контексте (чем выше, тем лучше), доля запросов, уходящих на модель ниже флагмана (показывает, работает ли маршрутизация), и наличие пер-командного биллинга с квотами в шлюзе доступа. Если все три на нуле — контур не имеет тормозов, и шоковый счёт лишь вопрос масштаба и времени. --- ## Note 11: 1С как первичный учётный слой: почему любой РФ AI-контур обязан с ним дружить **URL:** https://notes.temadev.org/2026/06/1c-primary-accounting-layer-rf-ai-integration.html **Published:** 2026-06-04 **Genre:** pattern-essay **Tags:** 1с, ai-интеграция, b2b-россия, учётные-системы, архитектура **Words:** 2319 **Summary:** Как выстроить архитектуру AI-агента, который не ошибается в ценах и остатках, — и почему без прямого коннектора к 1С это невозможно. # 1С как первичный учётный слой: почему любой РФ AI-контур обязан с ним дружить По данным компании «1С», платформой 1С:Предприятие пользуются более 1,5 млн организаций в России и СНГ — это автодилерские сети, строительные подрядчики, оптовые поставщики, производства, медицинские клиники. В большинстве из них 1С — не «одна из систем», а единственное место, где в данный момент лежат актуальная цена на товар, реальный остаток на складе, текущий статус контрагента и последний акт взаиморасчётов. AI-агенты, которые встраиваются в эти компании, чаще всего читают CRM — [amoCRM](https://www.amocrm.ru/), [Bitrix24](https://www.bitrix24.ru/), иногда Google Sheets с прайсом. 1С при этом остаётся в стороне: слишком сложно, слишком старый API, «разберёмся потом». И тогда агент начинает ошибаться предсказуемым образом: называет цену, которая изменилась три дня назад. Агент обещает наличие, которого нет. Агент подтверждает условия работы с контрагентом, о котором 1С уже знает, что тот в стоп-листе. ## Слепое пятно большинства AI-интеграций Типичная архитектура 2025–2026 года выглядит так: AI-агент подключён к мессенджеру через транспортный сервис, пишет в amoCRM через webhook, берёт историю сделок из CRM. Бизнес-логика — если сделка прошла этапы от заявки до договора — описана в промпте или простой конечной машине состояний. Такой агент отвечает на вопросы о статусе сделки, записывает следующий звонок, квалифицирует входящий лид. Задачи управления воронкой он закрывает, оперативные данные — нет. Это работает, пока не возникают оперативные вопросы — а именно они составляют значительную долю входящих сообщений в коммерческом чате. «Сколько стоит этот артикул для нового клиента?» — агент либо не знает, либо тянет цену из статичного прайса в Sheets, который обновлялся в прошлом квартале. «Есть ли товар на складе?» — агент либо молчит, либо ошибается. «Сколько мы должны этому контрагенту?» — тишина. CRM в классическом смысле — это реестр взаимодействий, а не операционных данных. amoCRM и Bitrix24 проектировались как инструменты управления продажами: pipeline, статусы, задачи, история переписки. Они не предназначены быть источником истины о ценах, складских остатках, договорных условиях и взаиморасчётах. Это ответственность учётной системы. В российском B2B учётной системой почти всегда является 1С. **AI как интерпретатор и операционный фронтенд поверх 1С как системы истины** — это архитектурный паттерн, при котором агент не хранит учётные данные у себя, а читает их напрямую из 1С при каждом запросе и переводит их в формат диалога — тонкий диалоговый слой над неизменяемым учётным регистром, а не вторая база данных. Замена 1С — это другой сценарий: перенос функций учётной системы на другую платформу. В российском B2B он практически не реализуется и в этой статье не рассматривается. ## Что именно хранит 1С — и почему это критично для агента? Конфигурация 1С:Предприятие в варианте «Управление торговлей» или «Бухгалтерия предприятия» ведёт как минимум шесть категорий данных, без которых AI-агент в коммерческом контексте неизбежно будет ошибаться. **Цены и ценовые условия.** Прайс-лист, ценовые группы контрагентов, персональные скидки, актуальные акции — всё это живёт в регистрах 1С и обновляется сотрудниками коммерческого отдела напрямую в системе. Если агент хочет дать корректную цену в чате, он должен спросить 1С — а не читать таблицу, которую кто-то последний раз открывал в пятницу. **Складские остатки.** Текущее количество товара с учётом резервов под другие заказы, ожидаемые поступления, остатки по складам — всё это обновляется в 1С автоматически при каждом движении товара. Таблица в Google Sheets не знает, что три часа назад на склад приехала партия или, наоборот, товар зарезервирован под другого покупателя. **Статус контрагента.** Стоп-лист, кредитный лимит, текущая дебиторская задолженность, дата последней оплаты — данные, без которых нельзя принимать решения о новых отгрузках. Они живут в 1С. CRM знает, что контрагент «в стадии переговоров», но не знает, что финансовый отдел приостановил с ним работу полгода назад. **Юридически значимые документы.** Счета, накладные, акты, договоры с проводками — 1С хранит не просто карточку сделки, а документ с финансовой историей. CRM хранит комментарии менеджера. **Взаиморасчёты.** Текущее сальдо по контрагенту, авансы, возвраты, история платежей — это бухгалтерия, не sales pipeline. **Номенклатурный справочник.** Единый список артикулов, единицы измерения, технические характеристики, аналоги — master data, которую нельзя держать в произвольном листе таблицы и которая меняется вместе с ассортиментом. Игнорирование любого из этих шести слоёв превращает AI-агента в вежливого лжеца: он говорит уверенно, но опирается на устаревшие или неполные данные. Разница между CRM и 1С по этим шести слоям видна наглядно: | Данные | CRM (amoCRM, Bitrix24) | 1С (учётная система) | |---|---|---| | Актуальная цена для контрагента | Нет или ручная копия | Регистр цен, обновляется в момент изменения | | Складской остаток с резервами | Нет | Обновляется при каждом движении товара | | Стоп-лист / кредитный лимит | Нет | Да, с дебиторской задолженностью | | Взаиморасчёты / сальдо | Нет | Да, с проводками | | Юридические документы (счёта, акты) | Комментарии менеджера | Документы с финансовой историей | | Номенклатурный справочник | Частично, вручную | Единый master data | | Статус сделки в воронке | Да — базовое назначение | Нет | Из семи строк таблицы шесть операционных параметров живут в 1С и недоступны в CRM — и именно эти шесть нужны агенту, чтобы отвечать на коммерческие вопросы корректно. ## Техническая сторона: как 1С открывает данные наружу С версии платформы 8.3 в 1С:Предприятии появился встроенный механизм HTTP-сервисов. Любая конфигурация может опубликовать RESTful endpoint прямо из конфигуратора — без сторонних middleware, без установки дополнительного ПО. [Портал разработчиков 1С](https://v8.1c.ru/) формулирует назначение этого механизма так: «HTTP-сервисы позволяют внешним системам обращаться к функциональности прикладного решения по протоколу HTTP». Запрос приходит на сервер 1С, выполняется код на встроенном языке платформы, возвращается JSON или XML — тот же формат, с которым уже работает любой AI-агент. Параллельно платформа поддерживает протокол OData — стандартный запрос `GET /odata/standard.odata/Catalog_Контрагенты` возвращает список контрагентов из справочника. Документация [ИТС](https://its.1c.ru/) описывает этот механизм прямо: «Стандартный интерфейс OData позволяет предоставлять доступ к данным прикладного решения без написания кода» — то есть чтение справочников и регистров доступно «из коробки» всем организациям с действующей подпиской. Третий путь — готовые коннекторы из экосистемы автоматизации. В сообществе разработчиков (например, в [хабе 1С на Habr](https://habr.com/ru/hubs/1c/)) регулярно появляются разборы интеграций между 1С и популярными оркестраторами вроде n8n: типовой подход — обернуть HTTP-сервис 1С в HTTP-узел оркестратора. Это снижает порог вхождения для команд, которые уже работают с low-code автоматизацией. На практике минимальный путь выглядит так: в конфигурации 1С публикуется HTTP-сервис (либо OData, либо кастомный метод), AI-агент вызывает этот endpoint через стандартный HTTP-запрос с авторизацией, ответ парсится и используется в диалоге. Агент знает актуальную цену и остаток перед тем, как ответить клиенту. Основная сложность не техническая, а организационная. Нужно участие 1С-программиста, чтобы опубликовать сервис, выдать учётные данные и описать схему запросов. Сама публикация читающего endpoint невелика по объёму, но требует приоритизации и координации с бухгалтерией или IT-отделом. Именно поэтому интеграция откладывается в пользу «пока поработаем с прайсом в Sheets» — и эта отсрочка оборачивается накопленными ошибками агента в ценах и остатках. ## Доступ и безопасность: что важно закрыть до прода Прямой доступ агента к 1С — это доступ к коммерчески чувствительным данным: цены, сальдо, контрагенты. Поэтому перед продом важны три вещи. Первое — отдельная служебная учётная запись для агента с правами только на чтение нужных регистров — не полный административный доступ. Второе — белый список методов: агенту открываются два-три endpoint'а (цена по артикулу, остаток, статус контрагента), а не весь OData-справочник целиком. Третье — журналирование: каждый запрос агента к 1С ложится в лог, чтобы любой ответ по цене или остатку можно было восстановить постфактум. Агент, который называет клиенту цену и подтверждает наличие, принимает коммерческие решения от имени компании, поэтому прозрачность его решений — не формальность. Минимальный audit log превращает «бот что-то напутал» в проверяемый инцидент с конкретным запросом и ответом 1С. ## Три паттерна поломки, которые проявляются без интеграции **Ценовые конфликты.** Менеджер по прайсу обновил цены в 1С в пятницу в 18:00. Агент продолжает отвечать клиентам по старому прайсу из таблицы все выходные — порядка 60 часов до понедельника, когда кто-то руками обновит Sheets. Если за эти выходные прошло 5–10 диалогов, компания получит несколько подтверждённых цен, которые держать не может. Тихий конфликт — формально виноват «бот», по факту это архитектурный долг: одно окно расхождения в двое суток против нулевого при прямом запросе. **Обещания по несуществующему наличию.** Агент сообщает, что товар есть в наличии — потому что в таблице стоит «да». В 1С же тот же товар уже зарезервирован под другой заказ. Клиент получает подтверждение, переходит к оформлению — и натыкается на нестыковку. Результат — отмена заказа, потерянное доверие и ручная разгрузка ситуации менеджером. **Работа с заблокированным контрагентом.** Агент квалифицирует лид и предлагает начать сотрудничество компании, у которой в 1С стоит флаг «приостановлено» из-за просроченной задолженности. Менеджер обнаруживает это только при выставлении счёта. Агент отработал корректно по CRM-логике — CRM не знала о статусе в учётной системе. Общий знаменатель всех трёх паттернов: AI-агент оперирует репликой данных, а не их источником. И все три решаются одним архитектурным решением: перевести 2–3 ключевых запроса (цена, остаток, статус) с таблицы-реплики на прямой вызов 1С. Из шести учётных слоёв эти три закрывают большинство ошибок, которые клиент видит в чате. ## Архитектурный принцип: 1С как источник истины Архитектурный принцип формулируется одним правилом: у каждого типа данных должен быть один канонический источник, и для операционных данных российского B2B этот источник — 1С. AI-агент не заменяет 1С, не дублирует его данные в собственной базе (это немедленно создаёт проблему расхождения версий), а обращается к нему напрямую при каждом запросе, требующем актуальных данных. По данным самой компании [«1С»](https://1c.ru/), платформой пользуются более 1,5 млн организаций в России и СНГ; отраслевые обзоры ([профиль 1С на TAdviser](https://tadviser.ru/)) стабильно фиксируют её как лидера российского рынка учётного ПО. Порядок величины важен не сам по себе: он означает, что для большинства B2B-команд вопрос «интегрироваться ли с 1С» — это не вопрос выбора технологии, а вопрос доступа к тому месту, где реально лежат операционные данные. На практике этот принцип разворачивается в конкретные следствия для трёх ролей. **Основатель** перед запуском агента в работу с клиентами задаёт вопрос: «Откуда агент берёт актуальную цену, остаток и статус контрагента прямо сейчас?» Если ответ — «из таблицы», агент не готов к production-использованию. Он готов к демонстрации. **Технический директор** включает 1С-коннектор в MVP-архитектуру, а не в roadmap «следующего квартала». Минимальный вариант — HTTP-сервис в 1С, возвращающий цену по артикулу и текущий остаток. Это несколько часов работы, но без этого вся ценность агента в части оперативных вопросов равна нулю. Ровно такой операционный контур — заявка квалифицируется за тридцать секунд по актуальным данным — мы собрали в смежной РФ-нише, аренде спецтехники: [рабочий пример контура](https://temadev.org/specteh/?utm_source=geo_referral&utm_medium=ai&utm_campaign=1c-primary-accounting-layer-rf-ai-integration&utm_content=inprose). **Руководитель операций** проводит аудит: какая информация сейчас дублируется между 1С и Sheets или CRM? Где сотрудник руками переносит данные из одной системы в другую? Каждая такая точка — потенциальное место ошибки агента. Прямая интеграция с 1С не добавляет синхронизацию, а убирает её. В AI-архитектуре 1С стоит рассматривать не как legacy-монолит на замену, а как операционный учётный регистр, который государство де-факто стандартизировало через обязательную финансовую отчётность. Более миллиона организаций ведут в нём ежедневный хозяйственный учёт — это и есть тот слой данных, от которого зависит корректность ответов агента. При прямом подключении к 1С агент получает актуальные цены и остатки в момент запроса; при работе через прайс в Google Sheets те же ответы систематически опираются на устаревшие данные. Это прямое продолжение более общего паттерна: [CRM хранит факты, а слой понимания и истины живёт отдельно](https://notes.temadev.org/2026/05/ai-over-crm-intelligence-layer-pattern.html) — в российском B2B этим слоем истины чаще всего оказывается именно 1С. ## Главное - В 1С хранятся данные, которых нет в CRM: актуальные цены, складские остатки, статус контрагента, взаиморасчёты. Без прямого коннектора агент работает с устаревшей репликой. - 1С:Предприятие 8.3+ поддерживает встроенные HTTP-сервисы и OData-протокол — документация на [v8.1c.ru](https://v8.1c.ru/) и [its.1c.ru](https://its.1c.ru/). - Три типичных паттерна поломки без 1С-интеграции: ценовые конфликты, обещания несуществующего наличия, работа с заблокированными контрагентами. - Правильная архитектура: 1С — источник истины, AI — интерпретатор и фронтенд над ним. Не замена, не дубль — надстройка над неизменяемым учётным слоем. - Первый шаг: HTTP-сервис в 1С, возвращающий цену по артикулу и складской остаток. Эти 2 запроса из 6 учётных слоёв закрывают большинство операционных ошибок агента и стоят несколько часов работы — это лучшая точка входа в интеграцию. - Доступ агента к 1С закрывают три меры: служебная учётная запись только на чтение, белый список из 2–3 endpoint'ов и журналирование каждого запроса. ## FAQ **Что такое HTTP-сервисы в 1С и чем они отличаются от COM-интеграции?** HTTP-сервисы — встроенный механизм платформы 1С:Предприятие 8.3, позволяющий опубликовать RESTful endpoint прямо из конфигуратора. Вызов идёт через стандартный HTTP-запрос, ответ — JSON или XML. COM-интеграция (устаревший подход) требует установки клиента 1С на сервере-вызывателе и работает только на Windows. HTTP-сервисы кроссплатформенны, документированы и поддерживаются текущими версиями платформы без дополнительных зависимостей. **Нужен ли 1С-программист для настройки интеграции?** Для публикации HTTP-сервиса или настройки OData-доступа — да. Это несколько часов работы для простых запросов на чтение. Основная сложность организационная, а не техническая: нужно согласовать перечень данных, схему авторизации, ограничения на запись. Готовые коннекторы для платформ автоматизации снижают порог для типовых сценариев. **Можно ли использовать OData-доступ без написания кода в 1С?** Да, OData работает «из коробки» в большинстве конфигураций после минимальных настроек на стороне сервера. Стандартный OData-endpoint открывает справочники и регистры в режиме чтения. Для операций записи — создание документов, обновление данных — нужны кастомные HTTP-сервисы с бизнес-логикой проверки. Документация [ИТС](https://its.1c.ru/) прямо предупреждает: «При публикации стандартного интерфейса OData следует ограничивать состав публикуемых данных» — то есть по умолчанию не стоит открывать все объекты подряд, достаточно 2–3 нужных агенту сущностей. **Почему нельзя просто синхронизировать 1С с Google Sheets раз в день?** Можно, но синхронизация раз в сутки создаёт окно устаревания до 24 часов и дополнительный хрупкий процесс. Цены и остатки в активном бизнесе меняются по несколько раз в день, а HTTP-запрос к 1С возвращает данные за доли секунды. Разница не в скорости, а в окне расхождения: у прямого запроса оно нулевое, у дневной реплики — до полных суток. AI-агент на дневной реплике систематически ошибается именно в периоды интенсивных изменений — то есть тогда, когда точность нужнее всего. **С каких шести слоёв данных начать интеграцию?** Практический приоритет такой: сначала цена по артикулу и складской остаток — эти два запроса закрывают большинство операционных вопросов в чате. Затем — статус контрагента (стоп-лист, лимит), потом взаиморасчёты, юридические документы и номенклатурный справочник. Два первых слоя дают основную ценность; остальные четыре добавляются по мере роста сценариев. **Чем 1С-интеграция отличается от подключения к обычной базе данных?** 1С — это не просто база данных, а система с бизнес-логикой, правами доступа и транзакционной моделью. Прямое подключение к SQL-базе данных 1С обходит эту логику и нарушает целостность данных. Правильный путь — через официальные механизмы публикации (HTTP-сервисы или OData), которые работают через 1С-сервер с соблюдением всех правил системы. --- ## Note 12: 95% AI-пилотов дают ноль. Что общего у выживших 5% **URL:** https://notes.temadev.org/2026/06/ai-pilot-failure-95-percent-survivors.html **Published:** 2026-06-01 **Genre:** market-deep-dive **Tags:** ai-adoption, b2b, roi, vertical-ai, buy-vs-build, pilots **Words:** 2050 **Summary:** Один структурный признак отличает 5% окупившихся AI-пилотов от 95% провальных — и три теста, чтобы проверить себя до старта. # 95% AI-пилотов дают ноль. Что общего у выживших 5% В августе 2025 года исследовательская инициатива MIT NANDA опубликовала отчёт «The GenAI Divide: State of AI in Business 2025», и одна цифра из него за неделю обошла все деловые издания: несмотря на 30–40 млрд долларов, влитых корпорациями в генеративный AI, 95% организаций не получили от своих пилотов измеримого возврата ([отчёт MIT NANDA](https://nanda.media.mit.edu/ai_report_2025.pdf), [Fortune](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)). Цифра прозвучала достаточно громко, чтобы на неё отреагировал рынок: Axios прямо связал августовскую коррекцию AI-акций с этим исследованием — инвесторы впервые увидели подтверждённый разрыв между расходами на AI и отдачей ([Axios](https://www.axios.com/2025/08/21/ai-wall-street-big-tech)). Дальше начинается интересное: вывод, который сделали из этой цифры почти все, был неверным. Стандартное прочтение звучит так: модели пока сырые, бюджеты маленькие, рынок незрелый — подождём год, всё наладится. Это удобная версия, потому что она ни к чему не обязывает. Отчёт NANDA говорит другое. Провал не в моделях и не в деньгах — в том, **куда** именно компания ставит AI. И у тех самых 5%, которые получили отдачу, есть общий структурный признак — он лежит не в технологии, а в процессе. ## Почему дело не в модели, а в том, куда её поставили? Сначала уберём с дороги две привычные объяснительные версии, потому что данные их не подтверждают. Версия «модели слабые» не выдерживает простой проверки: те же самые модели от тех же поставщиков одновременно дают и провальные, и успешные внедрения. NANDA фиксирует, что разрыв проходит не по качеству модели, а по способу её встраивания: пилоты, привязанные к конкретной рабочей операции с обратной связью, переживают полгода кратно чаще, чем универсальные ассистенты «для всех сразу». Сам факт, что 95% не окупились при 30–40 млрд расходов, исключает версию «мало вложили» — деньги были, отдачи не было. Любопытно, что инструменты для личной продуктивности при этом приживаются: сотрудники охотно пользуются универсальными чат-ассистентами в личном контуре. Но именно поэтому корпоративный пилот и проваливается — компания платит за систему, которую сотрудник дублирует бесплатным инструментом, не получая взамен ничего, что меняло бы сам процесс. Версия «рынок незрелый, подождём» опровергается поведением самих компаний. По данным S&P Global Market Intelligence, к середине 2025 года 42% компаний свернули или существенно сократили большинство своих AI-инициатив — против 17% годом ранее ([S&P Global Market Intelligence](https://www.spglobal.com/market-intelligence/en/news-insights/research/ai-experiences-rapid-adoption-but-with-mixed-outcomes-highlights-from-vote-2025)). Это не «ждут зрелости» — это откатывают то, что уже запустили и что не сработало. Рост отказов в 2,5 раза за год — сигнал не о том, что AI рано, а о том, что большинство строит его неправильно. Что же объединяет выживших? Один признак: у успешного пилота AI вшит в **один конкретный доходный процесс** — узкую операцию с измеримым входом, измеримым выходом и понятной ценой ошибки. У провального — AI размазан горизонтально: «дадим всем сотрудникам ассистента и посмотрим». Первое окупается, потому что отдачу можно посчитать в рублях на одной операции; второе — нет, потому что польза рассеяна по тысяче рабочих мест и не собирается ни в одну метрику, которую увидит финансовый директор. ## Купить вертикальное решение надёжнее, чем построить своё Второй сильный вывод NANDA касается развилки, на которой стоит почти каждая компания: купить готовое отраслевое решение у поставщика или построить своё силами внутренней команды. Данные отвечают однозначно. Покупка вертикального решения у внешнего поставщика приводит к успешному внедрению заметно чаще, чем внутренняя разработка — соотношение в отчёте составляет порядка двух к одному в пользу покупки. Внутренняя команда строит AI как технологический проект: выбирает модель, поднимает инфраструктуру, пишет интеграции — и упирается в то, что у неё нет накопленного опыта именно этой операции в десятках других компаний. Внешний поставщик вертикального решения приходит не с моделью, а с **готовой обвязкой** (agentic harness) вокруг неё: размеченными сценариями, типовыми исключениями, кодифицированными регламентами отрасли, которые он собрал, обслуживая похожие процессы у других клиентов. Модель внутри у всех примерно одна. Разница — в том, что построено вокруг неё. То, что создаёт ценность, — это не сама большая языковая модель, а **детерминированная оболочка** вокруг неё: слой, который превращает вероятностный текст модели в предсказуемое действие в рамках конкретной операции. Поставщики фронтирных моделей это понимают и сами двигают границу: Anthropic в работе [«Building effective agents»](https://www.anthropic.com/research/building-effective-agents) описывает, что большинство успешных продакшн-агентов — это не «умная модель в свободном полёте», а композиция простых, проверяемых шагов с жёсткими ограничениями. AWS вынес эту логику в отдельный продукт. AWS Bedrock AgentCore — это управляемая среда исполнения для AI-агентов с контролем памяти, инструментов и границ действий ([Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)). Сама эта обвязка стремительно становится массовой и доступной. А значит, защита внедрения уезжает не в модель и не в стандартную оболочку, а в то, насколько точно оболочка пригнана к одной конкретной операции и насколько долго она накапливала следы реальных решений. Это объясняет, почему «купить» обыгрывает «построить»: поставщик продаёт не технологию, а накопленную точность пригонки. Внутренняя команда начинает её копить с нуля — и в большинстве случаев не доживает до того момента, когда точность станет достаточной для окупаемости. Оговорка важна: вывод не означает «никогда не стройте». Он означает, что планка для решения «строим сами» выше, чем кажется на старте, и что инженерный бюджет в случае внутренней разработки должен уходить в обвязку, а не в бесконечное сравнение моделей. ## Правило 10/20/70: деньги уходят не туда, куда смотрят Третий признак выживших — структура бюджета. И здесь сходятся независимые наблюдения консультантов: успешные внедрения подчиняются правилу, которое короче всего формулируется как **10/20/70**. Десять процентов усилий и денег уходит на саму модель и алгоритмы, двадцать — на данные и инфраструктуру, и семьдесят — на людей, процессы и изменение способа работы. BCG, разбирая, где именно в AI-проектах возникает ценность, приходит к той же пропорции: технология — это меньшая часть работы, а основная масса усилий лежит в перестройке процессов и управлении изменениями ([BCG](https://www.bcg.com/publications/2024/wheres-the-value-in-ai)). Провальный пилот переворачивает эту пропорцию. Семьдесят процентов внимания уходит на выбор модели и сравнение поставщиков, двадцать — на инфраструктуру, и почти ничего — на то, чтобы перестроить процесс вокруг новой возможности и довести людей до того, чтобы они этим пользовались. Получается технически работающий пилот, которым никто не пользуется, потому что он навешен поверх старого процесса, а не встроен в новый. NANDA называет это разрывом обучения: системы не запоминают контекст, не адаптируются к рабочему процессу и не улучшаются от использования — и сотрудники тихо возвращаются к привычным инструментам. Публичная история Klarna — иллюстрация обеих ошибок сразу. Компания громко заявила о замене 700 сотрудников поддержки AI-ассистентом ([OpenAI](https://openai.com/index/klarna/)), но через полтора года начала нанимать людей обратно — на верхний слой, к сложным и эмоционально нагружённым случаям. Внедрение само по себе работало; провалилась попытка горизонтально вычистить целый слой людей вместо того, чтобы перерисовать границу эскалации. Семьдесят процентов работы — про людей и процессы — были недоделаны, и реальность это вернула. ## Конкретные тесты для трёх ролей Из трёх признаков выживших следует три разных набора проверок — для трёх разных людей, принимающих решение. **Собственнику нетехнологичного B2B.** Не спрашивайте «какой AI нам внедрить». Спросите иначе: какая одна операция в бизнесе имеет измеримый вход, измеримый выход и цену ошибки, которую владелец держит в голове без таблицы. Если такой операции не нашлось — пилот рано запускать, какая бы модель ни стояла внутри. Если нашлась — требуйте, чтобы отдача считалась именно на ней, в рублях, а не «в сэкономленных часах вообще». Один практический признак готовности: если владелец может назвать сумму, которую теряет на этой операции каждый месяц, проект имеет шанс окупиться; если сумма не называется, считать отдачу будет не от чего. **Директору по операциям или цифре.** Проверьте структуру плана внедрения на соответствие правилу 10/20/70. Если в смете 70% — это лицензии, модель и инфраструктура, а строчка «перестройка процесса и работа с людьми» либо отсутствует, либо стоит последней по бюджету — план перевёрнут, и его лучше переписать до старта, а не после отката. Второй тест — на буквальную обратную связь: умеет ли система запоминать исправления, которые вносит человек, и становиться от них точнее; если нет, в первый же месяц упрётся в потолок. **Тех-лиду на развилке «купить или построить».** По умолчанию считайте, что покупка вертикального решения вероятнее доведёт до окупаемости, и стройте своё, только если у вас есть честный ответ на вопрос: «что в нашей операции настолько уникально, что готового поставщика для неё не существует». Если же строите — тратьте инженерное время не на саму модель (она у всех одинаковая), а на детерминированную оболочку: формализацию сущностей, разметку исключений, накопление следов решений. Это и есть актив, который через год отделит вас от того, кто «просто запускает» модель поверх процесса. Именно такие контуры — один измеримый процесс с обвязкой вокруг него — мы и собираем как рабочие системы, а не как пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=ai-pilot-failure-95-percent-survivors&utm_content=inprose). ## Сигналы, по которым видно разворот За чем стоит следить в 2026 году, чтобы понять, что разрыв между 5% и 95% начинает закрываться. Первый сигнал — снижение доли свёрнутых проектов: если показатель S&P Global в районе 42% начнёт падать, это будет означать, что рынок усвоил урок про вертикальную привязку. Если он продолжит расти — компании по-прежнему ставят AI горизонтально и продолжают платить за это откатами. Второй сигнал — смещение языка вендорских предложений с «нашей модели» на «нашу пригонку к процессу». Когда поставщики перестанут продавать характеристики модели и начнут продавать накопленную точность под конкретную операцию, это будет означать, что граница ценности окончательно переехала из модели в оболочку. Третий — появление в корпоративных бюджетах отдельной защищённой строки на перестройку процессов и работу с людьми, сопоставимой по размеру с расходами на технологию: пока её нет, правило 10/20/70 будет нарушаться, а 95% — оставаться 95%. ## Главное - Провал 95% AI-пилотов — не про слабые модели и не про маленькие бюджеты: при 30–40 млрд долларов вложений отдачи всё равно нет, значит, причина структурная. - Выживших 5% объединяет один признак: AI вшит в один измеримый доходный процесс, а не размазан горизонтально по всей компании. - Покупка готового вертикального решения доводит до окупаемости заметно чаще внутренней разработки — потому что поставщик продаёт не модель, а накопленную точность пригонки к процессу. - Успешные бюджеты подчиняются правилу 10/20/70: 10% на модель, 20% на инфраструктуру, 70% на людей и перестройку процессов. Провальные переворачивают эту пропорцию. - Ценность создаёт не умная модель, а детерминированная оболочка вокруг неё; модель у всех примерно одинаковая, разница — в том, что построено вокруг. ## FAQ **Почему именно 95%, а не другая цифра?** Это показатель из отчёта MIT NANDA «The GenAI Divide: State of AI in Business 2025»: 95% обследованных организаций не получили измеримого возврата от своих генеративных AI-пилотов в течение полугода. Цифра подтверждена реакцией рынка и независимыми обзорами деловой прессы. **Значит ли это, что AI в бизнесе не работает?** Нет. Работают те 5%, у которых внедрение привязано к одной конкретной доходной операции. Вывод не «AI не работает», а «горизонтальное размазывание AI не работает, вертикальная привязка работает». **Если покупать надёжнее, чем строить, зачем вообще строить своё?** Строить стоит только там, где операция действительно уникальна и готового поставщика не существует, и где инженерное время вкладывается в оболочку вокруг модели, а не в саму модель. В большинстве случаев операция типовая, и покупка быстрее доводит до окупаемости. **Что такое правило 10/20/70 на практике?** Это пропорция распределения усилий в успешном AI-проекте: примерно 10% — модель и алгоритмы, 20% — данные и инфраструктура, 70% — люди, процессы и управление изменениями. Если в плане внедрения технология занимает большую часть бюджета, а перестройка процессов — меньшую, план почти наверняка приведёт в те самые 95%. --- ## Note 13: CRM хранит факты. Слой понимания живёт отдельно — и его пора строить поверх **URL:** https://notes.temadev.org/2026/05/ai-over-crm-intelligence-layer-pattern.html **Published:** 2026-05-29 **Genre:** pattern-essay **Tags:** ai-over-crm, intelligence-layer, b2b, world-model, defensibility, vertical-ai **Words:** 2028 **Summary:** Не замена CRM, а надстройка над ней: три уровня памяти, которые превращают таблицу фактов в актив, не воспроизводимый при смене поставщика. # CRM хранит факты. Слой понимания живёт отдельно — и его пора строить поверх ## В чём разрыв между тем, что записано в CRM, и тем, что компания на самом деле знает о клиентах По данным [Salesforce State of Sales](https://www.salesforce.com/resources/research-reports/state-of-sales/), значительная часть продавцов не вносит данные в CRM вовремя — оценки крутятся вокруг отметки 85% незаполнения по горячим следам. Это значит, что система, в которую компания вложила годы и бюджеты, по факту описывает не реальность сделок, а её бледную копию задним числом. Контакт, сделка, статус, заметка — всё внесено выборочно, неполно, с опозданием. Настоящее знание о том, почему клиент уходит, что блокирует сделку, какой паттерн предшествует отказу, живёт не в базе, а в головах менеджеров и исчезает вместе с их увольнением. Разрыв здесь не технический. Это разрыв между системой записи (system of record) и пониманием. ## Почему попытка закрыть разрыв заменой CRM почти всегда проваливается Соблазн очевиден: если CRM пустая, давайте заменим её на «умную». Эта логика приводит традиционный B2B к проектам rip-and-replace, которые проваливаются по одной и той же причине. CRM в зрелой компании — это не база данных, это поверхность, на которой держится дисциплина отдела продаж: pipeline, статусы, задачи, история. Люди привыкли к этому интерфейсу, регламенты написаны под него, отчётность собирается из него. Выдернуть его означает остановить работающий процесс ради обещания, что новый будет лучше. Проблема в том, что замена CRM не решает исходную задачу. Новая система так же останется таблицей фактов, которую так же не будут заполнять вовремя. Незаполнение CRM — это не дефект конкретного продукта, это структурное свойство любой системы, которая требует от человека ручного ввода в момент, когда он занят продажей. Та же [Salesforce State of Sales](https://www.salesforce.com/resources/research-reports/state-of-sales/) фиксирует ручной труд по администрированию данных как одну из главных причин, по которой продавцы тратят на собственно продажу меньше трети рабочего времени, — смена ярлыка на системе этого не меняет. Менять инструмент бессмысленно, если природа узкого места не в инструменте. Правильный вопрос звучит иначе. Не «бот или CRM» и не «какую CRM выбрать», а «какая операционная поверхность у клиента уже есть, и как надстроить над ней слой, который закроет то, чего она структурно не умеет». CRM умеет хранить и дисциплинировать. Она не умеет понимать свободный текст, вести диалог, держать контекст и работать как постоянно доступный собеседник. Именно сюда заходит AI — не вместо, а поверх. ## Три типа памяти, которые превращают пассивную базу в актив Слой понимания (intelligence layer) поверх CRM отличается от CRM не наличием модели, а способом накопления знания. CRM заполняется руками. Слой понимания заполняется пассивно — из самих диалогов, событий и исходов. Академический обзор [«Memory in the Age of AI Agents»](https://arxiv.org/abs/2512.13564) описывает память агента как несколько разных слоёв, и эта разбивка прямо ложится на задачу. Первый слой — эпизодическая память: что произошло, в каком порядке, с каким контекстом. Кто написал, когда, что попросил, что ответили. Второй — семантическая: что это значит. Профили клиентов, повторяющиеся ситуации, типичные возражения и то, как они разрешались. Третий — процедурная: как мы это делаем. Правила принятия решений, выведенные из практики, а не записанные в документ. Четвёртый, самый ценный и почти нигде не инструментированный, — память траекторий: что агент предложил, что человек изменил, какой получился исход. Этого нет ни в одной CRM, потому что CRM не фиксирует, что было отвергнуто и почему. Разница принципиальная. RAG (retrieval-augmented generation, генерация с поиском по документам) — это умный поиск: задаёшь вопрос, система достаёт релевантные фрагменты. Он улучшает точность ответа, но не понимает причинно-следственных связей между событиями. Слой понимания строит не индекс документов, а компактную модель операционной реальности бизнеса — модель мира (world model), — которая выводится из опыта. Тот же обзор фиксирует память не как функцию-приятную-добавку, а как базовую способность агентов. Для длинного цикла это критично: цена и доступность вчера не равны цене и доступности сегодня, и хранилище должно знать не только «что верно», но и «когда это было верно». ## Как слой замыкается на CRM, не ломая её: шина событий вместо новой системы Архитектура, которая работает, не подменяет CRM, а встраивается в её событийный поток. Современные CRM отдают события через вебхуки: новое сообщение, смена статуса, новый лид, новая задача. Это превращает CRM в шину событий (event bus), к которой подключается слой понимания. Он слушает входящий свободный текст, квалифицирует, задаёт уточняющие вопросы, переводит разговор в следующее разумное действие и пишет результат обратно в CRM — туда, где живёт менеджер. У этой схемы есть жёсткое инженерное требование. Ответ на вебхук обычно нужен быстрее, чем за пару секунд, иначе интеграция начинает деградировать. Платформы слоя поверх CRM строятся именно как событийно-управляемые продукты с коннекторами к системе записи, а не как ночной синк — это видно по архитектуре [Salesloft](https://www.salesloft.com/platform), который продаёт оркестрацию выручки поверх Salesforce и HubSpot как отдельный реактивный слой. Значит, слой должен быть событийно-управляемым и надёжным, а не пакетным ночным процессом. Это не «добавить чат-бота сбоку» — это построить постоянно доступный реактивный контур поверх системы записи. Здесь важно отличить слой понимания от транспортных сервисов, которые формально тоже «надстройка над CRM». Платформы передачи сообщений — мессенджер-агрегаторы, коннекторы каналов — переносят текст из WhatsApp или Telegram в карточку сделки. Они не дают reasoning, не квалифицируют автономно, не накапливают модель мира. Это инфраструктурный слой, и он уже занят и коммодитизирован. Слой понимания живёт на уровень выше: он не доставляет сообщение, он понимает его и принимает контекстное решение. Если AI остаётся только транспортным ботом без записи в pipeline, он не становится операционным слоем — но и CRM без AI остаётся пассивной базой, которая сама не двигает диалог. ## Где здесь защита: не модель, а глубина и накопленные данные Главное возражение к этому паттерну — «AI массовый, любой повторит за полгода». Возражение верное наполовину, и понимание границы важнее самого паттерна. Промпты переносимы: SaaStr в разборе [«4 уровня переносимости промптов»](https://www.saastr.com/the-4-levels-of-prompt-portability-why-some-ai-agents-will-hold-retention-and-most-wont/) фиксирует, что значительная часть AI-агентов копируется конкурентом за дни через перенос промпта и пару дней донастройки. Базовая модель тоже не защита: Foundation Capital в [«When model providers eat everything»](https://foundationcapital.com/ideas/when-model-providers-eat-everything-a-survival-guide-for-service-as-software-startups) прямо описывает, как провайдеры моделей идут вверх по стеку и съедают прикладной слой, у которого нет ничего, кроме обёртки. Стандартизация управляемых сред дополнительно обнуляет ценность инфраструктурной части — открытые протоколы вроде [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) делают подключение инструментов вопросом настройки, а не инженерии. Защита лежит в трёх других местах. Первое — глубина интеграции в ежедневную рутину. SaaStr в обзоре [«Follow the agents»](https://www.saastr.com/which-crm-should-you-use-in-2026-2027-follow-the-agents/) разводит уровни приживаемости: агенты уровня copy-paste промптов удерживают валовую выручку на уровне 80-85%, агенты, встроенные в рабочий процесс и домен, — 90-97%. Разница не в качестве модели, а в том, насколько глубоко слой вплетён в операции. Второе — вертикальные данные: накопленные траектории решений в конкретной отрасли, которые конкурент должен собирать с нуля. Третье — владение рабочим процессом: если при отключении слоя останавливается часть бизнеса, цена ухода становится запретительной. Каноничный пример — [Harvey](https://www.harvey.ai/) в юриспруденции. Защита там не в том, что они используют сильную модель, — модель доступна всем. Защита в том, что их хранилище копит не документы, а решения с исходами, и встроено в ежедневный рабочий цикл юриста, а не вызывается иногда. Воспроизвести это означает собрать те же годы практики заново. SaaStr формулирует водораздел резко: CRM, которая становится хабом для AI-агентов, выигрывает, а та, что не становится, превращается в базу данных, за которую вы переплачиваете. Защищён не AI и не CRM по отдельности — защищён слой, который накапливается между ними и принадлежит конкретному бизнесу. ## Что это значит на практике Для основателя, который строит продукт в традиционном B2B: не продавайте замену CRM. Продавайте точку входа (wedge), которая загорается быстро и не требует от клиента ломать процесс. Рабочие точки входа — резюме встречи с автозаполнением карточки и следующим шагом, реактивация зависших сделок по контексту истории, квалификация входящего свободного текста. Тест на правильную архитектуру один: что именно у клиента станет уникальным и непереносимым через полтора года работы. Если ответ — «настроенные промпты и коннекторы», вы строите обёртку, которую скопируют за квартал. Если ответ — собственная схема сущностей отрасли плюс история траекторий решений плюс кодифицированные регламенты, вы строите актив. Инструментировать накопление траекторий нужно с первого дня, даже если агент пока делает три вещи: задним числом эти данные не восстановить. Для руководителя традиционной компании, у которого CRM уже стоит и не заполняется: не меняйте CRM. Оцените её как операционную поверхность и спросите поставщика слоя понимания, как он встраивается в её событийный поток, не требуя миграции. Полезный тест на старте: попросите показать, где физически хранятся накопленные данные диалогов и решений и в каком формате вы можете их забрать. Если данные живут только в управляемой среде провайдера и их ценность неотделима от его инфраструктуры — вы покупаете не актив, а зависимость. Второй тест — латентность: слой обязан отвечать на событие за секунды, иначе он рассыпется на реальной нагрузке. И отдельно — ежемесячное сопровождение здесь не «поддержка», а процесс накопления интеллекта бизнеса: каждый месяц работы — это новые траектории и растущая стоимость ухода. Такой слой — приём и квалификация заявок поверх amoCRM, без замены самой CRM — у нас стоит в нише модульных домов: [открыть кейс](https://temadev.org/modular/?utm_source=geo_referral&utm_medium=ai&utm_campaign=ai-over-crm-intelligence-layer-pattern&utm_content=inprose). Для инженера, проектирующего такой слой: ключевой вопрос — где живёт управляющий контур (control plane). Если оркестрация, реестр инструментов и маршрутизация решений описаны в вашем коде и развёрнуты в вашей инфраструктуре, вы используете провайдера как среду исполнения, а не как операционную платформу. Память делите на два хранилища: сырые события и отдельно траектории решений с полем исхода — именно второе не должно утекать к провайдеру модели и именно оно создаёт защиту. Для операционных данных, где факты меняются во времени, временной граф знаний бьёт обычный векторный поиск: он знает не только «что похоже», но и «что было верно когда». ## На что смотреть дальше Паттерн воспроизводим везде, где у бизнеса уже есть операционная поверхность и длинный цикл: автодилеры, недвижимость, поддержка SaaS, проектные продажи, любой традиционный B2B. Сигнал, что слой понимания приживается как самостоятельная категория, — появление поставщиков, которые продают именно его, а не «AI внутри нашей CRM». Параллельно стоит следить за горизонтальными CRM: они добавят generic-AI поверх себя, и это случится, но с отставанием на полтора-два года и без вертикальной глубины. Окно для вертикального слоя понимания — этот зазор. Поставщики вроде [Salesloft](https://www.salesloft.com/platform) давно продают слой поверх CRM как отдельный продукт, но горизонтально и по англоязычному рынку; вертикальные ниши с длинным циклом этот слот пока держат открытым. Кто построит в нём актив, а не обёртку, тот и удержит клиента, когда модель станет массовой. ## Главное - CRM остаётся таблицей фактов: по данным Salesforce около 85% продавцов не заполняют её вовремя, и реальное знание о клиентах живёт в головах, а не в базе. - Замена CRM не решает проблему — новая система так же не будет заполняться. Правильный ход — надстроить слой понимания поверх существующей поверхности. - Слой копит знание пассивно через четыре типа памяти (эпизодическую, семантическую, процедурную и траекторий) и пишет обратно в CRM через её шину событий, требуя ответа за секунды. - Защита не в модели — она массовая через 12-24 месяца — и не в CRM, а в глубине интеграции, вертикальных данных и владении рабочим процессом. SaaStr фиксирует разрыв в удержании: 80-85% против 90-97%. - Паттерн воспроизводим в любом традиционном B2B с длинным циклом, где операционная поверхность уже существует. ## FAQ **Чем слой понимания отличается от обычного чат-бота на CRM?** Чат-бот доставляет и пересылает сообщения, не накапливая знание о бизнесе. Слой понимания квалифицирует входящий свободный текст, держит контекст, принимает контекстные решения и пассивно строит модель операционной реальности компании из диалогов и исходов. Бот без записи в pipeline остаётся транспортом, слой — становится операционным активом. **Почему нельзя просто заменить CRM на AI-native систему?** Незаполнение CRM — структурное свойство ручного ввода, а не дефект конкретного продукта. Новая система так же не будет заполняться вовремя. К тому же зрелая CRM держит дисциплину отдела продаж, и её замена останавливает работающий процесс ради обещания. Надстройка снимает узкое место, не ломая поверхность. **Если модели коммодитизируются, что мешает конкуренту повторить слой за полгода?** Промпты и базовая модель действительно переносимы за дни-недели. Не переносятся накопленные траектории решений в конкретной отрасли, собственная схема сущностей и глубина встраивания в ежедневный процесс. Конкурент получит обёртку, но не годы накопленного знания — именно это даёт разрыв в удержании 80-85% против 90-97% по данным SaaStr. **Как технически слой связан с CRM?** Через событийный поток. CRM отдаёт вебхуки на новое сообщение, смену статуса, новый лид. Слой подключается к этому потоку как к шине событий, реагирует за секунды и пишет результат обратно в карточку. Это событийно-управляемая архитектура, а не ночной пакетный синк. **В каких отраслях паттерн работает?** В любом традиционном B2B с длинным циклом, где у бизнеса уже есть операционная поверхность: автодилеры, недвижимость, проектные продажи, поддержка SaaS. Условие одно — существует система, в которой команда живёт ежедневно, и есть знание о клиентах, которое сейчас теряется между этой системой и головами сотрудников. --- ## Note 14: Klarna, Duolingo, Block: три кейса перестройки организации под агентов — что осталось после отката **URL:** https://notes.temadev.org/2026/05/klarna-duolingo-block-ai-native-restructure.html **Published:** 2026-05-27 **Genre:** market-deep-dive **Tags:** klarna, duolingo, block, organization, ai-restructure, operating-layer **Words:** 3146 **Summary:** Klarna, Duolingo, Block прошли цикл «громкая замена → тихий возврат». Граница, которую все три не увидели, проходит не там. # Klarna, Duolingo, Block: три кейса перестройки организации под агентов — что осталось после отката В феврале 2024 года Klarna опубликовала результаты работы AI-ассистента на собственном сайте и в интервью OpenAI: ассистент за первый месяц обработал 2,3 млн диалогов — две трети клиентского сервиса — и выполнил, по оценке компании, объём работы, эквивалентный нагрузке 700 штатных агентов поддержки ([OpenAI](https://openai.com/index/klarna/), [Siemiatkowski в X](https://x.com/klarnaseb/status/1762508581679640814)). Полтора года спустя, в мае 2025-го, CEO Klarna Себастьян Семятковски в интервью Bloomberg сформулировал это прямо: «From a brand perspective, I think it's critical that you are clear to your customer that there will always be a human if you want.» Он же признал, что компания «зашла слишком далеко» в замене людей агентами и возвращается к найму сотрудников клиентского сервиса ([Bloomberg](https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service)). Между этими двумя точками произошло ещё два публичных события того же типа. В апреле 2025 года CEO Duolingo Луис фон Ан разослал внутри компании меморандум о переходе на «AI-first» режим работы — он быстро ушёл в публичное поле через сотрудников и был подтверждён компанией ([The Verge](https://www.theverge.com/news/657594/duolingo-ai-first-replace-contract-workers)). К августу 2025-го фон Ан был вынужден объяснять смысл этого решения уже в The New York Times и признавать масштаб обратной реакции аудитории ([The New York Times](https://www.nytimes.com/2025/08/17/business/duolingo-luis-von-ahn.html)). В феврале 2026-го Block — холдинг Джека Дорси, владеющий Square и Cash App, — анонсировал сокращение около 40% штата, примерно 4 000 человек, прямо связав это с интеграцией ИИ в рабочие процессы компании ([The Guardian](https://www.theguardian.com/technology/2026/mar/03/jack-dorsey-block-ai-worker-jobs)). Три истории — три разные стадии одного и того же цикла. У Klarna публичный откат уже произошёл. У Duolingo идёт переформулировка позиции в реальном времени. У Block самый громкий старт — и кейс ещё не дозрел до коррекции. Эта статья — карта того, как именно не строится организация поверх агентов и что остаётся за вычетом громких заявлений. ## Дешевизна замены людей — в долг Общая ошибка трёх компаний воспроизводится по одной схеме. Выбирается операционный слой, нагруженный людьми и описываемый понятной метрикой: время ответа в поддержке, объём текста для перевода, количество рутинных операций. Запускается агентный пилот, считается экономия часов и зарплат. Цифра получается крупная, потому что числитель — экономия — считается в полном объёме задач, а знаменатель — то, что нужно достроить дополнительно, — остаётся пустым. Дальше следует публичное объявление. У Klarna это пост Семятковски в феврале 2024-го и совместный кейс с OpenAI, в котором цифра «700 человек» вышла на обложку деловой прессы и обвалила котировки Teleperformance — крупного call-center подрядчика ([Pragmatic Engineer](https://blog.pragmaticengineer.com/klarnas-ai-chatbot/)). У Duolingo — корпоративный меморандум апреля 2025 года, который немедленно ушёл наружу: «AI-first означает, что мы перестанем использовать подрядчиков для работы, которую может сделать ИИ» ([The Verge](https://www.theverge.com/news/657594/duolingo-ai-first-replace-contract-workers)). У Block — пост Дорси сотрудникам в феврале 2026-го, где сокращение прямо связано с «intelligence tools»: автоматизацией внутренних процессов и снижением потребности в повторяемом труде ([The Guardian](https://www.theguardian.com/technology/2026/mar/03/jack-dorsey-block-ai-worker-jobs)). Все три объявления формулируют ИИ-перестройку как операцию в плоскости задач — замену слоя людей слоем агентов. Ни одно не описывает изменений в плоскости организации: какие функции переезжают в новые единицы работы, какие границы ответственности перерисовываются, что становится с цепочкой эскалаций, какие новые роли создаются. Это и есть разница между «уменьшить численность на N процентов» и «переписать операционные единицы». Подробнее об этом сдвиге — в заметке про [роль вместо места](https://notes.temadev.org/2026/05/role-bolshe-seat-ai-native-org-chart.html): должность как контейнер для работы устарела раньше, чем большинство компаний это заметили. ## Что именно вернулось людям В 2025–2026 годах у всех троих в той или иной форме случилось одно и то же: тихий возврат функций людям. Интересна не сама траектория отката, а его геометрия. В Klarna после публичного признания Семятковски компания начала нанимать обратно сотрудников поддержки — но не на старые позиции. Возвращаемые роли сосредоточены вокруг работы с нестандартными случаями: спорные транзакции, эмоционально нагружённые ситуации, эскалации регуляторного характера ([Bloomberg](https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service)). По сути компания перерисовала уровень эскалации, признав, что плоская архитектура «агент-клиент» не покрывает дисперсию реальных запросов. Цифра «700 человек, эквивалент полной команды», на которую опиралась первая декларация, сама по себе скрывала важную деталь: с самого начала бот эскалировал «всё нестандартное» людям ([Pragmatic Engineer](https://blog.pragmaticengineer.com/klarnas-ai-chatbot/)). Когда команду людей сокращают, граница эскалации становится прозрачной — и оказывается, что она проходит по тонкому, но критичному слою клиентских историй. У Duolingo откат прошёл без громких аннонсов. CEO в интервью The New York Times и Fortune переформулировал позицию: «AI-first» — это не «без людей», а «по умолчанию через ИИ, с человеком там, где он нужен», и обратная реакция аудитории на меморандум апреля 2025 года была для него неожиданностью ([Fortune](https://fortune.com/2025/06/09/duolingo-ceo-surprised-backlash-ai-first-company-announcement/), [The New York Times](https://www.nytimes.com/2025/08/17/business/duolingo-luis-von-ahn.html)). На уровне операций часть подрядчиков вернулась в виде «контент-редакторов» и «языковых экспертов» — людей, которые верифицируют и финализируют машинный перевод, особенно для языков с малой обучающей выборкой и культурно нагружённых паттернов ([Customer Experience Dive](https://www.customerexperiencedive.com/news/duolingo-ai-first-consumer-backlash-lessons/757133/)). Цена ошибки в продукте, который учит языку, оказалась выше, чем экономия от отказа от проверки. У Block ситуация другая — это самый свежий и самый громкий случай. Сокращение 40% штата в феврале 2026-го не сопровождалось одновременным hire-back, и публичных свидетельств отката пока нет. Но в этой же истории видны два признака, которые в Klarna и Duolingo проявились до коррекции и в итоге её вызвали. Первый — внутренние сообщения о том, что «intelligence tools» (агенты, в частности проект Goose) применяются не к описанной перестроенной операции, а к существующей структуре труда: автоматизируется то, что и так выполнялось людьми, без переописания самой работы ([The Guardian](https://www.theguardian.com/technology/2026/mar/03/jack-dorsey-block-ai-worker-jobs)). Второй — слабый крипто-рынок и финансовое давление, на фоне которого AI-нарратив часто становится удобной публичной оболочкой для классической оптимизации затрат, не отвечающей на вопрос «какие операционные единицы перестроены». Аналитики уже называют это «AI-washing» — публичная привязка сокращений к ИИ как способ объяснить инвесторам цикл затрат. Во всех трёх случаях устойчивая ось одна и та же: люди возвращаются (или возвращение анонсируется) не на старые роли, а на верхний слой суждения, эскалаций и аккаунт-менеджмента. За агентами остаётся то, что поддаётся жёсткой формализации. ## Comparison: три кейса в одной таблице | Параметр | Klarna | Duolingo | Block | |---|---|---|---| | Год публичного объявления | Февраль 2024 | Апрель 2025 | Февраль 2026 | | Замещаемый слой | Клиентская поддержка | Подрядные переводы и контент | Сквозные операционные процессы и поддержка | | Цифра, вынесенная в публичное поле | «Эквивалент 700 агентов поддержки» | «AI-first компания», 10% подрядчиков сокращено | 40% штата, ~4 000 человек | | Форма коммуникации | Совместный пресс-кейс с OpenAI + пост CEO | Внутренний меморандум + утечка | Внутреннее сообщение Дорси + публичная подача | | Год коррекции | 2025 (явная) | 2025 (переформулировка) | Ещё не наступила (по состоянию на май 2026) | | Что вернулось людям | Сложные случаи, эскалации, нестандартные транзакции | Языковые редакторы, культурная проверка | Пока ничего публичного | | Что осталось за агентами | Первичная обработка типовых запросов | Перевод по языкам с большим корпусом | Внутренние ассистенты, рутинные процессы | | Тип ошибки | Недооценка дисперсии запросов | Подмена операционного дизайна лозунгом | Замена в плоскости задач без переописания единиц | ## Граница не по сложности, а по формализуемости Если собрать стабильную зону работы агентов по итогам коррекции Klarna и Duolingo и по тому, что про Block уже видно изнутри индустрии, получается узкий, но воспроизводимый набор. Первичная обработка типовых запросов с понятной таксономией. Перевод текста между языками с большой обучающей выборкой и проверкой постредактором. Кодогенерация под чёткие спецификации. Извлечение структурированных данных из документов. Рутинная аналитика по заранее определённым метрикам. Внутренние ассистенты-навигаторы по корпоративным знаниям. У всех элементов этого списка три общих свойства. **Измеримый выход**: правильность результата проверяется без привлечения организационного контекста. **Повторяемый вход**: классы запросов укладываются в конечное число паттернов. **Низкая цена единичной ошибки**: один плохой перевод или пропущенный тикет не разрушает систему. Где хотя бы одно из трёх свойств ломается — там агент возвращается под человека. Спорная транзакция в Klarna нарушает первое: измеримого «правильного» ответа нет, есть переговорный исход, в котором учтены история отношений, регуляторные ограничения и риск-аппетит. Локализация культурно нагружённого контента в Duolingo ломает второе: каждый случай уникален, и средний паттерн машинного перевода даёт результат, который в продукте про язык воспринимается как оскорбление. Регуляторная эскалация ломает третье: одна ошибка может стоить лицензии или превратиться в публичный скандал. Это и есть «хвосты распределения», которые в трёх кейсах публично проявились как причина отката или как зона ближайшего риска. Агенты эффективны в средней части распределения, но плохо ловят края. Хвосты — зона, где требуется суждение, контекст, ответственность за решение. Никакая универсальная агентная оболочка над фронтирной моделью эту зону не закрывает: вопрос не в качестве модели, а в том, что входной сигнал в хвостах слишком разрежен и контекстно нагружен, чтобы строить на нём измеримую таксономию. Связанный сюжет — почему универсальная агентная обвязка вообще не моат: это разбор в заметке про [управляемую обвязку как зависимость](https://notes.temadev.org/2026/05/managed-harness-vendor-lock-in-new-era.html). Здесь же ключевой вывод другой: если граница между агентом и человеком определяется не сложностью задачи, а её формализуемостью, то «процент автоматизации» — это плохая метрика трансформации. Она не отвечает на вопрос, какую долю **формализуемого** труда покрыли агенты, и какая доля **неформализуемого** труда осталась нагружённой на людей — и сколько новых ролей при этом не описано. ## Что отделяет PR-замену от структурной перестройки? Все три компании совершили операцию в плоскости задач — заменили людей, выполнявших отдельные функции, на агентов, выполняющих те же отдельные функции. Эта операция выглядит дёшево на бумаге: каждый человек — это зарплата, каждый агент — это API-вызов, разница — в счёт прибыли. Дорого она становится в момент, когда обнаруживается, что между «человеком, выполняющим работу» и «работой, выполненной правильно» лежит слой невидимого контекста: связи с другими функциями, история взаимодействия с клиентом, неявные знания о рисках, культурный паттерн. Этот слой не описан в инструкции и не воспроизводится промптом. Структурная перестройка устроена иначе. Она начинается не с вопроса «кого можно заменить», а с вопроса «какие операционные единицы у нас вообще есть». В классической организации единица — должность с описанием, KPI и местом в иерархии. В ИИ-нативной организации операционная единица определяется не носителем, а функцией, которую нужно выполнить: носитель — человек, агент или их комбинация — выбирается под класс случая. Эта инверсия описана в заметке про [роль вместо места](https://notes.temadev.org/2026/05/role-bolshe-seat-ai-native-org-chart.html). Из этого сдвига следуют три наблюдения о том, чего не было выстроено у Klarna, Duolingo и Block — и что отделяет работающую перестройку от PR-операции. **Первое наблюдение касается того, как запускается работа.** Klarna до отката пыталась перевести поддержку в чисто событийную модель — каждый тикет триггерит автоматическое исполнение. Не была достроена обработка событий, которые не закрываются с первого прохода: в исходной архитектуре «всё нестандартное» передаётся людям, но численность этих людей при этом сокращена. В организации, где координация строится через совещания и проектные статусы, агентный слой нагружается асимметрично: автоматизирует ходовую часть и оставляет нестандартные хвосты в неопределённом состоянии. У Duolingo один из признаков проблемы — для редких языков разрыв между поступившей задачей и тем, как именно её решить, оказывается шире, чем система способна закрыть без участия эксперта. **Второе наблюдение — про то, где живёт контекст принятия решения.** У Duolingo одна из причин отката — отсутствие машинной памяти о культурных особенностях языков. Постредакторы стали той самой памятью, которой не было в инструментах. У Klarna в спорных транзакциях контекст лежит в истории отношений с клиентом и в неявных правилах риска, не вытащенных в среду, к которой обращается агент. Контекст-в-голове-человека — это и есть незаметная зависимость, которая обнуляет экономику замены: пока он не вытащен в явную форму (память агента, правила маршрутизации, словари исключений), любое сокращение носителей этого контекста уменьшает качество решений на хвостах. У Block эта проблема ещё не проявилась публично, но именно потому, что 40-процентное сокращение свежее: ось «где живёт контекст» проверяется на горизонте 6–12 месяцев, как у Klarna. **Третье наблюдение — про принцип привязки ответственности.** В трёх компаниях коммуникация шла в логике «заменим должность А агентом А». В работающей перестройке логика противоположная: сначала описывается зона ответственности, затем определяется, на каком носителе — человек, агент, комбинация — она исполняется в каждом классе случаев. Это не семантическая разница: она определяет, можно ли откатываться без потери репутации. Klarna откатывалась с потерей именно потому, что вернулась к тому же языку «нанимаем агентов поддержки», от которого ушла полтора года назад. Если бы возврат описывался как «нанимаем носителей функции эскалаций» — это уже не откат, а уточнение архитектуры. Duolingo нашла этот язык во второй итерации: «AI-first» переформулирован: «We are not going to replace people with AI», — сказал фон Ан The New York Times. Внутренний смысл сдвига — «AI-default, с явно описанными зонами человеческого суждения». Block пока в первой итерации, и публичный язык — про сокращение, а не про перестройку. ## Что измеряют не там Связанная ошибка — в выборе метрики, на которую опирается решение об автоматизации. Чаще всего считают экономию часов или экономию фонда оплаты труда. Это знаменатель только частично: он не учитывает рост дисперсии решений, риск «незакрытых хвостов», стоимость новых ролей оператора и эскалатора, репутационную цену публичного отката. Об этом — отдельная заметка про [маржу, которая уходит выше уровня задач](https://notes.temadev.org/2026/05/agent-cases-margin-operating-layer.html): «сэкономленные часы» — это плохая прокси-метрика, потому что она замеряет цену **на уровне задач**, а структурная экономика автоматизации формируется **на уровне операционных единиц**. Цена «забытого» хвоста в Klarna 2025-го (репутация, регуляторное внимание, IPO-нарратив) выше, чем сумма зарплат сокращённой команды поддержки за 12–18 месяцев. Это не означает, что автоматизация поддержки была ошибкой; это означает, что метрика выбрана не на том уровне. ## Тесты на трёх ролях Из кейсов следуют три практические проверки для разных позиций — операционный руководитель, финансовый руководитель, совет директоров и инвесторы. **Операционный руководитель.** Возьмите ключевую функцию, которую планируете автоматизировать, и попробуйте описать её без упоминания конкретного человека или должности — что именно должно случиться, при каком условии, и как понять, что результат достигнут. Если функция описывается только через «такой-то человек делает то-то» — компания живёт в плоскости должностей, и любая замена будет PR-операцией. Дополнительный тест: какой процент входящих кейсов укладывается в описанные классы случаев? Если меньше 70% — хвост слишком большой, чтобы строить на нём чисто агентный слой. **Финансовый руководитель.** Отделите «среднюю часть распределения» — типовые случаи с измеримым ответом — от «хвостов» — нестандартных кейсов, где правильность определяется в диалоге. Если хвосты занимают существенную долю реальных запросов, экономия от замены людей агентами без слоя эскалации становится отрицательной — узнаётся это обычно через 6–12 месяцев, как у Klarna. Полезное правило: бюджет на новые роли (операторы агентных процессов, редакторы машинного вывода, ревьюеры эскалаций) должен закладываться **сверху** до запуска агентного слоя, а не «когда выяснится, что они нужны». **Совет директоров и инвесторы.** В отчётности компании, заявившей агрессивную ИИ-перестройку, ищите два сигнала. Первый — описание операционных единиц в языке функций, а не должностей: это признак реальной перестройки. Второй — структура hire-back или новых ролей вокруг эскалаций, суждения и аккаунт-менеджмента, а не возврат тех же ролей, что и до автоматизации. Это признак коррекции архитектуры, а не провала эксперимента. Если в годовом отчёте AI-инициатива описана через «сокращено N человек, сэкономлено $M», а не через «перерисованы такие-то операционные единицы и появились такие-то новые роли» — компания, скорее всего, ещё на стадии Klarna 2024 года. ## Сигналы 2026 года Три публичных индикатора покажут, превращается ли паттерн перестройки в массовую практику. **Первый — язык публичной коммуникации зрелых компаний.** Если CEO начинает рассказывать не «сколько мы сократили», а «как мы перерисовали границы ответственности» — это сигнал, что урок Klarna дошёл до уровня корпоративной нормы. Пока преобладает первый язык, и кейс Block февраля 2026-го показывает, что даже после публичного откатa Klarna инерция нарратива «сокращаем людей через ИИ» сильнее, чем инерция нарратива «переписываем единицы». **Второй — структура hire-back в компаниях, прошедших цикл агрессивной автоматизации.** Если возвращаемые позиции сгруппированы вокруг эскалаций, аккаунт-менеджмента и суждения — это нормальная коррекция. Если возвращаются те же роли, что и до отката, — это признание провала эксперимента. Klarna в 2025 году сделала шаг в сторону первого варианта (явно описывая возврат как работу с нестандартными случаями), но в публичной коммуникации язык всё ещё ближе ко второму. **Третий — появление новых операционных ролей, которых раньше не было**: операторы агентных рабочих процессов, редакторы машинного вывода, аудиторы агентных решений, тренеры памяти агентов. Чем больше таких ролей оформляется в стабильные должности, тем понятнее, что граница между человеком и агентом стабилизировалась на конкретных функциях, а не дрейфует. Сейчас эти роли существуют у вертикальных AI-компаний и почти не существуют у энтерпрайз-клиентов, которые в массовом порядке закупают агентные платформы. ## Главное - В 2024–2026 годах три публичных кейса — Klarna, Duolingo, Block — прошли (или проходят) цикл «громкая ИИ-замена → тихая коррекция → переформулировка». Это не свидетельство провала технологии, а карта типичной ошибки. - Граница между тем, что осталось за агентами, и тем, что вернулось людям, прошла не по сложности задачи, а по формализуемости: измеримый выход, повторяемый вход, низкая цена ошибки. - Все три компании совершили операцию в плоскости задач — заменили людей на агентов на тех же ролях. Структурная перестройка начинается с описания операционных единиц как зон ответственности, а не должностей. - Откат всегда вернёт людей на верхний слой суждения и эскалаций. Вопрос только в том, проходит ли этот возврат через публичный кризис коммуникации, как у Klarna, или планируется как уточнение архитектуры с самого начала. - Метрика «процент сокращённых» — плохая прокси трансформации. Лучшая — доля формализуемого труда, покрытого агентами, плюс структура новых ролей, оформленных за тот же период. ## FAQ **Что именно сделала Klarna в 2024 году с поддержкой?** В феврале 2024-го Klarna в совместной публикации с OpenAI и в посте Семятковски в X сообщила, что её AI-ассистент за первый месяц обработал 2,3 млн диалогов — две трети клиентского сервиса — и выполнил объём работы, эквивалентный нагрузке 700 штатных агентов поддержки ([OpenAI](https://openai.com/index/klarna/)). К маю 2025-го компания признала, что зашла дальше, чем стоило, и возобновила найм — но на верхний слой работы с нестандартными случаями ([Bloomberg](https://www.bloomberg.com/news/articles/2025-05-08/klarna-turns-from-ai-to-real-person-customer-service)). **Был ли у Duolingo полный отказ от человеческих переводчиков?** Нет. В апреле 2025-го компания объявила о переходе на «AI-first» режим работы и сокращении подрядчиков, чья работа поддавалась автоматизации ([The Verge](https://www.theverge.com/news/657594/duolingo-ai-first-replace-contract-workers)). После публичной реакции — включая удаление официальных аккаунтов Duolingo из социальных сетей на короткое время — часть функций вернулась людям в виде языковых редакторов и культурных проверяющих, а сам термин «AI-first» был переформулирован к августу 2025-го ([The New York Times](https://www.nytimes.com/2025/08/17/business/duolingo-luis-von-ahn.html)). **Что произошло с Block?** В феврале 2026-го Block анонсировал сокращение около 40% штата — примерно 4 000 человек, — связав это с интеграцией «intelligence tools» во внутренние процессы и автоматизацией повторяемого труда. Аналитики и пресса указали и на параллельный контекст: слабый крипто-рынок, давление на прибыль, удобство AI-нарратива как публичной оболочки сокращений ([The Guardian](https://www.theguardian.com/technology/2026/mar/03/jack-dorsey-block-ai-worker-jobs)). Публичного отката пока не было; коррекция, если она нужна, обычно проявляется через 6–12 месяцев. **Какая работа надёжно остаётся за агентами после всех откатов?** Та, у которой измеримый выход, повторяемый вход и низкая цена единичной ошибки. Первичная обработка типовых запросов, перевод между языками с большим корпусом, рутинная аналитика по заранее определённым метрикам, кодогенерация по жёсткой спецификации. Всё остальное возвращается под человека или работает как «агент плюс человек». **Что должно быть в компании, чтобы избежать откатов?** Описание ключевых функций как зон ответственности, а не должностей. Явное разделение «средней части распределения» (кандидат на агента) и «хвостов» (зона суждения). Заранее спроектированный слой эскалаций. Бюджет на новые роли, оформляемый до запуска агентного слоя, а не после. И язык внутренней и внешней коммуникации, в котором найм и автоматизация не противопоставлены, а описаны как варианты исполнения одной и той же функции. **Почему именно эти три компании, а не другие?** Потому что в каждой из них публично, под именем и с цифрой, прошёл громкий шаг автоматизации, на который рынок откликнулся. Это даёт редкую возможность сравнить три отдельных компании по одной оси — что они сделали, что сказали и что вернулось обратно. Большинство аналогичных случаев в энтерпрайзе проходит без громкого публичного аккорда, и проследить откат снаружи невозможно. --- ## Note 15: «Вертикальный AI» уже не значит то, что вы думаете **URL:** https://notes.temadev.org/2026/05/vertical-operating-layer-beats-horizontal-product.html **Published:** 2026-05-26 **Genre:** contrarian-take **Tags:** vertical-ai, services-as-software, b2b, market-structure, defensibility, operating-layer **Words:** 2567 **Summary:** К 2026 году ставка на «вертикальный AI» стала консенсусом — но смысл термина расходится на две разные модели. Одна защищена, другая нет. К весне 2026 года в B2B AI закончился спор о форме. Если в 2024-м тезис «вертикальные AI-агенты надёжнее горизонтальных продуктов» был контрарной позицией нескольких аналитиков, то к началу 2026-го он стал дефолтом. Y Combinator в [Request for Startups](https://www.ycombinator.com/rfs) держит «vertical AI agents» отдельной категорией с 2024 года. Joanne Chen из Foundation Capital в апреле 2024-го прямо [сформулировала](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) тезис service-as-software: «Быстрорастущий «рынок услуг» объёмом в триллионы долларов ждёт своей очереди на софтверизацию» — AI-агенты заходят не на 350 млрд долларов SaaS, а на 4,6 триллиона долларов рынка услуг, через специализированные продукты под конкретные роли и отрасли. Sequoia в [AI Ascent 2024](https://sequoiacap.com/article/ai-ascent-2024/) собрала эту же мысль в одну метафору: «генеративный AI второй акт» — про переход от инфраструктуры к прикладным вертикальным продуктам. Любой пост в венчурной ленте, любая презентация инвестору, любой питч в acceleration-программе начинаются с «мы строим вертикальный AI для…». Когда тезис становится консенсусом, он перестаёт работать как фильтр. Под одним словом начинают помещаться несколько разных вещей. Так уже было с «облаком» в 2010-м: между арендой виртуальной машины и платформой для совместной работы оказалась пропасть, которая выяснялась только через несколько лет операций. Под «вертикальным AI» сейчас живут две принципиально разные модели бизнеса с разной экономикой и разной защитимостью. Эту разницу можно описать через один вопрос: что именно у клиента останется уникальным через полтора года работы с продуктом, чего нет у соседа из той же отрасли с тем же поставщиком. ## Две вертикали под одной вывеской Первая модель — то, что можно назвать **вертикальным продуктом**. Команда берёт горизонтальный класс задач (customer support, sales development, qualification, content operations) и оборачивает его в отраслевые декорации: интеграции с типовыми CRM и ERP для конкретного сегмента, готовые сценарии для двух-трёх частых процессов, glossary терминов отрасли, шаблоны коммуникаций. Внутри агента — стандартная управляемая оболочка от Anthropic, OpenAI, AWS или Google. Снаружи — обёртка «AI for finance», «AI for legal», «AI for trades». Sales-команда продаёт «вертикальный AI» — архитектурно это горизонтальный продукт в нишевой упаковке. Вторая модель — **вертикальный операционный слой**. Здесь компания строит отдельный слой между фронтирной моделью и бизнес-процессом клиента: специфическое представление сущностей и событий отрасли, в котором каждое понятие имеет однозначное определение и набор допустимых состояний; накопленные траектории решений (что сделал агент, что вернулось из реальности, как это исправил человек) на горизонте года и больше; кодифицированные регламенты отрасли, версионируемые по мере того, как меняется реальность. Внутри тоже используется фронтирная модель, но защищённое — не она. Обе модели в публичных материалах называют себя одним словом. На презентации инвестору обе говорят: «мы знаем эту отрасль глубже, чем любой горизонтальный игрок». Но это разные «знаем глубже»: первая модель знает отрасль на уровне продакт-маркетинга, вторая — на уровне архитектуры данных, с артефактами, которые не воспроизводятся при смене поставщика. ## Сравнение: вертикальный продукт против вертикального слоя | Параметр | Вертикальный продукт | Вертикальный операционный слой | |---|---|---| | Что такое продукт | Управляемая оболочка плюс отраслевая обёртка | Слой между моделью и бизнес-процессом, накапливающий артефакты | | Какие интеграции | Готовые коннекторы к типовым CRM/ERP отрасли | Собственная схема, в которую отображаются данные клиента | | Где живёт «знание отрасли» | В промптах, шаблонах, маркетинговых материалах | В представлении сущностей, истории решений, регламентах | | Что воспроизводится после смены поставщика | Практически всё за 1–3 месяца | Восстанавливается за год и больше | | Источник защитимости | Скорость выхода на рынок, branding | Накопленные траектории и схема отрасли | | Чувствительность к управляемым оболочкам | Растворяется в них | Не пересекается с ними | | Стоимость переключения для клиента | Низкая: миграция за квартал | Высокая: год работы придётся проходить заново | ## Почему «вертикальный продукт» не выживает фазы массовых оболочек В 2024 году у вертикального продукта было оправдание. Управляемые агентные оболочки ещё не были массовыми, поэтому ценность «мы собрали для вас агента, оркестратор инструментов, память и аудит» была реальной — даже если базовая архитектура была одинаковой для всех вертикалей. Внешняя упаковка плюс инфраструктурная работа давали средний контракт выше, чем у голой подписки на API провайдера. В 2025–2026 годах эта база ушла. [Anthropic Agent Skills](https://www.anthropic.com/research/building-effective-agents), [OpenAI Assistants](https://platform.openai.com/docs/assistants/overview) и Responses API, [AWS Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/), [Google Vertex AI Agent Builder](https://cloud.google.com/products/agent-builder) — каждый из этих продуктов внутри 2025 года прошёл из beta в production: оркестрация инструментов, длинная память, политики безопасности, встроенные средства наблюдаемости теперь поставляются как часть облака. К концу 2025 года этот сдвиг стал очевидным: то, что было защитимой инженерией, стало доступной настройкой. Подробнее эта зависимость разобрана в [«Управляемая обвязка как зависимость»](https://notes.temadev.org/2026/05/managed-harness-vendor-lock-in-new-era.html). Foundation Capital в ноябре 2025-го прямо описала эту динамику в [«When model providers eat everything»](https://foundationcapital.com/ideas/when-model-providers-eat-everything-a-survival-guide-for-service-as-software-startups): провайдеры моделей «больше не продают только доступ к API — они агрессивно движутся вверх по стеку и превращаются из инфраструктурных компаний в продуктовые». Тезис фонда прямой: единственный способ построить устойчивый стартап на прикладном слое — система, в которой агенты непрерывно учатся на реальных взаимодействиях так, как лаборатории моделей воспроизвести у себя не могут. Это означает, что вертикальный продукт остаётся без своей основной ценностной составляющей. Раньше он продавал «отраслевую упаковку плюс настроенную агентную среду». Теперь второе перестаёт быть товаром — у каждого крупного облачного клиента это уже подключено. Остаётся одна отраслевая упаковка, конкурентоспособность которой ограничена скоростью копирования. Промпты копируются за дни, glossary — за недели, коннекторы — за месяц. В практике публичных миграций между AI-вендорами видна та же цифра: гайды по уходу с Sierra или Decagon на конкурента (например, [разбор миграции с Sierra](https://www.lorikeetcx.ai/articles/migrating-from-sierra-ai-enterprise-guide)) описывают перенос конфигурации в горизонт квартала. У вертикального продукта нет того, что не воспроизводится у конкурента в окне одного-двух кварталов. При этом средний контракт у вертикального продукта в 2026-м продолжает падать. Корпоративный покупатель к этому моменту прошёл два-три цикла внедрения и научился оценивать стоимость собственными силами. Он сравнивает не «вашу платформу с конкурентом», а «вашу платформу с собственным внутренним инженером плюс управляемая оболочка плюс месяц на интеграцию». В этом сравнении вертикальный продукт проигрывает, потому что не предлагает ничего, что покупатель не может собрать сам — за один проект, а не за подписку на годы. ## Почему вертикальный операционный слой работает иначе Вертикальный операционный слой защищён по другому основанию. Внутри он опирается на ту же самую управляемую оболочку — но строит над ней независимый продукт из артефактов, которые не лежат в облаке провайдера. Если смотреть на архитектуру работающих внедрений этой модели, прослеживаются три класса артефактов, которые и создают защиту. **Представление сущностей отрасли** — первое из таких артефактов. Это не «модель данных под клиента», как её делают системы интеграции. Это словарь, в котором каждое понятие отрасли имеет фиксированное определение и набор допустимых состояний, согласованных по всем процессам компании. В сегменте проектных продаж B2B это означает, что «возможность», «контрагент», «стадия квалификации» и «эскалация» определены одинаково для всех агентов и не зависят от формата исходной системы. В сегменте операций со спецтехникой — что «заявка», «единица техники», «маршрут» и «возврат» описаны как событийный поток, а не как строки в таблице. Эту схему нельзя купить готовой — она формируется непосредственно на продуктивных данных клиента в первом цикле внедрения и проверяется только тем, что система работает. **Накопленные траектории** — второй артефакт. Каждый запуск агента оставляет след: вызовы инструментов, последовательность шагов, результаты, корректировки от человека. На горизонте года этот след превращается в датасет, на котором базовая модель тонко настраивается под конкретный контекст, и который сам по себе становится отдельным активом. Этот тезис — отдельная статья: [«Данные траекторий: как закрытый цикл становится единственным реальным moat»](https://notes.temadev.org/2026/05/trajectory-data-decision-outcome-loop-moat.html). Чтобы новый поставщик воспроизвёл этот слой, ему нужно собрать те же месяцы логов с нуля. Платформенный провайдер тоже не имеет к нему доступа — траектории живут в инфраструктуре, к которой у клиента прямой контракт с поставщиком слоя. **Кодифицированные регламенты** — третий артефакт. В каждой отрасли есть негласные правила, которые меняются раз в квартал и не описаны ни в одном документе. Вертикальный слой фиксирует эти правила как версионируемые описания поведения агента: какие случаи эскалируются человеку, какие автоматизируются, какие требуют двойного подтверждения. Через год у клиента есть аудируемая история собственной операционной модели — артефакт, который сам по себе стоит дороже годовой подписки, потому что заменяет внутреннюю работу по регулярному пересмотру SOP. Эти три артефакта в отдельности доступны любому горизонтальному игроку. В сочетании, с продуманной архитектурой и со временем накопления — нет. Именно это сочетание — а не «отрасль в маркетинге» — отделяет вторую модель от первой. ## Когда разница между двумя моделями становится видной? Разница между двумя моделями становится очевидной не в момент покупки, а через полтора года после первого внедрения. В первый период оба продукта выглядят одинаково: и тот, и другой настраивают агента, подключают данные, запускают первые автоматизации. Покупатель сравнивает скорость старта, удобство интерфейса, ценник. На этом этапе вертикальный продукт может выигрывать — у него понятная упаковка, быстрый онбординг, агрессивный sales. Через год разрыв проявляется. У клиента вертикального продукта набор кейсов с метриками сэкономленных часов и закрытых тикетов — типичный набор, который воспроизводим у любого конкурента. У клиента вертикального слоя — собственный датасет траекторий, собственная отраслевая схема, собственная история регламентов. Первый клиент при появлении более дешёвого аналога меняет поставщика за квартал. Второй не меняет, потому что миграция уничтожит накопленные артефакты, и год работы придётся проходить заново. Это и есть пересборка экономики, описанная в [«Service-as-software: как агенты переписывают формулу выручки»](https://notes.temadev.org/2026/05/service-as-software-vertical-ai-revenue-model.html). В 2026 году большая часть «vertical AI» компаний — это первая модель. Они существуют, продаются, привлекают раунды, но в их публичной коммуникации почти ничего не сказано об артефактах. Они говорят о вертикали в категориях продакт-маркетинга («мы знаем финтех», «мы понимаем юристов»), а не в категориях архитектуры данных. Если в материалах компании не описано, чем именно защищено её положение через 18 месяцев — она в первой модели. Sierra и Decagon — два примера компаний второй модели, которые проговаривают логику открыто. Bret Taylor, сооснователь Sierra, в [подкасте Sierra](https://sierra.ai/resources/podcasts/bret-taylor-of-sierra-on-ai-agents-outcome-based-pricing-and-the-openai-board) формулирует принципиальную позицию: «software that gets better the more you use it» — слой накапливает контекст клиента, и именно этот контекст определяет качество ответа, а не базовая модель. Outcome-based pricing в этой логике становится естественным продолжением: вендор берёт деньги за разрешённый кейс, потому что качество разрешения опирается на собственный накопленный артефакт, а не на универсальные возможности модели. Decagon в публичных материалах строит ту же конструкцию вокруг «agent operating procedures» — версионируемого описания того, как компания работает с клиентом, которое и есть её продукт, а не отчёт о работе агента. Публичная экономика этой модели подтверждается цифрами. По [независимым разборам прайсинга Sierra](https://myaskai.com/blog/sierra-ai-complete-guide-2026), годовые контракты выходят на диапазон ​​«200–350 тысяч долларов в первый год» при setup fee 50–200 тысяч, Decagon в публичных обзорах стартует от порядка «95 тысяч в год» в нижнем сегменте. Эти цены реалистичны не потому, что поставщик «вертикален», а потому что внутри сидит операционный слой, выход из которого по тем же гайдам миграции занимает отдельный проект, а не переключение подписки. ## Граница тезиса: где обе модели не работают одинаково Разница между двумя моделями имеет две границы. Первая граница — слой инфраструктуры. Векторные базы, системы наблюдаемости, инструменты управления промптами, шлюзы безопасности — здесь горизонтальный продукт остаётся правильной формой, потому что у инфраструктуры по построению нет «отрасли». Pinecone, Weaviate, LangSmith работают по модели «один продукт — все вертикали», и это правильная для них стратегия. Защита у них устроена иначе: через сетевой эффект разработчиков и стоимость переключения инфраструктуры, а не через накопленные операционные артефакты. Описанное здесь различие касается прикладного слоя — продуктов, которые встраиваются в рабочий процесс компании, а не в стек разработчика. Вторая граница — сверх-широкие потребительские категории, где сам процесс универсален. Календарь, почта, заметки, базовая помощь в коде — это категории, в которых вертикализация не даёт преимущества, потому что у пользователя нет «отрасли». Горизонтальный AI-копилот для письменной коммуникации или для управления личным временем — рабочая модель. Но это потребительский слой; в B2B-сегменте подобных категорий мало, и они быстро поглощаются крупными платформами. Между этими двумя границами лежит остальной B2B-рынок. Здесь разница между двумя моделями становится критерием отбора, а не вопросом стиля. ## Как отличить вертикальный продукт от операционного слоя? Для фаундера ранней стадии, выбирающего рынок: одного «выбираем вертикаль» в 2026 году недостаточно — ключевой вопрос в том, какие именно артефакты накопятся у клиента в первый год и какой из них не воспроизводится при смене поставщика. Если ответ — «у нас будут логи», «у нас будут промпты», «у нас будут шаблоны» — это первая модель. Если ответ — представление отрасли, собранное на проде, плюс траектории решений, плюс кодифицированные регламенты — это вторая. Для фаундера на стадии масштабирования, у которого продукт уже работает: вторая ось расширения — не «соседняя индустрия». Соседняя индустрия для второй модели — это нулевой год накопления, со старта. Расширение в ту же индустрию по соседним слоям процесса сохраняет накопленные артефакты и держит экономику. Прыжок в соседнюю вертикаль возвращает компанию в зону конкуренции с управляемыми оболочками платформ, где у неё больше нет основания для премиальной цены. Для исполнительного руководителя, выбирающего поставщика: вопрос покупки в 2026-м — не «у кого лучше модель» и не «у кого красивее интерфейс». Полезный тест — попросить поставщика описать, что именно у клиента будет уникального через 18 месяцев работы, чего не было в день подписания контракта. Если ответ — общие фразы про «лучшее знание отрасли» — продукт в первой модели, и его себестоимость в долгую проиграет внутреннему инженеру плюс управляемой оболочке. Если ответ — конкретные артефакты с описанием того, как они хранятся и в каком формате принадлежат клиенту — продукт во второй модели. Для совета директоров и инвестора: метрика, которую стоит спрашивать в 2026-м, — не «какой у нас MRR» и не «насколько мы вертикальны в маркетинге», а «какие операционные артефакты собрали наши клиенты у себя, и сколько времени уйдёт у конкурента, чтобы их воспроизвести». Это прокси для второй модели и единственная защита, которая работает в фазе массовых оболочек. ## Главное - «Вертикальный AI» как тезис в 2026 году стал консенсусом, но потерял разрешающую способность. Под одним словом теперь живут две принципиально разные модели бизнеса. - Вертикальный продукт — это управляемая оболочка плюс отраслевая упаковка. В фазе массовых оболочек у него нет того, что не воспроизводится у конкурента за 1–3 месяца. - Вертикальный операционный слой — это представление сущностей отрасли, накопленные траектории решений и кодифицированные регламенты. Эти артефакты собираются годами на проде и не покупаются готовыми. - Большая часть «vertical AI» компаний 2026 года — это первая модель, продающая себя как вторая. Разница становится очевидной через полтора года, когда первый клиент меняет поставщика, а второй — нет. ## FAQ **Почему различие между двумя моделями не видно сразу?** Потому что в первые месяцы работы оба продукта делают похожие вещи: подключают данные, настраивают сценарии, запускают первые автоматизации. Артефакты второй модели накапливаются медленно — представление сущностей собирается на проде, траектории накапливаются по мере объёма решений. Через полтора года у клиента второй модели есть слой, у клиента первой — нет. До этого момента продукты выглядят одинаково. **Можно ли построить вертикальный операционный слой поверх управляемой оболочки провайдера?** Можно и нужно. Управляемая оболочка снимает инфраструктурную задачу: оркестрацию, память, аудит. Слой строится поверх неё как отдельный продукт — представление данных, история решений и регламенты живут в собственной инфраструктуре поставщика или клиента, а не у платформы. Главное условие — чтобы артефакты были архитектурно отделены от провайдера и переносимы. **Не значит ли это, что любая «vertical AI» компания со временем превратится в вертикальный слой?** Нет. Большая часть остаётся в первой модели — потому что сборка артефактов требует архитектурного решения с самого начала, а не «потом, когда будут ресурсы». Если компания не закладывала отдельный слой представления и накопления траекторий в момент запуска продукта, то через три года у неё накопятся только промпт-сниппеты и интеграционные коннекторы, не более. **Как покупатель в 2026 году отличает одну модель от другой до подписания контракта?** Через прямой вопрос: что именно у клиента будет уникального и собственного через 18 месяцев работы. Если поставщик отвечает в категориях продукта — «у вас будет настроенный агент», «у вас будут готовые сценарии» — это первая модель. Если в категориях артефактов — «у вас будет собственная отраслевая схема в открытом формате», «у вас будет история всех решений с экспортом», «у вас будет аудируемая версия регламентов» — это вторая. --- ## Note 16: Подписка против проекта: три класса экономики B2B-агентов и почему два из них умрут к 2027 **URL:** https://notes.temadev.org/2026/05/retainer-vs-project-b2b-ai-subscription-economics.html **Published:** 2026-05-25 **Genre:** pattern-essay **Tags:** b2b-ai, subscription-economics, retainer, unit-economics, operating-layer **Words:** 1777 **Summary:** Три формулы денежного потока в B2B-агентах и пять вопросов, после которых видно, какая подписка переживёт 2027 год. Между классическим SaaS и B2B-AI студиями в 2025 году расходится одна тихая цифра — удержание выручки в подписке. По данным [State of the Cloud 2024](https://www.bvp.com/atlas/state-of-the-cloud-2024) от Bessemer Venture Partners, медианная подписка зрелого вертикального SaaS держит чистое удержание выручки в районе верхних процентов сотни, а подписка на услуги, упакованные как AI-сервис, в среднем остаётся ниже этого ориентира. Разница не в возрасте рынка — слово «подписка» в этих двух случаях описывает разные экономические явления. Пока B2B-AI студии продают подписку формулой 2014 года — «оплата за то, что мы остаёмся на связи» — этот разрыв будет расти, а не сокращаться. В 2026 году типичная B2B-AI студия выстраивает денежный поток по знакомому шаблону: внедрение как фиксированный проект (обычно от 500 тысяч до 5 миллионов рублей в зависимости от размера контура), затем ежемесячная подписка под названием «сопровождение» или «поддержка» — как правило, 10–20 процентов от стоимости внедрения. Формула пришла из эпохи системной интеграции — там она держалась на том, что внедрение было дорогим, болезненным и невозвратным. В мире AI-агентов это условие исчезает: внедрение дешевеет структурно, и вместе с ним исчезает экономическое основание подписки-как-поддержки. Структурный обрыв этой модели мы [разобрали отдельно](https://notes.temadev.org/2026/05/ai-studio-commoditization-cliff-2027.html) — здесь же интересует именно экономика подписки. ## Три класса денежного потока на одной полке Если разложить публично известные B2B-AI компании 2024–2026 годов по форме контракта, видны три устойчивых класса. **Класс 1 — чистый проект.** Студия продаёт внедрение как фиксированную работу, после сдачи отношения заканчиваются. Это классическая бутиковая консалтинговая модель: проект сдан — выручка зафиксирована, дальнейшая экономика клиента уже не касается поставщика. Foundation Capital в эссе про [переход от software-as-a-service к service-as-software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) описывает подобный подход как ограниченный по горизонту: он живёт ровно до тех пор, пока спрос на внедрение растёт быстрее, чем падает его цена. За 2024–2025 годы цена внедрения типового AI-агента снижалась структурно — провайдеры моделей кратно удешевляли токены, а паттерны типовых задач становились публичным референсом в виде open-source проектов и шаблонов. **Класс 2 — проект плюс подписка-как-поддержка.** Самая распространённая сегодня модель. Внедрение продаётся как проект, дальше клиент платит ежемесячно за «доступ к команде», «обновления», «мониторинг», «горячую линию». Внешне это похоже на SaaS, но по экономике это лизинг команды. Клиент платит не за продукт, а за гарантию, что кто-то будет рядом, если сломается. **Класс 3 — подписка-как-углубление.** Внедрение плюс ежемесячная плата за то, что операционная модель клиента с каждым месяцем становится дороже к замене. Подписка покупает не присутствие команды, а постепенное накопление специфичной для клиента информации, которая на стороне нового поставщика не воспроизводится мгновенно. Это самая молодая из трёх форм: устойчивых публичных кейсов мало, а сам контур ближе к гипотезе, чем к практике. ## Comparison: три класса по семи параметрам | Параметр | Класс 1: проект | Класс 2: проект + поддержка | Класс 3: подписка-как-углубление | |---|---|---|---| | Источник выручки | Разовый платёж | Разовый платёж + ежемесячный | Разовый платёж + ежемесячный | | Что покупает клиент | Готовое внедрение | Готовое внедрение + страховка | Готовое внедрение + накопление артефактов | | Базовый risk клиента | «Сломается — никто не починит» | «Платим, чтобы не сломалось» | «Через год бизнес станет дороже к замене» | | Защитимость поставщика | Нет | Слабая (команда взаимозаменяема) | Высокая (артефакты не переносятся) | | Что происходит при коммодитизации внедрения | Маржа падает | Подписка теряет смысл | Подписка усиливается | | Ожидаемая глубина контракта (гипотеза) | Один проект | Краткосрочная | Долгосрочная | | Состояние на 2026 | Стагнация | Доминирует | Появляется | ## Дешевизна внедрения в долг Стоимость одного интеграционного цикла «вынуть процесс из бизнеса, обернуть в агента, вернуть» падает по трём независимым осям одновременно. Первая ось — управляемая агентная оболочка. Anthropic, OpenAI, AWS и Google последовательно вынесли в платный продукт всё, что раньше студии писали как кастом: оркестрацию, обработку инструментов, память, безопасность, проверки. [Anthropic в публикациях об агентной инфраструктуре](https://www.anthropic.com/news) открыто описывает движение от «соберите свою оболочку» к «возьмите нашу». Это перенос границы между продуктом и сервисом в ту же сторону, в которую он двигался в эпоху AWS: то, что раньше было поводом для гонорара интегратора, становится платным месячным сервисом провайдера. Маржа уходит на платформу, а не на студию. Вторая ось — стоимость токенов на типовых задачах. Цена входного токена у фронтирной модели в 2024–2025 годах последовательно снижалась — это видно по обновлениям прайс-листов [Anthropic](https://www.anthropic.com/news) и [OpenAI](https://openai.com/blog/): за 18 месяцев цена per-million tokens у топовых моделей упала на 60–80 процентов на сопоставимых задачах. Это означает, что «дорогая часть» внедрения — пилотирование, прогон, тюнинг подсказок, дебаг — стала пренебрежимой в общей смете. Раньше она окупалась ручным трудом дорогих инженеров, теперь — дешёвым прогоном дешёвых моделей. Третья ось — типизация бизнес-процессов. К 2026 году рынок накопил публичные паттерны для самых ходовых случаев: классификация входящих обращений, маршрутизация запросов, синтез отчётов, генерация черновиков, обогащение клиентских данных. Любая студия, которая в 2024 году считала это своим ноу-хау, в 2026 году видит open-source референсы, повторяющие то же самое. Сложить три оси — и внедрение перестаёт быть барьером. Цена внедрения типового AI-агента в типовой процесс приближается к цене квартальной подписки на корпоративный SaaS — примерно 200–500 тысяч рублей вместо 2–5 миллионов годом ранее. В этой точке чистая проектная модель теряет премию. А когда у внедрения нет премии, подписка-как-поддержка лишается экономической функции. Если внедрение стоит как годовая подписка, никто не будет платить ту же сумму ещё раз каждый месяц «на всякий случай». Клиент либо переходит на управляемый сервис провайдера, либо нанимает внутреннего инженера, либо разрывает контракт в первые месяцы — когда становится понятно, что подписка не приносит ничего, чего не было в день сдачи проекта. ## Что именно покупает клиент, когда подписка работает? Гипотеза третьего класса — что подписка может удерживаться не отношениями, а накоплением. Клиент платит ежемесячно не за «доступ к команде», а за то, что операционный слой его бизнеса с каждым месяцем становится дороже к замене. Чтобы это работало, у подписки должно быть формальное содержание — материал, который остаётся у клиента и который новый поставщик не способен повторить за неделю. В публичных дискуссиях вокруг агентных систем (см. эссе [Foundation Capital про самообучающихся агентов](https://foundationcapital.com/ideas/the-paradox-of-self-building-agents-teaching-ai-to-teach-itself) и [a16z про вертикальный SaaS с AI](https://a16z.com/vsaas-vertical-saas-ai-opens-new-markets/)) такое содержание обычно описывается через три направления накопления. Первое — собственная история операционных решений: какие случаи возникали, какие выборы делались, где система ошибалась. На горизонте года эта история превращается в материал, на котором базовые модели можно тюнить под конкретный контекст. Чтобы новый поставщик догнал этот материал, ему нужно собрать те же месяцы наблюдений с нуля. Второе — фиксация поведения в форме, которую можно версионировать. В любом корпоративном процессе есть негласные правила, которые меняются и нигде не записаны системно. Подписка такого класса делает их явными и аудируемыми. Через год у заказчика есть собственная история того, как менялись операционные политики, — артефакт, который не переносится мгновенно в чужую систему. Третье — отраслевая схема: формальное описание сущностей и отношений предметной области, которое со временем расходится с реальностью бизнеса. Подписка такого класса включает ежемесячное переопределение этой схемы. Это не «поддержка»: это нормативно-справочная работа, которая в прошлую эпоху велась внутри крупных предприятий собственными отделами. Если подписка работает хотя бы по двум из трёх направлений, у клиента нет рационального повода её отменять. Если ни одно из трёх не выполняется — это рассрочка внедрения под видом подписки, и ранний отток предсказуем. Именно такой накопительный контур вокруг одного измеримого процесса мы и собираем как рабочую систему, а не как пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=retainer-vs-project-b2b-ai-subscription-economics&utm_content=inprose). ## Пять вопросов покупателю — до подписания Эти вопросы стоит держать со стороны покупателя, как способ читать предложение до подписания контракта. Они не претендуют на исчерпывающий чеклист — это пять простых тестов на то, что именно стоит за словом «подписка». Первый. Что клиент получает в первый месяц подписки, чего у него не было в день сдачи проекта? Если ответ формулируется через слова «доступ», «команда», «поддержка» — контракт во втором классе. Второй. Где хранятся данные решений за последний период и какой у клиента доступ к ним? Если хранилище полностью на стороне поставщика и экспорт не предусмотрен договором — клиент платит за удобство разрыва договора в одну сторону, не за углубление. Третий. Что именно версионируется ежемесячно, и кто это видит? Если ответ — «мы постоянно что-то улучшаем» без артефакта — версионирования нет, есть присутствие. Четвёртый. Какой ценностный артефакт клиент уносит, если разрывает контракт через год? Если ответ — «опыт работы с нами» — артефакта нет, есть отношения. Пятый. Если убрать из контракта слово «поддержка» и его синонимы — что останется в формулировке предмета договора? Если предмет договора растворяется — подписка во втором классе. Если на три или более из пяти вопросов выходит общая фраза вместо имени конкретного артефакта — подписка скорее всего относится ко второму классу, и в горизонте 2026–2027 её срок жизни ограничен. ## Сигналы 2026 года Три публичных сигнала покажут, насколько быстро происходит разделение классов. Первый сигнал — появление в стандартных корпоративных тендерах строки «экспорт данных решений в открытом формате» как обязательного требования. Покупатели, предъявляющие этот пункт в тендерной документации, уже разделяют накопительный слой данных и стандартный сервис как разные предметы закупки. Второй сигнал — сдвиг прайс-листов провайдеров (Anthropic, OpenAI, крупных платформ) в сторону платных подписочных тиров за инфраструктуру агентов, включающих хранение истории решений и версионирование поведения. Это вынесет часть третьего класса в управляемый сервис — и оставит студиям только верхний слой: отраслевую схему. [a16z в материалах про вертикальный SaaS с AI внутри](https://a16z.com/vsaas-vertical-saas-ai-opens-new-markets/) прямо описывает сценарий, в котором управляемая инфраструктура поглощает часть того, что сегодня считается ценностью студий. Третий сигнал — первая публичная отчётность B2B-AI компании, в которой удержание выручки в подписке на услуги растёт за счёт увеличения глубины основного контракта, а не за счёт продажи новых модулей. Целевой ориентир — NRR выше 115 процентов на услугах (а не на лицензиях), который в текущих публичных отчётах сектора пока не виден. Это будет первый кейс, подтверждающий, что третий класс в принципе масштабируется в публичных метриках, а не только в анекдотических заметках инвесторов. Связь с пересмотром метрики, по которой такая подписка считается, мы разбирали в [заметке про charge metric](https://notes.temadev.org/2026/05/seat-pricing-unit-dead-outcome-based-ai.html). ## Главное - В B2B-AI существуют три экономически различных класса контракта: проект, проект-плюс-поддержка, проект-плюс-углубление. Внешне второй и третий выглядят как подписка — внутри это разные явления. - Первые два класса схлопываются к 2027 году, потому что цена внедрения структурно падает по трём независимым осям и вместе с ней исчезает экономическая функция «поддержки». - Третий класс держится на том, что операционная модель клиента становится дороже к замене каждый месяц — за счёт накопления данных решений, версионирования поведения и углубления отраслевой схемы. - Любой контракт можно проверить пятью вопросами на предмет, в каком классе он находится. Если на большинство выходит общая фраза вместо имени артефакта — это второй класс. ## FAQ **Подписка-как-поддержка в B2B-AI обречена?** В её текущей форме — скорее всего да, в горизонте 18–24 месяцев. Когда внедрение перестаёт быть барьером, «поддержка» теряет основание. Но та же ежемесячная плата может остаться, если её предмет переписать с «доступа к команде» на конкретные артефакты — данные решений, версии поведения, схему предметной области. **Чем «подписка-как-углубление» отличается от классического retainer'а в консалтинге?** Retainer в консалтинге продаёт время эксперта. Подписка третьего класса продаёт артефакт, который накапливается у клиента и который новый поставщик не может воспроизвести мгновенно. Это разница между лизингом ресурса и накоплением капитала. **Можно ли построить третий класс на готовой управляемой оболочке провайдера?** Частично. Управляемая оболочка снимает часть инфраструктурных задач (хранение, оркестрация), но не закрывает версионирование поведения и отраслевую схему. Их по-прежнему придётся строить как отдельный слой над оболочкой провайдера, иначе третий класс не отличим от второго. **Какая метрика лучше всего показывает, в каком классе находится контракт?** Сравнение того, что клиент получает в первый и в двенадцатый месяц подписки. Если ответ совпадает — это второй класс. Если в двенадцатом месяце есть артефакты, которых не было в первом, и они принадлежат клиенту — это третий класс. --- ## Note 17: Управляемая обвязка как зависимость: новый замок, которого не замечают **URL:** https://notes.temadev.org/2026/05/managed-harness-vendor-lock-in-new-era.html **Published:** 2026-05-22 **Genre:** contrarian-take **Tags:** ai-agents, vendor-lock-in, managed-services, platform-risk, b2b-ai **Words:** 1943 **Summary:** Три механизма, через которые управляемая агентная обвязка создаёт зависимость глубже API lock-in — и как выстроить защиту от неё заранее. # Управляемая обвязка как зависимость: новый замок, которого не замечают За первый квартал 2026 года четыре крупнейших облачных провайдера — Amazon, Google, Microsoft и Anthropic — независимо друг от друга перевели свои агентные платформы из статуса «бета» в статус «production-ready». AWS запустил [Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) с управляемой памятью, хранилищем инструментов и средой исполнения агентов; согласно [AWS Bedrock FAQ](https://aws.amazon.com/bedrock/faqs/), AgentCore позиционируется как «открытая платформа для построения, подключения и эксплуатации AI-агентов». Google открыл [Agent Builder](https://cloud.google.com/products/agent-builder) с глубокой интеграцией в Vertex Search. OpenAI довёл [Assistants API](https://platform.openai.com/docs/assistants/overview) до v2 с тредами, векторными хранилищами и прикреплёнными файлами; в апреле 2026 года модели OpenAI [появились на Bedrock Managed Agents](https://www.theregister.com/software/2026/04/28/openai-jumps-out-of-microsofts-bed-into-amazons-bedrock/5223754) — управляемая обвязка перестала быть привязанной к одному вендору модели. Anthropic, выпустив [Model Context Protocol](https://www.anthropic.com/news/model-context-protocol), одновременно строит управляемую агентную среду поверх него — Anthropic Agents — это hosted-окружение, которое управляет вызовами инструментов, памятью сессий и политиками безопасности от имени клиента. Рынок прочитал это как демократизацию: теперь запустить AI-агента можно за несколько часов, без месяца инженерных работ. Чтение точное по поверхности, но пропускающее структурный сдвиг. По данным [McKinsey State of AI 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai), 78% организаций уже используют AI, и 74% сообщают об ROI в первый год — рост adoption очевиден. Внутри этой простоты спрятан новый вид зависимости, который сложнее и дороже, чем API lock-in 2015 года. ## Почему API-зависимость 2015 года была управляемой Когда Twilio, Stripe и Sendgrid захватили рынок, компании регулярно переоценивали стоимость перехода и находили её приемлемой. Логика была прямая: если поставщик поднимает цены или ухудшает качество — переписываем интеграционный слой, меняем API-ключ, деплоим. Переписать интеграцию — это инженерный проект с предсказуемым объёмом: несколько недель работы двух-трёх инженеров и прямые затраты, которые легко поставить в бюджет. Бизнес-процессы при этом оставались нетронутыми: операторы продолжали делать то, что делали, просто SMS теперь уходило через другой шлюз. Управляемая агентная обвязка (агентная оболочка, или managed harness) — это принципиально другая конструкция. AWS Bedrock AgentCore — это не просто API для вызова языковой модели. Это управляемая среда, в которой живут: история сессий и диалогов, долгосрочная память агентов, реестр инструментов и политики их вызова, журнал решений и трассировки. То же самое верно для OpenAI Assistants с их тредами и векторными хранилищами, для Vertex AI Agents с интегрированными хранилищами данных, для антропиковской среды поверх MCP. Эти сервисы не плохие; они делают то, для чего предназначены — сокращают time-to-production с недель до часов. Проблема в том, что они создают три типа зависимости, которые накапливаются незаметно — до тех пор, пока переключение не становится проектом на полгода. Заново обучить организацию — это именно та стоимость, которая возникает на месте инженерного бюджета API-эпохи, и именно она делает этот lock-in фундаментально иным. ## Три механизма зависимости ### Гравитация данных: память остаётся у провайдера Первый механизм — данные. Каждый разговор агента с пользователем, каждое решение, каждый след инструментального вызова оседает в управляемой памяти провайдера. В OpenAI Assistants это треды и вектора; в AWS AgentCore — сессионное хранилище и Knowledge Bases; в Vertex — интегрированный Search with datastores. Эти данные — не просто логи. Это обучающий сигнал: пары «контекст → решение → исход», которые нельзя воссоздать ретроспективно. [AWS в документации по Bedrock Agents](https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html) описывает session memory как способ «помнить прошлые взаимодействия и использовать их для персонализации поведения» — явное признание, что данные влияют на качество агента. Если через год компания решит перейти на другой стек, она унесёт с собой файлы и схему — но не накопленную калибровку агента под специфику своих процессов: определённые формулировки эскалаций, выверенные после сотен реальных диалогов, параметры retrieval, собранные из фидбэка пользователей, поведенческие правила, отлитые в операциях. Новый агент начнёт с нуля. Проблема, которую инженеры начали называть «невидимым lock-in данных», состоит в следующем: данные технически экспортируемы, но их ценность нераздельно связана с конкретной моделью и средой, в которой они накапливались. Отдельная проблема — где физически хранятся данные. AWS AgentCore хранит память в DynamoDB и S3 в пределах выбранного региона. Но политика использования данных для дообучения моделей у каждого провайдера своя, и по умолчанию не всегда в пользу клиента. ### Маршрутизация решений: tool registry и policy — проприетарные Второй механизм — маршрутизация. В каждой из четырёх платформ реестр инструментов (tool registry) устроен по-своему: разные схемы описания функций, разные политики разрешений, разные способы передачи контекста в инструмент. Это не случайность — это сознательное проектирование. Когда компания наращивает экосистему инструментов поверх одной платформы — интеграции с CRM, ERP, внутренними системами, — она невольно пишет всё это под конкретный contract провайдера. Переход означает не только перенос логики инструментов, но и адаптацию всего реестра под новые схемы. В больших установках это десятки и сотни инструментов. Anthropic, выпустив Model Context Protocol как открытый стандарт, формально снижает этот риск — MCP-сервер можно подключить к любому совместимому runtime. Но управляемая антропиковская среда поверх MCP всё равно добавляет собственный слой абстракции для политик и управления. Открытость протокола не равна нейтральности платформы. ### Инерция SOP: бизнес-процессы переписываются под среду Третий механизм — самый медленный и самый дорогой. Когда AI-агент входит в операционный процесс, люди адаптируются к тому, как работает этот конкретный агент в этой конкретной среде: как он запрашивает подтверждение, как формулирует результат, когда эскалирует, как структурирует ответ. Стандартные операционные процедуры (SOP) переписываются вокруг этого поведения. «Заново обучить организацию» — это пересборка всех SOP, инструкций и неформальных практик, которые выстроились вокруг поведения старого агента. Инженерная часть при переходе на другую платформу занимает недели. Организационная — месяцы: переобучение операторов, переписывание инструкций, обновление эскалационных флоу, восстановление доверия к новым ответам. [McKinsey в ежегодном обзоре State of AI 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) фиксирует: при 78% adoption разрыв между внедрением и измеримым влиянием на P&L остаётся большим именно из-за организационной адаптации — инфраструктурная часть перестала быть узким местом. Переключение поставщика обвязки запускает этот процесс заново. ## Чем это отличается от классического vendor lock-in Традиционный vendor lock-in предполагал, что данные и логика физически живут у поставщика и технически недоступны. Регуляторный ответ — требования к портируемости данных, открытые форматы, право на экспорт. Это работало для хранилищ и SaaS-продуктов — выгрузил CSV, пересёл в другую базу, импортировал. Новый lock-in устроен иначе: данные технически экспортируемы, но их ценность нераздельна с контекстом, в котором они накапливались. Промпты переносятся. Векторы — формально тоже (экспорт в parquet, JSON, npz — вопрос API). Но накопленная история решений, организационное знание «как наш агент работает», пространственная конфигурация инструментов — всё это либо не экспортируется в значимом виде, либо теряет смысл вне исходной среды. Это меняет уравнение «build vs buy». Раньше «купить» значило сэкономить на инфраструктуре с умеренным риском зависимости. Сейчас «просто запустить на managed harness» означает согласиться на постепенно нарастающую операционную зависимость в обмен на скорость запуска. Это разумный компромисс в большинстве случаев, но он перестал быть нейтральным выбором. | Параметр | API lock-in (2015) | Managed harness lock-in (2026) | |---|---|---| | Что остаётся у поставщика | Маршрутизация запроса | Память, решения, SOP | | Стоимость переключения | Недели инженерных работ | Месяцы организационной адаптации | | Данные экспортируемы? | Да | Формально да, ценность теряется | | Виден ли риск на старте? | Умеренно | Слабо — накапливается незаметно | | Рычаг давления поставщика | Ценообразование | Ценообразование + операционная инерция | ## Как выстроить защиту Для основателя и CTO позиция «мы не используем managed harness» в 2026 году — это не решение, это задержка. Скорость разработки на управляемых платформах реальна: рост adoption до 78% [по данным McKinsey](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai) фиксирует, что выбор «оставаться вне» обходится дороже, чем считалось два года назад. Защита строится не отказом от платформ, а архитектурным слоем поверх них — об этом подробнее в заметке [«Обвязка стала коммодити, операционный слой — нет»](/2026/04/harness-commodity-operating-layer.html). **Для инженера:** ключевой вопрос — где живёт control plane. Если оркестрация агентов, реестр инструментов и маршрутизация решений описаны в вашем коде и деплоятся в вашей инфраструктуре — вы используете провайдера как runtime, а не как операционную платформу. Если оркестрация делегирована в AWS Step Functions for Bedrock или в OpenAI Assistants threads — control plane у провайдера. Открытые проекты вроде LangGraph, Temporal и самостоятельно хостируемые MCP-серверы позволяют строить vendor-нейтральный control plane с подключаемыми runtime-backends. **Для executive:** при оценке AI-проектов добавьте в модель стоимость переключения через 2–3 года. Если ответ «мы никогда не будем переключаться» — окей, но это осознанная ставка на конкретного поставщика, а не нейтральная позиция. Если ответ «не знаем» — это операционный риск, который стоит оценить сейчас, а не когда контракт на рестракчуринг уже подписан. **Для основателя:** компании, которые строят продукт поверх управляемой обвязки без собственного операционного слоя, получают скорость запуска сегодня и операционную зависимость через несколько релизных циклов. Компании, которые тратят дополнительные инженерные ресурсы на vendor-нейтральный control plane на старте, покупают возможность переключиться или пересмотреть условия — то есть реальные переговорные позиции с поставщиком. Такой заменяемый контур вокруг одного измеримого процесса мы и собираем как рабочую систему, а не как пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=managed-harness-vendor-lock-in-new-era&utm_content=inprose). ## Сигналы, на которые стоит смотреть Рынок пока не выработал устойчивые практики. Несколько индикаторов покажут, как будет развиваться ситуация в ближайшие 12 месяцев. Первый сигнал — появление требований к экспорту агентной памяти в регуляторных инициативах. Европейский AI Act в 2026 году фокусируется на прозрачности и объяснимости, но портируемость данных агентов пока вне его периметра. Если регулятор двинется в эту сторону — провайдеры начнут конкурировать по openness. Второй сигнал — появление managed harness с открытым control plane как продуктом. Несколько стартапов уже позиционируют себя в этой нише (vendor-neutral agent orchestration), но ни один пока не достиг масштаба, при котором enterprise-покупатель готов сделать на него ставку. Если один из них наберёт критическую массу — баланс сил сдвинется. Третий сигнал — ценовые манёвры текущих провайдеров. Исторически после периода роста adoption следует этап monetization pressure: цены на хранение данных, на memory API calls, на tool registry. Если этот этап начнётся раньше, чем рынок выработает альтернативы — зависимость проявится в P&L быстрее, чем в операционных процессах. ## Главное - Управляемая агентная обвязка (Anthropic Agents, OpenAI Assistants, AWS Bedrock AgentCore, Vertex AI Agents) — это не просто API, это операционная платформа с тремя уровнями зависимости. - Данные, накопленные в управляемой памяти провайдера, формально экспортируемы, но их ценность неотделима от контекста платформы — это принципиально иначе, чем API lock-in. - Стоимость переключения складывается из инженерной части (недели) и организационной части (месяцы) — вторая обычно не закладывается в оценку на старте. - Защита строится не отказом от платформ, а выбором где живёт control plane: у вас или у провайдера. - Разумный компромисс — использовать managed harness как runtime-backend при vendor-нейтральном control plane поверх него. ## FAQ **Что такое управляемая агентная обвязка и чем она отличается от обычного API?** Управляемая агентная обвязка — это hosted среда, в которой провайдер берёт на себя управление памятью агента, хранением истории сессий, реестром инструментов и политиками их вызова. В отличие от обычного API, который просто маршрутизирует запросы, обвязка хранит состояние и накапливает данные о решениях. AWS Bedrock AgentCore, OpenAI Assistants v2, Vertex AI Agent Builder — примеры таких платформ, запущенных в production в первом полугодии 2026 года. **Почему переключить поставщика обвязки сложнее, чем сменить API-провайдера?** При смене API-провайдера меняется интеграционный слой — инженерная задача. При смене обвязки меняются три вещи: данные памяти (формально переносимые, но теряющие калибровку), конфигурация инструментов (разные схемы у каждого провайдера), и стандартные операционные процедуры людей, привыкших к конкретному поведению агента. Последнее — организационная задача, которая занимает месяцы, а не недели. **Всегда ли использование managed harness — плохой выбор?** Нет. Скорость запуска реальна, и в большинстве сценариев компромисс разумный. Плохой выбор — не осознавать накапливающуюся зависимость. Управляемая обвязка как runtime-backend при собственном control plane (оркестрация в вашем коде, реестр инструментов у вас) — это вполне устойчивая архитектура. **Как оценить, насколько наш стек уже зависим?** Простой тест: если завтра AWS поднимет цены на Bedrock AgentCore в два раза — сколько времени займёт переход на альтернативу? Если ответ «2–4 недели» — зависимость на уровне API. Если «6+ месяцев» — операционная зависимость уже накоплена. Отдельный вопрос: где описана оркестрация агентов — в вашем коде или в настройках платформы. **Меняет ли что-то открытость Model Context Protocol от Anthropic?** Частично. MCP снижает зависимость на уровне инструментального контракта — сервер, написанный по этому стандарту, теоретически подключается к любому совместимому runtime. Но управляемая среда Anthropic поверх MCP добавляет собственный слой политик и управления, который остаётся проприетарным. Открытость протокола не равна нейтральности платформы. --- ## Note 18: Авито как операционная плоскость: почему B2B-канал в России перестал быть рекламной доской **URL:** https://notes.temadev.org/2026/05/avito-b2b-operational-layer-russia.html **Published:** 2026-05-21 **Genre:** pattern-essay **Tags:** pattern-essay, avito, b2b, operational-layer, lead-response, russia, ai-внедрение **Words:** 2400 **Summary:** Авито в B2B — не рекламная доска, а операционный слой входящего потока: алгоритм ранжирует по скорости ответа, ручная обработка не масштабируется. # Авито как операционная плоскость: почему B2B-канал в России перестал быть рекламной доской В целом ряде российских B2B-вертикалей — от промышленного оборудования и стройматериалов до ремонтных услуг, аренды техники и оптовых поставок — Авито давно перестал быть рекламной площадкой. Он стал операционным слоем входящего потока: интерфейсом, через который компании ежедневно ведут переговоры, квалифицируют запросы и закрывают сделки. По [официальному описанию правил ранжирования Авито](https://www.avito.ru/legal/rules/ranking-ads), площадка учитывает поведение продавца как один из факторов выдачи, и это меняет логику работы с каналом радикально. Вопрос не в том, размещать ли объявления. Вопрос в том, как именно — и от ответа зависит, попадёт ли компания в первый экран поиска или останется на десятой странице. ## Что именно изменилось в физике канала? В декабре 2024 года Авито обновил алгоритм ранжирования: время размещения объявления перестало быть основным фактором выдачи, ему на смену пришёл многоуровневый ML-механизм, оценивающий релевантность, поведение покупателей и активность продавца. Подробный разбор обновлённой логики [vc.ru приводит в материале 2026 года](https://vc.ru/marketing/2871111-algoritm-avito-kak-privlech-klientov-i-izbezhat-sliv-budjeta): алгоритм работает в четыре этапа — первичный отбор по текстовому соответствию, персонализация под пользователя, оценка поведенческих факторов и учёт активности продавца. На последнем этапе в формулу попадают скорость ответа в чате, рейтинг аккаунта и свежесть объявления. [Технический блог Авито](https://avito.tech/content/je6de84u31-kak-rabotaet-poiskovoe-ranzhirovanie-dly) описывает поисковое ранжирование как комбинацию текстовых сигналов, пользовательского поведения и качественных характеристик карточки. Скорость ответа в этой комбинации — не отдельный «бонус», а часть сигнала качества продавца, который алгоритм считает по совокупности диалогов и завершённых сделок. Это означает важное следствие: продавец, который отвечает медленно, теряет позицию не из-за плохого предложения, а из-за поведенческого профиля. Восстановить позицию после деградации требует недель активной работы — алгоритм усредняет сигналы на длинном окне. Похожая логика встроена в крупные классифайды по всему миру, но в российском контексте у неё есть специфика: значительная доля B2B-покупок мелкого и среднего масштаба фактически маршрутизируется через мессенджер Авито, а не через сайты продавцов или email. Это превращает интерфейс площадки в основной фронт-офис компании. И именно здесь рекламная рамка работы с каналом ломается. ## Почему «рекламная доска» — это уже не рабочая модель? Большинство компаний в традиционных B2B-вертикалях до сих пор работают с Авито в логике «разместили — ждём звонков». В этой модели у канала три ключевых параметра: количество размещений, цена платного продвижения и качество фото. Всё остальное — операционная рутина за пределами «маркетинга». Эта рамка игнорирует три структурных сдвига. **Первое: объём.** Авито остаётся крупнейшим классифайдом России с десятками миллионов активных объявлений и десятками миллионов уникальных посетителей в сутки. В B2B-вертикалях с короткими сезонами спроса — строительный цикл, осенняя подготовка, предновогодние поставки — всплеск обращений в пиковый день может в 4–8 раз превышать среднюю дневную норму. Ручная обработка физически не масштабируется до этого уровня без расширения штата, который потом простаивает в межсезонье. **Второе: алгоритм.** Поведение продавца зашито в ранжирование. Это означает, что компания с хорошим предложением, но медленным ответом, систематически теряет позицию — не разово, а по нарастающей. Механизм работает как отрицательная обратная связь: медленный ответ → ниже позиция → меньше обращений → меньше практики у менеджера → ещё медленнее ответ. [Vc.ru формулирует прямо](https://vc.ru/marketing/2871111-algoritm-avito-kak-privlech-klientov-i-izbezhat-sliv-budjeta): «Алгоритм фиксирует, как быстро продавец отвечает на сообщения. Ответ в течение нескольких минут — хорошо. Ответ через час — плохо». **Третье: структура решения.** Покупатель на Авито редко общается только с одним продавцом. Он ведёт несколько параллельных диалогов в мессенджере площадки, сравнивает условия и выбирает того, кто первым дал содержательный ответ — с ценой, сроком, условиями и следующим шагом. [Авито в собственном блоге для B2B-продавцов](https://www.avito.ru/blog/kak-rabotat-na-avito-v-segmente-b2b) приводит реальный кейс компании, которая получает 2 000 лидов в месяц, 13 млн ₽ оборота и 1 млн ₽ чистой прибыли от размещения через площадку — и описывает скорость и качество первого ответа как ключевую составляющую конверсии. По прикидкам [Cossa.ru](https://www.cossa.ru/instahero/345510/), в ряде ниш покупатель ведёт от 3 до 5–7 параллельных диалогов одновременно — это видно в обзоре по сценариям работы ботов на повторяющиеся вопросы. Опоздание на 30–40 минут в насыщенной нише часто означает, что конкурент уже сформировал коммерческое предложение, и покупатель сравнивает остальных с ним. Рекламная рамка не предусматривает ни одного из этих трёх факторов. Операционная — учитывает все три. ## Какие слои нужно автоматизировать Компании, которые осознали Авито как операционный слой, перестают работать с ним как с одноразовой воронкой и собирают замкнутый контур из четырёх ступеней. ### Квалификация в первые минуты Первый ответ на входящее обращение — не «здравствуйте, что вас интересует», а момент квалификации. Цель первого сообщения в следующие 5 минут — уточнить 4 параметра запроса (объём, сроки, регион, бюджет), отсечь нецелевые обращения и передать квалифицированный контакт на следующий шаг. Алгоритм фиксирует задержку, а параллельные диалоги делают цену опоздания асимметрично высокой. Стандартное решение — бот-квалификатор, который задаёт сценарный набор вопросов и заполняет карточку лида. [Cossa.ru в обзоре конструкторов чат-ботов для Авито 2026 года](https://www.cossa.ru/instahero/345510/) перечисляет порядка 15 решений; среди них [AvBot](https://avbot.ru/landing/) описывает свою модель как «диалоги из Авито в Telegram- или Max-чат команды плюс ИИ-ответы». Ограничение шаблонных ботов известно: они ломаются на нестандартных вопросах. Если покупатель спрашивает то, чего нет в сценарии, бот либо отвечает не в тему, либо передаёт менеджеру без контекста — и преимущество скорости съедается потерей качества. Зрелая реализация — языковая модель, ведущая квалификационный диалог в свободной форме, понимающая контекст и формирующая структурированную карточку. Это дороже, но устойчиво работает на вариативных нишах. Подробно про закономерность отклика и её связь с ранжированием — в нашем разборе [«Скорость ответа — не сервис, а фактор ранжирования»](/2026/05/speed-of-response-b2b-ranking-russia-2026.html). ### Память диалогов вне платформы Операционный слой подразумевает, что история диалогов с покупателем не живёт только в интерфейсе Авито. Она должна быть доступна менеджеру в его рабочем инструменте — CRM, таблице или специализированном боте. Покупатель, который писал в январе и не купил, может вернуться в апреле. Без памяти диалогов продавец начинает разговор с нуля; с памятью — он видит, что интересовало клиента, какие параметры обсуждались, почему не купил в прошлый раз. В высокочековых сегментах это разница между случайным ответом и осмысленным предложением. Проблема в том, что Авито — закрытая платформа. Прямой экспорт диалогов в произвольную систему без партнёрского соглашения недоступен. Решений два: официальный API Авито для бизнеса (требует одобрения и имеет ограничения) или промежуточные прослойки — уведомления через email/webhook, операторские интеграции, продукты-агрегаторы вроде AvBot и аналогов. [Свежий разбор архитектуры устойчивой системы ответов на vc.ru](https://vc.ru/marketing/2924597-kak-sozdat-ustoychivuyu-sistemu-otvetov-na-avito) описывает типичные узкие места таких связок — от потерь сообщений до рассинхронизации статусов диалогов. ### Follow-up и реактивация В рекламной логике диалог без сделки — потеря. В операционной — лид в базе с историей. Зрелые продавцы выстраивают практику: диалоги, завершившиеся без сделки, через 7–14 дней получают follow-up — сообщение с уточнением статуса потребности. Конверсия реактивированных диалогов ниже, чем у горячих лидов, но при большом объёме это значимый дополнительный поток без дополнительного рекламного бюджета. Важное ограничение: Авито ограничивает автоматические исходящие сообщения и запрещает рассылки по базе. Легальный follow-up — это сообщение человека в конкретный диалог. Рабочая практика — автоматизировать напоминание менеджеру («этот диалог 10 дней без активности — проверь»), а само сообщение пишет человек. Это сохраняет соответствие правилам платформы и при этом возвращает в работу часть «остывших» лидов. ### Аналитика конверсий от показа до сделки Итоговая ступень контура — понимание, какие объявления, в каких категориях и с какими параметрами дают лучшую конверсию в сделку. Это позволяет правильно распределить бюджет на платное продвижение внутри площадки туда, где оно работает. Авито показывает внутреннюю аналитику до первого контакта: просмотры, контакты, конверсия из просмотра в обращение. Но конверсия из обращения в сделку существует только на стороне продавца. Кейс [SV-Digital, разобранный в Sostav.ru](https://www.sostav.ru/publication/kak-s-pomoshchyu-prodvizheniya-na-avito-uvelichit-potok-tselevykh-b2b-lidov-v-6-5-raza-78112.html), показывает, как агентство выводило B2B-кабинет промышленного оборудования из исходного состояния в сентябре 2023 года: 6 036 просмотров за три месяца, 98 контактов, 21 целевой лид, цена контакта 834 ₽, цена целевого лида 3 892 ₽, конверсия из просмотра в контакт 1,62%, конверсия из контакта в целевой лид 21,43%. С сентября 2023-го по февраль 2025-го (17 месяцев) поток целевых лидов вырос в 6,5 раз — но кратное улучшение стало возможно только потому, что агентство замкнуло измерение на сделку, а не на клики. ## Почему стандартные боты не справляются на B2B? Большинство представленных на рынке решений ориентированы на C2C-сегмент: ответить на типовые вопросы о товаре, прислать прайс, согласовать встречу. На B2B-нишах с длинной коммуникацией и нестандартными запросами шаблонные сценарии быстро упираются в потолок. Признаки, при которых шаблонного бота уже недостаточно: - запросы покупателей различаются по структуре (объём, конфигурация, сроки, условия поставки); - продавцу нужно не подтверждать наличие, а формировать индивидуальное предложение; - сделка требует нескольких раундов уточнений до встречи или КП; - покупатель ждёт от ответа понимания своей задачи, а не сухого подтверждения. В таких сценариях шаблон отвечает не в тему — и это видно покупателю. Эффект противоположный ожидаемому: автоответ роняет восприятие компании, и менеджер начинает диалог из минуса. Развитие в этом направлении — применение языковых моделей для понимания свободного текста и ведения квалификации в контексте. Это уже не «шаблон с ветвлением», а агент, который умеет уточнять, переспрашивать и адаптироваться к нестандартному вопросу. По данным [TAdviser](https://www.tadviser.ru/index.php/Статья:Искусственный_интеллект_(рынок_России)), российский рынок ИИ-решений для бизнеса в 2025 году рос двузначными темпами, и значительная часть этого роста — автоматизация коммуникационных каналов. ## Рекламная доска против операционного слоя: в чём разница Одни и те же объявления, но разные режимы работы дают принципиально разный результат. Это видно, если разложить две модели по ключевым параметрам. | Параметр | Рекламная доска | Операционный слой | |---|---|---| | Скорость первого ответа | 1–4 часа, неравномерно | менее 5 минут, круглосуточно | | Квалификация | вручную менеджером, по свободному сценарию | бот + фиксированный набор параметров, структурированная карточка | | Память диалогов | только в интерфейсе Авито, без поиска по истории | CRM/база вне платформы, история 12+ месяцев доступна | | Follow-up по незакрытым лидам | нет или случайный | системно, через 7–14 дней, рукой менеджера | | Аналитика | просмотры/контакты | от показа до сделки и среднего чека | | Поведение алгоритма | позиция деградирует по поведению | позиция растёт, платное продвижение работает | | Пиковая пропускная способность | упирается в число менеджеров | упирается в качество квалификации | Принципиальная разница не в бюджете на продвижение, а в том, какой физический процесс стоит за одним входящим обращением в чате площадки. ## Что это означает для разных типов бизнеса **Для B2B-компании с небольшой командой продаж.** Если Авито — значимый входящий канал, первый шаг минимальный и не требующий разработки: измерить фактическое время первого ответа. Вероятно, оно существенно выше 10 минут. Это прямые потери в ранжировании. Решение начального уровня — настроить уведомление в Telegram о новом сообщении на Авито с текстом диалога. Без ботов, без интеграций — просто мониторинг, который убирает слепое пятно. **Для компании с сезонным спросом.** В пиковые периоды ручная обработка не масштабируется. Нужен автоматический первый ответ и квалификация — пусть даже шаблонная. Цель: не терять позицию в ранжировании в момент, когда спрос максимален. Именно в пике цена ошибки наивысшая, потому что упущенные лиды — это не только сделки этого сезона, но и поведенческий шлейф в алгоритме до следующего пика. Ровно такую механику — заявка квалифицируется за полминуты и уходит человеку готовой карточкой — мы собрали как рабочий пример контура в смежной нише, аренде спецтехники: [рабочий пример контура](https://temadev.org/specteh/?utm_source=geo_referral&utm_medium=ai&utm_campaign=avito-b2b-operational-layer-russia&utm_content=inprose). **Для операций с высоким средним чеком.** Покупатель с крупным бюджетом не принимает решение за один диалог. Он изучает рынок 2–4 недели, сравнивает предложения, возвращается с уточнениями. Компания, которая помнит его параметры и делает своевременный follow-up, имеет преимущество, которое трудно создать иначе. Здесь критичны память диалогов и реактивация — не только скорость первого ответа. ## Что измерять и как выбрать первый рычаг Прежде чем выбирать инструмент, имеет смысл замерить своё текущее положение по четырём метрикам — их достаточно, чтобы понимать, в каком из четырёх слоёв контура у вас основные потери. 1. **Среднее время первого ответа в чате Авито.** Измеряется по выборке из 30–50 последних входящих диалогов. Если медиана выше 15 минут — это первый рычаг, остальные слои можно отложить. 2. **Доля диалогов, завершившихся без сделки и без явного отказа.** Если эта доля больше 50% — рычаг в памяти диалогов и follow-up. 3. **Доля возвратных обращений.** Сколько покупателей из базы возвращается в течение 6–12 месяцев. Если меньше 5–10% — либо вы их теряете на фоллоу-апе, либо работаете в нише разовых покупок, и этот слой можно отключить. 4. **Конверсия из обращения в сделку по категориям объявлений.** Без этой разбивки платное продвижение внутри Авито работает вслепую — и обычно это обнаруживается после первых же пробных бюджетов порядка 30–60 тыс. ₽. Связь между этими метриками и выбором решения прямая. Если провал на (1) — берёте бот-квалификатор или минимум уведомления. Если провал на (2) и (3) — строите CRM-прослойку. Если провал на (4) — ставьте аналитику от показа до сделки. Это не взаимозаменяемые вещи, и порядок вложений обычно именно такой, как в этом списке. ## Чеклист для самодиагностики Пять проверок, которые можно сделать за 1—2 часа без никакой разработки: - выбрать 30 последних входящих диалогов в Авито и считать медиану времени первого ответа; - посчитать долю диалогов, где ответ был позже «15 минут» и позже «1 часа»; - отметить диалоги без финального статуса (не «купил» и не «отказ»), посчитать их долю в общем объёме; - проверить, есть ли хотя бы 1 клиент из базы, который вернулся в течение года и купил повторно — если нет, работы над памятью диалогов больше, чем кажется; - сопоставить конверсию из просмотров в контакты по топ-10 объявлениям — разброс больше в 2–3 раза между лучшим и худшим обычно означает, что бюджет на продвижение распределён неправильно. Эти пять цифр дают понимание, в каком из 4 слоёв контура основная потеря, и позволяют не покупать всё сразу, а выбрать первый рычаг и идти дальше после фактического эффекта. ## FAQ **Можно ли работать на Авито только через объявления и звонки, без автоматизации?** Можно, но это конкурентный недостаток на нишах, где у соседей по выдаче автоматизация уже стоит. Алгоритм ранжирует продавцов по поведенческому профилю, включая скорость ответа в чате; ручная обработка систематически проигрывает по этому фактору. Минимальная альтернатива автоматизации — жёсткий регламент дежурств и уведомления о новых сообщениях с временем реакции до 5 минут. **Сколько стоит автоматизация ответов на Авито?** Шаблонные боты-агрегаторы из обзора [Cossa.ru](https://www.cossa.ru/instahero/345510/) обычно стоят от 5 000 до 30 000 ₽ в месяц на аккаунт — в зависимости от объёма диалогов и интеграций (в обзоре перечислены порядка 15 решений). Решения с языковыми моделями и квалификацией в свободной форме обычно дороже и собираются под конкретный сценарий ниши. Окупаемость считается не от стоимости лицензии, а от прироста позиции в выдаче и числа закрытых диалогов в пик. **Можно ли через бота делать рассылки по базе клиентов на Авито?** Нет. Правила платформы запрещают массовые исходящие сообщения. Легальные follow-up — это сообщения человека в конкретный диалог, инициированные на основании предыдущей переписки. Большинство сертифицированных решений умеют напоминать менеджеру о «зависших» диалогах, но сам ответ остаётся за человеком. **Какая скорость первого ответа считается нормой в B2B-нишах на Авито?** По публикациям самой Авито и отраслевым материалам комфортный порог — 15 минут, конкурентная норма на насыщенных нишах — менее 5 минут. Разрыв между ответом через несколько минут и ответом через час в материале vc.ru 2026 года прямо назван «хорошо против плохо» по влиянию на ранжирование. На сезонных пиках разрыв между этими порогами и реальной обработкой увеличивается; именно там автоматизация даёт максимальный возврат. **Где Авито встроен сильнее всего в B2B-воронку?** В вертикалях с дорогими сделками, короткой коммуникацией и большим числом параллельных запросов: промышленное оборудование, аренда техники, ремонтные подряды, оптовые поставки, стройматериалы, услуги для бизнеса. На этих нишах площадка фактически замещает собственный сайт как точку входа. ## Главное - Авито в B2B перестал быть рекламной доской — он стал операционным слоем входящего потока, и работа с ним требует контурного, а не воронкового мышления. - Алгоритм ранжирования учитывает поведение продавца: скорость ответа в чате влияет на позицию объявления. Медленный продавец системно теряет охват, а не только конверсию. - Операционный контур состоит из четырёх ступеней: квалификация в первые минуты, память диалогов вне платформы, follow-up по незакрытым лидам, аналитика конверсий от показа до сделки. - Компании, строящие этот контур, конкурируют не предложением, а скоростью и памятью — это структурное преимущество, которое сложно воспроизвести в ручном режиме. - Первый практический шаг — измерить реальное время первого ответа. Если оно больше 10 минут, это уже влияет на ранжирование, и автоматизация окупается не «вместо менеджера», а через возврат позиции в выдаче. Связанные разборы: [скорость ответа как фактор ранжирования](/2026/05/speed-of-response-b2b-ranking-russia-2026.html), [вертикальный AI для автодилеров](/2026/05/vertical-ai-auto-dealers-crm-intelligence-layer.html), [AI в строительстве — ROI за 90 дней](/2026/05/vertical-ai-construction-roi-90-days-russia.html). --- ## Note 19: Charge metric: главное решение AI-компании, которое не пишут в прайс-листе **URL:** https://notes.temadev.org/2026/05/seat-pricing-unit-dead-outcome-based-ai.html **Published:** 2026-05-20 **Genre:** concept-piece **Tags:** pricing, ai-native, saas, outcome-based, b2b-ai, capital-efficiency **Words:** 2338 **Summary:** Бывает три способа считать деньги в AI-продукте — потребление, процесс, результат. Выбор между ними определяет не строку в инвойсе, а то, за что компания вообще взялась отвечать. # Charge metric: главное решение AI-компании, которое не пишут в прайс-листе Когда Salesforce выпустил первую версию Agentforce в конце 2024 года, ценообразование было простым: $2 за разговор. Казалось логичным — агент работает, ты платишь за работу. Уже через несколько месяцев компания переделала схему, добавив гибридный вариант с кредитами, подписками и лицензиями на уровне отделов. Причина: разные покупатели внутри одной компании хотели принципиально разных гарантий предсказуемости. Этот эпизод точно описывает, в каком переходном состоянии сейчас находится ценообразование AI-продуктов. Старая логика — «больше людей, больше мест, больше выручки» — строилась на предположении, что ценность ПО масштабируется с числом пользователей. AI-агент это предположение нарушает: один агент может выполнять объём работы, который раньше требовал десятка сотрудников. Если вы взяли за него $X/место в месяц, вы проиграли сами себе. $X/seat/month — это модель ценообразования, при которой клиент платит фиксированную сумму за каждого человека (seat = лицензированного пользователя), получившего доступ к продукту. Она работает, пока добавление каждого нового пользователя приносит вендору пропорциональную выручку без пропорционального роста расходов. AI-агент ломает обе половины этого уравнения: один агент обслуживает работу многих пользователей, а его операционная стоимость растёт не с числом seats, а с объёмом выполненной работы. Этот сдвиг — продолжение более широкой темы [роли важнее места](https://notes.temadev.org/2026/05/role-bolshe-seat-ai-native-org-chart.html): если сама работа перестаёт быть «местом», то и счёт нельзя выставлять за «места». ## Откуда взялась модель «место в месяц» и почему она начинает давать сбои В SaaS 2000-х годов лицензия за место была разумной прокси для ценности. Чем больше людей использует CRM — тем более ценным он становится для компании. Salesforce, HubSpot, Notion — все они стоят ровно столько, сколько число активных пользователей умножить на тариф. Модель работала, потому что программное обеспечение усиливало людей, но не замещало их. Gross margin SaaS при этом держалась на уровне 80–90% — издержки на доставку продукта (хостинг, поддержка) были невысокими, а дополнительное место не требовало дополнительных переменных затрат. В этой конструкции место в месяц было почти идеальной единицей расчёта: предсказуемо для клиента, почти бесплатно для вендора. AI-агенты работают по принципиально другой логике. Sierra, компания по автоматизации клиентского сервиса, заряжает за каждый [разрешённый тикет](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents), а не за число операторов, подключённых к платформе. Intercom Fin стоит [$0.99 за результат](https://www.intercom.com/pricing) — то есть за каждый случай, когда бот закрыл обращение без передачи человеку. Логика очевидна: если ценность в том, что заявка обработана, а не в том, что оператор залогинился, почему единицей расчёта должен быть оператор? Проблема не абстрактная. Компания, которая продаёт AI-агента для обработки входящих лидов, сталкивается с конкретным вопросом: сколько «мест» занимает агент? Один? Эквивалент пяти менеджеров по продажам, которых он заменяет? Ответа у per-seat логики нет. Более того, клиент, который покупает AI-агента по per-seat модели, неизбежно начнёт давить на цену, считая «справедливой» ценой долю стоимости замещаемых сотрудников. Это ставит вендора в позицию, где потолок выручки определён числом людей, которых агент заменяет, — а это потолок из мира кадрового аутсорсинга, а не SaaS. ## Три слоя ценообразования, которые победили Bessemer Venture Partners в своём [AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook), опубликованном в начале 2026 года, выделяют три принципиально разных способа посчитать ценность AI-продукта: | Модель | Что считается | Пример | Маржинальность | |---|---|---|---| | **Потребление** (токены, API-вызовы) | Вычислительные ресурсы | Cognition Devin — $2.25 за единицу вычислений (acu) | 60–70% | | **Процессы** (задачи, операции) | Завершённые единицы работы | Salesforce Agentforce — кредиты | 50–65% | | **Результат** (исход, решение) | Бизнес-итог | Sierra — $X/resolved ticket | 40–60% | Как подчёркивает Bessemer: по мере движения от потребления к результату вы берёте на себя больше стоимостного риска в обмен на более точное выравнивание ценности. Платёж за результат идеально объясняет клиенту, почему он платит, — но требует от вендора понимать свои операционные расходы с точностью до единицы. По данным аналитиков [Hire Fraction](https://www.hirefraction.com/blog/ai-is-killing-saas-margins-outcome-based-pricing-is-how-you-get-them-back), 92% AI-компаний уже применяют смешанные схемы — базовая подписка плюс потребление или результат. Чистый per-seat остаётся только там, где агент действительно усиливает существующего сотрудника, а не замещает его. Таких ситуаций становится меньше. ## Как это выглядит у конкретных компаний ### Harvey: дорогие места с принудительным расширением Harvey — AI-ассистент для юридических фирм — продаёт по $1 200–2 500 за место в месяц. По меркам SaaS это дорого. По меркам юридического рынка — не очень: один ассоциат в BigLaw обходится фирме в $200–400k в год. Согласно данным [Sacra](https://sacra.com/research/harvey-at-195m-arr/), Harvey вырос от нуля до $195 млн ARR за 36 месяцев при 290% роста год к году. Ключ не в том, что место стоит дорого, а в том, как оно расширяется: компания начинает с одной практики (например, M&A), затем добавляет Workflows, затем переходит на другие подразделения. Минимальный порог входа — 20 мест и 12-месячный контракт, то есть минимальный годовой контракт от $288k. Здесь per-seat работает, потому что место — это место юриста, который всё равно нужен. Агент усиливает, а не заменяет. Но выручка растёт не через новые места, а через expansion внутри клиента. ### Sierra: чистый результат Компания Bret Taylor и Clay Bavor пошла по другому пути. Sierra продаёт агентов для клиентского сервиса, и её ценообразование — это платёж за результат без фиксированной подписки. Минимальный годовой контракт около $150k, но структура — исключительно за разрешённые обращения. В [блоге компании](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents) Sierra объясняет логику прямо: «Мы берём деньги только тогда, когда клиент получает реальную ценность». Это жёсткое утверждение, потому что оно привязывает выручку вендора к измеримому качеству работы агента. Если агент начинает хуже разрешать тикеты — падает выручка. ### Glean: ладдер от мест к агентной нагрузке Glean, платформа корпоративного поиска с AI, использует гибридную модель: базовая подписка $45–50/место в месяц, дополнительный AI-модуль +$15/место, а поверх этого — consumption-based SKU для агентных рабочих нагрузок. По данным [Futurum](https://futurumgroup.com/insights/glean-doubles-arr-to-200m-can-its-knowledge-graph-beat-copilot/), компания удвоила ARR с $100M до $200M за девять месяцев. Это иллюстрация «безопасного» перехода: не нужно отказываться от per-seat полностью. Достаточно добавить новые SKU поверх существующей базы, которые монетизируют агентное поведение отдельно. ## Что меняется в логике сделки За сменой единицы расчёта стоит более глубокий сдвиг. Когда клиент платит за место, договор звучит так: «вы купили доступ к инструменту — используйте его хорошо». Когда клиент платит за результат, договор другой: «мы берём деньги только тогда, когда работа сделана». Это перекладывает ответственность. Вендор на per-seat не несёт ответственности за то, что менеджер открыл систему пять раз за месяц. Вендор на per-outcome несёт ответственность за каждый нерешённый тикет — в прямом финансовом смысле. Foundation Capital в [своём эссе о service-as-software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) формулировали этот принцип как SaaS²: AI-компании могут захватить в 10 раз больше ценности, чем традиционный SaaS, именно потому что они выполняют работу, а не просто дают инструмент для её выполнения. Но это работает только если ценообразование отражает работу, а не доступ к инструменту. Обратная сторона этого договора — вендор начинает нести ответственность за качество работы. При per-seat клиент несёт ответственность за то, как использует продукт. При per-outcome ответственность частично переходит к поставщику: если агент работает плохо, выручка вендора снижается автоматически. Это создаёт принципиально другую мотивацию к качеству продукта. ## Как это читается для трёх аудиторий **Для основателя AI-продукта.** Вопрос «за что мы берём деньги» — это не строка в прайс-листе, а стратегическое заявление о том, где вы видите ценность. Bessemer называют выбор «charge metric» самым важным решением AI-компании. Если ваш агент замещает сотрудников — per-seat будет работать против вас: клиент не купит пять мест для одного агента. Найдите результат, который клиент уже измеряет, и зарядите за него. **Для операционного директора компании, покупающей AI.** Чистый per-seat с AI-поставщиком — это красный флаг. Либо инструмент просто усиливает существующих сотрудников (тогда per-seat оправдан), либо он что-то делает сам — и тогда вы должны понимать, за какую именно работу платите. Требуйте прозрачной метрики результата в контракте. **Для product manager'а.** Если ваш продукт переходит от ассистентского режима (AI помогает человеку) к автономному (AI делает сам), это требует ревизии юнит-экономики. Gross margin у outcome-based AI составляет 40–60% против 80–90% у классического SaaS — значит, стоимость операционных расходов должна быть под контролем уже сейчас. ## Сигналы, на которые стоит смотреть Рынок ещё не устоялся. Salesforce переделала Agentforce дважды за год. Cognition Devin упал в цене на порядок между первым и вторым запуском. Это не признаки слабости — это признаки того, что правильная единица расчёта для разных типов агентных продуктов только нащупывается. Две вещи, которые стоит отслеживать: первая — как крупные enterprise-покупатели начнут требовать стандартизации метрик результата (сейчас «resolved ticket» у каждого поставщика значит что-то своё). Вторая — появятся ли revenue-share схемы в вертикальных сегментах, где AI-агент напрямую участвует в генерации выручки клиента. Harvey уже работает с такими договорённостями в юридическом секторе. ## Что это значит для российского контекста В РФ дискуссия про outcome-based pricing пока редкость — большинство B2B AI-проектов продаются либо как setup-проект с фиксированной сметой, либо как ежемесячный retainer. Это объяснимо: outcome-based требует трёх вещей, которых на рынке пока мало: согласованных метрик результата, доверия между поставщиком и клиентом и инфраструктуры для подсчёта тех самых результатов. Но направление движения то же. Заказчик, который заплатил 800 тысяч рублей за «внедрение AI-ассистента менеджеров», через три месяца спрашивает не «сколько раз бот залогинился», а «сколько лидов он квалифицировал и сколько встреч сгенерировал». То есть в голове у клиента метрика уже outcome-based, даже если в договоре стоит фиксированная сумма. Это создаёт окно для тех, кто готов первыми сшить контракт под результат. Не обязательно идти в чистый per-outcome — для большинства русских клиентов это слишком радикально на старте. Гибрид «base retainer + bonus за достигнутый KPI» куда продаваемее, потому что сохраняет предсказуемость для финансиста и при этом привязывает выручку поставщика к качеству работы. Чтобы такой контракт держался, под одним измеримым процессом нужен контур, который этот процесс реально ведёт и считает свою единицу результата, — такие контуры мы и собираем как рабочие системы, а не пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=seat-pricing-unit-dead-outcome-based-ai&utm_content=inprose). Здесь же возникает структурный вопрос: setup-фаза, в которой строится сам контур, уже плохо масштабируется и постепенно [перестаёт быть точкой захвата маржи](https://notes.temadev.org/2026/05/ai-studio-commoditization-cliff-2027.html). Если ценность переместится в operational layer — туда же должна переместиться и единица расчёта. Retainer привязанный к доступу — это всё ещё SaaS-логика; retainer, привязанный к delivered work, — уже outcome-based. ## Почему рынок ещё не перешёл на outcome-based: чего не хватает? Два технических блока удерживают рынок на per-seat дольше, чем стоило бы. Первое — атрибуция результата. Когда тикет «разрешён» — это решил агент, или человек, дочистивший его за агентом? Когда лид «квалифицирован» — это работа бота или менеджера, который через час перезвонил? Без чёткой attribution-системы любой outcome-based контракт превращается в спор о том, кто что сделал. Sierra тратит непропорционально много инженерных усилий именно на это: их платформа умеет показывать клиенту, что конкретно сделал агент, а что — оператор. Второе — наблюдаемость экономики на стороне вендора. Per-seat предсказуем по определению: подписали 200 мест — знаешь выручку на год вперёд. Outcome-based требует, чтобы вендор в реальном времени видел свою себестоимость на единицу результата: сколько inference-вызовов, сколько эскалаций к человеку, сколько повторных обращений. Большинство AI-стартапов эту инфраструктуру не строят на старте — и попадают в ловушку, когда выручка есть, а маржинальность отрицательная. Эти два блока — не вспомогательные. Они и есть стек, который должен быть готов, прежде чем компания может перейти от per-seat к outcome-based. Без них переход даёт обратный эффект: выручка падает, риски растут. ## Главное - Модель «место в месяц» строилась на том, что ценность ПО масштабируется с числом пользователей. AI-агенты это допущение нарушают. - Bessemer выделяют три уровня ценообразования: потребление → процесс → результат. По мере роста «выравнивания ценности» растёт и стоимостной риск для вендора. - 92% AI-компаний уже используют гибридные схемы; чистый per-seat остаётся только там, где агент усиливает, а не замещает. - Harvey ($195M ARR, +290% в год) зарядил дорого за место, но растёт через expansion внутри клиента. Sierra и Intercom зарядили за результат и убрали место из уравнения полностью. - Смена единицы расчёта — это смена договора с клиентом: от «доступа к инструменту» к «оплате за работу». ## FAQ **Чем «ценообразование за результат» отличается от «ценообразования за использование»?** Использование измеряет то, что система потратила (токены, вызовы API, вычислительные ресурсы). Результат измеряет то, что клиент получил (тикет закрыт, лид квалифицирован, документ подписан). Использование хорошо предсказуемо для вендора, но плохо объясняет ценность клиенту. Результат лучше выравнивает интересы, но требует чёткого определения того, что именно считается результатом. **Когда per-seat всё ещё оправдан для AI-продукта?** Когда агент действительно усиливает существующего сотрудника, а не выполняет работу вместо него. Harvey — корректный пример: юрист всё равно нужен, агент делает его быстрее. Если же продукт полностью заменяет функцию — per-seat работает против вендора: клиент видит агента как замену N мест и оценивает «справедливую» цену соответственно. **Как клиенту защититься от непредсказуемых счетов при outcome-based ценообразовании?** Ключевые параметры для переговоров: чёткое определение «результата» (кто считает и как), минимальный базовый платёж (предсказуемый floor), максимальный cap на расходы за период. Intercom Fin стоит $0.99/результат, но есть минимум $49.50/мес — это и есть floor + per-unit структура. **Насколько снижается маржинальность при переходе на outcome-based?** По данным Bessemer, классический SaaS работает на gross margin 80–90%. AI-продукты с outcome-based ценообразованием — 40–60%. Разница объясняется тем, что операционные расходы (inference, мониторинг, fallback на человека) теперь входят в стоимость «результата». Это не плохо — это другая бизнес-модель с другими мультипликаторами. **Что означает «charge metric — это стратегическое заявление»?** Bessemer формулируют так: выбор метрики расчёта определяет не только строку в инвойсе, но и то, какую проблему вы публично обязуетесь решать. Если вы берёте за место — вы говорите «мы продаём доступ». Если за результат — «мы продаём работу». Последнее сложнее продать на входе, но создаёт более прочные долгосрочные отношения с клиентом. **Можно ли начать с per-seat и потом перейти на outcome-based?** Можно, и так делают почти все, кто проходит этот переход осознанно. Glean — каноничный пример: per-seat остаётся базой, поверх неё постепенно появляются consumption-SKU за агентные нагрузки. Через 12–18 месяцев outcome-часть может вырасти до половины контракта. Резкий переход «было per-seat, стало per-outcome» обычно ломает существующие сделки — лучше двигаться слоями. --- ## Note 20: Вертикальный AI для автодилеров: что меняется, когда CRM перестаёт просто хранить **URL:** https://notes.temadev.org/2026/05/vertical-ai-auto-dealers-crm-intelligence-layer.html **Published:** 2026-05-19 **Genre:** market-deep-dive **Tags:** vertical-ai, autodealers, crm, авито, российский-рынок, b2b **Words:** 2041 **Summary:** AI-чатбот на Авито ускоряет первый ответ, но не решает главное: данные о каждом авто, покупателе и сделке живут в трёх мессенджерах и голове менеджера. # Вертикальный AI для автодилеров: что меняется, когда CRM перестаёт просто хранить По данным [Calltouch](https://calltouch.ru), стоимость лида в автобизнесе выросла до 3 496 ₽ (+24% за полгода), а 60% клиентов уходят к конкуренту при первом же долгом ответе. Авито стало каналом №1 в регионах — 65% обращений приходит именно оттуда. В этот момент рынок инструментов для дилеров предлагает одно решение: чатбот, который отвечает быстрее. Это — правильный ответ на неправильный вопрос. Медленный первый ответ — симптом. Болезнь глубже: операционная реальность мелкого автодилера фрагментирована принципиально. Каждый лид живёт в отдельном мессенджере, P&L по конкретному авто не сводится нигде, история переговоров с покупателем — в памяти менеджера, который может уволиться завтра. AI-чатбот на входе закрывает дыру в скорости, но не трогает архитектуру информации внутри. ## Почему CRM не решает эту задачу в текущем виде CRM с AI — это стандартная CRM (Битрикс24, AmoCRM, Salesforce), в которую встроили автоответы и напоминания поверх существующей модели данных. Это не intelligence layer: первое — реактивная система учёта с AI-надстройкой, второе — проактивный агент с собственной моделью реальности, который сам решает, что и когда делать. CRM как класс продуктов исторически спроектирована для фиксации фактов: кто позвонил, что сказал, когда перезвонить. Разумная архитектура для крупного B2B с длинным циклом сделки — но плохо подходящая для автодилера, который ведёт 15–30 активных диалогов одновременно, где каждый объект продажи (конкретный автомобиль) имеет свою историю, а покупатель за одну неделю может трижды поменять параметры поиска. [Salesforce State of Sales](https://www.salesforce.com/news/research/sales-statistics/) отмечает: «85% продавцов признают, что не ведут CRM вовремя, и большая часть данных о взаимодействиях с клиентами теряется в личных переписках и памяти менеджеров». Данные живут в головах и мессенджерах. Это справедливо для любого B2B, но в авторознице проблема острее: стандартные CRM (Битрикс24, AmoCRM) не понимают, что за объект продаётся — авто остаётся просто «лидом» с набором полей, а не сущностью с историей: пробег, сколько раз снижали цену, кто уже приходил на осмотр, почему не купил. Авито — ключевой канал: [67% автовладельцев](https://autostat.ru/infographics/57826/) покупают и продают через него, там же 170 000+ дилерских объявлений [на платформе](https://avito.ru). Это означает, что первичный контакт почти всегда происходит в Авито-мессенджере, потом переезжает в WhatsApp или Telegram, а в CRM попадает в лучшем случае к концу недели. Горизонтальная платформа [AvBot](https://avbot.ru) делает автоответы в Авито с RAG-памятью по диалогам и follow-up — инструмент рабочий, но он решает задачу скорости, не задачу интеграции данных. ## Что такое intelligence layer и чем он отличается от AI-чатбота Вертикальный intelligence layer (или «операционный AI-слой», как его чаще называют в русском контексте) — это не отдельный продукт поверх существующей инфраструктуры. Это архитектурный принцип: агент, который держит единую модель реальности для бизнеса и использует её при принятии каждого операционного решения. Для автодилера это означает несколько конкретных вещей. **Карточка авто как живая сущность.** Каждый автомобиль имеет историю: когда поступил, какие объявления запускались, сколько диалогов было, на каком этапе сорвались, кто из покупателей подходил близко к покупке. AI-слой, который держит эту историю, может инферировать: «Этот покупатель три недели назад смотрел аналогичный авто — предложить ему актуальный вариант автоматически». **Квалификация без потери контекста.** Типичный сценарий: покупатель пишет в Авито, переходит в Telegram, потом звонит. Каждый раз менеджер начинает заново. Intelligence layer, интегрированный с мессенджерами и CRM, помнит весь контекст — и при звонке менеджер видит: «Интересуется Kia Rio, бюджет до 900К, торговался по поводу комплектации». **Follow-up как система, а не как намерение.** [Исследование vc.ru](https://vc.ru/trade/748391-crm-dlya-avtodilerov-zachem-avtosalonu-crm) фиксирует, что дилеры теряют от 30 до 50% потенциальных покупок на этапе follow-up — не потому что покупатель отказался, а потому что никто не перезвонил в нужный момент. AI-слой, понимающий, где находится каждый лид в воронке, может инициировать правильное касание в правильное время без инструкции менеджеру. ## А где же на этом рынке вертикальный AI? Рынок инструментов для автодилеров РФ расслоился на три категории — но ни одна не закрывает полный контур. | Категория | Примеры | Цена/мес | Закрывают | Не закрывают | |---|---|---|---|---| | Авито-боты | AvBot, avChat, AvitoFoer | 799–2 499 ₽ | Скорость первого ответа в Авито | CRM, история объектов, телефония | | Горизонтальные конструкторы | Nextbot, LeaderChat, Salebot | 3 000–6 000 ₽ | Сценарии диалогов | Авто-специфику, аналитику по объектам | | Нишевые под ключ | KhurmaAI, Reconnect, AutoPrompt | 15 000–50 000 ₽ | CRM + базовая аналитика | Полную интеграцию Авито + дилерскую dealer-management-систему | | Полноценная дилерская система | 1С:Альфа-Авто (Rarus) | от 200К ₽ внедрение | Учёт, склад, документооборот | Стоимость, AI-слой, малые дилеры | Кратко по категориям. **Авито-боты** решают одну задачу — скорость в Авито-диалогах — и не касаются CRM, истории объектов и телефонии. **Горизонтальные конструкторы** дают гибкость в сценариях, но шаблон «автодилер» не понимает специфику б/у рынка и разницы между дилером с 5 и с 40 авто. **Нишевые «под ключ»** ближе к intelligence layer, но обычно либо без Авито-интеграции, либо без аналитики по объектам, либо требуют замены существующего стека. **[1С:Альфа-Авто](https://rarus.ru)** — зрелая dealer-management-система для 2 700+ дилеров, но проектировалась для крупных автосалонов: для дилера с 15 авто избыточна и дорога. **Ключевой пробел**, который никто не закрыл: единый контур «Авито-лидбот + квалификация + история объекта + CRM + follow-up + аналитика». Либо берёшь три разных продукта и соединяешь вручную, либо платишь за Альфа-Авто и получаешь систему, которая сложнее, чем нужно. ## Где формируется устойчивое преимущество На [SaaStr](https://saastr.com) Jason Lemkin фиксирует закономерность: AI-native CRM-стартапы, достигшие $100M ARR быстрее всего (Sierra — за 21 месяц), делали это не через вытеснение Salesforce, а через занятие той ниши, где стандартная CRM структурно не работает. Они строили «полную память» без ручного ввода — агент сам записывает, структурирует и инферирует. Похожий разрыв между «фиксацией фактов» и «пониманием контекста» мы [разбирали в заметке про representation layer](https://notes.temadev.org/2026/04/representation-layer-vertical-schema.html) — там же лежит общий каркас: модель меняется за выходные, а схема данных живёт годами. Для мелких автодилеров РФ та же логика: барьер не в стоимости CRM (AmoCRM стоит 2–5К ₽/мес), а в том, что ручное ведение CRM требует дисциплины, которой у микродилера нет и не будет. Самозаполняющийся intelligence layer, который пишет данные сам (из диалогов, из Авито-активности, из звонков), решает именно эту задачу. Из этого вырастает переключающая стоимость. Когда система 6 месяцев держит историю каждого лида и каждого авто — её не заменят на другой продукт просто потому, что там дешевле. Данные и паттерны накоплены в конкретном контексте конкретного дилера. Это и есть то, что называют «data moat» в b2b SaaS — только в данном случае он строится не через сложность интеграции, а через накопление операционной памяти. ## Конкретные тесты для трёх аудиторий **Владельцы и операционные директора автосалонов (5–50 авто).** Простой тест: возьмите любой лид, который не купил за последние 3 месяца. Можете ли вы за 2 минуты восстановить полную картину — что смотрел, почему не купил, что мешало? Если нет — значит операционная память теряется, и следующий менеджер начнёт этот разговор с нуля. AI-слой, который это решает, стоит оценивать именно в единицах «лидов, которые можно было дожать, но не дожали». **B2B AI founders, выбирающие следующую вертикаль.** Проверочный вопрос: есть ли в вертикали объект с историей (авто, квартира, проект), который живёт дольше одного диалога? Есть ли несколько каналов коммуникации, между которыми теряется контекст? Если да — это кандидат на вертикальный intelligence layer. Авторозница отвечает обоим критериям и при этом имеет высокую маржинальность сделки (50–200К ₽ на б/у авто), что делает экономику автоматизации разумной даже при high-touch внедрении. **Product managers, оценивающие эволюцию CRM.** Горизонтальный SaaS постепенно добавит авто-специфичные шаблоны. Вопрос не «появятся ли?», а «когда и насколько глубоко». Ближайшие 12–18 месяцев — окно, в котором нишевый игрок может накопить данные и операционную экспертизу, которые горизонтальный продукт не воспроизведёт шаблоном. После — придётся конкурировать на цене. Аналитики [luckru.ru](https://luckru.ru) отмечают: в РФ лишь около 14% компаний внедрили CRM, а из купивших AmoCRM активно пользуются через месяц только 27%. Они формулируют это прямо: «порог вовлечённости пользователей в CRM в малом бизнесе оказался ниже ожиданий». Это и есть структурная дыра, в которую входит intelligence layer: не заставить менеджера вести CRM, а записывать всё самому. ## Сигналы для наблюдения Calltouch, комментируя стоимость лида в автосегменте, пишет: «60%+ клиентов уходят к конкуренту при долгом ответе, и это не проблема рекламы, это проблема обработки обращений». Речь не только про скорость в первом сообщении — про связность всей последующей коммуникации. Это второй уровень рынка, к которому горизонтальные платформы пока не подошли. Авито планомерно расширяет API-доступ и инструменты для профессиональных дилеров. Когда Авито сам начнёт предлагать built-in AI-ответы как часть платного размещения — горизонтальные чатботы потеряют основной аргумент «скорость ответа». Вертикальные intelligence layers к тому моменту должны быть уже укоренены в операционной памяти клиентов, чтобы не конкурировать с Авито на его же поле. Второй сигнал — консолидация горизонтальных платформ. Если Bitrix24 или AmoCRM начнут покупать нишевых игроков с авто-экспертизой, это будет валидацией ниши и одновременно сигналом к ускорению. Не потому что станет страшнее — а потому что платформенный игрок всегда оставляет незакрытыми хвосты по настройке и операционному сопровождению, именно там и живёт ниша. ## Главное - 70–80% мелких автодилеров РФ работают без CRM — но проблема не в отсутствии учёта, а в том, что CRM хранит факты, а не понимает операционную реальность. - Горизонтальный AI-чатбот ускоряет первый ответ, но не решает фрагментацию данных между Авито, мессенджерами и телефоном. - Вертикальный intelligence layer строит единую память по объектам (авто), контактам и сделкам — это и есть источник устойчивого преимущества, а не функциональность. - Переключающая стоимость возникает не от сложности интеграции, а от накопленной операционной истории: 6 месяцев данных о лидах и авто — это актив, который нельзя перенести в другой продукт. - Окно для занятия ниши до commoditization горизонтальных платформ — 12–18 месяцев. ## FAQ **Чем вертикальный AI-слой отличается от обычной CRM с чатботом?** CRM с чатботом добавляет скорость ответа поверх существующей инфраструктуры. Вертикальный intelligence layer строит единую модель данных с нуля, интегрируя все каналы (Авито, мессенджеры, телефония) и держа историю по каждому объекту продажи, а не только по контакту. Разница практическая: во втором случае система сама инициирует follow-up и принимает решения, а не ждёт, пока менеджер откроет CRM. **Почему сейчас, а не через год?** Авито расширяет API-доступ, горизонтальные платформы добавляют авто-шаблоны. Через 12–18 месяцев базовый AI-ответ на Авито станет commoditized функцией. Дифференциация возможна только через накопленную операционную память — а она требует времени присутствия в нише. **Для каких дилеров это имеет смысл?** Экономика работает при марже сделки от 50К ₽ и минимум 10–15 активных диалогах в месяц. Это сегмент 15–50 авто с б/у рынком. Микродилеры (3–5 авто) скорее всего не окупят полноценный intelligence layer — для них оптимален горизонтальный инструмент типа AvBot. --- ## Note 21: Роль важнее места: как AI-native компании переписывают организационную структуру **URL:** https://notes.temadev.org/2026/05/role-bolshe-seat-ai-native-org-chart.html **Published:** 2026-05-18 **Genre:** concept-piece **Tags:** ai-native, org-design, future-of-work, agents **Words:** 2495 **Summary:** Три теста, по которым видно, переходит ли компания к ролевой модели или просто оптимизирует позиции — и почему это важнее любого конкретного AI-инструмента. В феврале 2024 года [Klarna публично заявила](https://www.klarna.com/international/press/klarna-ai-assistant-handles-two-thirds-of-customer-service-chats-in-its-first-month/): её AI-ассистент, построенный на партнёрстве с OpenAI, выполняет работу, эквивалентную 700 сотрудникам поддержки, и компания экономит около 40 миллионов долларов в год. Цифра стала референсной не потому, что впечатляющая, а потому, что показывала структуру решения. В мае 2025 года [Klarna публично откатилась](https://www.forbes.com/sites/quickerbettertech/2025/05/18/business-tech-news-klarna-reverses-on-ai-says-customers-like-talking-to-people/) и начала нанимать людей обратно. CEO Себастьян Семятковский сказал прямо: «По правде говоря, в погоне за издержками мы зашли слишком далеко. Качество от этого пострадало». Параллельно в апреле 2025 года Луис фон Ан, CEO Duolingo, разослал [внутреннее письмо](https://www.linkedin.com/posts/duolingo_below-is-an-all-hands-email-from-our-activity-7322560534824865792-l9vh), ставшее публичным: компания становится AI-first, прекращает контракты с большинством фрилансеров и переписывает процессы под агентов. В письме фон Ан формулирует это так: «Точно так же, как ставка на мобильное в 2012 году сделала всё, чем мы являемся сегодня, ИИ — следующая такая ставка». Salesforce за тот же год сократила около 4000 сотрудников в поддержке и одновременно запустила [Agentforce](https://www.salesforce.com/agentforce/) — платформу для развёртывания агентов внутри корпоративных процессов клиентов. На поверхности это три разные истории: одна — про откат, две — про разгон. По сути это одна и та же история под разными названиями: переписывание организационной структуры. И именно случай Klarna объясняет, в чём отличие настоящего перехода от лозунга. ## Что такое позиция и почему она была нужна Современная оргсхема родилась не из природы работы, а из природы людей. До появления вычислений вся когнитивная работа требовала человека. Бухгалтерия требовала бухгалтера, анализ — аналитика, поддержка клиентов — оператора, юридическая проверка — юриста. Поэтому организация состояла из единиц, которые в HR-софте называются «позиция» (по-английски *seat*): должность, к которой привязаны зарплата, KPI, отчётность, метрики и трудовой договор. Позиция существовала как контейнер для конкретного человека с конкретным контрактом. Эта модель была настолько естественной, что её перестали замечать. Когда компания хотела увеличить пропускную способность поддержки, она нанимала ещё людей — то есть открывала ещё позиции. Когда нужно было ускорить разработку — открывали позиции для инженеров. Бюджет строился вокруг штата, оргсхема — вокруг должностей, карьерные треки — вокруг повышения внутри иерархии. HR-системы, ATS, payroll, performance review, грейдовые сетки — вся корпоративная инфраструктура построена на предположении, что единица производительности — это человек, занимающий место. Эта предпосылка ломается, когда работу начинают выполнять системы. Не инструменты, которые помогают человеку — этим компании пользовались десятилетиями, — а системы, которые выполняют работу целиком, до результата, без человеческой петли внутри процесса. Joanne Chen из Foundation Capital в [эссе Service-as-Software](https://www.forbes.com/sites/joannechen/2024/04/29/ai-leads-a-service-as-software-paradigm-shift/) формулирует это коротко: услуги, которые раньше предоставлялись людьми, становятся программным продуктом. Не интерфейсом для человека, а заменой человека. И тогда позиция перестаёт быть единицей измерения. Единицей становится роль — конструкция из ответственности, интерфейсов и метрик, существующая независимо от того, кто её исполняет. ## Как выглядит ролевая модель на практике? ![Слева пирамида из деревянных стульев, справа сеть из карточек-контрактов с одной зелёной — два способа нарисовать одну компанию](/assets/role-bolshe-seat-ai-native-org-chart-inline-1.jpg) Klarna — самый чистый пример того, как роль отделяется от исполнителя. До 2023 года поддержка была организована классически: сотни позиций, разбитых на команды, с менеджерами, тренерами, шифт-планировщиками, отделом контроля качества. После перехода вся эта структура схлопнулась в одну роль — «обработка обращения первой линии». Роль определяется через три вещи. Первое: входной интерфейс — чат, e-mail, push-уведомление. Второе: ответственность — закрыть обращение, переключить на человека, обновить статус. Третье: метрики — время разрешения, точность, удовлетворённость. Внутри этой роли в каждый момент времени работают и люди, и агенты. Соотношение между ними — параметр, а не структурное свойство компании. В 2024 году роль на 90% исполнял агент, на 10% — человек. В 2025 году Klarna публично призналась, что перегнула, и сдвинула соотношение обратно в сторону людей — но сама роль не изменилась. Оргсхема не перерисовывается. Меняется только конфигурация исполнителей. Это и есть главный признак ролевой модели: смесь агент/человек настраивается, а не определяет компанию. Salesforce делает то же самое, но на уровне продукта, а не только внутренней операции. Agentforce — это не AI-инструмент для собственных сотрудников Salesforce. Это платформа, на которой клиенты Salesforce разворачивают свои собственные роли: «специалист по обработке претензий», «координатор онбординга», «менеджер по возврату товара». Каждая такая роль — это набор инструкций, доступов к данным, разрешённых действий и метрик. Кто её исполняет — отдельный вопрос. По умолчанию роль исполняет агент. При эскалации подключается человек. При особо сложных случаях — эксперт. Salesforce продаёт компаниям возможность переписать собственную оргсхему, не нанимая. Duolingo демонстрирует третий вариант — внутренняя продуктовая команда. Курсы языков создавались десятилетиями коллективами подрядчиков: лингвисты, методисты, носители языка, иллюстраторы, аудиоинженеры. После перехода на AI-first эти подрядчики перестали быть нужны как позиции. Роль «создать новый юнит курса французского» осталась — но теперь она исполняется конвейером из нескольких агентов под контролем небольшой внутренней команды. Подрядчик как позиция исчез. Роль как функция — нет. Microsoft в [Work Trend Index 2025](https://www.microsoft.com/en-us/worklab/work-trend-index/2025-work-trend-index) ввёл для этого термин *Frontier Firm* — компания, в которой человек и агент работают как взаимозаменяемые исполнители одной роли, а руководитель оперирует не штатом, а пропускной способностью функций. Это и есть ролевая модель в её корпоративной формулировке. В том же отчёте Microsoft фиксирует характерный сдвиг: руководители внутри Frontier Firms всё чаще говорят не «мне нужен ещё один аналитик», а «мне нужно увеличить аналитическую функцию на 40%». Это не оборот речи, а отражение того, что внутри компании появилась возможность купить пропускную способность отдельно от человека. Этой возможности не было ещё пять лет назад. Важно отличать ролевую архитектуру от автоматизации. Автоматизация работала с конкретными процессами внутри позиции: вместо того чтобы оператор копировал данные из одной системы в другую, скрипт делал это сам, но оператор оставался необходим для остального. Ролевая архитектура работает на уровень выше: роль целиком исполняется не-человеком, и человек подключается только там, где роль явно эскалирует. Это структурное различие. Автоматизация делает позицию дешевле, ролевая архитектура делает её необязательной. ### Позиция против роли: краткое сравнение | Параметр | Seat-based (позиционная) модель | Role-based (ролевая) модель | |---|---|---| | Единица планирования | Штатная единица (FTE) | Пропускная способность роли | | Описание работы | Должностная инструкция | Контракт: вход → выход → SLA → эскалация | | Исполнитель | Один человек, постоянно | Человек или агент, переменное соотношение | | Что покупает руководитель | +1 человек | +40% функции | | Реакция на отключение агентов | Не зависит | Деградация пропускной способности, не остановка | | Базовая статья затрат | Payroll, предсказуемый | Payroll + переменное потребление моделей | | Профиль доходов | Подписка на seat | Оплата за единицу работы | | Скорость онбординга | Недели–месяцы | Часы–дни | ## Три признака AI-native перехода Различить компанию, которая действительно переходит к ролевой модели, и компанию, которая просто добавила ChatGPT в существующие позиции, можно по трём тестам. Их полезно держать в голове и основателю, и руководителю, и инженеру. **Первый тест — единица планирования бюджета.** В позиционной компании, когда руководитель хочет увеличить производительность функции, он запрашивает дополнительную штатную единицу: ещё одну позицию, ещё одного человека. В ролевой компании он запрашивает пропускную способность роли: «обработать на 30% больше обращений в квартал». Как этот рост будет достигнут — нанять человека, добавить агентскую конфигурацию, оптимизировать инструкции, разрешить агенту больше действий — это операционное решение, принимаемое внутри роли, а не структурное решение HR. Если в бюджетной таблице компании единица — это FTE, она остаётся позиционной, как бы много AI ни было внутри. **Второй тест — определение работы.** В позиционной компании работа описана через должностные обязанности: «менеджер по работе с клиентами делает A, B, C». В ролевой компании работа описана через интерфейс и контракт: «роль принимает X на вход, выдаёт Y на выход, не превышает Z по времени, эскалирует при условии W». Это формулировка, которую может исполнить и человек, и агент, и гибрид. Если в компании нельзя написать должностную инструкцию в форме контракта роли — потому что слишком много неявного, слишком много «зависит от ситуации», слишком много политики — компания ещё не перешла. Это не значит, что переход невозможен. Это значит, что работа ещё не разобрана на формализуемые роли. Бо́льшая часть работы перехода уходит именно сюда — на онтологическую инженерию, на превращение «как мы делаем» в «что мы делаем». **Третий тест — реакция организации на отключение агентов.** Если завтра отключить всех агентов в Klarna, поддержка не остановится — она деградирует по пропускной способности, но не структурно. Именно поэтому Klarna смогла откатить долю агентов вниз в 2025 году, не перестраивая компанию: роль осталась той же, изменилось только соотношение. В условной позиционной компании, которая «использует AI», отключение агентов означает, что отдельные сотрудники не смогут выполнять свою работу: их позиция включает использование агента как обязательный шаг. Это и есть симптом того, что компания не перешла к ролевой модели, а сделала позицию зависимой от агентов. Парадоксально, но первая модель прочнее, потому что в ней роль и исполнитель разделены. Вторая модель хрупче, потому что в ней позиция теперь зависит от внешней системы, контракт с которой может измениться. ## Что меняется в найме, бюджете, управлении Для основателя главное следствие — пересмотр того, что значит «команда». Сэм Альтман ещё в феврале 2024 года говорил [в интервью Fortune](https://fortune.com/2024/02/04/sam-altman-one-person-unicorn-silicon-valley-founder-myth/): «я регулярно гадаю, когда появится первый основатель, доведший компанию до миллиардной оценки без единого нанятого сотрудника». Это не риторическая фигура. Это утверждение о том, что в ролевой архитектуре основатель может удерживать большое количество ролей в виде агентских конфигураций, а не позиций. На практике большинство компаний нанимают людей — но логика изменилась: люди нанимаются туда, где плотная экспертиза, неявное знание, переговорная сила, ответственность за принятие решений и креативная нестандартность. Всё остальное проходит через роли, исполняемые агентами под минимальным контролем — то, как именно команда удерживает контекст без штатного роста, мы подробно разбирали в заметке про [память вместо документа в AI-native команде](/2026/05/memory-beats-document-ai-native-team.html). Гарри Тэн, CEO Y Combinator, в [октябрьском интервью Mixergy](https://mixergy.com/interviews/garry-tan-y-combinator-startups-growing-5x-faster-heres-what-changed/) формулирует это прямо: «ИИ всё изменил. Раньше стартапы YC росли по выручке на 2–4% в неделю. Сейчас — на 10–20% в неделю. И они делают это командами из 3–5 человек». Похожую динамику YC фиксирует в [эссе «The New Way To Build A Startup»](https://www.ycombinator.com/library/NH-the-new-way-to-build-a-startup): маленькие команды обыгрывают компании в 20 раз крупнее за счёт встроенных автоматизаций внутри каждого процесса. Это не про эффективность. Это про то, что новые компании изначально проектируют не штат, а граф ролей. Для руководителя следствие — пересмотр оценки результативности. Невозможно провести квартальный обзор с агентом в формате «один на один». Метрика роли становится важнее метрики человека внутри роли. Это означает, что прослойка менеджеров среднего звена, которая существовала для координации между позициями, перестаёт быть нужной в прежнем виде. Появляется новая функция — оператор роли: человек, который проектирует роль, настраивает её инструкции и доступы, следит за её метриками, разбирает пограничные случаи. Это не менеджер людей. Это инженер по работе. В Klarna такие люди называются специалистами по агентским операциям. В Agentforce — *agent builders*. В Duolingo — *learning system engineers*. Название разное, функция одна: владеть ролью, а не людьми. Для инженера следствие — фокус на интерфейсы и обвязку. Сама модель — Claude, GPT, кастомные дообученные — становится взаимозаменяемой инфраструктурой. Защита компании не в выборе модели и не в её весах. Защита в обвязке: контракты ролей, доступы к данным, инструменты, разрешённые действия, политики эскалации, обратная связь от качества к настройкам. Anthropic в [представлении Claude Opus 4.7](https://www.anthropic.com/news/claude-opus-4-7) — модели, специально натренированной на длительные агентские задачи, — формализует это: модель сама по себе важна, но то, как именно роль ограничена и наделена возможностями, определяет, можно ли её доверить бизнесу. Инженер в AI-native компании больше пишет конфигурации ролей и обвязку вокруг агента, чем код самой модели. Для финансового директора следствие — переписывание модели затрат. В позиционной компании главная статья — фонд оплаты труда: прогнозируемый, медленно меняющийся. В ролевой компании появляется второй центр затрат: потребление моделей у провайдеров. Эта статья короткая, переменная, прыгает с трафиком. Ценообразование клиентам тоже меняется: появляется опция продавать не подписку на позицию, а оплату за результат — обработанный кейс, оформленный документ, пройденный квалификационный звонок. [Модель Service-as-Software экономически выживает](/2026/05/service-as-software-vertical-ai-revenue-model.html) потому, что издержки и доходы оба становятся переменными и оба привязываются к единице работы, а не к единице времени. Для HR следствие — пересмотр онбординга и грейдовых сеток. Когда роль описана в форме контракта, онбординг нового человека становится похож на онбординг агента: выдать доступы, показать интерфейс, объяснить метрики, дать набор разобранных примеров. Время входа в роль сокращается в разы. Грейдинг также пересобирается: различие между junior и senior внутри роли определяется не стажем, а способностью работать с большими пограничными случаями, перепроектировать роль, вводить новые подроли. Senior в этой логике — это человек, который не просто исполняет роль, а умеет её проектировать и отлаживать. ## Главное - Позиционная оргсхема — это контейнер для людей, появившийся, когда вся работа требовала человека. Ролевая архитектура — контейнер для функции, который может занять человек или агент. Это первая серьёзная смена единицы измерения организации со времён появления HR как дисциплины. - Откат Klarna в 2025 году — не провал ролевой модели, а её доказательство. Компания смогла сдвинуть соотношение агент/человек в роли, не перестраивая оргсхему. Это и есть симптом настоящего перехода: исполнители — параметр, роль — структура. - Переход к ролевой модели проверяется не по количеству AI-инструментов внутри компании, а по трём признакам: единица бюджетирования (пропускная способность роли, а не FTE), форма описания работы (контракт интерфейсов, а не должностные обязанности), реакция на отключение агентов (деградация, а не остановка). - Самая дефицитная функция в AI-native компании — не разработчик моделей и не оператор агентов, а человек, способный разложить существующую неформальную работу на формальные роли. Это онтологический инженер, и эта функция уже сейчас определяет скорость перехода больше, чем выбор провайдера моделей. ## FAQ **Чем роль отличается от должности?** Должность — это слот в штатном расписании, привязанный к человеку и трудовому договору. Роль — это контракт интерфейсов: что приходит на вход, что уходит на выход, какие метрики, когда эскалация. Один человек может исполнять несколько ролей; одну роль могут исполнять и человек, и агент одновременно. Должность отвечает на вопрос «кто», роль — на вопрос «что делается». **Если Klarna откатилась к людям, разве это не провал AI-подхода?** Откат Klarna — это не отказ от ролевой модели, а корректировка одного параметра внутри неё. Роль «поддержка первой линии» осталась той же; изменилось только соотношение «90% агент / 10% человек» в сторону большего участия людей. Позиционная компания такого манёвра без увольнений и пересборки команды сделать бы не смогла. Способность сдвинуть параметр без перестройки — это и есть преимущество ролевой архитектуры. **Значит ли это, что AI-native компании увольняют людей?** Salesforce и Klarna сокращали, Duolingo прекратила контракты с фрилансерами. Но многие AI-native стартапы просто не нанимают там, где раньше пришлось бы. Команды из 3–5 человек доходят до миллионных выручек потому, что с нуля проектируют граф ролей, а не штат. **Как понять, перешла ли наша компания к ролевой модели?** Три быстрых вопроса. Первое: что вы запрашиваете у финансового директора, когда нужна бо́льшая пропускная способность функции — ещё одну штатную единицу или прирост к роли? Второе: можете ли вы написать должностную инструкцию ключевой роли в форме «вход → выход → SLA → эскалация»? Третье: что произойдёт, если завтра отключить всех ваших агентов — деградация или остановка? Если ответы «штатная единица», «нет», «остановка» — вы пока в позиционной модели. **Кто становится самым ценным сотрудником в ролевой компании?** Онтологический инженер — человек, способный разобрать неформальную работу на формальные роли. Пересечение бизнес-аналитики, продуктового мышления и инженерной строгости. Скорость перехода к ролевой модели определяет не выбор провайдера, а наличие такого человека в команде. **Что делать руководителю прямо сейчас?** Выбрать одну функцию, где работа повторяется и формализуема — поддержка, квалификация лидов, обработка заявок, рутинная аналитика. Описать её в форме контракта роли: вход, выход, метрики, правила эскалации. Один квартал держать роль на гибридном исполнении агент+человек. Переписывать всю компанию сразу — самый частый способ сорваться обратно в позиционное мышление. --- ## Note 22: Скорость ответа — не сервис, а фактор ранжирования: что показывают B2B-воронки в РФ в 2026 **URL:** https://notes.temadev.org/2026/05/speed-of-response-b2b-ranking-russia-2026.html **Published:** 2026-05-17 **Genre:** pattern-essay **Tags:** pattern-essay, b2b-funnel, lead-response, avito, ranking, ai-внедрение, russia **Words:** 2327 **Summary:** Скорость ответа в B2B-воронке перестала быть сервисной метрикой и работает в трёх слоях: ranking платформ, LRM-воронка, якорь восприятия. # Скорость ответа — не сервис, а фактор ранжирования: что показывают B2B-воронки в РФ в 2026 Самый дешёвый способ потерять платёжеспособного клиента в 2026 году — ответить ему через четыре часа. Не отказать, не ошибиться в цене, не предложить плохой продукт — просто ответить позже, чем тот, кто настроил автоответ. Это утверждение перестало быть тезисом о сервисе и стало структурным фактом сразу в трёх плоскостях: алгоритмы платных площадок поднимают в выдаче тех, кто отвечает быстрее; классическая закономерность Lead Response Management даёт кратную разницу в конверсии при отклике до пяти минут; и психологически первый ответивший становится якорем, относительно которого покупатель сравнивает всё остальное. Каждый из этих слоёв работает отдельно, и компании, которые видят только один из них, недосчитываются денег в двух других. Lead Response Management — это паттерн B2B-воронки, описанный в исследовании Oldroyd, McElheran и Elkington и популяризированный в [материалах InsideSales и Harvard Business Review](https://www.insidesales.com/response-time-matters/): скорость первого контакта с лидом определяет вероятность квалификации и закрытия сделки сильнее, чем большинство «качественных» факторов. Это не инструмент, не продукт, не отдельный софт. Это закономерность, которая существует независимо от того, знает о ней владелец бизнеса или нет. «Качество ответа важнее скорости» — это расхожее возражение, которое в 2026 году ошибочно по простой причине: качество имеет значение только после того, как ответ вообще случился. Алгоритм платной площадки не оценивает глубину консультации — он оценивает факт реакции и время до неё; покупатель, написавший в четыре конкурирующих объявления, не дожидается, кто ответит лучше — он работает с тем, кто ответил первым. Качество становится дифференциатором на стадии переговоров, но до неё ещё нужно дожить. «AI заменит менеджера» — это лозунг, который в данном контуре подменяет цель. Автоматизация ответа закрывает не функцию «менеджер», а паузу между приходом лида и первым контактом с человеком. Сделку по-прежнему ведёт человек; робот закрывает только окно, в которое лид остывает. ## Почему алгоритм платформы уже решил за вас? Команда data science поискового ранжирования Авито в [техническом блоге компании](https://avito.tech/content/je6de84u31-kak-rabotaet-poiskovoe-ranzhirovanie-dly) описывает поисковое ранжирование как ML-систему, в которой объявления сортируются на основе сотен признаков, включая поведение продавца. Автор той же публикации представляется как data science team lead поискового ранжирования в Авито и описывает выбор карточки как машинное решение, опирающееся в том числе на фактическое поведение продавца. «behavioural signals» из этой публикации — формулировка, в которой скорость ответа продавца принципиально неотличима от других фичей модели. Из публичных правил [avito.ru/legal/rules/ranking-ads](https://www.avito.ru/legal/rules/ranking-ads) следует, что алгоритм учитывает не только текст и цену, но и активность продавца, наличие и качество ответов, применение платных услуг. Внешние разборы алгоритма, например [у «Точки»](https://reklama.tochka.com/blog/kak-rabotaet-poisk-na-avito), формулируют это прямо: «продавец, который быстро отвечает на сообщения» — один из явных факторов ранжирования наряду с подтверждённым профилем, отзывами и оценками. Структурный сдвиг здесь не в том, что Авито стал «строже». Структурный сдвиг — в том, что скорость ответа перестала быть метрикой, которую видит только сам продавец и его руководитель. Теперь её видит ML-модель, и она же определяет, попадёт ли объявление в первые десять позиций выдачи. Для нишевых B2B-категорий — аренды спецтехники, монтажа, ремонта, B2B-логистики — первые десять позиций забирают непропорционально большую долю просмотров и заявок. Это значит, что компания с медленным ответом не просто «теряет качество сервиса»: она структурно платит за рекламу, которая работает с пониженным КПД, потому что её карточка показывается реже. Это не отдельная политика Авито. Profi.ru, Яндекс.Услуги, отраслевые маркетплейсы по B2B-услугам — все они идут в ту же сторону: SLA исполнителя превращается из сервисного обещания в алгоритмический сигнал. Платформа перекладывает свою экономику на исполнителя: ей дороже показывать карточку, после клика по которой ничего не происходит, поэтому она пессимизирует таких продавцов на уровне модели, а не на уровне правил. Из этого следует первое практическое наблюдение. Когда руководитель B2B-сервисной компании спрашивает: «А действительно ли нам нужно отвечать через минуту, а не через час?» — он по сути спрашивает, готов ли он переплачивать за рекламу, которая алгоритмически дисконтируется. Ответ почти всегда отрицательный, даже если он сам этого ещё не сформулировал. ## Сколько на самом деле стоит задержка в воронке? Поверх алгоритмической логики платформы работает классическая закономерность лидогенерации, изученная задолго до того, как площадки стали учитывать SLA. [InsideSales](https://www.insidesales.com/response-time-matters/) фиксирует базовый эффект: вероятность контакта с лидом, отвечающим на онлайн-заявку, более чем в восемь раз выше, если попытка сделана в течение пяти минут после её появления, по сравнению с попыткой через 30 минут. Их же [инфографика по Lead Response Management Best Practices](https://resources.insidesales.com/wp-content/uploads/2019/11/infograpic-_LeadRespMgmt.pdf) показывает, что и contact rate, и qualification rate падают резкими ступенями именно в первые десятки минут — а дальше плавно деградируют, но уже из совсем другого диапазона. Внешние исследования рынка приходят к похожему выводу с другой стороны. [Motarme приводит](https://motarme.com/how-much-time-do-you-have-to-respond-to-sales-leads/) данные, по которым средний срок отклика на web-лид составляет 42 часа: 37% компаний отвечают в первый час, 16% — в первые сутки, 24% — позже суток, а 23% не отвечают вообще никогда. Это распределение важно не как обвинение, а как описание реальности: «отвечать быстро» означает оказаться в верхних 37% рынка по операционной дисциплине, а не делать что-то экстраординарное. Российские отраслевые срезы дают тот же сюжет в местной терминологии. [UIS пишет](https://www.uiscom.ru/blog/kak-biznes-sam-upuskaet-klientov-pochemu-kazhdyy-tretiy-zvonok-ostaetsya-bez-otveta-i-chto-s-etim-de/), что каждый третий звонок в малом и среднем бизнесе РФ остаётся без ответа — и это про прямой канал, без учёта мессенджеров, заявок с площадок и чатов на сайте. [Ассоциация «Российские автомобильные дилеры»](https://asroad.org/news/novosti-partnerov/telefonnye-zvonki-klientam-bolshe-ne-rabotayut/) в обзоре авторитейла 2024 года формулирует то же самое со стороны спроса: телефонный звонок как канал теряет долю, покупатель переходит в мессенджеры, и дилеры, которые не успели за этим миграционным движением, проседают по конверсии. Аналогичный сдвиг [ранее описан для рынка аренды спецтехники](/2026/05/rental-big-four-ai-russia-window-2026.html) — окно реакции сжимается быстрее, чем отрасль перестраивает процессы. Объединяет эти данные одно: разрыв между «средним рынком» и «верхними 5–10%» по скорости ответа измеряется не процентами, а кратами. И этот разрыв растёт не потому, что лидеры стали быстрее, а потому, что покупатель стал нетерпимее: у него в окне браузера или в телефоне открыто три похожих предложения, и переключиться с одного на другое стоит ему ноль усилий. ## Слой третий: якорь восприятия У третьего слоя нет красивых цифр в публичных отчётах, но он не менее структурен. Авторы «The Short Life of Online Sales Leads», переведённого в [материалы InsideSales](https://www.insidesales.com/response-time-matters/) и в их совместные публикации с Harvard Business Review, фиксируют это прямо: компании, пытающиеся связаться с лидом в течение часа, оказываются почти в семь раз продуктивнее в квалификации, чем те, кто пробует выйти на клиента хотя бы часом позже. Это эмпирически подтверждает якорный эффект: из одного и того же потока лидов выигрывают не те, у кого лучше sales pitch, а те, кто первым оказался в поле внимания покупателя. Первый ответивший компании-исполнитель занимает в голове покупателя позицию якоря: относительно его цены сравниваются все остальные цены, относительно его сроков — все остальные сроки, относительно его манеры — все остальные манеры. Это та же самая anchoring bias, которую поведенческая экономика описывает на товарных рынках, только в B2B-воронке она работает на уровне продавца, а не цены. Практическое следствие — догонять якорь дороже, чем им быть. Второй ответ должен либо явно бить первый по очевидному критерию (цена ниже, срок короче, гарантии шире), либо переубеждать покупателя на уровне восприятия — а это требует времени переговоров, которое второй продавец вынужден тратить, а первый — нет. В корпоративных закупках с длинным циклом это менее заметно, но и там «первое разосланное коммерческое» структурно задаёт повестку для последующих предложений. В сочетании со вторым слоем это даёт неприятный эффект: компания, которая отвечает медленно, не просто теряет долю лидов — она систематически попадает в роль догоняющего и тратит больше переговорных усилий на каждую сделку, которую всё-таки доводит. Это уже не воронка с разной конверсией, это два разных режима продаж с разной экономикой. ## Что объединяет три слоя У всех трёх слоёв общая структурная причина — платформенная экономика смещает SLA из сервисной плоскости в алгоритмическую. Отдельно это видно в каждом слое: Авито переносит скорость в ranking-фичи; HBR/InsideSales показывают это на conversion-воронке; поведенческая экономика — в измерении «reference-anchor effect». Раньше «быстрый ответ» был обещанием бренда покупателю и был виден только участникам сделки. Теперь это сигнал, который видит модель, и сигнал, который покупатель сравнивает мгновенно. Сервисная риторика про «качество» и «индивидуальный подход» осталась там же, где была, но рамка, в которой эта риторика работает, изменилась — она теперь активируется только после того, как ответ случился. Из этой общей причины следует, что три слоя не складываются как независимые проблемы. Они усиливают друг друга: медленный ответ снижает позицию в выдаче, что снижает поток лидов; меньший поток лидов делает каждую конкретную задержку дороже; и в каждой конкретной сделке компания всё чаще оказывается во второй роли — догоняющим. Это композитный, а не аддитивный эффект, и именно поэтому компании, которые «знают, что надо отвечать быстро», часто всё равно недооценивают его масштаб. ## Как перевести три слоя в решения B2B-компании на 30–500 человек Для руководителя B2B-сервисной компании в этом сегменте практический вывод сворачивается в три действия. Первое — измерить, а не предполагать. Среднее и медианное время первого ответа по основному входящему каналу (Авито, сайт, WhatsApp, Telegram, телефон) — это первая цифра, которая должна появиться на дашборде у коммерческого директора, рядом с количеством лидов и конверсией. Без неё нельзя ни выбирать инструмент, ни оценивать его эффект. Второе — автоматизировать не «менеджера», а паузу. Первое сообщение в ответ на лид — короткое, фактическое, с уточняющим вопросом — спокойно автоматизируется без потери качества. Это закрывает алгоритмический слой (платформа фиксирует факт ответа), закрывает второй слой (лид получает реакцию в пределах окна Lead Response Management) и нейтрализует якорный эффект третьего слоя — первый ответивший становится не конкурентом, а вашей собственной компанией. Передача в человеческие руки происходит на следующем шаге, и качество переговоров от этого не страдает. Третье — не автоматизировать ведение сделки. Это распространённая ошибка, в которой компания пытается заменить менеджера агентом по всему циклу, упирается в качество, разочаровывается и сворачивает проект. Автоматизация окупается на пятиминутном окне реакции, а не на двухнедельном цикле согласования сметы. Эти два уровня требуют разной зрелости системы, разных метрик и разной приёмки. ## Что измерять первыми двумя неделями Две базовые метрики закрывают большую часть картины. Первая — **медианное время первого ответа** по основному входящему каналу (ПО времени от входящего сообщения до первого ответа сотрудника или бота). Вторая — **доля лидов без ответа** (как в срезе рабочего дня, так и в срезе ночь/выходные). Эти две цифры достаточны, чтобы оценить оба первых слоя и принять обоснованное решение об автоматизации первого ответа. Третья полезная, но уже производная метрика — **доля вторых и третьих касаний** от сотрудника, если в первые 24–48 часов ответ не случился. Она показывает, насколько операционная дисциплина справляется с выпавшими лидами, и часто даёт быстрый выигрыш без любой автоматизации — введением ручного регламента. Сравнение медианы внутри компании с публичными референсами (5 минут у лидеров, 1 час у верхних 37%, «каждый третий без ответа» у рыночного среднего) обычно укладывается в одну неделю работы аналитика. Для большинства компаний это тот срез реальности, который фиксируется впервые и сразу меняет приоритеты коммерческого блока на следующий квартал. ## Сигналы 2026 года В ближайшие двенадцать месяцев стоит следить за тремя структурными сигналами. Первый — момент, когда WhatsApp Business или Telegram Business начнут публично использовать SLA продавца как фактор видимости в каталогах услуг. Сейчас они это явно не делают, но логика площадочной экономики толкает в эту сторону, и первый из них, кто введёт жёсткий ranking-сигнал по скорости, заставит остальных подтянуться в течение полугода. Второй — момент, когда крупный российский маркетплейс B2B-услуг (Profi.ru или аналог) введёт hard-cutoff: исполнители с медианным временем ответа выше N минут перестают показываться в первой странице выдачи. Третий — момент, когда отраслевая ассоциация (например, по авторитейлу или строительной аренде) опубликует медианную скорость first response по сегменту: это превратит индивидуальную метрику в публичный бенчмарк, и любой исполнитель, попадающий ниже медианы, начнёт терять клиентов уже из-за репутационного эффекта, а не только из-за алгоритма. ## Главное - Скорость первого ответа в B2B-воронке 2026 года работает на трёх независимых слоях: ML-ранжирование платных площадок, Lead Response Management по воронке, якорный эффект восприятия. Эффекты этих слоёв перемножаются, а не складываются, и компании, видящие только один из них, недосчитываются в двух других. - Авито и аналогичные платформы встроили скорость ответа продавца в алгоритм ранжирования. Это перевело SLA из плоскости «сервис лучше у быстрых» в плоскость «выдача меньше у медленных» — то есть в плоскость прямой экономики платных каналов. - Lead Response Management как закономерность даёт кратную разницу в контакте и квалификации при отклике до пяти минут против тридцати; российские отраслевые срезы показывают, что средний рынок живёт в режиме отклика, измеряемого часами и сутками. Разрыв между средним и верхними 10% компаний по скорости — это разрыв в режимах продаж, а не в процентах конверсии. - Автоматизация окупается на пятиминутном окне реакции, а не на двухнедельном цикле сделки. Первое — это короткое автосообщение с уточняющим вопросом, закрывающее три слоя сразу. Второе — это попытка заменить менеджера агентом по всему циклу, которая в 2026 году ещё не окупается на массовом сегменте B2B-сервисов. ## FAQ **Что значит «Lead Response Management» в одном предложении?** Это паттерн B2B-воронки, по которому вероятность квалифицировать и закрыть сделку сильно зависит от времени до первого контакта с лидом: пять минут против тридцати уже дают разницу в разы, а не в процентах, согласно классическому исследованию Oldroyd и коллег, популяризованному [InsideSales и HBR](https://www.insidesales.com/response-time-matters/). **Это действительно подтверждено для российского рынка, а не только для США?** Да, в той части, что измеряется. [UIS](https://www.uiscom.ru/blog/kak-biznes-sam-upuskaet-klientov-pochemu-kazhdyy-tretiy-zvonok-ostaetsya-bez-otveta-i-chto-s-etim-de/) приводит данные по малому и среднему бизнесу РФ — каждый третий звонок не получает ответа. [Ассоциация «Российские автомобильные дилеры»](https://asroad.org/news/novosti-partnerov/telefonnye-zvonki-klientam-bolshe-ne-rabotayut/) фиксирует тот же эффект в авторитейле и подтверждает миграцию покупателей в мессенджеры. Универсальный российский benchmark по медианному first response пока не опубликован — это и есть один из ожидаемых сигналов 2026 года. **Если у нас уже стоит CRM с автоответом — зачем ещё что-то делать?** Автоответ типа «спасибо, мы скоро свяжемся» закрывает только формальный факт реакции, но не закрывает Lead Response Management: для алгоритма Авито это сигнал, для воронки — нет. Сообщение должно содержать уточняющий вопрос или короткий шаг вперёд, чтобы попасть во вторую и третью плоскости. Шаблон «спасибо, мы перезвоним» работает в этом смысле так же плохо, как полное молчание. **С чего начать B2B-компании на 100 человек, у которой первый ответ — это «как получится»?** С измерения. Поставить замер медианного времени первого ответа по основному каналу — Авито, сайт, WhatsApp — на ближайшие две недели и сравнить с публичными референсами. Далее — короткая автоматизация первого сообщения с уточняющим вопросом; ведение сделки оставить менеджеру. Перестраивать ведение сделки имеет смысл только после того, как закроется первое окно, и в цифрах будет видно, что именно изменилось. --- ## Note 23: AI в стройке: три точки окупаемости за квартал — и три зоны, где её не будет **URL:** https://notes.temadev.org/2026/05/vertical-ai-construction-roi-90-days-russia.html **Published:** 2026-05-15 **Genre:** market-deep-dive **Tags:** vertical-ai, строительство, россия, smb, roi, ai-внедрение **Words:** 2416 **Summary:** Карта по слоям: где AI в стройке окупает подписку за квартал, а где «трансформация» означает горизонт двух лет и данные, которых ещё нет. # AI в стройке: три точки окупаемости за квартал — и три зоны, где её не будет Менее одного процента выручки идёт на IT, всего три процента компаний используют AI — таков базовый уровень цифровизации строительной отрасли в России по данным НЦРИИ ([Движение.ру](https://dvizhenie.ru/media/181/iskusstvennyi-intellekt-v-developmente-keisy-zastroishchikov)). На этом фоне публичные кейсы выглядят как чудеса: ГК «Самолёт» сообщает о росте производительности труда на 40% после внедрения S.Monitoring, ГК ПИК — о +20% от системы мониторинга действий рабочих, Pragmacore — о клиенте, который сэкономил около миллиона рублей в неделю только на сокращении совещаний ([Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl), [Движение.ру](https://dvizhenie.ru/media/181/iskusstvennyi-intellekt-v-developmente-keisy-zastroishchikov)). Разрыв между «3% используют» и «у одних в неделю миллион, у других в год сорок процентов» — это и есть главный вопрос для CTO средней строительной или ремонтной компании в России: где здесь экономика, а где маркетинговая презентация. У стройки нет **общего ROI на AI** — это иллюзия отраслевого среднего, в которой кейс «миллион в неделю» крупного девелопера смешивается с реальностью бригады из десяти человек и превращается в маркетинговый слайд. На отдельном проекте окупаемость зависит не от «AI», а от того, какую именно операцию автоматизация заменяет. ## Почему базовая планка цифровизации в стройке так низка? Каркас, на котором держится дальнейший разговор, описывают аналитики Strategy Partners в отчёте, с которым [ознакомился Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl). Российский рынок программного обеспечения для управления строительством оценивается примерно в 6 млрд рублей в 2024 году против 4–5 млрд в 2020-м, девелоперы тратят на IT-внедрения в среднем менее 1% выручки (как правило, до 100 млн рублей в год), тогда как лидеры розничной торговли — до 5%. Прогноз — четырёхкратный рост к 2028 году за счёт нацпроекта по цифровизации и инвестиций в отрасль. К 2028 году объём рынка превысит 8 млрд рублей, а доля российских ERP-решений в строительстве уже к концу 2023-го достигла 55% в денежном выражении, причём более 80% этого сегмента приходится на «семью» 1С. Первая — стартовая планка действительно низкая: компания, которая внедрит хоть какую-то автоматизацию, конкурирует с интуицией владельца, а не с уже работающим контуром. Вторая — большая часть учётной поверхности уже занята 1С, и любая попытка построить отдельную «AI-замену 1С» означает не три месяца разработки, а длинную миграцию данных и переобучение бухгалтерии. Издание [«Строительная газета»](https://stroygaz.ru/publication/technologies/tsifrovizatsiya-stroitelnoy-otrasli-v-2024-godu/) фиксирует ту же картину со стороны бизнес-процессов: компании выделяют на цифровизацию менее 1% выручки, и большинство внедрений «работает на половину мощности», потому что цифровые инструменты накладываются поверх старых процессов, а не пересобирают их. ## Что объединяет операции, окупаемые за квартал Прежде чем перечислять точки окупаемости, стоит сформулировать критерий, по которому они отбираются. **Целый отдел** в смысле автоматизации — это набор связанных, но разнородных задач (например, «продажи» или «строительный надзор»), у которого нет одного измеримого входа и одного измеримого выхода. Заменить целый отдел AI-инструментом за квартал нельзя в принципе: слишком много границ, состояний и исключений. А вот заменить одну операцию внутри отдела — иногда можно. Окупаемая за квартал автоматизация выглядит одинаково. Это операция, у которой есть формализуемый вход (входящее сообщение клиента, новый лот в ЕИС, акт КС-2), формализуемый выход (квалифицированный лид с карточкой, ранжированный список тендеров, заполненная учётная запись в 1С) и понятная цена ошибки в рублях, которую владелец считает в голове, не открывая Excel. И ещё одна общая черта: на входе или выходе обязательно стоит другой человек — клиент, тендерный специалист, бухгалтер. То есть это не «AI вместо ERP», а «AI на конкретном шве между ERP и людьми». ## Три операции, где деньги возвращаются за квартал ### Ответ на лиды и квалификация в мессенджере Первая точка — стык между Авито/WhatsApp и любой учётной системой (CRM, 1С, табличка). По собственной оценке поставщика автоматизации [aibotmanager.ru](https://aibotmanager.ru/ii-dlya-remonta-kvartir/), без независимой проверки, рынок ремонтных услуг физлицам в России — около 1,4 трлн рублей в год, и при этом «70% бригад теряют клиентов из-за медленного ответа» — характерная задержка ответа на WhatsApp измеряется не минутами, а часами и сутками. Авито в 2026 году ввело «уровень сервиса» и пессимизирует объявления компаний с медленным ответом — то есть скорость ответа перестала быть просто маркетинговой метрикой и стала фактором ранжирования в платном канале. Публичный кейс, опубликованный тем же источником: ремонтная бригада из пяти человек в Москве после внедрения автоответчика с квалификацией в чате получила +2,3 млн рублей выручки за квартал и рост конверсии «заявка → замер» с 7 до 19 процентов при инвестициях около 30 тыс. рублей в месяц. Это — нижняя ценовая граница рынка, и она показывает базовую экономику явления, а не верхнюю границу. Важный нюанс: окупаемость здесь не «AI отвечает вместо человека», а «AI отвечает за тридцать секунд, пока человек не успел отвлечься от объекта». Дальше квалифицированная карточка клиента уходит владельцу, и сделку всё равно ведёт человек. Это и есть механика первого слоя: AI сокращает время реакции, а ведение сделки остаётся за человеком. Ровно такую механику — заявка квалифицируется за тридцать секунд, готовая карточка уходит человеку — мы собрали в смежной нише, аренде спецтехники: [рабочий пример контура](https://temadev.org/specteh/?utm_source=geo_referral&utm_medium=ai&utm_campaign=vertical-ai-construction-roi-90-days-russia&utm_content=inprose). ### Тендерный мониторинг и подготовка к заявке Вторая точка — государственные и коммерческие закупки. По данным [Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl) рынок ПО для управления строительными проектами растёт за счёт того, что строители впервые начинают системно работать с закупочными контурами; параллельно растёт количество специализированных тендерных площадок, агрегаторов и API. В ручном режиме тендерный специалист упирается в физический потолок по числу лотов, которые реально просмотреть за месяц — каждое объявление надо открыть, прочесть техзадание, оценить соответствие парку техники и компетенциям компании, прикинуть рентабельность с учётом снижения цены. Автоматическая фильтрация по ОКПД2 и ключевым словам с последующим LLM-скорингом релевантности поднимает поток обработанных лотов в несколько раз — публичный пример такой услуги, упакованной как продукт, есть у [«Триада Компани»](https://triadacompany.ru/uslugi/ai-dlia-tender), которая прямо позиционирует «автоматизацию поиска, оценки заявок и подготовки к участию в тендерных закупках с помощью искусственного интеллекта». Связь с выручкой здесь прямая: больше просмотренных лотов — больше поданных заявок — больше выигранных контрактов, при стабильной доле побед. Окупаемость держится на двух условиях: данные ЕИС доступны через сторонние API (ГосПлан API, DaMIA), а сама подача заявки требует квалифицированной электронной подписи и не автоматизируется. AI закрывает только верхнюю воронку: мониторинг, фильтрацию, скоринг релевантности, подготовку шаблонов документов. И именно поэтому окупается — заменяется одна операция (просмотр и фильтрация), а не «целый отдел тендерных». ### Документооборот по актам КС-2 и КС-3 Третья точка — стык между объектом и 1С. Это самый громкий публичный кейс в категории: «Социальный код» сообщает, что её решение по автоматизации анализа и заполнения документов для девелоперов «Группы ЛСР» ускорило скорость обработки документов более чем в 10 раз и автоматизировало ввод больших объёмов данных в систему 1С при приёмке строительных объектов ([Движение.ру](https://dvizhenie.ru/media/181/iskusstvennyi-intellekt-v-developmente-keisy-zastroishchikov)). На том же уровне работают кейсы Pragmacore: подготовка данных к проекту сокращается с трёх месяцев до двух недель, а сам владелец платформы Кирилл Поляков говорит о клиенте, сэкономившем около миллиона рублей в неделю только на сокращении совещаний управленческого персонала ([Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl)). Десятикратное ускорение на отдельной операции — это не «AI заменил бухгалтерию». Это AI прочитал акт, сверил позиции со сметой и записал результат в 1С — операция, которая ровно укладывается в критерий «формализуемый вход, формализуемый выход, ошибка считается в рублях штрафа за просрочку оплаты». В компании с десятками объектов в месяц это даёт кратное сокращение цикла «акт — оплата», что прямо отражается на оборотном капитале. ## Что объединяет эти три точки Все три операции выглядят по-разному, но устроены одинаково. Во-первых, у них есть один измеримый KPI, который владелец называет в одной строке: «время до первого ответа», «количество просмотренных лотов в месяц», «срок прохождения акта до оплаты». Во-вторых, цена ошибки в каждой из них известна заранее — потерянный лид на сумму контракта, пропущенный тендер, просроченный акт с неустойкой за задержку оплаты. В-третьих, AI здесь заменяет не функцию, а паузу — те минуты или дни, когда задача стоит в очереди, потому что у живого человека нет ресурсов на неё реагировать. Из этого следует практический критерий: операция окупается за квартал, если её можно описать одной картой состояний на одной странице, а не блок-схемой на десяти. Если на одной странице не получается — значит, на самом деле автоматизируется не операция, а отдел. ## Три зоны, где окупаемости за квартал не будет ### BIM-аналитика и автоматизация проектирования Тяжёлая аналитика проектных моделей и автоматизация архитектурных решений — направление, в котором публичные кейсы существуют (ДОМ.РФ, AVA, Pragmacore), но горизонт отдачи измеряется в годах, не в кварталах. По данным [ai-journal.ru](https://ai-journal.ru/ii-dlya-stroitelstva/), ГК «Самолёт» с помощью S.Monitoring достигла точности прогноза стоимости материалов 92,6% и снизила затраты на закупку арматуры на 9,3% — но это эффект интегрированный, на годовой смете крупного девелопера, при наличии собственного дата-офиса и команды дата-инженеров. Для компании на 100 человек с проектами объёмом 50–300 млн рублей в год сборка такого контура — это не «внедрение продукта», а перестройка процессов работы с моделями и данными. Это окупается, но в горизонте двух-трёх лет и при условии, что у компании уже есть единый источник данных по проектам, не разнесённый по десяти Excel-таблицам. У большинства такого источника нет. ### Видеоаналитика стройплощадки Системы машинного зрения на стройке — отдельная история, в которой публичные числа выглядят впечатляюще. По описанию продукта [Билайн Big Data & AI](https://bigdata.beeline.ru/blog/articles/promyshlennaya-videoanalitika) видеоаналитика покрывает контроль использования средств индивидуальной защиты, охрану периметра, выявление попыток хищений и аномалий в производственных процессах. Это полностью рабочая категория продукта, но экономика её устроена так: основная стоимость — не алгоритмы, а инфраструктура (камеры с нужным разрешением, серверы, каналы связи) и интеграция в существующие службы охраны и охраны труда. Это означает CAPEX-разговор, а не подписку. Установка и настройка контура видеоаналитики на объекте средней площади занимает несколько месяцев, окупаемость считается на горизонте проекта (12–24 месяца), а сравнение «сколько стоило / сколько сэкономили» получается осмысленным только тогда, когда у клиента уже есть выстроенная система безопасности и есть данные о потерях. У SMB-стройки этого, как правило, нет, и видеоаналитика для неё работает как имидж, а не как операция. ### Полная замена 1С и связанной ERP Третья зона — соблазн «AI-агент вместо 1С». В отчёте Strategy Partners, на который ссылается [Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl), есть ключевое число: более 80% сегмента российских ERP в стройке приходится на продукты «семьи» 1С. Любая попытка заместить учётный контур означает миграцию десятилетней истории документов, переподготовку бухгалтерии, перенастройку обмена с банками и налоговой, согласование с проверяющими органами. Стоимость переключения здесь делится не на технологию, а на бизнес-риск, и она велика даже там, где техническая часть выглядит простой. Это не значит, что 1С невозможно вытеснить. Это значит, что окно для вытеснения открывается раз в 5–10 лет — обычно после санкционного шока или принципиальной смены ИТ-стандартов — и сейчас оно закрыто. Любой проект «вместо 1С» в горизонте 90 дней — это либо переоценка, либо подмена цели. ## Что это значит для CTO средней компании Для технического директора российской строительной или ремонтной компании на 50–500 человек практический вывод выглядит так. Первая проверка — у выбранной операции должен быть владелец с одной метрикой и одной ценой ошибки в рублях. Если их нет — операция не готова к автоматизации, надо начинать с её формализации, а не с покупки решения. Вторая проверка — горизонт окупаемости заявленного решения. Если поставщик обещает «трансформацию» и не показывает, какая именно операция и за сколько окупится, разговор сворачивается в сторону пилота на одну операцию, а не на «комплексное внедрение». Кейс «миллион в неделю на сокращении совещаний», описанный Pragmacore в [Forbes](https://www.forbes.ru/tekhnologii/544222-pravila-vozvedenia-kak-cifroviziruetsa-stroitel-naa-otrasl), — это, по сути, тоже одна операция (управленческие совещания), а не «трансформация»; это ровно тот режим, в котором выручка привязывается к конкретному результату, а не к подписке на инструмент ([см. «Service-as-software: как агенты переписывают формулу выручки в B2B»](/notes/service-as-software-vertical-ai-revenue-model/)). Третья проверка — у текущей операционной модели уже есть один поставщик данных. У актирования это 1С. У тендерного мониторинга — ЕИС и его API-обёртки. У ответов на лиды — Авито Pro и WhatsApp Business API. Если выбранная автоматизация делает вид, что этих систем нет, и предлагает «собственное хранилище» — это не AI-инструмент, это второй ERP, и в нём провалится не AI, а данные. В сумме это даёт простую дорожную карту: одна точка автоматизации на 90 дней, измеримая метрика на входе, прямой выход в существующую учётную систему, понятная цена ошибки. Всё остальное, что называется «AI-проектом», стоит откладывать до тех пор, пока первый цикл окупаемости не пройдёт по факту, а не на бумаге. ## Сигналы 2026 года Это раздел авторского прогноза, а не аналитики по источникам — в нём собраны события, которые изменят раскладку выше, если произойдут. В ближайшие двенадцать месяцев стоит следить за тремя сигналами. Первый — момент, когда крупный 1С-партнёр интегрирует LLM-распознавание актов КС-2/КС-3 в стандартный коробочный продукт. После этого окно для самостоятельных интеграторов на этом стыке сужается до полугода: ускорение обработки документов перестаёт быть конкурентным преимуществом и становится отраслевой нормой. Второй — публичный кейс среднего застройщика (не из топ-30), который показывает окупаемость одного AI-внедрения за квартал с конкретными цифрами выручки или сокращения цикла. До такого кейса рынок живёт на референсах «Самолёта» и «ЛСР», после — начинает считать по себе. Третий — момент, когда «Авито Бизнес 360» или другая горизонтальная площадка встроит автоматическую квалификацию входящих сообщений как часть платного тарифа. Это закроет первый из трёх описанных слоёв окупаемости как самостоятельный рынок и сделает его частью маркетплейса, а не интегратора. ## Главное - В стройке нет «общего ROI на AI». Окупаемость за квартал даёт три операции: ответ на лиды в мессенджере, тендерный мониторинг и автоматизация документооборота по КС-2/КС-3. Всё, что описывается как «трансформация целого отдела», за квартал не окупается. - Базовая планка цифровизации в отрасли низкая: менее 1% выручки на IT, 3% компаний используют AI, более 80% ERP-сегмента приходится на «семью» 1С. Это одновременно объясняет, почему первые внедрения дают видимый эффект, и почему «замена 1С» — заведомо неокупаемая цель. - Три зоны без отдачи в 90 дней — BIM-аналитика и автоматизация проектирования, видеоаналитика стройплощадки, полная замена 1С. Они работают как направления, но их окупаемость считается на горизонте 18–36 месяцев и требует данных, которых у компании среднего размера ещё нет. - Практический критерий: одна автоматизация — одна метрика — одна цена ошибки в рублях. Если выбранную операцию нельзя описать на одной странице карты состояний, автоматизируется не операция, а отдел, и срок окупаемости перетекает в годы. ## FAQ **Что значит «общего ROI на AI» в стройке?** Это иллюзорный отраслевой средний показатель, в котором кейсы топ-3 девелоперов («Самолёт», ПИК, ЛСР) смешиваются с реальностью SMB-стройки и превращаются в маркетинговый слайд. На отдельном проекте окупаемость зависит не от «отраслевой нормы», а от конкретной операции — её формализуемости, цены ошибки и длительности цикла «вход — выход». **Что значит «целый отдел» в смысле автоматизации?** Это набор связанных, но разнородных задач (продажи, строительный надзор, бухгалтерия), у которого нет единого измеримого входа и единого измеримого выхода. Заменить такой отдел AI-инструментом за квартал нельзя в принципе — слишком много границ, состояний и исключений. Заменить одну операцию внутри отдела — иногда можно, и именно на этом строится квартальная окупаемость. **Окупается ли видеоаналитика стройплощадки за квартал?** Нет. Установка и настройка контура занимает несколько месяцев, основная стоимость лежит не в алгоритмах, а в инфраструктуре (камеры, серверы, каналы связи), и окупаемость считается на горизонте 12–24 месяцев. Для SMB-стройки эта категория остаётся скорее имиджевой, чем операционной. **С чего начать CTO, у которого 100 человек в строительной компании и нет внутреннего AI-опыта?** С одной операции, у которой есть владелец, одна метрика и известная цена ошибки в рублях. Чаще всего это ответ на входящие лиды, обработка тендерных лотов или актирование КС-2/КС-3 в 1С. Дальше — пилот на 60–90 дней с прямым выходом в существующую учётную систему. До тех пор, пока эта операция не окупится по факту, остальные AI-проекты лучше держать в режиме наблюдения. --- ## Note 24: Локально или в облако: что реально требует 152-ФЗ от B2B AI в 2026 году **URL:** https://notes.temadev.org/2026/05/152-fz-b2b-ai-on-prem-vs-cloud-russia-2026.html **Published:** 2026-05-14 **Genre:** market-deep-dive **Tags:** russia, 152-fz, compliance, b2b-ai, on-prem, gigachat, data-residency **Words:** 2338 **Summary:** 152-ФЗ не требует on-prem для большинства B2B AI-проектов. Что реально нужно — зависит от типа данных и отрасли. Разбор четырёх сценариев, где локальное развёртывание обязательно, и трёх — где достаточно договора. # Локально или в облако: что реально требует 152-ФЗ от B2B AI в 2026 году ## Почему все вдруг стали бояться облака 30 мая 2025 года в России вступили в силу новые штрафы за утечки персональных данных. [Размер санкций изменился радикально](https://b-152.ru/zakon-o-personalnyh-dannyh-2025): утечка от 100 000 субъектов — до 20 млн ₽, повторное нарушение — оборотный штраф до 500 млн ₽. Параллельно, по данным [Habr со ссылкой на статистику Роскомнадзора](https://habr.com/ru/articles/878048/), за 2025 год возбуждено более 600 уголовных дел по статье 272.1 — неправомерный доступ к компьютерной информации. Рынок отреагировал предсказуемо: консультанты, юристы и интеграторы массово стали советовать «делать всё on-prem». Это понятная реакция, но она некорректна как универсальное правило. Подавляющее большинство B2B AI-проектов — автоматизация спецтехники, производства, строительства, оптовой торговли — оперирует данными юридических лиц. ИНН, название компании, корпоративный email, должность ЛПР — это **не персональные данные** по смыслу 152-ФЗ. Закон защищает физических лиц, а не организации. Задать правильный вопрос важно: не «облако или сервер?», а «что именно обрабатывает ваш AI и кому это принадлежит?» ## Что 152-ФЗ защищает, а что нет 152-ФЗ «О персональных данных» распространяется на информацию, по которой можно идентифицировать **физическое лицо**. Из этого следует несколько практических следствий для B2B AI. **Зелёная зона** — данные, с которыми AI-инструменты работают свободно без специального правового оформления: - Реквизиты юридических лиц: ИНН, ОГРН, название, адрес, корпоративный телефон, юридический email - Операционные данные без привязки к конкретному физлицу: парк техники, объёмы заявок, прайс-листы - Публичная информация: сайт клиента, опубликованные тендерные документы, прайсы - Обезличенные агрегаты: средняя скорость ответа, загруженность по дням недели, конверсия этапов воронки **Жёлтая зона** — требует оформления, но облако не исключено: - Имена и телефоны контактных лиц (ЛПР) в компании-клиенте — технически это ПДн, но риск умеренный при наличии ДПО - Записи деловых переговоров и звонков — требуют уведомления участников и договора об обработке - Формы с физическими адресами доставки (если это домашний адрес) **Красная зона** — облако реально рискованно или прямо запрещено: - Биометрия: голосовые отпечатки, фотографии лиц → штрафы до 15–20 млн ₽ за утечку - Специальные категории ПДн: диагнозы, кредитные истории, данные о вероисповедании, данные о судимостях - Данные физических лиц (покупателей, пациентов, работников) без обезличивания - Любые данные, передаваемые в США без уведомления РКН о трансграничной передаче Прослойка между этими зонами — техника обезличивания. [Согласно securegpt.ru](https://securegpt.ru/blog/ai-personal-data-legal-risks), обезличенные данные выходят из-под действия 152-ФЗ при условии, что восстановить идентичность субъекта по оставшимся атрибутам невозможно. На практике это означает маскирование имён, телефонов и адресов перед отправкой в API внешней модели. ## Четыре сценария, где on-prem действительно обязателен Существуют отраслевые контексты, в которых архитектура с локальным развёртыванием модели — не паранойя, а требование регулятора или невозможность иначе обойти правовые риски. **Банки и финансовые организации.** ЦБ РФ Положение № 787-П устанавливает требования к внутреннему контролю ИТ-рисков. Статья 395-1 ФЗ «О банках» — банковская тайна — запрещает передачу информации о клиентах и операциях третьим лицам без согласия. Кредитные истории регулируются отдельным 353-ФЗ. На практике любой банк, который хочет внедрить AI-агента в кредитный процесс или клиентский сервис, обязан использовать решения, одобренные ЦБ, либо on-prem-развёртывание. Claude или OpenAI API напрямую — невозможны. **Медицина.** Приказ Минздрава № 911н и Постановление Правительства № 1119 (уровень защищённости УЗ-1) устанавливают требования к медицинским информационным системам. AI-ассистент для ведения электронных медицинских карт обязан работать в аттестованной МИС с интеграцией в ЕГИСЗ. Обход невозможен через организационные меры — данные о здоровье относятся к специальным категориям ПДн по ст. 10 152-ФЗ, и облачные зарубежные API исключены без исключений. **Государственные закупки с элементами гостайны.** Для систем, работающих с документами, составляющими государственную тайну, требуется сертификация ФСТЭК и/или ФСБ. Ни один публичный облачный AI-провайдер в 2026 году такой сертификацией не обладает. Для обычных тендеров по 44-ФЗ / 223-ФЗ облако формально допустимо, но начиная с 1 января 2026 применяются единые защитные меры вне зависимости от категории закупок (поправки к 44-ФЗ, вступившие в силу с 01.01.2026). Готовящийся реестр доверенных моделей, который войдёт в AI-закон, сделает on-prem-сертифицированные решения обязательными для государственных заказчиков. **Массовые физлица без обезличивания.** Компании, которые обрабатывают заявки конечных потребителей — электронная коммерция, телемедицина, кредитование, — и хотят пропускать необезличенные данные через AI-модель, юридически не могут использовать зарубежный облачный API без уведомления РКН о трансграничной передаче и заключения договора с провайдером в стране, находящейся в Перечне разрешённых направлений. В 2026 году США в этом перечне нет. Германия (AWS Bedrock EU, регион Frankfurt) — есть, что открывает одну из рабочих схем, но требует отдельной юридической проверки. ## Три сценария, где облако работает законно **B2B-сервис с данными юрлиц.** Автоматизация закупок, управление парком техники, тендерный мониторинг, классификация входящих обращений от корпоративных клиентов. Если в системе хранятся только юридические реквизиты контрагентов — это не персональные данные. ДПО (договор поручения обработки ПДн) между компанией-разработчиком и клиентом требуется для фиксации ответственности, но сам по себе не запрещает облако. Типичная конструкция: разработчик выступает обработчиком, клиент — оператором, при этом в приложении к договору прямо указано, что обработке подлежат только данные юрлиц, и зафиксировано, что ФИО конкретных людей маскируются перед отправкой в API. **Обезличенный голосовой AI.** Запись и транскрипция звонков — часто вызывает тревогу, но при правильном оформлении работает через облако. Требуется три меры: уведомление клиента до начала разговора («разговор записывается и обрабатывается автоматической системой»), обезличивание имён и телефонов перед отправкой в LLM, хранение необезличенной записи только на российском сервере. Практика уведомления клиентов о записи разговоров давно отработана колл-центрами — достаточно фразы до начала разговора с упоминанием автоматической обработки. AI-слой добавляет к этому только требование об обработчике. **Строительство и спецтехника (B2B-коммуникация).** Запросы от компаний-заказчиков, координация субподрядчиков, управление объектами — в основе лежат данные юрлиц. Основной риск — данные о работниках (ФИО, паспортные данные, данные иностранных граждан по 115-ФЗ). Пока AI-агент работает с координацией заявок и операционными данными, а не с кадровым учётом, облачный стек совместим с 152-ФЗ. При появлении кадровых задач — граница проходит по типу данных, а не по отрасли. Ровно такой контур — AI квалифицирует заявку и собирает карточку, а сделку ведёт человек — мы собрали в смежной нише, аренде спецтехники: [рабочий пример контура](https://temadev.org/specteh/?utm_source=geo_referral&utm_medium=ai&utm_campaign=152-fz-b2b-ai-on-prem-vs-cloud-russia-2026&utm_content=inprose). ## Сравнительная таблица: что реально нужно по отраслям | Отрасль | Тип данных | Можно облако? | Что нужно минимально | |---------|-----------|---------------|----------------------| | Спецтехника B2B | Данные юрлиц + заявки | Да | ДПО + обезличивание ФИО ЛПР | | Строительство (субподрядчики) | Юрлица + данные работников | Частично | ДПО + обезличивание; кадровые данные — отдельно | | Оптовая торговля B2B | Юрлица + корп. контакты | Да | ДПО + стандартная политика ПДн | | Розничная e-commerce | Данные физлиц (адреса, телефоны) | С оговорками | Обезличивание + ДПО + уведомление РКН | | Автодилеры (ПТС + кредиты) | ПДн физлиц + кредитные данные | Нет для кредитов | On-prem или GigaChat Enterprise; 395-1 ФЗ + 353-ФЗ | | Медицина | Медицинские данные | Нет | On-prem + МИС + ЕГИСЗ | | Банки | Банковская тайна | Нет | On-prem + требования ЦБ | | Госзакупки с гостайной | Сведения ограниченного доступа | Нет | ФСТЭК/ФСБ сертификация | ## GigaChat Enterprise: когда он действительно нужен GigaChat Enterprise — не «импортозамещение ради галочки», а реальный production-вариант для сценариев из красной зоны. [Официальная страница b2b.giga.chat](https://b2b.giga.chat/) описывает три формата развёртывания: облако Сбера, гибрид (данные на серверах клиента, модель в приватном облаке Сбера), локальная установка на мощностях клиента. Гибридный формат — наиболее распространённый для compliance-sensitive B2B: данные физически не покидают периметр клиента, а модель работает в изолированном облачном сегменте. Цена вопроса: [согласно документации GigaChat API](https://developers.sber.ru/portal/products/gigachat-api), GigaChat 2 Pro стоит 500 ₽ за миллион токенов (около $5.55), что в 10–15 раз дешевле Claude Sonnet. GigaChat 3.1 Lightning — self-hosted GGUF-модель, доступная для локального запуска без API-расходов. Разрыв в качестве относительно лидирующих западных моделей на аналитических задачах реален; на задачах диспетчеризации, классификации и суммаризации на русском языке он значительно меньше. Четыре инженерных ограничения, которые стоит проверить перед production-внедрением: (1) качество function calling на длинных цепочках инструментов — документация 2026 года существенно улучшилась, но тесты на реальных сценариях остаются обязательными; (2) latency гибридного развёртывания — добавляет задержку по сравнению с прямым облачным API; (3) context window — актуальные характеристики меняются с каждым релизом, сверяться с [документацией SberDevices](https://developers.sber.ru/portal/products/gigachat-api) на момент старта проекта; (4) observability — для enterprise on-prem нужен отдельный logging-слой, который обычно не идёт из коробки. ## Договорная конструкция: минимум для запуска Неочевидная часть compliance в B2B AI — не выбор модели, а договорная структура. [Согласно практике, описанной RTM Group](https://rtmtech.ru/articles/saas-software-as-a-service/), для AI-сервисов корректная конструкция — договор возмездного оказания услуг, а не лицензионный договор: экземпляр ПО пользователю не передаётся, сервис оказывается на стороне провайдера, лицензия юридически ничтожна. Ключевой инструмент — **договор поручения обработки ПДн (ДПО)**. Он фиксирует: кто является оператором (клиент, в чьих интересах данные), кто — обработчиком (разработчик AI-сервиса), какие именно категории данных передаются, каков максимальный срок хранения. [Шаблоны ДПО для B2B-сервисов](https://b-152.ru/dogovor-na-obrabotku-personalnyih-dannyih) включают стандартные блоки, адаптируемые к конкретному проекту. Практика сопровождения ПДн показывает, что юридическая работа по оформлению ДПО и адаптации политики конфиденциальности для одного B2B-клиента обычно стоит 25–40 тыс. ₽ у специализированного юриста. Минимальный пакет, с которым можно запускать AI-агента в B2B-эксплуатацию: 1. **ДПО между разработчиком и клиентом** с перечнем передаваемых категорий данных 2. **Политика конфиденциальности клиента** с разделом об AI-обработке 3. **Уведомление РКН** (если клиент ещё не подавал — подаётся до начала обработки через Госуслуги) 4. **Уведомление конечных пользователей** о взаимодействии с AI (стандартный текст в начале чата или звонка) Дополнительно, при использовании зарубежного облачного API с любыми ПДн: процедура обезличивания с документированием того, какие поля маскируются перед отправкой, и кто несёт ответственность за полноту маскирования. ## Что меняет закон об AI (с 2027 года) В марте 2026 года Минцифры опубликовало законопроект «Об основах государственного регулирования применения технологий ИИ». [По материалам vc.ru](https://vc.ru/ai/2804069-novyj-zakon-ob-ii-v-rossii-izmeneniya-dlya-biznesa) и [разбору на Habr](https://habr.com/ru/articles/1013968/), закон рамочный, вступает в силу с 1 сентября 2027 года. Три пункта важны для команд, которые проектируют AI-системы сегодня. **Обязанность информировать.** Статья 9.1 устанавливает: компания обязана уведомить пользователя о том, что с ним взаимодействует AI, до начала взаимодействия. Это уже сейчас хорошая практика; с 2027 — правовое требование. Чат-бот, который выдаёт себя за человека, станет нарушением закона. **Реестр доверенных моделей.** Один из ключевых механизмов, который обсуждается в проекте — реестр AI-моделей, прошедших сертификацию для работы в государственных и критических информационных системах. Для частного B2B это требование может не применяться напрямую, но создаёт косвенное давление: клиенты из регулируемых отраслей будут всё чаще спрашивать о наличии сертификации. **Распределение ответственности.** Закон вводит цепочку: разработчик модели → оператор AI-системы → пользователь. Ответственность за вред, причинённый AI-выводом, распределяется «соразмерно степени вины». Для B2B AI-провайдера это означает: договор должен явно фиксировать, на ком лежит ответственность за конкретные решения системы, иначе суд будет распределять её по своему усмотрению. ## Главное - Большинство B2B AI-проектов работает с данными юрлиц — это не персональные данные по 152-ФЗ, и on-prem для них не требуется. - On-prem обязателен в четырёх сценариях: банки и финансы, медицина, госзакупки с гостайной, необезличенные данные физических лиц. - Для серой зоны (деловые контакты, записи звонков, адреса доставки) достаточно ДПО + обезличивания + уведомления РКН — облако работает законно. - Штрафы за утечку выросли до 500 млн ₽, но само по себе использование облачного AI без ПДн нарушением не является. - GigaChat Enterprise гибрид — практичный выбор для compliance-sensitive B2B; выигрывает у YandexGPT по изолированности данных, уступает Claude по качеству на аналитических задачах. - AI-закон (с 2027): уведомлять пользователей об AI-взаимодействии, готовиться к реестру доверенных моделей, фиксировать ответственность в договоре уже сейчас. ## FAQ **Что такое ДПО и чем он отличается от обычного договора?** Договор поручения обработки персональных данных (ДПО) — это обязательный документ по ст. 6 ч. 3 152-ФЗ, который заключается, когда оператор (клиент) привлекает третью сторону (разработчика AI) для обработки ПДн. В отличие от обычного NDA или договора оказания услуг, ДПО фиксирует именно правовые основания для доступа к данным, перечень обрабатываемых категорий, запрет использования данных в иных целях и срок хранения. Без ДПО разработчик AI-сервиса формально является незаконным обработчиком ПДн. **Данные юрлиц точно не персональные данные?** Точнее — не всегда. Реквизиты самой организации (ИНН, ОГРН, юридический адрес) — не ПДн. Но ФИО директора, email «ivan.petrov@company.ru», корпоративный мобильный номер конкретного менеджера — это уже информация, позволяющая идентифицировать физическое лицо. Практически это означает: обращения от юрлиц обрабатываются свободнее, но ФИО контактных лиц лучше маскировать перед отправкой в облачный API — это снимает 90% вопросов. **Обезличивание: какой минимум защищает?** Стандартный минимум для B2B AI, работающего с голосом или текстом: замена имён и отчеств на токены типа «[PERSON_1]», маскирование телефонных номеров (первые 6 цифр + маска), удаление адресов проживания. Этого достаточно, чтобы данные, отправляемые в облачный LLM, формально стали обезличенными по критериям РКН. Детальные требования к методам обезличивания установлены Приказом РКН № 996 от 5 сентября 2013 года. **Когда уведомление о взаимодействии с AI не нужно?** Сейчас — когда AI работает полностью во внутреннем контуре клиента без прямого контакта с его клиентами. Например, AI-агент, который обрабатывает входящие заявки и готовит черновики ответов для менеджера — контакт происходит между менеджером и клиентом, а не между AI и клиентом. С 2027 года, после вступления AI-закона в силу, правило об информировании станет обязательным при любом прямом взаимодействии AI с конечным пользователем. **Как проверить, что ваша текущая архитектура не нарушает 152-ФЗ?** Три вопроса для быстрой диагностики: (1) Какие категории данных физических лиц видит AI-модель до маскирования? Если ответ «никакие» — вы в зелёной зоне. (2) Есть ли подписанный ДПО с каждым клиентом, данные которого обрабатывает ваш AI? Если нет — это первоочередной риск. (3) Куда физически уходят данные при обращении к API модели — в РФ или за рубеж? Если за рубеж и среди данных есть ПДн физлиц без обезличивания — нужно уведомление РКН о трансграничной передаче. --- *Ещё по теме: [Не GigaChat против Claude. Моноархитектура против маршрутизатора](/2026/04/gigachat-yandexgpt-claude-b2b-russia-2026.html) — как выбирать LLM-стек по архитектурным, а не закупочным критериям. [Регламент как код](/2026/05/institutional-sop-executable-policy-decision-graph.html) — как превратить compliance-инструкции в исполняемые правила.* --- ## Note 25: Регламент как код: почему Notion-инструкция никогда не становится операционной политикой **URL:** https://notes.temadev.org/2026/05/institutional-sop-executable-policy-decision-graph.html **Published:** 2026-05-13 **Genre:** pattern-essay **Tags:** policy-as-code, ai-native, knowledge-management, operating-layer, decision-graph **Words:** 2551 **Summary:** Notion-регламенты не управляют операцией — они её описывают постфактум. Что меняется, когда политика становится исполняемой. # Регламент как код: почему Notion-инструкция никогда не становится операционной политикой В любой B2B-команде размером от двадцати человек есть Notion-страница «Как мы работаем». Её открывают на онбординге, проходят по диагонали, ставят галочку и больше не возвращаются. Через шесть месяцев процесс уже не такой, как на странице, а через год расхождение становится системным: новые сотрудники задают одни и те же вопросы в чате, потому что страница врёт, а никто этого не отметил. В [материале PagerDuty, посвящённом определению runbook](https://www.pagerduty.com/resources/learn/what-is-a-runbook/) описывается типовой паттерн: команда без исполняемых runbook-ов в инциденте тратит первые минуты не на устранение проблемы, а на восстановление того, кто что должен делать. Регламент существует, но не управляет ничем. За этой бытовой картиной стоит структурная проблема. Корпоративный регламент в виде документа — это описание мира как он должен быть. Операционная политика — это правило принятия решения в конкретной ситуации с конкретными входными данными. Между ними не косметическая разница, а категориальная. Документ обращается к человеку и предполагает, что человек его прочитает, запомнит и применит. Политика обращается к системе и предполагает, что система её соблюдает, проверяет и фиксирует исключения. Первый формат тиражируем через копипасту. Второй — версионируем, исполняем и аудируем. Этот сдвиг выходит из узкого инженерного сегмента в массовую практику, а не остаётся эксклюзивом крупного инженерного бизнеса. Дисциплина policy-as-code, выросшая из инфраструктурного мира, доросла до уровня зрелости, при котором её можно применять к управленческим решениям. Архитектура памяти агентов даёт примитив для хранения граф-структуры этих решений. Управляемые среды исполнения для крупных языковых моделей позволяют использовать эти модели как ограниченных по политике исполнителей, а не как свободных текстогенераторов. Эти три слоя — формальные правила в коде, графовая память, контролируемая среда исполнения ИИ-моделей — совпадают к тому моменту, когда скорость принятия решений становится критичной величиной, и документ-регламент перестаёт быть первичным артефактом. ## Почему регламент как документ не работает? Документ-регламент страдает теми же тремя дефектами, что любой документ-как-источник-истины, но с операционными последствиями, которые не списываются на «устарело — обновим». Первый дефект — **разрыв между описанием и решением**. Регламент описывает шаги, политика описывает условие. Страница «как мы квалифицируем входящего лида» в Notion перечисляет пять шагов; в живой работе менеджер принимает решение «передавать ли в отдел продаж или закрывать как мусор» по семи признакам, четыре из которых не описаны нигде. Эти четыре признака — реальная политика компании. Они живут в голове у трёх старших менеджеров и передаются на онбординге устно. При уходе одного из них часть политики исчезает, и об этом узнают по росту числа жалоб. Второй дефект — **отсутствие исполнителя**. У документа нет того, кто его соблюдает. Считается, что соблюдает человек, но человек принимает решение в условиях усталости, цейтнота, неполной информации и легко конкурирующих интерпретаций. В инженерной культуре эта проблема решена давно: ни одна команда уровня Netflix или Stripe не полагается на то, что инженер «вспомнит политику безопасности». Политика выражена кодом, валидатор отвергает деплой, нарушающий её, и инженер физически не может проигнорировать правило. В операционных отделах аналогичной дисциплины почти не существует — за исключением узкого сегмента финансовых рабочих процессов, где её требует регулятор. Третий дефект — **отсутствие истории**. Регламент в Notion не помнит, когда и почему правило изменилось. Эта же проблема в инженерном мире решалась в последние 15 лет через [дисциплину commit-сообщений и ADR-документов](https://adr.github.io/), фиксирующих контекст решения в момент его принятия. Версионная история страницы есть, но она показывает diff текста, а не контекст решения. На вопрос «почему мы перестали закрывать сделки в пятницу» страница ответит словом «потому что мы решили так делать», а реальная причина — конкретный провалившийся релиз шесть месяцев назад — не зафиксирована нигде, кроме как в памяти трёх человек. При смене этих троих причина исчезает, правило остаётся как карго-культ, и через два года кто-то его молча отменяет, не зная истории. Эти три дефекта не лечатся «лучшим Notion» по той же причине, по которой не лечится документ как примитив знания в целом: они вшиты в природу документа как акта рефлексии после события. Регламент пишется тогда, когда уже принято решение, как должно быть. Политика работает тогда, когда решение ещё принимается. Чтобы перевести одно в другое, нужно изменить единицу — со страницы на правило-в-исполнении. ## Что такое исполняемая политика как артефакт Исполняемая политика (executable policy) — это правило принятия решения, выраженное в формальном языке, которое исполняется средой исполнения и порождает аудиторский след с временем, актором, входными данными и результатом. Не текст про правило, а само правило, доступное для машинной проверки. Разница укладывается в три практических критерия, которые можно проверить в любой команде: | Критерий | Регламент в Notion | Исполняемая политика | |---|---|---| | Что описывает | Мир как должно быть | Правило принятия решения | | К кому обращается | К человеку (читает + запоминает) | К системе (проверяет + фиксирует) | | Исполнение | Надежда на дисциплину | Машинное принуждение с эскалацией | | История изменений | Diff текста страницы | Контекст решения с временем и автором | | Аудит | Ручной сэмплинг | Автоматический, 100% решений | Первые три строки — категориальные; последние две — экономические и как раз объясняют, почему первые три выливаются в операционную бесполезность документа. В инженерном мире эта концепция реализована в проекте [Open Policy Agent (OPA)](https://www.openpolicyagent.org/docs/latest/), который [принят в CNCF на уровне graduated в феврале 2021 года](https://www.cncf.io/announcements/2021/02/04/cloud-native-computing-foundation-announces-open-policy-agent-graduation/), через 5 лет после запуска проекта в 2016 году и используется крупными технологическими компаниями для проверки облачных конфигураций, прав доступа Kubernetes и контрактов API. OPA задаёт язык Rego, в котором правило описывается как «при таких входных данных вернуть такое решение». Правило живёт в [репозитории на GitHub](https://github.com/open-policy-agent/opa) рядом с тестами, проходит ревью пулл-реквестом и развёртывается как любой код. У этой архитектуры есть конкретные свойства, которые отсутствуют у Notion-страницы: правило проверяется автоматически на каждом релевантном событии, его нарушение блокируется или эскалируется, история изменений живёт в коммитах с обязательным описанием. Тот же подход в виде [Sentinel у HashiCorp применён к управлению инфраструктурой](https://developer.hashicorp.com/sentinel): прежде чем Terraform создаёт ресурсы, набор политик проверяет, не нарушает ли изменение требования безопасности, расходов или соответствия. Решение «можно ли развернуть эту конфигурацию» принимается не инженером и не страницей в Confluence, а исполняемой политикой с аудиторским следом. В операционных отделах того же уровня дисциплины почти нет. Не потому что задача отличается принципиально, а потому что не было дешёвого способа описывать управленческие правила в формальном виде, доступном для машинной проверки. Управленческое правило обычно содержит ссылки на свободный текст: «эскалировать клиенту с признаками недовольства», «закрывать сделку, если шансы низкие». Раньше эти фразы было нельзя вычислить иначе, как заставить человека читать и решать. Сейчас крупные языковые модели делают этот шаг технически возможным — но именно как исполнители политики, а не как авторы. ## Граф решений как форма политики Линейный список правил перестаёт работать, как только правил становится больше 30–40. Зависимости между ними не описываются плоской таблицей: «эскалировать инцидент» зависит от типа клиента, тарифа, истории взаимодействия, текущей загрузки команды и времени суток. Это не таблица, это граф. И именно как граф решений политика становится управляемым артефактом. Графовые системы для агентной памяти, такие как [Graphiti — открытый временно́й граф знаний](https://github.com/getzep/graphiti), решают близкую задачу: фиксируют сущности, отношения и время их валидности. Тот же примитив применим к политике. Узел графа — это правило с условием и результатом. Ребро — это зависимость одного правила от другого. Двойная метка времени, как у Graphiti, отвечает на вопрос «с какого момента это правило действует и когда оно перестало действовать». Изменение правила не затирает старое — добавляет новый узел с новыми границами валидности. На вопрос «как мы решали этот случай в марте» система отвечает не догадкой, а извлечённым состоянием графа на марте. Этот сдвиг меняет саму единицу, с которой работает регламент. Документ остаётся — но как проекция графа, рендер для конкретного читателя в конкретный момент. Онбординг новичка читает «текущее состояние политики на сегодня» как сгенерированный из графа документ; аудит получает diff между двумя моментами; владелец процесса работает не с текстом, а с самими узлами и ребрами. Документ перестаёт быть источником и становится одной из возможных поверхностей чтения. ## Где это уже работает в управленческой плоскости? Узкий, но показательный сегмент, где исполняемая политика управляет операцией — финансовые рабочие процессы в крупных компаниях. Правила соответствия (compliance) описаны не страницей в Confluence, а исполняемыми правилами в системах вроде ServiceNow или внутренних оркестраторах. Заявка на договор проходит через граф проверок, каждая из которых имеет аудиторский след; отклонение фиксируется как событие; политика версионируется и пересматривается раз в квартал. Это работает по принуждению регулятора — но архитектурно то же самое применимо к любому операционному процессу, где решения принимаются часто: скидка выше порога без согласования начальника — такое же policy rule, как порог выделения ресурсов в Kubernetes-кластере. Второй кейс — инцидент-менеджмент в зрелых технических командах. Норма последних лет, отражённая в [операционных руководствах по runbook-практикам инцидент-менеджмента](https://www.pagerduty.com/resources/learn/what-is-a-runbook/), сводится к одному требованию: runbook проходит путь от описательного документа к исполняемому артефакту — связанным с триггерами, выполняемым системой и эскалирующим человеку только то, что требует решения. Шаги не пишутся в свободной форме — они описываются как набор автоматизированных действий с явными условиями перехода. Регламент инцидента превращается в исполняемый граф. Третий сегмент — корпоративные политики использования крупных языковых моделей. [Модель контекстного протокола (Model Context Protocol) от Anthropic](https://www.anthropic.com/news/model-context-protocol) сам по себе не является policy-framework — это протокол подключения модели к источникам данных и инструментам. Но он создаёт точку, в которой политика может сработать: какие серверы разрешены конкретному агенту, какие действия он может выполнять, какие фильтры наложены на данные. Именно эта слойность — протокол внизу, исполняемые правила вверху — превращает корпоративный вопрос «по каким правилам наш агент имеет право действовать» из теоретического в инженерный. Объединяет эти три сегмента одно: в каждом из них регламент в виде документа физически не справляется со скоростью и плотностью операции. Документ работает, пока решений мало и они принимаются медленно. Когда решений тысячи в сутки и они должны приниматься за секунды, документ исчезает из контура — либо как формальный артефакт без операционной нагрузки, либо целиком уступая место исполняемой политике. ## Что меняется для трёх типов читателей Для основателя на стадии 15–50 человек тест простой. Возьмите три решения, которые ваша команда принимает чаще всего — квалификацию лида, эскалацию клиента, согласование скидки — и спросите, где живёт правило. Если ответ «у нас есть страница в Notion», откройте её и сравните с тем, как реально решает старший менеджер. Если расхождение очевидно после трёх минут разговора — у вас нет операционной политики, у вас её описание шестимесячной давности. Конкретное действие: возьмите одно из этих правил и опишите его как граф — узлы условий, узлы результатов, явные исключения. Это уже политика, даже если граф пока живёт в одной таблице. Дальше — выбор между человеческим исполнением и автоматическим — становится инженерной задачей, а не управленческим спором. Для руководителя операционного блока полезен другой вопрос: какой процент решений в вашем отделе принимается «по практике», а не «по регламенту». Если ответ выше 20% — у вас есть устная политика, которой нет в письменном виде. Этот сегмент несёт двойной риск: уход носителя практики обнуляет часть политики, и аудит не может проверить её исполнение. Перевод этого сегмента в исполняемые правила имеет более высокую отдачу, чем редактура существующих документов. Начинать стоит с правил, у которых уже есть автоматический триггер — то есть с тех, где наступление условия фиксируется системой, а не человеком. Для инженера, оценивающего проект, тест третий: посмотрите, есть ли в продукте отдельный артефакт «policy» — репозиторий, рендер графа, версионная история правил с описанием контекста изменений. Если есть и он живёт как код — продукт устойчив к смене людей: правила переживают уход носителя практики, и накопленный опыт каждой итерации остаётся в системе. Если политика живёт в свободном тексте промптов и инструкций для команды поддержки — любая смена ключевого менеджера переписывает половину поведения системы, и проектная работа не накапливается. ## На что мы будем смотреть дальше Если тезис верен, в течение ближайших 12–18 месяцев в управленческом сегменте должны появиться три явления. Первое — публичные открытые наборы политик для типовых операционных решений по отраслям, аналог того, как для инженерного мира появились библиотеки готовых правил OPA для Kubernetes и облаков. Сейчас каждый бизнес пишет свою политику квалификации лида с нуля; первая попытка стандартизации станет сигналом зрелости рынка. Второе — появление продуктов, где граф политики является самостоятельным артефактом, а не модулем поверх привычного офисного стека. Это другой вид инструмента, а не «Notion с автоматизацией». Третье — рост сегмента аудита и переноса политик: когда правила компании выражены как граф, миграция между поставщиками операционных систем становится не «выгрузить документы», а «перенести граф». Появление переносимых форматов для управленческой политики скажет, что сегмент перестал быть привязан к одному вендору. Регламент как документ проживёт долго — у него есть инерция и чувство контроля у руководителей, привыкших работать с текстом. Но в той части бизнеса, где операционная скорость определяет экономику, документ уже не первичен — его место занимает исполняемая политика как самостоятельный артефакт. Первым сигналом будет не публичный манифест, а появление открытых библиотек операционных политик в одной из плотных отраслей — так, как это произошло в инженерной дисциплине, когда общие Kubernetes-политики внезапно обнаружились на GitHub в виде воспроизводимых наборов, а не внутренних wiki-страниц. Какой сегмент сделает этот шаг первым — открытый вопрос; ответ на него заметен только постфактум, по появлению переносимых форматов между вендорами. ## Главное - Корпоративный регламент в виде Notion-страницы описывает мир как должно быть; операционная политика описывает правило принятия решения в конкретной ситуации. Это два разных артефакта, и первый никогда не становится вторым автоматически. - Документ-регламент имеет три структурных дефекта: разрыв между описанием и решением, отсутствие исполнителя, отсутствие истории контекста. Все три не лечатся «лучшим Notion». - Исполняемая политика — это правило в формальном виде, которое исполняется средой исполнения с аудиторским следом. В инженерной плоскости это реализовано через policy-as-code (OPA, Sentinel); в управленческой — пока узко, но архитектурно готово. - Граф решений с двойной меткой времени заменяет линейный список правил. Документ остаётся как проекция графа, а не как источник истины. - Сдвиг наблюдается там, где скорость операции превышает скорость ручной интерпретации регламента: финансовое соответствие, инцидент-менеджмент, политики использования агентов. Первый отраслевой сегмент, где это станет нормой, окажет большее влияние на рынок операционных инструментов, чем любой обобщённый прогноз в тех же границах. ## FAQ **Чем исполняемая политика отличается от хорошо написанного регламента?** Регламент описывает, как должно быть и предполагает, что человек его прочитает и применит. Политика выражена в формальном языке, исполняется средой и фиксирует каждое решение с временем и входными данными. Разница не в качестве текста, а в том, кто является исполнителем. **Нужно ли переписывать все Notion-страницы в исполняемый вид?** Нет. Документы остаются полезными как референс и обучающий материал. Переводить в исполняемый вид нужно те правила, где решение принимается часто (10+ раз в день), быстро (быстрее 60 секунд на решение) и имеет проверяемый результат. На практике это не все сотни внутренних регламентов, а узкий поднабор «горячих» правил, вокруг которых разбивается основное операционное время команды. **Как понять, что у нас есть ±устная политика», не отражённая нигде?** Простой тест: выберите 5 частых решений (эскалации, скидки, обработка жалоб, приоритизация заявок) и попросите двух старших менеджеров отдельно описать, как они принимаются. Если расхождение выше 30% хотя бы по 2 из 5 — у вас есть устная политика, и это норма, а не исключение. **Как это совместимо с ИИ-агентами?** Исполняемая политика отвечает на вопрос «что агенту разрешено делать в этом контексте» — без неё агент либо работает в свободном режиме и иногда уходит в поведение, которое никто в компании не планировал, либо блокируется жёсткими входными фильтрами и перестаёт быть полезным. Рабочая промежуточная форма — явный граф политики, в котором агент является одним из исполнителей, а не единственным носителем правил. **Где живёт это в бизнес-модели?** Соседний сюжет — в разборе [service-as-software](https://notes.temadev.org/2026/05/service-as-software-vertical-ai-revenue-model.html): когда выручка билингуется за исход, а не за лицензию, исполняемая политика становится опорной точкой, в которой провайдер отвечает за SLA, а не за факт доступа. --- ## Note 26: Service-as-software: как агенты переписывают формулу выручки в B2B **URL:** https://notes.temadev.org/2026/05/service-as-software-vertical-ai-revenue-model.html **Published:** 2026-05-12 **Genre:** market-deep-dive **Tags:** service-as-software, vertical-ai, pricing, b2b, revenue-model, saas-squared **Words:** 2572 **Summary:** Новый класс B2B-выручки: ценообразование за результат, а не за лицензию. Что меняется в экономике, кто уже на $100M+ ARR и куда уходит маржа. # Service-as-software: как агенты переписывают формулу выручки в B2B В марте 2026 года Жюльен Бек из Sequoia опубликовал статью «Services: The New Software», к которой за два месяца публично вернулись Y Combinator в RFS Summer 2026 и Bessemer в AI Pricing Playbook: на каждый $1 расходов корпоративного бизнеса на программное обеспечение приходится примерно $6 на людей, которые делают сервис, поддерживаемый этим программным обеспечением ([Julien Bek, Sequoia Capital - Services: The New Software, 5 March 2026](https://sequoiacap.com/article/services-the-new-software/)). До 2026 года инструментальный слой ($1) брали поставщики SaaS, сервисный слой ($6) - операторы, агентства, штатники. Vertical AI впервые в истории корпоративного программного обеспечения претендует на оба слоя одной транзакцией - и это та часть тезиса, которую Sequoia формулирует как верхний потолок, а не центральный прогноз. Это смена правил, по которым продукт извлекает выручку: не лицензия на инструмент, а оплата за результат работы, выполненной агентом на стороне поставщика. Y Combinator в Summer 2026 Request for Startups ставит ту же рамку - буквальная формулировка с открывающей страницы: «AI has stopped being a feature and started being the foundation» ([Y Combinator, Requests for Startups, Summer 2026](https://www.ycombinator.com/rfs)). В английской терминологии это закрепилось как service-as-software (SaaS2, SaS); по-русски - модель, в которой агент продаёт результат, а не инструмент. ## Сдвиг, который пока называют не своим именем Service-as-software чаще всего описывают как «следующее поколение SaaS» - удобная, но обманчивая формулировка. Меняется ценностная единица: SaaS продаёт лицензию на инструмент и выставляет счёт за seat; service-as-software продаёт завершённую работу и выставляет счёт за outcome - закрытое обращение, оформленную декларацию, забронированную встречу. В классическом SaaS поставщик отвечает за работоспособность инструмента - ответственность за результат лежит на клиенте. В service-as-software поставщик принимает на себя стоимость вычислений, ошибки и интеграцию - в обмен на цену, анкорованную против стоимости труда, а не инструмента. Bessemer формулирует это короче: «По мере перехода от consumption через workflow к outcome-pricing вы принимаете больший риск по себестоимости в обмен на более плотное совпадение с ценностью» ([Bessemer Venture Partners, AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook)). 92% AI-компаний, по данным того же отчёта, уже работают в смешанных моделях, где база подписки сочетается с usage- или outcome-компонентом. Та же оптика звучит и в публичных материалах руководства Y Combinator: десятки вертикалей - здравоохранение, юриспруденция, финансы, страхование, compliance, логистика, customer service - пока находятся в single-digit проникновении AI, а расходы на труд в каждой исчисляются $100B+ в год ([Y Combinator RFS Summer 2026](https://www.ycombinator.com/rfs)). Победитель в такой вертикали - не «SaaS-юникорн с $100M ARR», а значимая доля сервисного слоя индустрии, перепрошитая под экономику программного обеспечения. ## Что показывают компании, которые уже играют по новым правилам К маю 2026 года в публичных данных есть четыре опорных кейса, которые показывают, как меняется формула выручки на практике. Harvey, юридический AI, дошла от нуля до $195M ARR за 36 месяцев ([Sacra, Harvey at $195M ARR](https://sacra.com/research/harvey-at-195m-arr/)). Чек - $1 200-$2 500 на одного юриста в месяц, минимум 20 рабочих мест, двенадцатимесячный контракт. Это формально per-seat, но ценовой якорь - не «лицензия на программное обеспечение». Якорь - 5-7% от стоимости рабочего времени associate в крупной юридической фирме. Если AI-инструмент стоит как 5% от человека, которого он частично заменяет, $14 000 за рабочее место в год становятся не дорогими, а очевидными. По данным того же Sacra-профиля, Harvey движется в сторону revenue-share: доля с billable hours, выставленных клиентам через AI ([Sacra, Harvey at $195M ARR](https://sacra.com/research/harvey-at-195m-arr/)). Это переход от per-seat к outcome без отказа от первого. Sierra, AI для customer support, собрала $100M ARR на чистой outcome-модели: оплата только за разрешённое обращение, сохранённую подписку, состоявшийся апсейл ([Sierra, Outcome-based Pricing](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents)). Стартовый контракт - $150 000 в год, с расширением до $1M+ при многоканальной голосовой интеграции. Sierra доказала, что в узком домене с измеримым исходом можно совсем отказаться от seat. Но даже у Sierra модель смешанная: для рутинной маршрутизации обращений действует per-conversation, для ценных разрешений - per-resolution. Чистый outcome-pricing - миф, к которому индустрия стремится, но в производственном развёртывании всегда живёт гибрид. Intercom Fin - самая чистая иллюстрация принципа: $0.99 за разрешённое обращение, никаких seat-fee ([Intercom Pricing](https://www.intercom.com/pricing)). Outcome определён однозначно: Fin закрыл тикет без передачи человеку. Bessemer использует Fin как эталонный пример совпадения ценообразования с ценностью. Glean показывает противоположный паттерн - расширение поверх классического SaaS, а не замена ему. База $45-50 на пользователя в месяц, надстройка Work AI за $15, отдельный SKU за governance, новый consumption-billing для агентных нагрузок поверх per-seat. Результат: $100M → $200M ARR за 9 месяцев, оценка $7.2B ([Futurum Group on Glean](https://futurumgroup.com/insights/glean-doubles-arr-to-200m-can-its-knowledge-graph-beat-copilot/)). Прикладное следствие: устойчивый SaaS может не ломать существующую модель, а добавлять новые ценовые слои сверху — без перехода на чистый outcome-pricing. Между четырьмя кейсами есть общее, и оно фиксируется по их же публичным материалам ([Sacra Harvey](https://sacra.com/research/harvey-at-195m-arr/), [Sierra outcome-pricing](https://sierra.ai/blog/outcome-based-pricing-for-ai-agents), [Intercom pricing](https://www.intercom.com/pricing), [Futurum on Glean](https://futurumgroup.com/insights/glean-doubles-arr-to-200m-can-its-knowledge-graph-beat-copilot/)). Никто из них не продаёт «AI-инструмент». Harvey продаёт замещение стоимости юриста, Sierra - закрытое обращение, Intercom - разрешённый тикет, Glean - слой корпоративного знания. Каждая компания смогла объяснить клиенту единицу ценности, против которой выставляется счёт, и привязать её к показателям, которые клиент уже считает внутри своей отчётности. ## Почему формула «5-7% от стоимости труда» меняет калькуляцию? В классической экономике корпоративного программного обеспечения цена продукта анкорилась против цены другого продукта. Salesforce стоил против Siebel, потом против HubSpot. Потолок задавался не «сколько ценности», а «сколько готов платить клиент относительно альтернативного программного обеспечения». Это давало 80-90% валовой маржи, потому что предельная стоимость дополнительной лицензии стремилась к нулю. В service-as-software цена анкорится против стоимости труда, который продукт замещает. Это поднимает потолок: годовой бюджет на двадцать associate в крупной юридической фирме при базе $250-400 тыс. в год на человека - это $5-8M, и $300 000 за инструмент, который реально снимает 15-20% их операционной нагрузки, выглядит дёшево. Но это же опускает валовую маржу: AI-first компании работают на 50-60%, а не на 80-90% ([Bessemer AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook)). Себестоимость вычислений вернулась в баланс. Следствие, которое часто пропускают: в SaaS underpricing вреден, но в service-as-software он смертельно опасен. Поставщик берёт на себя стоимость inference, ошибки, дообучения и поддержки рабочего процесса. Один power-user, который генерирует 10x ожидаемого объёма outcome, способен в один квартал увести юнит-экономику в отрицательную зону. Replit в 2025 году публично прошёл через колебания валовой маржи от 36% до минус 14% за два месяца ([Sacra, Replit profile](https://sacra.com/c/replit/)); GitHub Copilot при базовой цене $10 терял до $20 на среднем пользователе и до $80 на heavy-user, что привело к переходу на usage-based pricing в 2026 ([DevOps.com, GitHub resets Copilot pricing](https://devops.com/github-resets-copilot-pricing-as-ai-compute-costs-surge/)). Каждый кейс - не сбой стартапа, а структурное следствие новой модели. Net revenue retention 130%+, который по бенчмаркам [Bessemer](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook) относится к top decile в классическом SaaS, в выживших service-as-software компаниях становится не идеалом, а условием существования. Harvey демонстрирует 290% YoY роста по данным Sacra - траектория, типичная для service-as-software: от per-seat к revenue-share, от ассистента к workflow-платформе по мере углубления в клиентскую операцию. ## Где эта рамка ломается и кто проигрывает Консенсус Sequoia / YC / Bessemer выглядит ровным, но у него есть три уязвимые точки, которые часто опускают в венчурных текстах. **$1:$6 - это верхний потолок, а не центральный прогноз.** Sequoia осторожно подчеркивает это в своём же материале ([Bek, Services: The New Software](https://sequoiacap.com/article/services-the-new-software/)): реальный capturable share зависит от того, насколько глубоко поставщик входит в операцию клиента. В большинстве вертикалей сервисный слой не сжимается до нуля - AI ассистирует человеку, а не замещает его полностью. Реалистичный диапазон захвата для удачной AI-первой компании в 2026 году - не «6× software-рынок», а порядка 1.2-2× software-бюджета вертикали. Это всё равно огромный рынок, но венчурная презентация с множителем «×6» в слайде TAM обычно разбивается о первый квартал продаж. **Риск, переданный поставщику, не нравится крупным клиентам.** В регулируемой отрасли CFO неохотно подписывает контракт, в котором внешняя система отвечает за исход операции. В страховании, медицине, финансах compliance-команды требуют человеческого надзора как условие закупки - это возвращает гибрид к per-seatу и снижает долю outcome-компонента в итоговом чеке. Регулятор страхового рынка ЕС в обзоре генеративного AI 2025 года прямо фиксирует доминирование human-in-the-loop как нормы в страховой индустрии ([EIOPA Generative AI EU Market Survey - разбор RPC Legal](https://www.rpclegal.com/thinking/financial-services-regulatory-and-risk/generative-ai-eu-market-survey-key-takeaways-from-eiopas-report/)). Крупный юридический, финансовый и медицинский enterprise подписывает service-as-software медленнее, чем ожидает венчурная форвард-проекция. **Три условия удачи редко выполняются одновременно.** Модель работает, когда клиент уже мерит исход в своём дашборде, стоимость замещаемой операции достаточно высока, чтобы окупить себестоимость inference, и поставщик финансово выдерживает первоначальный период отрицательной маржи на heavy-userах. В большинстве сделок хотя бы одно из условий отсутствует - и «outcome-pricing» в контракте превращается в слайд о будущем, а счёты выставляются по usage с минимальным консьюмпшеном. Проигрывают в этой модели три категории. Универсальные «AI-агенты» без вертикальной экспертизы зажаты между управляемыми платформами гиперскейлеров и узкими отраслевыми продуктами. Классический per-seat SaaS, который не успел нарастить consumption-billing поверх своей подписки, проигрывает в renewals к концу 2026 - 92% AI-компаний уже работают в гибридах, по данным того же [Bessemer AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook). Консалтинговые контракты по «AI-трансформации», которые заканчиваются отчётом, а не выходят в продукт внутри операции клиента, не замыкают петлю «решение → исход» и не накапливают защиты поверх лицензионного слоя — подробнее этот механизм разобран в [«Trajectory Data: the Decision→Outcome Loop Moat»](/notes/trajectory-data-decision-outcome-loop-moat/). ## Где компаундирующая защита - и почему универсальная обвязка её не даёт Это и есть та граница, которая отделяет vertical AI с устойчивой выручкой от стартапов, делающих «универсального AI-агента» и упирающихся в потолок на $1-3M ARR. Вертикальные AI-платформы воспроизводят паттерн, который раньше дал Veeva в фармацевтике, Procore в строительстве, ServiceTitan в сервисном бизнесе. Veeva в продуктовой развёртке Vault AI встраивает агентов прямо в отраслевые модули ([Veeva Vault AI](https://www.veeva.com/products/vault/ai/)) - это сигнал, что отраслевой SaaS не намерен отдавать сервисный слой горизонтальным игрокам. NFX в анализе data network effects формулирует условие устойчивости: данные должны быть автоматически захвачены при использовании продукта, давать видимое клиенту улучшение, иметь высокий порог входа для конкурента и медленную асимптоту насыщения ([NFX, The Truth About Data Network Effects](https://www.nfx.com/post/truth-about-data-network-effects)). Большинство B2B-компаний этот тест не проходят: они собирают данные, но улучшение продукта происходит вручную, а не непрерывно. Закрытая петля «решение → исход» в конкретной операционной среде - это то, что нельзя восстановить ретроспективно из логов. Через 12 месяцев работы внутри одного клиента у поставщика накапливается доменная модель данных, набор воспроизводимых решающих правил и история фактических исходов под каждым решением - три слоя, которые в академической литературе и индустрии обозначаются как domain model, business logic и outcome history. Это и есть compounding switching cost: горизонтальная обвязка не может воспроизвести их без аналогичного срока работы внутри той же операции. Универсальный AI-агент, который ставится из конфига за один спринт, в эту защиту не попадает. Он сжимается между управляемыми платформами от Anthropic, OpenAI, AWS и узкими отраслевыми продуктами с собственным системным учётом, регуляторным контекстом и многолетними данными. Средний слой исчезает - и у большинства горизонтальных агентных продуктов нет ответа на этот сжимающийся спред. ## Где это работает, где нет, и что важно проверить до контракта У service-as-software есть условия применимости, и три из них определяют, работает ли модель в конкретной вертикали. Первое условие — измеримый исход. Регулятор страхового рынка ЕС в обзоре генеративного AI 2025 года ([EIOPA — разбор RPC Legal](https://www.rpclegal.com/thinking/financial-services-regulatory-and-risk/generative-ai-eu-market-survey-key-takeaways-from-eiopas-report/)) и McKinsey в State of AI 2025 ([Global Survey on AI](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)) фиксируют одно и то же: в регулируемых сервисах человеческий надзор остаётся доминирующим, а галлюцинации — главным цитируемым риском. Compression цены подтверждена в узких доменах с однозначным правильным ответом (поддержка, бронирования, рутинные документы) и не подтверждена там, где исход размыт или требует регуляторного одобрения. Второе условие — клиент уже считает этот исход. Bessemer в AI Pricing Playbook прямо фиксирует: outcome-pricing работает там, где выбранный value metric уже входит в публичную отчётность клиента ([Bessemer AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook)). CFO, который мерит «разрешённые тикеты» или «выигранные тендеры» до того, как поставщик пришёл, — это правильный value metric. Если единицу измерения нужно изобретать вместе с продуктом, цикл сделки удлиняется, а отказ становится дешёвым. Третье условие — достаточная маржа в операции, чтобы было что замещать. Bek в том же Sequoia-эссе осторожно отмечает: дисраптить работу за $50 в час сложно, замещать работу за $500 в час — оправдано ([Bek, Services: The New Software](https://sequoiacap.com/article/services-the-new-software/)). На нижнем краю операционной экономики переход в outcome-pricing не окупает себестоимость вычислений. Эти три условия складываются в практический фильтр: модель работает только при пересечении измеримого исхода, его уже существующего учёта у клиента и достаточной маржи операции. Если хотя бы одно условие отсутствует, разумнее оставаться в гибриде с большой долей фиксированной подписки и небольшой usage-надбавкой, а не запускать чистый outcome-pricing. Для руководителя, который оценивает внедрение: чем меряет себя поставщик в публичных кейсах? Если только «сэкономленные часы» - это эффект первого года в горизонтальной обвязке. Если в SLA фигурирует измеримый бизнес-результат, привязанный к финансовой отчётности клиента, - это другая категория контракта, и она требует другой due diligence. С инженерной точки зрения главный технический риск — отсутствие фиксации decision traces с первого дня. Связка «решение → исход» — архитектурное решение, которое нельзя добавить позже; без неё через 12 месяцев у компании будут логи, но не будет компаундирующей защиты. Именно такие контуры — берём один измеримый процесс и собираем вокруг него систему, которая ведёт его сама и копит decision traces с первого дня, — мы и делаем как рабочие системы, а не пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=service-as-software-vertical-ai-revenue-model&utm_content=inprose). ## Главное - **$1:$6 - это не метафора.** Sequoia формализовала: software-слой и services-слой исторически делили выручку 1 к 6; service-as-software забирает оба одной транзакцией. Это смена правил захвата, а не следующее поколение SaaS. - **Цена анкорится против труда, не против программного обеспечения.** Это поднимает потолок ($150K-$1M+ годовых контрактов на одного клиента) и опускает валовую маржу до 50-60%. Underpricing в этой модели смертелен. - **Чистый outcome-pricing - миф.** Harvey, Sierra, Intercom Fin, Glean - все работают в гибриде: база + usage или outcome поверх. 92% AI-компаний уже не на чистом per-seat. - **Средний слой исчезает между двумя полюсами.** Сверху давят отраслевые платформы (Veeva, Procore, ServiceTitan) с собственным AI; снизу - управляемые среды исполнения от гиперскейлеров. Универсальный AI-агент сжимается между ними за 18 месяцев. - **Компаундирующая защита — в закрытой петле решение→исход.** Доменная модель, воспроизводимые решающие правила и история фактических исходов накапливаются только изнутри операционной среды клиента. Горизонтальный конкурент воспроизводит их либо годами работы внутри той же операции, либо никак. ## FAQ **Чем service-as-software отличается от обычного SaaS с AI-фичами?** Единицей выставления счёта. SaaS берёт деньги за доступ к инструменту; service-as-software - за выполненный исход. Это переносит операционный риск на поставщика и анкорит цену против стоимости человеческого труда, а не против стоимости альтернативного программного обеспечения. **Можно ли запустить service-as-software без отказа от подписки?** Да, и это безопаснее. Glean показал паттерн расширения: per-seat остаётся ядром, поверх него добавляются SKU за AI-возможности, потом - consumption-billing за агентные нагрузки, потом - отдельные модули за governance. Это даёт NDR 130%+ без слома существующих контрактов. **Где outcome-pricing не работает?** Там, где исход неоднозначен, регулятор требует человеческого надзора или маржа исходной операции ниже $50 в час. Compression цены подтверждена в support, бронированиях, рутинных документах; не подтверждена в стратегических решениях, регулируемой медицине, сложных трансформациях. **Что должен накопить продукт за первые 12 месяцев, чтобы не быть заменимым?** Три базовых слоя из обычной software-инженерии, но привязанные к конкретному клиенту: domain model (какими сущностями оперирует бизнес и как они связаны), business logic (исполнимые правила решений, эскалаций, ценообразования) и outcome history (история фактических исходов под каждым решением с контекстом момента). Порознь берётся любым SaaS-продуктом, вместе они воспроизводимы только внутри той же операции. --- ## Note 27: Кейсы AI-агентов измеряют сэкономленные часы. Маржа уходит выше **URL:** https://notes.temadev.org/2026/05/agent-cases-margin-operating-layer.html **Published:** 2026-05-08 **Genre:** contrarian-take **Tags:** ai-agents, b2b, vertical-ai, operating-layer, margin **Words:** 2320 **Summary:** Как отличить продукт в массовой обвязке от продукта в операционном слое бизнеса. Три теста и три сигнала 2026 года. # Кейсы AI-агентов измеряют сэкономленные часы. Маржа уходит выше ## Что показывают публичные ROI-кейсы и что они скрывают? За последние девять месяцев индустрия получила первый качественный набор измеримых результатов от платформ для агентной автоматизации. На странице клиентов [Activepieces](https://activepieces.com/customers) Alan заявляет о более чем 6 300 сохранённых часах в год и трёхстах с лишним рабочих сценариях; Funding Societies — о ста с лишним сценариях в восьми департаментах. На странице кейсов [n8n](https://n8n.io/case-studies) Flow AI рапортует о сокращении исходящих касаний с 3–5 часов до менее минуты, Field Aerospace переводит подготовку коммерческого предложения из двух недель работы команды в 25 минут, Formula Bot уменьшает срок добавления нового коннектора с недели до полутора дней. Это не маркетинговые лозунги — реальные операторы согласились публиковать цифры с именами и должностями. Если смотреть на эти кейсы не отдельно, а как на карту рынка, проступает другой узор. Все они решают одну задачу — ускоряют существующие горизонтальные процессы. И все выстраиваются в один и тот же ценовой и архитектурный класс. Потолок этого класса виден. ## Где заканчивается стандартная среда исполнения и начинается отраслевой продукт Различим три рабочих понятия, без которых разговор про слои размывается. Стандартная среда исполнения агента — слой с унифицированными интерфейсами: цикл сессии, маршрутизация инструментов, память, изолированная песочница, разворачивание. К маю 2026 года он перестал быть инженерным проектом и стал готовым продуктом у всех крупных провайдеров. Anthropic в [инженерном посте про управляемые агенты](https://www.anthropic.com/engineering/managed-agents) формулирует это прямо: предположения, зашитые в обвязку агента, устаревают вместе с моделями, и поэтому компания упаковывает оркестрацию в стабильные интерфейсы поверх сменяемого исполнения. The New Stack в [разборе релиза](https://thenewstack.io/with-claude-managed-agents-anthropic-wants-to-run-your-ai-agents-for-you/) описывает сдвиг от модели к модели плюс готовая оркестрация как продукту провайдера. Отраслевой SaaS-продукт — другой полюс: продукт со своими экранами, отчётами, ролями, встроенными требованиями регулятора и многолетним операционным контекстом. Veeva для фармы, Procore для стройки, ServiceTitan для сервисного бизнеса. Veeva в продуктовой [развёртке Vault AI](https://www.veeva.com/products/vault/ai/) описывает, как встраивает агентные сценарии прямо в отраслевые модули — это сигнал, что вертикальные игроки видят угрозу снизу и начинают двигаться навстречу. Между этими двумя полюсами есть промежуточный слой, который в публичных кейсах почти не виден. Это уровень, на котором агентная система перестаёт быть «лучше Zapier» и становится способом, которым организация фактически работает: операционный слой бизнеса (operating layer). На карте маржи именно туда смещается ценность по мере того, как стандартная среда становится массовой. ## Что Alan, Flow AI и Field Aerospace на самом деле сделали Если разобрать публичные кейсы по слоям, получается следующая картина. Alan развернул на Activepieces платформу для внутреннего обеспечения сотрудников. Цифры впечатляют, но вся работа происходит в горизонтальной плоскости: автоматизация HR-онбординга, синхронизация задач между корпоративными инструментами, эскалации в чатах. Это не отраслевая модель медицинского страхования — это родовая сантехника, которая ускоряет существующие процессы, но не переописывает их. Сама компания подчёркивает логику обеспечения: «300+ сценариев, 200+ внутренних авторов» означает, что цель была дать сотрудникам инструмент, а не построить специализированную операционную систему страхового продукта. Flow AI — стартап в дистрибуции страховых продуктов. Их голосовые исходящие касания действительно дают радикальное сжатие времени: 3–5 часов превращаются в 60 секунд. Но если посмотреть, на чём построены касания, это связка из ElevenLabs, веб-хуков, Postgres, n8n и SMS/email-провайдеров. Качественная горизонтальная сборка. Слой, на котором Flow AI становится незаменим для брокеров — отраслевая модель оценки рисков, история взаимодействия с конкретными типами клиентов, политики комплаенса для разных юрисдикций — в публичной презентации не виден. Не потому что его нет, а потому что не он там измеряется. Field Aerospace сократил подготовку коммерческого предложения с двух недель до 25 минут и снял около 30 000 долларов годовых затрат на программное обеспечение. Цифры серьёзные. Но это автоматизация документального процесса — извлечение, форматирование, сборка. Под этим слоем лежит специфика аэрокосмических контрактов: регуляторные требования, история ценообразования, специфическая структура спецификаций, партнёрские договорённости. Эта специфика в кейсе не видна. Видна только верхняя горизонтальная аппликация. Formula Bot ускорил добавление нового коннектора с недели до полутора дней. Это операционная победа платформенной команды, не отраслевая защита. Если завтра OpenAI Connector Registry выпустит официальный SAP-коннектор с лучшей надёжностью, ценность собственной интеграционной полки начнёт оседать. Все четыре кейса — честная работа с измеримым результатом. Но они отвечают на один вопрос: как ускорить существующие процессы. И не отвечают на другой: что становится защищённым активом за горизонтом 18 месяцев, когда стандартная среда исполнения станет массовой. ## Три уровня защиты и куда смещается маржа Полезно ввести явное разделение слоёв. На каждом из них живёт разный класс продукта и разный класс конкуренции. | Слой | Что это | Горизонт защиты | Кто здесь играет | |---|---|---|---| | Стандартная среда исполнения | цикл сессии, маршрутизация инструментов, память, песочница | 6–18 месяцев до выхода управляемого аналога | n8n, Activepieces, OpenHands, Anthropic Managed Agents, AWS AgentCore | | Операционный слой | онтология предметной области, политика принятия решений, следы решений конкретной организации | годы; невозможно воссоздать ретроспективно | специализированные интеграторы и вертикальные AI-продукты | | Отраслевой SaaS | полный продукт отрасли с продажами, комплаенсом, экосистемой | десятилетия | Veeva, Procore, ServiceTitan и их аналоги | Публичные кейсы живут в первом слое. Их экономия впечатляет, потому что сравнение идёт с ручным трудом и устаревшими инструментами; в этой системе координат любой грамотно собранный сценарий выглядит как прорыв. Но горизонт жизни этого преимущества короткий. Anthropic уже [явно пишет](https://www.anthropic.com/engineering/managed-agents), что предположения обвязки устаревают вместе с моделями, и сама же выпускает управляемую альтернативу. n8n и Activepieces встраивают MCP-серверы и конструктор агентов в ядро. То, что год назад требовало месяца сборки, через год будет ставиться из конфига. Отраслевой SaaS — третий слой, куда нельзя зайти из горизонтального проекта без отраслевой команды, многолетнего опыта продаж и собственного продуктового цикла. Операционный слой — средний слой, куда публичные кейсы не заходят: это требует отказа от логики «универсальное решение для всех» и согласия на меньший потенциальный рынок ради более глубокого контроля над одним конкретным процессом. ## Откуда берётся накопительное преимущество Операционный слой держится на трёх вещах, которые не упаковываются в управляемый продукт. Первое — модель предметной области (domain world model). Это онтология с конкретными сущностями, их состояниями, валидными переходами и исключениями. Не «у вас есть документы про X», а «в этой организации сущность A может перейти в состояние B только если выполнены условия C, D, E, и сотрудник X не может одобрить переход без подтверждения от Y». Поисковые системы вроде Glean знают, что в компании есть документы. Они не знают, что партнёры определённого типа требуют иного порядка согласования, что обращения определённой категории клиентов требуют немедленной эскалации, а не стандартной очереди. Эта разница между корпусом документов и операционной моделью — фундаментальная. Второе — институциональное знание как исполнимая политика. Это превращение неформализованных знаний в граф решений: когда запускать повторное касание, правила скидки до определённого порога без эскалации, триггеры эскалации по типу клиента. Все эти решения, которые в традиционной компании живут «в головах сотрудников» и в разрозненных документах, в операционном слое становятся явным, исполнимым уровнем. Это не данные и не код, это кодифицированная логика принятия решений, которая отделяет компанию от конкурентов внутри той же отрасли. Она объясняет, почему две компании в одной нише с одинаковой обвязкой и одинаковой моделью получают разный операционный результат. Третье — следы решений (trajectory data). Закрытый цикл «решение → исход» в конкретном контексте. Не «лог действий», а связка между принятым решением и тем, что произошло через N дней: оплатил клиент или нет, прибыло вовремя или нет, привело к сделке или нет. Эту связку нельзя восстановить ретроспективно из логов: контекст момента уже потерян. Подробнее этот компонент мы разбирали в [отдельной заметке про данные траекторий](/2026/05/trajectory-data-decision-outcome-loop-moat). Все три компонента объединяет одно: их нельзя купить или упаковать в SDK — их можно только накопить изнутри конкретной операционной среды. Управляемый продукт по определению не может конкурировать на этом слое. О том, почему именно представление, а не модель, оказывается главным барьером переключения, мы писали в [заметке про слой представления и вертикальную схему](/2026/04/representation-layer-vertical-schema). ## Почему публичные кейсы туда не идут Структура стимулов объясняет это лучше, чем намерения игроков. Activepieces и n8n — горизонтальные платформы по бизнес-модели. Им нужны кейсы, демонстрирующие универсальность: чем шире применимость, тем сильнее их позиционирование для расширения базы пользователей. Вертикальный операционный слой — анти-пример для такого позиционирования. Он показывает, что максимум ценности достигается, когда сборка делается под одну конкретную организацию или одну конкретную отрасль, а не как переиспользуемый шаблон. Alan, Flow AI, Field Aerospace, Formula Bot оптимизируют под скорость отдачи: быстрые цифры для инвестиционного цикла. Горизонтальная автоматизация даёт этот срез; операционный слой требует месяцев работы внутри домена без яркого «до и после». Наконец, провайдерская сторона рынка — Anthropic, OpenAI, AWS, Google — активно толкает управляемую обвязку как готовый продукт. К маю 2026 года стандартная среда исполнения стала массовым товаром у всех четырёх гиперскейлеров. Это значит, что публично видимая часть рынка дальше будет смещаться к ещё более горизонтальным кейсам, потому что именно там провайдерам выгодно показывать свои продукты. Операционный слой останется в тени публичной коммуникации, хотя именно туда уходит маржа. Эту разделительную линию между обвязкой и операционным слоем мы подробно разбирали в [заметке про переход обвязки в массовый товар](/2026/04/harness-commodity-operating-layer). ## Как проверить, в каком слое живёт ваш продукт Полезные тесты для двух разных аудиторий. Для основателей: если обвязку можно заменить на Anthropic Managed Agents или OpenAI AgentKit за один спринт без потери ценности — продукт в массовом слое. Если при смене среды исполнения разрушается накопленная модель предметной области, политика решений и следы решений — продукт уже в операционном слое. Второй тест: если завтра конкурент с большей командой и большим бюджетом захочет повторить продукт за 90 дней, что у него получится? Универсальный сценарий повторяется. Онтология предметной области конкретного клиента, накопленная за 12 месяцев работы внутри организации, не повторяется. Для технических руководителей, которые оценивают AI-внедрения. Если поставщик показывает кейсы только класса «X часов сэкономлено в месяц», стоит уточнить, какой слой подрядчик построил поверх горизонтальной автоматизации. Часовая экономия — это эффект первого года; через 18 месяцев он начинает выравниваться по рынку. Глубина изменения процесса — это другая категория измерения. Temporal в [документации по принципам исполнения процессов](https://temporal.io/blog/workflow-engine-principles) формулирует похожую мысль для инфраструктурного слоя: устойчивое состояние и долго живущие процессы становятся ценными там, где процесс действительно встроен в работу бизнеса, а не там, где автоматизирована отдельная задача. Второй вопрос для оценки внедрения: фиксируются ли следы решений отдельным слоем, или система пишет только логи действий. Это инженерное решение, которое нужно принимать в начале, а не добавлять задним числом. Именно так — взять один измеримый процесс и собрать вокруг него AI-контур с моделью домена, политикой решений и следами решений с первого дня — мы и строим как рабочую систему, а не пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=agent-cases-margin-operating-layer&utm_content=inprose). ## Сигналы 2026 года Три сигнала покажут, как развивается дифференциация между слоями. Если управляемые обвязки от Anthropic, OpenAI и AWS дойдут до общедоступности с встроенными вертикальными шаблонами — это означает попытку провайдеров занять операционный слой сверху, через пресеты. Сценарий маловероятный в ближайшие 12 месяцев, потому что отраслевое знание не упаковывается в шаблон, но провайдерская сторона будет пробовать. На встречные движения вертикальных игроков указывает, например, продуктовая [платформа Vault AI от Veeva](https://www.veeva.com/products/vault/ai/) — отраслевой SaaS не отдаёт операционный слой без боя. Если на n8n и Activepieces появятся кейсы, где экономика измеряется не в часах, а в процентах улучшения отраслевого исхода — например, «точность решения X выросла на Y процентов за 6 месяцев» — это будет сигналом, что операционный слой начинает становиться публично видимым. Если вертикальные SaaS-игроки уровня Veeva и Procore начнут публично анонсировать собственные среды исполнения агентов — это означает движение третьего слоя вниз, к операционному слою, и сжатие пространства для независимых вертикальных AI-продуктов. Похожую общую логику смещения ценности на стыке инфраструктуры и данных описывает [материал a16z про большие технологические идеи 2025](https://a16z.com/big-ideas-in-tech-2025/). ## Главное - Публичные кейсы AI-агентов дают честную экономию, но измеряют только горизонтальную плоскость: сокращение времени на существующие процессы. - Между стандартной средой исполнения и отраслевым SaaS существует средний слой — операционный слой бизнеса, который держится на онтологии предметной области, исполнимой политике решений и следах решений. - Этот слой нельзя упаковать в управляемый продукт: его компоненты создаются внутри конкретной организации и не воспроизводятся ретроспективно. - Маржа в категории смещается именно туда по мере того, как стандартная среда становится готовым продуктом у всех крупных провайдеров. - Тест: если продукт можно за спринт перенести на чужую управляемую среду без потери ценности, он живёт в массовом слое. ## FAQ **Чем операционный слой отличается от отраслевого SaaS?** Отраслевой SaaS — это полноценный продукт отрасли со своими экранами, отчётами, ролями, машиной продаж и десятилетним циклом накопления отраслевой экспертизы. Операционный слой — это уровень, на котором агентная система становится способом, которым конкретная организация работает: онтология предметной области, политика решений и следы решений одной компании или одной узкой ниши. Отраслевой SaaS требует капитала и команды другого порядка; операционный слой строится небольшими специализированными командами и держится за счёт глубины внедрения, а не масштаба распространения. **Почему стандартная среда исполнения считается массовой, если стартапы вокруг неё растут?** Рост стартапов на этом слое идёт за счёт расширения базы пользователей и быстрой отдачи, а не за счёт долгосрочной защиты. Anthropic в [материале про управляемые агенты](https://www.anthropic.com/engineering/managed-agents) фиксирует тезис о том, что предположения обвязки устаревают вместе с моделями. К маю 2026 года четыре крупнейших провайдера выпустили управляемые аналоги. Это не отменяет рост категории, но смещает источник маржи выше по стеку. **Когда операционный слой не имеет смысла строить?** Когда задача действительно горизонтальная — общие исходящие касания, обработка документов без отраслевой специфики, синхронизация задач между корпоративными инструментами. В таких сценариях глубина операционного слоя избыточна, и горизонтальная сборка даёт лучшую экономику. Операционный слой оправдан там, где есть устойчивая предметная область с собственной онтологией и регуляторными или операционными ограничениями. **Сколько времени занимает построение операционного слоя?** По открытым отраслевым материалам первая устойчивая версия онтологии и явной политики решений появляется обычно в горизонте от полугода до года активной работы внутри домена. Следы решений — самостоятельная категория, требующая отдельной инженерной работы; их накопительный эффект проявляется после нескольких месяцев замкнутого цикла «решение → исход». **Как отличить кейс операционного слоя от хорошо упакованной горизонтальной сборки?** Главный маркер — что измеряется в результатах. Горизонтальная сборка измеряет сэкономленные часы и сокращение цикла существующего процесса. Операционный слой измеряет качество принимаемых решений в домене и устойчивость этого качества при смене модели или среды исполнения. Если кейс не показывает второй тип метрик, скорее всего, он живёт в горизонтальной плоскости. --- ## Note 28: Память больше документа: что заменяет Notion в ИИ-нативной команде **URL:** https://notes.temadev.org/2026/05/memory-beats-document-ai-native-team.html **Published:** 2026-05-07 **Genre:** concept-piece **Tags:** memory, ai-native, knowledge-management, agents **Words:** 2385 **Summary:** Почему документ структурно проигрывает агентной памяти и что приходит на его место в ИИ-нативной команде. # Память больше документа: что заменяет Notion в ИИ-нативной команде ## Notion хранит то, что вы решили записать В январе 2026 года [Sentra привлекла $5 млн от a16z speedrun и Together Fund](https://siliconangle.com/2026/01/28/sentra-app-raises-5m-build-ai-teammate-organize-enterprise-memory/) под заявку «организационная память», в феврале [Glean поднял Series F при оценке $7,2 млрд](https://www.glean.com/blog/glean-series-f-announcement) с переименованием продукта из «корпоративного поиска» в «систему контекста», в октябре 2025-го [Mem0 закрыл $24 млн Серии A](https://www.prnewswire.com/news-releases/mem0-raises-24m-series-a-to-build-memory-layer-for-ai-agents-302597157.html) под универсальный слой памяти для агентов. Три раунда подряд под одну категорию, которая ещё в 2024-м году в инвестиционных дек-ах называлась «ИИ-документация». За этим стоит признание того, что центральная единица корпоративного знания меняется — с документа на запись о произошедшем. Notion хранит то, что вы решили записать. Агентная память хранит то, что произошло, даже если никто ничего не писал. Разница между этими режимами фиксации определяет, какая команда сможет поддерживать знание актуальным при росте, а какая — нет. ## Что сломано в документе как примитиве знания Документ — это снимок состояния, сделанный человеком в момент рефлексии. У этого примитива три встроенных дефекта, которые невидимы при размере команды до 10 человек и становятся фатальными при 50. Первый дефект — **временная мёртвая точка**. Документ не знает, когда он перестал быть правдой. В Notion-странице «как мы делаем онбординг клиента» нет поля «действителен до». Решение об изменении процесса принимается в чате, фиксируется в звонке, иногда оседает в карточке задачи — но обновление документа требует отдельного волевого акта от того, кто помнит, что такая страница существует. Бенчмарк [LongMemEval](https://arxiv.org/abs/2410.10813), опубликованный исследователями из университетов Альберты и Калифорнии Сан-Диего, формализовал эту проблему через 5 категорий провала памяти у языковых моделей (одна сессия, несколько сессий, обновление знания, рассуждение во времени, воздержание от ответа); обновление знания — категория, в которой система не умеет понять, что новый факт отменил старый, и в которой даже передовые модели показывали падение точности на 30+ процентных пунктов относительно более простых задач извлечения. Документ страдает тем же — но без диагностики. Второй дефект — **отсутствие трассировки от операции**. Документ не знает, откуда он взялся. У страницы про процесс продаж нет ссылки на конкретные сделки, которые привели к её появлению. У описания архитектуры нет связи с коммитами, которые её реализовали. Знание, оторванное от операции, превращается в фольклор — оно правдиво ровно настолько, насколько правдиво помнит автор в момент написания. Третий дефект — **ручной режим записи**. Документ существует только если кто-то нашёл время его написать. На малых командах это компенсируется тем, что писать есть кому и когда. На средних — превращается в постоянный долг, в котором половина страниц устарела, а другая половина не существует, потому что у людей не было свободного часа в календаре. [Карпатый в своих публичных рассуждениях о языковой модели как операционной системе](https://karpathy.medium.com/software-2-0-a64152b37c35) формулирует это от обратного: память должна быть полноправным примитивом, а не побочным продуктом работы. Документ-как-примитив этому требованию не соответствует, потому что предполагает, что между событием и его фиксацией всегда стоит человек с клавиатурой. Эти три дефекта не лечатся «лучшим Notion». Лучший Notion — это не быстрее редактор и не умнее ИИ-помощник; это переопределение того, что считается единицей знания. Если единица — документ, то улучшить можно только скорость его создания и поиска. Если единица — запись о произошедшем, то документ становится не источником, а проекцией. ## Документ против агентной памяти: где проходит граница Различие проходит не по одному параметру, а сразу по семи измерениям — и именно совокупность расхождений делает «Notion с AI» категориально другой системой, а не апгрейдом старой. | Параметр | Документ | Агентная память | |---|---|---| | Единица знания | Страница, написанная человеком | Запись о произошедшем событии | | Режим записи | Ручной волевой акт после рефлексии | Автоматический в момент операции | | Актуальность | Действителен до следующего изменения процесса; обновление руками | Действителен в момент записи; семантический слой переписывается, когда новые эпизоды противоречат старым выводам | | Трассировка | Нет связи с конкретными операциями | Каждая запись связана с актором, временем и предшествующим эпизодом | | Источник истины | Последняя версия страницы | Структурированный слой + извлечённые из эпизодов утверждения | | Владение | Владелец страницы поддерживает содержимое | Владелец схемы проектирует структуру; наполнение делает работа | | Готовность для агентов | Требует отдельного индексирования и конвейера поиска | Слой памяти изначально структурирован под агентов: эпизодический / семантический / структурированный | | Масштабируемость | Линейный рост стоимости поддержки от размера команды | Стоимость поддержки растёт от количества схем, а не от объёма событий | Каждая правая ячейка предполагает, что в системе уже есть слой, фиксирующий операцию; без него правый столбец нереализуем. Именно поэтому категория «слой памяти» (memory layer) отделилась от «ИИ-документации» в 2025–2026 годах — появились компоненты, без которых правый столбец нельзя собрать: временны́е графы, эпизодические блоки, разрешение сущностей через единые идентификаторы. ## Трёхэтажная архитектура: что фактически собирается Категория, которую инвестиционный рынок к маю 2026 года называет «мозгом компании» (company brain) или «корпоративным слоем памяти», стоит на трёх различимых слоях. Это не одна база и не три разных продукта — это три типа фиксации, каждый со своим горизонтом и своим способом записи. **Эпизодический слой** — последовательность событий, которые произошли с участием системы или вокруг неё. Звонки, сообщения, действия агента, реакции клиента, статусы заказов. У каждого события есть отметка времени, актор и связь с предшествующим. [Letta, наследник проекта MemGPT, реализует этот слой через блоки памяти](https://www.letta.com/blog/memory-blocks) — структурированные записи, которые агент создаёт в ходе работы и к которым возвращается в следующих сессиях. Sentra в [своей публичной модели](https://siliconangle.com/2026/01/28/sentra-app-raises-5m-build-ai-teammate-organize-enterprise-memory/) описывает это как «память взаимодействий»: «встречи, диалоги, сообщения». Эпизод — атом операционной памяти; он создаётся в момент события и не требует отдельного акта документирования. **Семантический слой** — извлечённые из эпизодов устойчивые утверждения о мире. «Этот клиент платит на третий день после счёта», «эта команда эскалирует раньше, чем требует процесс», «этот тип возражений снимает кейс из соседней отрасли». [Mem0 в своей технической документации](https://mem0.ai/research) отделяет семантическую память от эпизодической как архитектурный слой: один — журнал, другой — выводы. Принципиально, что семантический слой не пишется руками — он извлекается из эпизодического слоем над ним. Если завтра выясняется, что клиент платит уже не на третий, а на седьмой день, новый эпизод противоречит старому утверждению; задача памяти — пометить старое как недействительное и сформировать новое, а не молча затереть. [Graphiti, открытый движок временно́го графа знаний](https://github.com/getzep/graphiti), решает это через две метки времени — «действителен с» и «недействителен с», — где противоречие становится свойством системы, а не дефектом. **Структурированный слой** — система записи, которую видят люди и системы за пределами агента. Карточки клиентов, статусы сделок, состояния оборудования, выгрузка в учётную систему. Это знание, которое должно быть пригодно к показу, аудиту и выгрузке. Sentra называет этот слой «фактической памятью», [исследования категории «мозг компании»](https://mem0.ai/research) — «системой записи». Принципиально, что структурированный слой — первичный, а не производный: память агента обязана сводить сущности через единые идентификаторы из этого слоя, иначе разные эпизоды про одного клиента превратятся в трёх разных клиентов с похожими именами. Эти три слоя складываются не в иерархию «черновик → чистовик», а в петлю. Эпизодический слой пишется автоматически в момент работы. Семантический извлекается из эпизодического и переписывается, когда новые эпизоды противоречат старым выводам. Структурированный обновляется, когда семантический достигает уровня надёжности, при котором утверждение можно показать наружу. Документ в этой схеме — не отсутствует, но перестаёт быть источником истины: он становится одной из возможных проекций структурированного слоя для конкретного читателя в конкретный момент. ## Почему «лучший Notion» — это категориальная ошибка Первый рефлекс команды при столкновении с этой архитектурой — встроить её в существующее представление о документе: «Notion с агентами», «ИИ-википедия, которая сама обновляется», «база знаний, которая запоминает диалоги». Все 3 формулировки описывают один продукт: документоцентричную систему с добавленным слоем автозаполнения. Это категориальная ошибка по той же причине, по которой автомобиль не описывается как «лошадь, которая не устаёт». Меняется не атрибут, а единица. У автомобиля единица движения — оборот двигателя, а не шаг. У ИИ-нативной памяти единица знания — закрытая запись о произошедшем, а не страница с заголовком. Документ может жить как поверхность поверх этой памяти, но перестаёт быть тем, что её порождает. Этот сдвиг виден на «единице правды». В документоцентричной команде вопрос «а как у нас устроен онбординг» закрывается ссылкой на страницу. В команде с памятью — агрегацией: «12 последних онбордингов, извлечённые из них устойчивые шаги, и те из них, что менялись за 6 недель». Первая система отвечает последней отредактированной версией. Вторая — выводом из того, что фактически делалось. Совпадают они только в идеальном мире; в реальном — расходятся уже через квартал. Из этой же логики растёт и инвестиционный тезис рынка. [Glean переименовал продукт](https://www.glean.com/blog/glean-series-f-announcement) из «корпоративного поиска» в «систему контекста» при оценке $7,2 млрд именно потому, что поиск по документам перестал быть достаточным ответом — нужна агрегация по операциям. Sentra зашла под тезисом «память участвует, а не ждёт» с раундом $5 млн. Mem0 на $24 млн Серии A продаёт «универсальный слой памяти», а не «лучшую корпоративную базу знаний». Все 3 формулировки — отказ от документа как первичной единицы. ## Как это меняет архитектуру самой команды Сдвиг от документа к памяти меняет и роли. В документоцентричной команде владелец знания отвечает за актуальность страниц и регулярные ревизии — роль, которая на 20-й странице перестаёт масштабироваться. В команде с памятью она распадается на две: **владелец схемы** решает, какие сущности живут в семантическом и структурированном слоях и как они связаны (работа раз в квартал, а не еженедельная редактура); **владелец триггеров** — при каких условиях семантический слой порождает уведомления и эскалации. Обе роли проектируют слой, а не наполняют его — наполнение делает работа. Параллельно меняется онбординг. В документоцентричной команде новичка учат через страницы, устаревшие на квартал. В команде с памятью он получает доступ к эпизодическому слою домена за 6–12 месяцев и к актуальному семантическому слою: вместо «как мы делаем» он видит «как 200 раз делали». Устаревание знания на онбординге исчезает как класс. И наконец, меняется природа решений. [Sentra](https://siliconangle.com/2026/01/28/sentra-app-raises-5m-build-ai-teammate-organize-enterprise-memory/) выделяет третий тип памяти — «память решений»: решения и договорённости с временной меткой, актором и связью с эпизодом, который к ним привёл. Этот слой заменяет жанр «решение по итогам встречи в Notion-странице»: решение становится записью, привязанной к породившей её ситуации, а не пунктом в странице, которую через полгода никто не открывает. По той же логике, по которой [замкнутый цикл «решение → исход» становится единственным реальным защитным рвом для вертикальных ИИ-агентов](/notes/2026/05/trajectory-data-decision-outcome-loop-moat), память решений становится активом ИИ-нативной команды: решения в связке с исходами не воспроизвести чтением документации. ## Конкретные тесты для трёх типов читателей Для основателя на стадии команды в 10–15 человек тест такой: возьмите 3 ключевых процесса — продажа, онбординг, эскалация инцидента — и спросите, откуда команда узнаёт, как они устроены. Если ответ «из страницы в Notion» и последнее обновление старше 6 недель при изменившемся процессе — документ и реальность уже расходятся. База из 50 операционных страниц требует 5–10 точечных обновлений в месяц при умеренной динамике; при ручном режиме доходят 1–2. Единственный способ закрыть разрыв при росте — перенести точку фиксации с документа на запись о произошедшем. Для инженера, выбирающего проект, тест другой: посмотрите, как в продукте устроен слой памяти агентов. Если это «вектор плюс поиск по сходству» — это первая стадия зрелости, ещё без временно́й структуры. Если есть явные слои «эпизодический / семантический / структурированный» с двойными метками времени и сведением сущностей через единые идентификаторы из системы записи, продукт уже стоит на актуальной архитектуре. Разница между этими двумя состояниями — не косметическая; вторая система допускает изменение фактов о мире без переписывания истории, первая — нет. Для руководителя, оценивающего внедрение ИИ, тест третий: спросите поставщика, какой результат внедрения остаётся у вас через год. «Обученный на ваших документах ассистент» — снимок состояния, начинающий устаревать с первого изменения процесса. «Трёхслойная память, накапливающаяся из вашей операционной активности» — растущий актив; тогда уместны вопросы про возможность выгрузки этой памяти и про владельца структурированного слоя — именно он ядро защиты от смены поставщика. Такие контуры — где память копится вокруг одного измеримого процесса и остаётся у вас активом — мы собираем как рабочие системы, а не как пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=memory-beats-document-ai-native-team&utm_content=inprose). ## На что смотреть дальше Категория «мозг компании» к маю 2026 года ещё не имеет общепринятой границы между горизонтальными платформами (Glean, Sentra, Microsoft Copilot) и вертикальными системами памяти, привязанными к домену. Но первая граница уже проходит по владению структурированным слоем. Если он принадлежит поставщику платформы, замена поставщика стирает бо́льшую часть накопленного знания; если заказчику — смена памяти становится инженерной задачей, а не катастрофой. Вторая граница — между извлечением семантического слоя машиной и его курацией человеком. [LongMemEval](https://arxiv.org/abs/2410.10813) показал, что модели уверенно справляются с поиском, но проваливаются на 2 из 5 категорий — разрешении противоречий и понимании временно́го порядка. Пока этот разрыв не закрыт, семантический слой требует человеческого надзора над тем, что засчитано как новое устойчивое утверждение, а что — как шум. Третья граница — выгрузка. Документоцентричная эра дала привычку, что знание принадлежит команде и переносится между инструментами в виде файлов. Память агента слабее переносима по построению — привязана к схеме, временно́й модели, структуре эпизодов. Появление стандартов выгрузки слоя памяти — или их отсутствие в ближайшие 12 месяцев — скажет, останется ли эпоха архитектурно открытой или закроется вокруг 1–2 доминирующих стеков. ## Главное - Документ как единица знания страдает 3 структурными дефектами: не знает, когда устарел, не связан с операцией, требует ручной записи. На команде до 10 человек это незаметно, при 50 — фатально. - На его место приходит трёхэтажная память: эпизодический слой пишется автоматически, семантический извлекается из него, структурированный остаётся системой записи и аудита. - «Лучший Notion» — категориальная ошибка. Это не улучшение документа, а замена единицы знания: со страницы, которую кто-то отредактировал, на запись о произошедшем. - Сдвиг меняет роли: владельцы знания превращаются в проектировщиков схем и триггеров; онбординг идёт по эпизодам последних 6–12 месяцев, а не по устаревшим страницам. - Главная архитектурная проверка — кому принадлежит структурированный слой. Если поставщику горизонтальной платформы — актив временный. Если заказчику — память остаётся за командой при смене стека. ## FAQ **Документы исчезнут совсем?** Нет. Они перестанут быть источником истины и станут проекцией структурированного слоя — рендером для конкретного читателя. Контракт, отчёт регулятору, описание продукта на сайте — всё это документы. Но генерируются из памяти, а не порождают её. **Это не то же, что ИИ-помощник в Notion?** Нет. ИИ-помощник в документоцентричной системе ускоряет работу с документом — пишет, ищет, суммирует. Архитектура памяти меняет единицу: знание фиксируется в момент события, а не рефлексии. Помощник без смены единицы — электронная таблица с макросами там, где нужна реляционная БД: ускорение операций над неподходящим примитивом. **Когда такой переход оправдан для команды?** Когда расхождение между актуальным процессом и его документированной версией начинает регулярно стоить решений — повторных вопросов на онбординге, дублирующих диалогов, ошибок в эскалациях. В командах до 10 человек это решается дисциплиной; от 30 — становится структурным: количество одновременных изменений превышает скорость их описания руками. **Это не то же, что корпоративный поиск вроде Glean?** Близко, но не то. Корпоративный поиск строится поверх существующих документов и ускоряет их нахождение. Слой памяти фиксирует операцию напрямую и извлекает знание из неё. [Сама Glean переименовала продукт](https://www.glean.com/blog/glean-series-f-announcement) в «систему контекста», признавая этот сдвиг. **Кому принадлежит память агента?** Главный вопрос архитектурного выбора. Если структурированный слой живёт в собственной системе записи заказчика, память остаётся у него и переживает смену вендора. Если он живёт в SaaS-платформе вендора, замена платформы стирает большую часть актива. --- ## Note 29: Данные траекторий: как закрытый цикл «решение → исход» становится единственным реальным moat **URL:** https://notes.temadev.org/2026/05/trajectory-data-decision-outcome-loop-moat.html **Published:** 2026-05-06 **Genre:** concept-piece **Tags:** ai-agents, data-moat, trajectory-data, vertical-ai, b2b, switching-costs **Words:** 2696 **Summary:** Модель и схему данных можно заменить. Closed-loop данные решений и исходов - нет. Почему trajectory data стала единственным нестираемым moat в вертикальном AI. # Данные траекторий: как закрытый цикл «решение → исход» становится единственным реальным moat ## Что уже можно купить, а что — нет К апрелю 2026 года стек вертикального AI разделился на то, что покупается из коробки, и то, что не покупается ни за какие деньги. За последний квартал четыре крупнейших провайдера — Anthropic, OpenAI, Google и AWS — независимо выпустили managed agent harness как отдельные продукты — этот сдвиг рынка [businessengineer.ai назвал «harness as the agentic moat»](https://businessengineer.ai/p/the-harness-as-the-agentic-moat) ещё в марте, а к маю продуктизация уже завершилась. То, что год назад требовало месяца инженерной работы, ставится из SDK за несколько часов. Параллельно появилась индустрия памяти для агентов: Mem0 [закрыл Series A на $24 млн в октябре 2025](https://www.prnewswire.com/news-releases/mem0-raises-24m-series-a-to-build-memory-layer-for-ai-agents-302597157.html) при оценке $150 млн, [Graphiti](https://github.com/getzep/graphiti) накопил десятки тысяч звёзд на GitHub, LongMemEval ([arXiv:2410.10813](https://arxiv.org/abs/2410.10813)) стал стандартным академическим бенчмарком долговременной памяти агентов. Если модель меняется за выходные, а слой памяти переносится за 2–4 недели, вопрос звучит прямо: что именно нельзя купить, синтезировать или воспроизвести? Не инфраструктура памяти. А данные, которые через эту инфраструктуру прошли. Конкретнее — это один тип данных: записи закрытого цикла. Каждая такая запись — формула вот что решил агент / человек, вот что произошло в итоге — это контракт между действием и его измеримым следствием через N дней. Если сформулировать точно, пара **решение → исход — это атомарная единица обучающего сигнала вертикального AI, состоящая из трёх связанных полей**: контекст, в котором было принято решение; само действие (что сделал агент или человек); измеримое последствие через заданный промежуток времени. Эта же сущность называется **trajectory data — структурированная пара контекста и фактического исхода, зафиксированная в момент реального действия и связанная во времени с последствием.** В отличие от обычного лога, такая запись содержит не только сам факт, но и связь действия с измеримым результатом. Это единственный слой защиты, который нельзя восстановить задним числом — сколько бы денег на восстановление ни потратить. ## Три уровня, три разных горизонта жизни Вертикальный AI-продукт сегодня строится на трёх слоях. У каждого из них - разный срок жизни как конкурентного преимущества. **Первый слой — модель.** Горизонт защиты: 12–18 месяцев. Пока вы используете одну фронтирную модель, конкурент использует другую; через год оба перейдут на следующее поколение, и разница исчезнет. Jason Lemkin из SaaStr формулирует это прямо: [«AI is table stakes, prompts are portable, AI quality is not your moat»](https://www.saastr.com/the-wave-of-ai-agent-churn-to-come-prompts-are-portable/) — то есть качество модели и переносимость промптов не создают устойчивого преимущества. Это знакомая логика технического преимущества, которое утекает вниз по стеку — её прошли реляционные базы данных, облачная инфраструктура, теперь проходят фронтирные модели. На модели устойчивость не строится. **Второй слой — схема данных (representation layer).** Горизонт защиты: годы. Это онтология домена: какие сущности существуют, как они связаны, что считается статусом, кто имеет право эскалировать, какие исключения валидны. Подробно про этот слой — в [предыдущей заметке про representation layer как источник стоимости переключения](/2026/04/representation-layer-vertical-schema.html). Чужому провайдеру нужны месяцы на корректное описание домена и ещё месяцы на калибровку схемы под реальное поведение конкретного рынка. **Третий слой — данные траекторий (trajectory data).** Горизонт защиты: невозможно воссоздать ретроспективно. Это не «история действий». Это **закрытый цикл (closed loop) — замкнутая связь между решением в конкретном контексте и фактическим исходом, наблюдаемым через определённый промежуток времени**. Решение либо привело к нужному результату, либо нет. Прогноз сбылся или не сбылся. Рекомендация была принята клиентом или отвергнута. Именно эти пары «решение → исход» становятся обучающим сигналом, который улучшает следующие решения системы в похожих ситуациях. **Более умной моделью — это значит не модель с большим числом параметров, а система, у которой выше точность прогнозирования исхода в конкретном домене за счёт накопленных пар.** Их нельзя синтезировать, восстановить из логов или купить. ## Почему «нельзя воссоздать» — не метафора, а физическое ограничение Данные траекторий создаются только в момент реального решения в реальном контексте. Ни ретроспективная разметка логов, ни синтетические данные, ни дообучение на общедоступных датасетах не воспроизводят этот слой. Причина: запись содержит не только сам факт решения, но и контекст момента — состояние системы, историю предшествующих взаимодействий, конкретные условия, сложившиеся к тому часу. Этот контекст начинает теряться уже через сутки: параллельные процессы успевают изменить состояние, а исход решения проявляется позже самого решения, и связать одно с другим по логам постфактум становится невозможно ([arXiv:2507.05257](https://arxiv.org/abs/2507.05257)). Исследования памяти агентов подтверждают асимметрию количественно. MemoryAgentBench, представленный в работе Hu, Wang и McAuley «[Evaluating Memory in LLM Agents via Incremental Multi-Turn Interactions](https://arxiv.org/abs/2507.05257)», вводит четыре ключевых компетенции для систем с памятью: точный поиск, обучение во время использования, понимание длинных горизонтов и избирательное забывание. Авторы фиксируют, что ни один из проверенных подходов — от простого расширения контекста до retrieval-augmented generation и внешних модулей памяти — не закрывает все четыре компетенции одновременно. На LongMemEval ([arXiv:2410.10813](https://arxiv.org/abs/2410.10813)) разрыв в категории temporal reasoning между системами с накопленной долговременной историей и без неё авторы оценивают в десятки процентных пунктов — и этот разрыв не закрывается увеличением контекстного окна. MEM1 ([arXiv:2506.15841](https://arxiv.org/abs/2506.15841)) идёт дальше: работа показывает, что системы, обученные на реальных траекториях решений, формируют принципиально другие внутренние представления задачи — не описательные, а оперативные. Из этого следует, что разрыв в качестве между провайдером с историей и провайдером без неё не просто существует — он увеличивается с каждым месяцем работы в одном домене. ## Gong: прецедент монетизации Рынок уже научился продавать запись траекторий как отдельный продукт — за пределами AI-агентов. Самый показательный пример — Gong.io. Gong записывает каждый разговор отдела продаж, извлекает из него паттерны и связывает их с исходами сделок. Это и есть запись траекторий в чистом виде — только для sales-команды, а не для AI-агента. Модель продукта состоит из [трёх обязательных строк прайса](https://www.itsconvo.com/pricing/gong): платформенная подписка ($5 000–$50 000/год), per-user лицензия ($1 300–$1 600 на пользователя в год) и единовременное внедрение ($7 500–$65 000). Для команды из 10 человек первый год обходится примерно в $28 000, для 50 человек — около $106 000. Причина, по которой рынок готов платить эти деньги, проста: Gong не продаёт «аналитику звонков». Gong продаёт накопленную историю «вот что говорилось на этом этапе сделки — вот чем сделка закончилась». Платформенная подписка отделена от лицензии на пользователя именно потому, что хранилище и доступ к историческим записям — это базовая ценность, не зависящая от размера команды. Внедрение стоит отдельно и дорого по той же причине: клиент платит за то, чтобы правильно поставить запись траекторий с первого дня, а не пытаться разметить логи задним числом, когда контекст уже потерян. Та же логика работает в LLM-observability. Langfuse продаёт [запись траекторий агента от $29 до $2 499/мес](https://langfuse.com/pricing) в зависимости от глубины ретенции данных. Braintrust — [от $249/мес с отдельной строкой за хранение данных](https://www.braintrust.dev/pricing). Коммерческая логика общая: хранение и анализ траекторий — отдельная позиция прайс-листа, а не «инфраструктура внутри». ## Вертикальный маховик против горизонтального «company brain» К 2026 году оформилась отдельная категория горизонтальных «company brain» продуктов: корпоративная память для всей компании. Glean привлёк оценку в районе $7 млрд в раунде 2025 года. Y Combinator включил enterprise memory layer в Request for Startups последних батчей. Эта категория решает реальную задачу — поиск и связывание знаний внутри организации. Но для вертикального AI у горизонтальных платформ есть структурное ограничение: они не накапливают данные траекторий в конкретном операционном домене. Возьмём поток обращений в службу поддержки SaaS-продукта. Горизонтальная платформа знает, что в компании есть документация по продукту и тикеты. Она не знает, какие решения о приоритизации, эскалации или закрытии тикета в каком контексте приводили к удержанию клиента, а какие — к отказу от подписки в течение следующих 90 дней. Эта связь между решением и исходом не накапливается автоматически — она требует явной фиксации в момент действия и привязки к измеримому событию через N дней. Исторический прецедент — Veeva против Salesforce в фармацевтике. Veeva не победила лучшей CRM-системой. Она победила потому, что накопила domain-specific онтологию и историю реальных взаимодействий именно для pharma sales: паттерны контакта с врачами, регуляторные ограничения, специфику цикла одобрения препарата. Salesforce не воспроизвёл это через универсальную CRM не потому, что не мог собрать данные, а потому, что схема и контекст у Veeva уже были откалиброваны. Sanjay Srivastava в [Forbes-эссе «The Moat Is Moving»](https://www.forbes.com/sites/sanjaysrivastava/2026/03/04/in-ai-the-moat-is-moving/) формулирует тот же тезис в более узком виде: institutional regulation, deep ecosystem integration и, главное, «closed-loop data — operational evidence linking decisions to outcomes» в 2026 году становятся не маркетинговой «defensibility», а единственными слоями, которые провайдер модели физически не может упаковать в свой SDK. Этот механизм — data network effects, описываемый в [a16z-эссе «The Economic Case for Generative AI and Foundation Models»](https://a16z.com/the-economic-case-for-generative-ai-and-foundation-models/) как одна из ключевых форм defensibility в эпоху foundation моделей: ценность компаундируется, когда больше использования системы создаёт лучшую калибровку, а лучшая калибровка привлекает больше использования. Разрыв в стоимости между вертикальным маховиком и горизонтальной платформой здесь не косметический, а структурный. Совокупная стоимость владения горизонтальной enterprise-платформой уровня Glean для крупной компании, по публичным выкладкам аналитиков рынка корпоративного поиска, измеряется сотнями тысяч долларов в год. Вертикальный AI-контур, собранный поверх open-source инфраструктуры памяти и собственной онтологии домена, на сопоставимом периметре существенно дешевле. Эта ценовая разница — не конкурентный риск для вертикального игрока, а его структурная защита: горизонтальная платформа не может опуститься в эту цену, не обесценив свою же модель монетизации. ## Что произойдёт, когда managed eval станет товаром? Закономерный риск: OpenAI уже выпустил [Evals API](https://platform.openai.com/docs/guides/evals). Anthropic движется в ту же сторону. Если managed evaluation станет бесплатной инфраструктурой — не обесценивает ли это запись траекторий как таковую? Нет — по той же причине, по которой Datadog существует рядом с бесплатным AWS CloudWatch. CloudWatch даёт сырые метрики; Datadog продаёт интерпретации в контексте конкретного стека и рабочего процесса. Gong существует рядом с Salesforce Einstein много лет по той же логике: Salesforce умеет анализировать структурированные данные CRM, но не воспроизводит специфику разговоров, которую Gong накопил в конкретных индустриях. ## Почему это работает как порог, а не как движение Накопление траекторий ведёт себя не линейно. До определённого объёма записей система ведёт себя как «лучший промпт» — её можно воспроизвести копией инструкции. После того, как система накопила заметный объём закрытых циклов в одном операционном контексте, «перенести знание» к конкуренту выписыванием промпта уже нельзя: ценность живёт в парах «решение → исход», в сезонных паттернах и в длинном хвосте исключений, которые нельзя выразить одной инструкцией. Конкуренту придётся накапливать это заново — в том же режиме реального времени, в том же домене, при тех же условиях. Публичных бенчмарков, которые прямо транслируют размер trajectory корпуса в «проценты switching cost», пока нет — и это честнее признать. Но форма разрыва фиксируется количественно на смежных прокси. MemoryAgentBench ([arXiv:2507.05257](https://arxiv.org/abs/2507.05257)) показывает, что разрыв в качестве temporal reasoning между системами с накопленной историей и без неё измеряется десятками процентных пунктов на LongMemEval — и этот разрыв не закрывается ни ростом контекстного окна, ни сменой модели. Единственный фактор, который его закрывает, — накопление реальной истории в том же домене. Без явного слоя записи траекторий — фиксации входа, решения и исхода — эти данные не накапливаются автоматически. Это инженерное решение, которое имеет смысл принимать на старте: вход (контекст), решение (что агент или человек сделал), исход (что произошло через N дней) — три поля в каждой записи. Ретроспективная разметка старых логов возможна, но контекст момента уже потерян, и качество таких данных принципиально ниже. ## Что из этого следует | Слой | Что заменить | Сколько времени | Что нельзя воспроизвести | |---|---|---|---| | Модель | Любой альтернативный LLM | 1-2 недели | - | | Memory backend | Graphiti → Mem0 → Letta | 2-4 недели | - | | Схема данных | Написать новую онтологию домена | 3-6 месяцев | Калибровку исключений и граничных случаев | | Trajectory data | Нельзя | - | Тысячи реальных пар «решение → исход» (для иллюстрации) | Четыре следствия для вертикального AI-продукта. **Первое.** Архитектурное решение: запись траекторий должна быть явным слоем с первого дня, а не логом, который «потом разметим» ([arXiv:2506.15841](https://arxiv.org/abs/2506.15841)). Вход (контекст), решение (что агент или человек сделал), исход (что произошло через N дней) — три поля в каждой записи. Без этой структуры данные копятся, но не становятся обучающим сигналом. **Второе.** Коммуникационное решение: клиент должен понимать, что именно компаундируется со временем. Не «мы поддерживаем AI-систему», а «за 6 месяцев система накопила N закрытых циклов в вашем домене, и это делает её точнее, чем любое новое решение с нуля». Gong [продаёт ровно это сообщение](https://www.itsconvo.com/pricing/gong): клиент платит не за записи звонков, а за то, что система с каждым месяцем точнее предсказывает исходы сделок, чем интуиция менеджера. **Третье.** Стратегическое следствие: горизонт конкурентного преимущества зависит от того, как давно и насколько методично ведётся запись ([arXiv:2507.05257](https://arxiv.org/abs/2507.05257)). Провайдер, начавший фиксировать траектории год назад, имеет год структурного опережения. Этот разрыв не закрывается «лучшей моделью» — только временем работы в том же контексте. Оценка вертикального AI-продукта в этой логике строится не на технологическом стеке, а на глубине и длине накопленной истории. **Четвёртое.** Конкурентное следствие: managed eval от OpenAI и Anthropic не уравнивает игровое поле — он смещает ценность дальше в сторону данных ([Evals API](https://platform.openai.com/docs/guides/evals)). Когда инфраструктура записи доступна всем, выигрывает тот, кто начал записывать раньше и в правильном вертикальном контексте. Коммодитизация инструментов в зрелых рынках систематически усиливает преимущество тех, кто накопил содержание раньше — этот сдвиг ценности от инструмента к данным в его работе уже прошли инфраструктурный мониторинг (CloudWatch против Datadog) и CRM (Salesforce против Gong); сейчас он повторяется на уровне AI-агентов. ## Главное - **Модель и слой памяти коммодитизируются** на горизонте 12–18 месяцев — это базовое условие рынка, на котором приходится строить продукт. - **Схема данных (representation layer) держится годами.** Необходимый, но не достаточный уровень защиты. - **Данные траекторий — единственный слой с физической невоспроизводимостью.** Закрытые циклы «решение → исход» нельзя купить, синтезировать или воссоздать ретроспективно ([arXiv:2506.15841](https://arxiv.org/abs/2506.15841)). - **Поведение слоя нелинейно:** до определённого объёма записей знание переносится копией промпта; после — нет, и конкуренту приходится накапливать заново в реальном времени. - **Рынок уже монетизирует этот слой:** Gong (≈$28 000–$106 000/год на команду), Langfuse и Braintrust — отдельная позиция прайс-листа за хранение и анализ траекторий. - **Managed eval не убивает преимущество** — он создаёт инфраструктуру записи. Ценность — в том, что именно записано и под какой домен откалибровано. ## FAQ **Чем данные траекторий отличаются от обычных логов системы?** Лог фиксирует факт: агент ответил так-то в такое-то время. Запись траектории фиксирует замкнутый цикл: агент принял такое решение в таком контексте, и через N дней исход был таким. Разница принципиальная — лог описывает действие, запись траектории связывает действие с последствием. Эта связь и создаёт обучающий сигнал, который улучшает следующие решения в похожих ситуациях ([arXiv:2506.15841](https://arxiv.org/abs/2506.15841)). **Почему нельзя воссоздать данные траекторий задним числом — разве нельзя разметить старые логи?** Ретроспективная разметка работает для очевидных случаев, но не воспроизводит контекст момента решения. Временная метка, история предыдущих взаимодействий, состояние системы, параллельные события — всё это либо не сохранилось в логах, либо не было связано в структуру, пригодную для извлечения паттернов. MEM1 ([arXiv:2506.15841](https://arxiv.org/abs/2506.15841)) показывает, что внутренние представления модели, обученной на реальных траекториях, отличаются от представлений модели, обученной на синтетически восстановленных записях, — и этот разрыв не закрывается ростом объёма синтетики. **Горизонтальные платформы корпоративной памяти вроде Glean — разве они не решают ту же задачу?** Нет. Горизонтальная платформа знает, что в компании есть информация по домену, но не знает, какие решения в каком контексте приводили к каким исходам. Это разница между корпусом документов и историей действий, привязанных к последствиям. Горизонтальная платформа работает с первым; данные траекторий — это второе. Вертикальный AI-продукт с двенадцатью месяцами работы в домене и горизонтальная корпоративная память — разные категории, а не конкуренты. **Когда данные траекторий начинают создавать реальное конкурентное преимущество — с первого дня или нужно накопить порог?** Поведение нелинейно. До определённого объёма закрытых циклов в одном операционном домене знание системы можно перенести к конкуренту копией инструкции — switching cost практически нулевой. После — нет: ценность живёт в парах «решение → исход», в сезонных паттернах и в длинном хвосте исключений, которые нельзя выписать одной инструкцией. Конкурент в этой точке вынужден накапливать заново в режиме реального времени, в том же домене и при тех же условиях. Конкретный порог зависит от плотности решений и длины обратной связи в вертикали — публичных бенчмарков, переводящих размер корпуса траекторий в проценты switching cost, пока нет. **Как объяснить клиенту ценность данных траекторий, не раскрывая технических деталей?** Лучше всего работает аналогия с опытным сотрудником. Новый сотрудник может знать тот же регламент, что и опытный, но опытный помнит, что у определённого типа клиентов принято работать не по регламенту, что некоторые обращения требуют звонка до отправки ответа, что сезонный пик нужно прогнозировать заранее. Эти знания нельзя передать в инструкции — они накапливаются в работе. Данные траекторий — это способ, которым AI-система фиксирует и использует именно такой опыт. --- ## Note 30: Большая четвёрка уже сделала это. Когда российский rental дойдёт до AI и что строить до того, как стало поздно **URL:** https://notes.temadev.org/2026/05/rental-big-four-ai-russia-window-2026.html **Published:** 2026-05-05 **Genre:** market-deep-dive **Tags:** rental, спецтехника, AI, Россия, vertical-ai **Words:** 2054 **Summary:** Большая четвёрка rental уже встроила AI в core operations. Российский рынок отстаёт на 18–24 месяца — окно для вертикального AI-слоя закрывается. # Большая четвёрка уже сделала это. Когда российский rental дойдёт до AI и что строить до того, как стало поздно В августе 2025 года United Rentals сообщила, что 76% её выручки в 2025 году пришло от клиентов, использующих digital-инструменты. В 2023 году этот показатель был 70%, в 2024-м — 73%. Шесть процентных пунктов в год при выручке около 16 млрд долларов — это не маркетинговый слайд, это фактический сдвиг операционной модели. Тот же отчёт фиксирует +22% online-выручки и +31% онлайн-платежей год к году, а ML-рекомендатор Smart Suggestions уже даёт −27% времени на подбор и заказ техники на пилотных аккаунтах ([investors.unitedrentals.com](https://investors.unitedrentals.com/press-releases/press-releases-details/2025/United-Rentals-Expands-Digital-Platform-with-Smart-Suggestions-and-Equipment-Fit-Augmented-Reality-Capabilities/default.aspx)). В это же время большинство российских арендодателей спецтехники принимают заявки телефонным звонком, ведут партнёров в Excel и проверяют наличие машины ручным обзвоном. Это не оценка, это наблюдаемая реальность отрасли, в которой основной канал поиска подрядчика — Авито, а основной операционный софт — мессенджеры. Разрыв между двумя картинами — не «отставание из-за санкций» и не «русские не умеют в AI». Это окно, которое закроется в течение 18–24 месяцев — и закроется не само, а руками тех, кто решит занять вертикальный слой раньше остальных. ## Что значит «AI у большой четвёрки» сейчас Под большой четвёркой мирового rental-рынка понимаются United Rentals (≈$16 млрд выручки 2025), Sunbelt Rentals в составе Ashtead Group (≈$8 млрд+), Loxam (€2,47 млрд) и Herc Rentals (≈$3 млрд). У всех четырёх в 2024–2025 годах появился публично заявленный AI-контур, и архитектурно он устроен похоже. United Rentals публикует [Total Control](https://www.unitedrentals.com/services/online-services/total-control) как proprietary fleet management platform: web и mobile, заказ и возврат техники, разнесение затрат по объектам, управление инвойсами, расширенная телематика. Поверх этой поверхности в 2025 году добавлены три AI-функции: Smart Suggestions предсказывает следующий заказ клиента на основе истории, сезонности и характера объекта; Equipment Fit AR позволяет через камеру телефона разместить 3D-модель техники на стройплощадке и проверить, пройдёт ли она в узкое место; predictive maintenance закрывает поломки до их появления через ML на телематических данных. Sunbelt идёт по более тяжёлому пути. В ноябре 2025 года компания расширила [партнёрство с Trackunit](https://trackunit.com/press/sunbelt-trackunit-partnership/) и подключила к платформе IrisX более 20 000 единиц техники, включая аккумуляторные хранилища, солнечные модули и башенные осветительные мачты — то есть нетипичные для классического rental позиции. Поверх этого работает AI-driven customer portal с метриками утилизации и downtime, приложение True Fuel Costing и открытый Fleet API. На уровне группы это одна из пяти стратегических осей [Sunbelt 4.0](https://ir.sunbeltrentals.com/) — connectivity и data перестали быть «инициативой ИТ» и стали отдельным направлением P&L. Архитектурно за этим стоит не велосипед: Sunbelt США давно живёт на [PTC ThingWorx](https://www.ptc.com/en/case-studies/sunbelt-transform-business-with-iot-fleet-management) как IoT-агрегаторе, нормализующем данные с разнородных OEM. Loxam в финансовом отчёте 2025 года прямо заявляет: «вся цепочка процесса с клиентом теперь оцифрована — от заказа до управления контрактом онлайн, а deployment AI продвинулся, в особенности в predictive maintenance и fleet management». Herc Rentals продаёт [ProControl](https://www.hercrentals.com/procontrol.html) с технологией M.A.C. — multi-user billing, geofencing, контроль доступа к технике, ETA-прогноз, mobile-first UX. В [спонсорском материале Wired](https://www.wired.com/sponsored/story/the-next-generation-of-equipment-rental-pro-control-for-customers-at-their-fingertips/) Herc формулирует это как «следующее поколение аренды техники в кармане у клиента» — и эта формулировка показывает, что для них мобильное приложение клиента уже не дифференциатор, а минимум. Общий паттерн у всех четверых одинаковый. Никто не строит всё внутри: у каждого есть собственный customer-facing portal плюс интеграция с горизонтальными B2B-сетями — Trackunit и SmartEquip для парка и запчастей, ThingWorx как промышленный IoT-слой. То, что стоит дороже всего, — нормализация данных от десятков OEM и обвязка операционных процессов вокруг этой нормализации. Это и есть defensible часть. Модель и UX — заменимые. | Оператор | Выручка (2024) | AI-продукт | Интеграция | Статус | |---|---|---|---|---| | United Rentals | $16 млрд | Smart Suggestions, Equipment Fit AR | Proprietary Total Control | AI в продакшне | | Sunbelt/Ashtead | $8+ млрд | Sunbelt 4.0, IrisX telemetry | Trackunit IrisX, PTC ThingWorx | AI в продакшне | | Loxam | €2.47 млрд | AI fleet management, predictive maintenance | Собственная платформа | AI в продакшне | | Herc Rentals | $3 млрд | ProControl, M.A.C. tech | Собственный портал | AI в продакшне | | Авито Спецтехника | н/д | Онлайн-аренда, ЭДО | Transbaza, Контур.Диадок | Платформа без AI-диспетчера | | Российский SMB-rental | н/д | — | Авито + Excel + мессенджеры | Цифровизация = 0 | ## Что в этой архитектуре делает вертикальный AI Vertical AI — это операционный слой, в котором AI решает не общую задачу (написать текст, ответить на письмо), а конкретную последовательность шагов внутри одной отрасли, опираясь на её собственную модель сущностей, статусов и инвариантов. Для аренды спецтехники такой слой описывает, что считается заявкой, какой статус у партнёра, что значит «техника подтверждена», как переходят между состояниями документ и платёж. Это не «прикрутить чат-бот к сайту» — это построить диспетчерский контур с confidence scoring по парку и рейтингом по партнёрам, в который потом встраиваются языковые модели как исполнители, а не как продукт. Большая четвёрка, по сути, уже построила такой слой и теперь докручивает в него AI. На фоне этого индустрия фиксирует базовое условие: по [исследованию Quipli за 2025 год](https://quipli.com/resources/2025-state-of-rental-report/) только 16% rental-операторов в США имеют полностью интегрированные системы, ещё 67% живут на частично интегрированных, а 50% по-прежнему вручную переносят данные между системами. Большая четвёрка — это исключение, а не среднее. Российский рынок аналогичный слой не построил пока ни на каком уровне — и здесь проходит развилка. ## Российская картина: где мы сейчас и где пройдёт граница Российский рынок аренды спецтехники структурно отличается от американского по нескольким измерениям, и большую часть этих различий нельзя проигнорировать. Мирового масштаба IoT-инфраструктуры в РФ нет: Trackunit-устройство стоит порядка 10–30 долларов в месяц на единицу, и для парка 200 машин это 200–600 тыс. рублей ежемесячно — годовая выручка одной единицы. OEM-производители тяжёлой техники не отдают CAN-данные на старых моделях. Retrofit-сенсоры стоят 50–200 тыс. рублей за единицу. Полноценный predictive maintenance на сенсорной телеметрии в SMB-rental в горизонте 2026–2028 годов нерентабелен; это не выбор, это арифметика. Зато оцифрован соседний слой. ATI.SU (биржа грузоперевозок) ввела банковскую верификацию через Т-Бизнес, СберБизнес и Альфа-Бизнес, ML-детектор подозрительных аккаунтов и публичную «Карту грузов» с heatmap спроса по регионам ([ati.su](https://ati.su/landings/ati-2025/)). ATI.SU занимает в грузоперевозках ту же позицию, в которой кто-то скоро окажется в аренде спецтехники: централизованная верификация контрагентов, репутационная база, операционная аналитика поверх. Это не гипотеза — это работающая модель в смежной нише. Именно поэтому август 2025 года был ключевым для отрасли. Тогда «Контур.Диадок», Transbaza и «Авито Спецтехника» [публично объявили](https://www.cnews.ru/news/line/2025-08-20_konturdiadoktransbaza_i_avito) интеграцию ЭДО прямо в платформу аренды. Цифры из релиза: 60% арендаторов на Авито Спецтехнике — юридические лица, число арендодателей выросло на 15% за 2024 год, документооборот ускорился в 10 раз, а по оценкам платформы автоматизация документов сберегает 2% бюджета строительной сметы (при том, что сама спецтехника — это около 20% бюджета стройки). Сложение читается прямо: маркетплейс с трафиком и рейтингом, нишевая CRM с историей в учёте аренды спецтехники, инфраструктура ЭДО федерального масштаба. Этой связке не хватает двух элементов — диспетчерского AI и dynamic pricing — чтобы стать «Яндекс.Аренда спецтехники» де-факто. Оба элемента технически доступны: GigaChat 3 Pro и YandexGPT 4 закрывают LLM-слой, [Яндекс Маршрутизация](https://yandex.ru/routing/) с 300+ параметрами и заявленными −30% логистических затрат закрывает route optimization, российские поставщики голосовых агентов — общение с водителями и партнёрами. Никто из big tech пока не запустил продукт целиком — но запретов нет, и это главное. ## Цена входа и реальная экономика Параллельно стало понятно, сколько стоит вертикальный AI на российских данных. Опубликованный на [vc.ru разбор 50 кейсов внедрения GigaChat и YandexGPT](https://vc.ru/ai/2282231-stoimost-vnedreniya-ii-v-biznes) даёт устойчивые цифры: средний бюджет внедрения — 75 тыс. рублей в месяц, окупаемость 3–6 месяцев, ROI 150–400% за полгода, доля провалов 23%. Простой Telegram-бот для приёма заявок — 15 тыс. рублей внедрение и 3 тыс. в месяц, экономит около 30 тыс. на зарплате оператора. Голосовой ассистент для входящих звонков — 120 тыс. внедрение и 25 тыс. в месяц, заменяет двоих администраторов из трёх. Это не «AI-революция», это бытовая операционная экономика, которая уже работает. То же на международной стороне. По данным Quipli за 2025 год, 83% rental-операторов борются с дефицитом персонала, 67% теряют ресурсы на задачи, которые могла бы решить автоматизация, и только 16% имеют полностью интегрированные системы. Большая четвёрка двинулась в AI не из любви к технологиям, а потому что не хватает людей, и это единственный способ удержать утилизацию парка выше 30% по EBITDA-маржинальности. Российский рынок ровно в той же демографической ловушке. ## Что это означает для трёх типов решений Первое — для собственника rental-парка. Конкретный тест: посмотрите, какой процент входящих заявок попадает в CRM в течение 15 минут, и какой процент партнёров имеет хоть какой-то рейтинг или confidence-метрику. Если первый показатель ниже 40%, а второй ниже 30%, вы строите бизнес на интуиции диспетчера. Это работало в 2018 году, в 2026-м работает по инерции, к 2028 году не будет работать. Минимальный AI-контур — парсер заявок из чатов с автозаписью в CRM плюс бот первой линии — стоит 50–150 тыс. рублей разово и окупается за квартал. Дальше идёт диспетчерский слой с confidence по партнёрам и dynamic pricing v0 на правилах. Ровно эту механику — заявка квалифицируется за тридцать секунд, своя и партнёрская техника на одном экране, один менеджер ведёт парк — мы собрали как рабочий контур для аренды спецтехники: [посмотреть, как это устроено](https://temadev.org/specteh/?utm_source=geo_referral&utm_medium=ai&utm_campaign=rental-big-four-ai-russia-window-2026&utm_content=inprose). Второе — для руководителя направления в крупной компании, у которой rental — часть строительной или промышленной операции. Возможный тест: оцените, какой процент решений о выборе техники проходит через сравнение нескольких поставщиков. Если меньше 50% — вы не пользуетесь рынком, вы пользуетесь привычкой одного менеджера. К 2027 году платформенный слой (Авито + Transbaza + Диадок и преемники) сделает прозрачность default. Решение о подключении к этой экосистеме лучше принять до того, как она станет обязательной — переговорная позиция в двух случаях разная. Третье — для инженера или продукт-менеджера, рассматривающего вертикальный AI как направление. Конкретный тест: можно ли описать модель сущностей, статусов и инвариантов выбранной отрасли в одном документе размером 5–10 страниц без внутренних противоречий. Если нет — представления нет, и значит модель будет встраиваться в чужой UX (как в случае с Авито). Если есть — есть шанс на собственный диспетчерский слой и собственную позицию в стеке. Большая четвёрка строила эти представления десятилетиями; российский SMB-rental не строил их никогда, и это одновременно недостаток и форточка возможностей. Подробнее о том, почему горизонтальные AI-решения проигрывают вертикальным в B2B: [[/2026/04/harness-commodity-operating-layer]]. ## Три сигнала, по которым видно скорость закрытия окна Три сигнала, которые покажут, как закрывается окно. Первый — публичный запуск AI-чата или voice-агента на Авито Спецтехнике или внутри Transbaza, с привязкой к ЭДО. Это означает, что горизонтальная платформа закрыла customer-facing AI-слой и нишевый игрок остаётся снаружи. Второй — сделка между крупным rental-оператором (СтройТакси, Перевозка24) и одной из big tech (Яндекс или Сбер) о технологическом партнёрстве. Это означает консолидацию платформы и снижение независимой переговорной силы региональных арендодателей. Третий — появление публичного списка SMB-rental-компаний, опубликовавших собственный AI-контур (диспетчерский, dispatcher-mode, predictive «по симптомам»). Это означает, что окно ещё открыто, но конкуренция идёт уже не за концепцию, а за качество исполнения. Большая четвёрка прошла развилку «строить вертикальный слой или быть поставщиком в чужом UX» примерно в 2018–2020 годах и выбрала первое. Российский рынок проходит её сейчас. Здесь нет отрицательного ответа — есть только разный возраст ответа, и более ранний всегда стоит дешевле. ## Главное - United Rentals в 2025 году получала 76% выручки от клиентов, использующих digital-инструменты, и эта доля растёт примерно на 6 процентных пунктов в год; AI-функции (Smart Suggestions, Equipment Fit AR, predictive maintenance) уже встроены в основной customer-facing продукт. - Большая четвёрка строит двухслойную архитектуру: собственный customer-portal плюс интеграция с горизонтальными B2B-сетями (Trackunit, SmartEquip, ThingWorx). Никто не делает всё внутри — основная защищённая часть это нормализация данных и операционные процессы вокруг неё. - На российском рынке аренды спецтехники связка «Авито Спецтехника + Transbaza + Контур.Диадок» с августа 2025 года уже закрыла маркетплейс, нишевую CRM и ЭДО. Не хватает диспетчерского AI и dynamic pricing — обе компоненты технически доступны, но пока никем не запущены. - Окно для вертикального AI-слоя в российском rental сужается к 2027–2028 годам, после чего AI-чат, мобильное приложение клиента и автоматический ЭДО станут минимумом, а не дифференциатором. Компании, которые построят собственный диспетчерский слой раньше, сохранят прямой доступ к клиенту; остальные будут поставщиками техники в чужом UX. ## FAQ **Кто такие «большая четвёрка» в мировой аренде спецтехники?** United Rentals (США, ≈$16 млрд выручки), Sunbelt Rentals в составе Ashtead Group (UK, ≈$8 млрд+), Loxam (Франция, €2,47 млрд) и Herc Rentals (США, ≈$3 млрд). Это публичные операторы, которые в 2024–2025 годах публично заявили AI-функции в основных продуктах и публикуют операционные метрики этих функций. **Может ли United Rentals или Loxam выйти на российский рынок?** В горизонте 2026–2028 годов — нет. Loxam фокусируется на Европе, MEA и Латинской Америке, United Rentals — на США, Канаде, Австралии и UK. Санкционный режим и капиталоёмкость входа делают прямое присутствие маловероятным. Угроза приходит не от них, а от локальных аналогов, которые копируют архитектуру. **Чем Vertical AI отличается от обычного чат-бота?** Чат-бот — это интерфейс, способный отвечать на вопросы. Vertical AI — это операционный слой со своей моделью сущностей и статусов конкретной отрасли, в котором языковая модель работает как исполнитель шагов, а не как продукт. У чат-бота нет понятия «партнёр с confidence 0.7 и историей 12 месяцев». У вертикального слоя — есть, и именно это делает его трудно копируемым. **Что должен сделать средний rental-оператор в России в ближайшие 12 месяцев?** Минимум — закрыть две вещи: автоматический парсинг входящих заявок из чатов и Авито в CRM с временем реакции до 15 минут, и базовый рейтинг партнёров с confidence-метрикой, которая обновляется по факту сделок. Это закрывается бюджетом 50–200 тыс. рублей разово и 5–25 тыс. рублей в месяц на сопровождение, окупается на горизонте квартала. Всё остальное — диспетчерский слой, dynamic pricing, predictive по симптомам — стоит начинать после того, как закрыт этот минимум. --- ## Note 31: Конец «ИИ-интеграций под ключ»: куда уходят деньги, когда модель становится товаром **URL:** https://notes.temadev.org/2026/05/ai-studio-commoditization-cliff-2027.html **Published:** 2026-05-01 **Genre:** contrarian-take **Tags:** ai-agents, commoditization, pricing, b2b, russia, ai-studio **Words:** 2761 **Summary:** Стоимость работы моделей упала в 280 раз за два года. Этап внедрения «ИИ под ключ» исчезает в управляемых платформах. К 2027 рынок раскалывается на два полюса - товарный низ и отраслевой верх с обязательствами по результату. # Конец «ИИ-интеграций под ключ»: куда уходят деньги, когда модель становится товаром ## Цифра, после которой остальное - следствия За 23 месяца стоимость запуска моделей уровня GPT-3.5 упала с $20 до $0.07 за миллион токенов. Это сокращение в 280 раз ([Stanford HAI AI Index 2025](https://hai.stanford.edu/ai-index/2025-ai-index-report/research-and-development), [через анализ Tobias Pfütze](https://medium.com/@tobias_pfuetze/the-model-commoditisation-trap-2c137956d6b7)). Средняя цена корпоративного токена упала на 75% за один год - $10 → $2.50 в 2024-2025 ([Ramp Velocity](https://ramp.com/velocity/ai-is-getting-cheaper)). Ведущие модели дешевеют со скоростью 5-10× в год; уровни возможностей, превратившиеся в товар, - на 40-900× в год ([arXiv 2511.23455, ноябрь 2025](https://arxiv.org/abs/2511.23455)). DeepSeek V3 стоит $0.14 за миллион входных токенов против $3.00 у GPT-4o - минус 95% при сопоставимом качестве на большинстве корпоративных задач ([Silicon Canals](https://siliconcanals.com/sc-n-chinas-deepseek-triggers-global-ai-price-war-as-tech-giants-slash-api-costs/)). Это не пузырь и не маркетинговая флуктуация. Это S-образная кривая (классическая траектория зрелости технологии - медленный старт, резкий рост, насыщение), которую видели облачные вычисления, жёсткие диски, оптоволокно и до них - десятки технологических волн. Исторически такие кривые разворачивались только при регуляторном вмешательстве или физическом лимите ресурсов; в работе моделей ни того, ни другого не просматривается. ИИ-студия, продающая «ИИ-интеграцию под клиента» в 2026 году по тем же правилам, по которым она продавала её в 2024-м, продаёт продукт, себестоимость которого через 18 месяцев упадёт ещё в несколько раз - а его конкуренция переедет этажом выше: туда, где сидят управляемые сервисы Bitrix24, RetailCRM и Yandex AI Studio. Это не «рост рынка». Это обрыв превращения в товар - момент, когда продукт перестаёт различаться по бренду и его цена сходится к себестоимости. И механика у него ровно та же, что у веб-разработки в 2005 году и у SEO в 2015-м, - только сжатая в три раза по времени. ## Не первый раз: веб-разработка, SEO, цифровой маркетинг Каждое технологическое поколение проходит одну и ту же кривую: инновация → высокая маржа → инструментарий → платформы → гонка цен вниз для товарного слоя → выживают только специализированные ниши. Цикл одинаковый, разница - в скорости. | Отрасль | Период первичной маржи | Триггер товаризации | Что уцелело на премиальных ценах | |---|---|---|---| | Веб-разработка | 1995-2005 | Wix, Squarespace, WordPress | Заказная корпоративная разработка, e-commerce платформы, агентства с дизайнерским ядром | | SEO | 2005-2015 | Обновления Google + контент-инструменты | Отраслевой SEO (legal, medical), оптимизация под поисковые системы с ИИ | | Цифровой маркетинг | 2008-2018 | Самообслуживаемые рекламные платформы | Работа на больших объёмах, бренд-стратегия | | ИИ-сервисы | 2023-2027? | Превращение LLM в товар + управляемые платформы | Открытый вопрос | Каждая из предыдущих волн занимала пять-десять лет. ИИ-волна сжата до 24-36 месяцев по трём причинам: товаризация идёт не через open-source-копии, а через прямое снижение цен у самого провайдера; платформы исполнения (Bitrix24, RetailCRM, Yandex AI Studio) уже встроены в стек клиента; генеративные инструменты ускоряют сами агентства, и они конкурируют сами с собой. Boutique Consulting Club описывает это как сжатие с двух сторон. Смысл их тезиса: ИИ обесценивает кодифицируемые задачи, а платформы исполнения двигаются вверх по цепочке, упаковывая лёгкий консалтинг в свои продукты ([эссе Danilo Kreimer, основателя Boutique Consulting Club](https://www.boutiqueconsultingclub.com/essays/escape-routes-for-experts-in-an-ai-first-world)). Сверху давит платформенная упаковка, снизу - обнуление кодифицируемой работы. Их прогноз к 2035 году: кодифицируемая работа низкой сложности сохранит 10-20% человеческого присутствия, типичное беспорядочное внедрение - около 33%, стандартная стратегическая работа - 20-30%, сложные трансформации - около 50%. Сроки - 1-3 года для простых задач, 3-6 лет для среднего по сложности интеллектуального труда. Параллельный сигнал из маркетингового сектора: Productive.io опросили 180+ агентств в ноябре 2025 - около трети уже получили запросы на «ИИ-скидку», ещё половина ждут такие запросы в ближайшие месяцы ([Productive.io](https://productive.io/blog/agencies-in-the-ai-era/)). Search Engine Land формулирует это короче: агентства внедряли ИИ ради экономии, но клиенты сделали то же самое - и теперь ожидания растут, бюджеты сжимаются, а ценность подвергается проверке ([Search Engine Land, апрель 2026](https://searchengineland.com/ai-squeezing-marketing-agencies-472189)). Себестоимость падает быстрее, чем цена. Это финансовое определение сжатия. Историческая параллель полезна для калибровки ожиданий. В 2005 году средняя цена корпоративного сайта в Москве была 150-500 тысяч рублей; к 2012 году WordPress + готовая тема + фрилансер закрывали тот же объём за 20-40 тысяч. Уцелели те, кто переехал в e-commerce-платформы для крупных ритейлеров и в продуктовый дизайн. Та же геометрия повторилась в SEO между 2010 и 2018: дешёвая оптимизация on-page ушла в $200-500, а специализированный legal или medical SEO со знанием нормативных требований закрепился на $10-15K в месяц. Средний слой исчез не из-за падения спроса, а потому, что спрос распался на два класса - самообслуживание и отраслевую экспертизу. ## Что уже произошло в РФ - а не «может произойти» Главная ошибка в обсуждении товаризации - говорить о ней в будущем времени. В русском B2B нижняя планка абонементного уровня уехала вниз уже сейчас. Yandex AI Studio - это управляемая платформа Яндекса для сборки LLM-агентов поверх YandexGPT и внешних моделей без кода. Она в связке с SpeechKit покрывает четыре сценария применения, на которых живёт средняя ИИ-студия в РФ: квалификация лидов, контроль закрытий сделок, реактивация отказников, мониторинг скорости ответа по SLA. Стоимость для команды 10-15 менеджеров - 12 000-30 000 ₽/мес из коробки ([vc.ru / Salekit, апрель 2026](https://vc.ru/life/2864011-integratsiya-yandex-ai-studio-v-crm)). Маркетплейс Bitrix24 содержит [подборку ИИ-приложений и агентов](https://www.bitrix24.ru/apps/?tag=ai) от сторонних разработчиков - часть бесплатна, часть стоит 5-15 K ₽/мес как надстройка к основной подписке. RetailCRM штатно [предлагает ИИ-агентов](https://www.retailcrm.ru/chatbots) внутри тарифа, без отдельной интеграции. В США тренд тот же: Salemwise приводит ориентир базовой ИИ-автоматизации для SMB - $500-5 000 единоразово плюс $49-500 в месяц. То есть в долларовом эквиваленте дешёвый абонемент уже сейчас стоит 4 000-40 000 ₽/мес. Это меняет арифметику разговора с клиентом. До 2025 года ИИ-студия могла честно сказать: «то, что мы делаем, нельзя купить как продукт». В 2026-м у клиента уже открыта вкладка с [маркетплейсом Bitrix24](https://www.bitrix24.ru/apps/?tag=ai), и он видит там ИИ-помощника за 7 000 ₽/мес. Чтобы продать ту же базовую интеграцию по типичному студийному ориентиру ([разбор бюджетов внедрения ИИ на vc.ru](https://vc.ru/ai/2282231-stoimost-vnedreniya-ii-v-biznes)), нужно объяснять разницу, а разница больше не очевидна, потому что обвязка модели теперь товар ([«Когда обвязка становится товаром»](/2026/04/harness-commodity-operating-layer.html)). Прогноз на 2027-2028, основанный на текущей траектории цен и платформенной активности: | Категория | Сегодня (2026) | 2027-2028 | |---|---|---| | Внедрение «подключить ИИ к CRM», ≤3 сценария | рыночный разброс от фрилансера до студии ([vc.ru обзор бюджетов](https://vc.ru/ai/2282231-stoimost-vnedreniya-ii-v-biznes)) | Товарная нижняя планка сжимается к стоимости управляемых платформ; премиальное внедрение выживает только как архитектурный аудит | | Абонемент «поддержка ИИ-агента» | управляемые сервисы 12-30 K ₽/мес ([Yandex AI Studio + SpeechKit](https://vc.ru/life/2864011-integratsiya-yandex-ai-studio-v-crm)); студийный абонемент сверху | Нижняя планка сближается с ценой управляемых платформ; премиум выживает только за ответственность за бизнес-результат | | Внедрение «ИИ-операционная система внутри отрасли» | на порядок выше товарного внедрения, под конкретный операционный ландшафт | Растёт в связке с ростом сложности управления и нормативных требований | | Абонемент «отраслевой ИИ-контур с обязательствами по результату» | редкая категория на рынке РФ в 2026 | Стандартный формат отраслевого верха: база + % от результата | Это и есть форма обрыва: рынок раскалывается на два слоя - товарный низ и отраслевой верх. Среднего слоя, в котором сейчас живёт большинство российских ИИ-студий, через 18-24 месяца не будет. ## Что не схлопывается под давлением товаризации? Защитная геометрия. Из четырёх независимых источников за последний год - [BVP AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook), [Pfütze](https://medium.com/@tobias_pfuetze/the-model-commoditisation-trap-2c137956d6b7), [Euclid Ventures о защитном рве в отраслевом ИИ](https://insights.euclid.vc/p/dude-wheres-my-moat), [Boutique Consulting Club](https://www.boutiqueconsultingclub.com/essays/escape-routes-for-experts-in-an-ai-first-world) - сходится один консенсус: после товаризации модели и обвязки остаются три источника отличия, и ни один из них не покупается у поставщика. **Контекст и качество данных.** То, что компания накопила внутри себя за годы: исторические решения, паттерны клиентов, нормативный контекст, граничные случаи. [BigDATAwire 2026 enterprise predictions](https://www.hpcwire.com/bigdatawire/2026/01/05/2026-enterprise-data-predictions-context-capitalism-the-meaning-layer-the-data-activation-shift/) формулируют это как «context capitalism» («капитализм контекста»): отличие смещается от доступа к модели к точности понимания реальных операций бизнеса. ИИ-студия не владеет этими данными, но может построить контур, который их захватывает и кодифицирует, - и тогда контур становится живым активом клиента, а не отчуждаемым артефактом. **Архитектура рабочего процесса.** Где сидят контрольные точки управления, как результаты модели верифицируются до того, как они влияют на бизнес, какие триггеры эскалации, какие правила ценообразования, какие исключения допустимы. [StackAI 2026 enterprise adoption](https://www.stackai.com/insights/enterprise-ai-adoption-2026-trends-benchmarks-and-best-practices-for-scalable-success) называет это «repeatability - ability to deliver one governed workflow and replicate it 20 times» (повторяемость - способность выстроить один управляемый рабочий процесс и тиражировать его двадцать раз) и определяет как ключевой стратегический актив. Это не задача, которую решает Agent Builder. Это задача, которую решает человек, неделями сидящий внутри операции конкретной компании. **Доверие и ответственность за результат.** Кто отвечает, если ИИ ошибся. Кто согласует с регулятором. Кто поддерживает культурные изменения. Boutique Consulting Club пишет об этом без эвфемизмов: уцелеет именно человеческая, неудобная часть - внутренняя политика, выстраивание доверия, тонкое искусство договариваться с теми, кто сам по себе. Деталь, которую в дискуссиях о товаризации пропускают: средний слой схлопывается всегда, но _оба полюса_ становятся жёстче. Товарный низ дешевеет быстрее, чем показывает публичный рынок; отраслевой верх дорожает быстрее, чем это видно снаружи. Та же динамика наблюдалась в SEO: к 2018 году дешёвая оптимизация on-page стоила $200-500, а специализированный legal SEO со знанием нормативных требований - $15 000+ в месяц. Разрыв вырос, не сжался. ## Почему сближение возможностей моделей обнуляет «выбор стека» как продукт Ещё один сигнал, который меняет правила воронки. На SWE-bench Verified - наиболее достоверном практическом ориентире для оценки моделей в задачах разработки в 2026 году - топ-5 моделей разделены 1.3 процентного пункта, что [Smartscope](https://smartscope.blog/en/generative-ai/chatgpt/llm-coding-benchmark-comparison-2026/) называет «фактической ничьей». Сближение возможностей на уровне ведущих моделей означает, что выбор модели перестал быть стратегическим решением. Это просто выбор уровня: дороже-точнее или дешевле-почти-как. Для агентств, которые строили часть своего авторитета на «мы знаем, какую модель брать под какую задачу», это плохая новость. Эта экспертиза обнуляется. Но домен и контекст - нет. Pfütze формулирует это так: каркас, контекст и обвязка агента определяют результат сильнее, чем интеллект самой модели. В 2024 году это было наблюдением. В 2026-м - это рабочая гипотеза для всей стратегии монетизации в B2B-ИИ. ## Что это значит на практике для ИИ-студии в 2026 Логичный шаг - не переписывать страницу с ценами, а переписать определение того, что продаётся. Первое: внедрение перестаёт быть «технической интеграцией» и становится «архитектурным аудитом и проектированием рабочих процессов». Тот же объём работы, но с другой формой ценности. Аудит - это не «подключим API», а «опишем, какие сущности первичны в вашей операции, где точки верификации, какие данные траекторий мы будем собирать с первого дня, как будет выглядеть слой представления через шесть месяцев». Это работа, которую Agent Builder не делает и не сделает - потому что Agent Builder не сидит внутри клиентской операции. Второе: абонемент перестаёт быть «поддержкой агента» и становится «управлением ИИ-контуром с метриками результата». Здесь критичен сдвиг в формулировке SLA. Не «время ответа на тикеты» и не «процент бесперебойной работы агента», а измеримый бизнес-исход - время до контакта с лидом, конверсия на этапе квалификации, доля реактивированных отказников, потерянные заявки в неделю. То, что попадает в финансовую отчётность клиента, а не в дашборд интегратора. И, как часть того же абонемента, гибридный компонент - % от результата поверх базы. Это убивает позиционирование «мы такие же, как Yandex AI Studio, только дороже» и заменяет его на «мы берём деньги за результат, а не за инфраструктуру». Ровно такие контуры - один измеримый процесс, который система ведёт сама, - мы и собираем как рабочие системы, а не пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=ai-studio-commoditization-cliff-2027&utm_content=inprose). Третье - и это структурно важнее первых двух: отраслевой подход, а не универсальный. ИИ-студия, которая знает один-два рынка глубоко, не попадает в сжатие, потому что её защита - не код, а отраслевой контекст. Владельцы небольших операционных бизнесов в РФ не покупают «ИИ». Они покупают решения конкретных операционных болей: потерянные заявки, медленная диспетчеризация, потеря клиента после первого касания, ручная сверка по складу. Между «ИИ-агент» и «потерянная заявка» лежит пропасть, которую закрывает не модель, а человек, понимающий конкретный бизнес. Boutique Consulting Club приводит ту же мысль в формате четырёх маршрутов выхода: либо ты уходишь в глубину (узкая отрасль), либо в ответственность за результат (берёшь обязательство по бизнес-метрике), либо в доверие (становишься частью команды клиента, а не подрядчиком), либо в собственные продукты (строишь продукт, не сервис). Все четыре маршрута имеют общее свойство - они не масштабируются за счёт SDK. Они масштабируются только за счёт человеческого контакта с конкретной операционной средой. ## Что мы будем наблюдать Несколько сигналов, которые покажут, в какую сторону рынок движется быстрее, чем ожидается. Первый - публичные кейсы в маркетплейсах Bitrix24, RetailCRM, AmoCRM. Когда управляемый ИИ начнёт показывать измеримые результаты (не «внедрили ИИ», а «сократили время до первого контакта на 40%»), нижняя планка абонементного сегмента сдвинется ещё ниже - потому что у клиента появится ориентир, против которого он будет считать стоимость работы студии. Второй - появление ценообразования по результату у заметных российских ИИ-студий. [BVP AI Pricing Playbook](https://www.bvp.com/atlas/the-ai-pricing-and-monetization-playbook) фиксирует этот сдвиг в США с 2024-2025: контракты с оплатой по результату выросли с ~5% до ~15% выборки за 18 месяцев. Рынок РФ почти целиком живёт в оплате по часам и материалам или по схеме «внедрение плюс абонемент»; первый, кто публично закроет крупный контракт по схеме «процент от вынесенного в SLA бизнес-результата», задаст рамку, в которую остальные будут вынуждены войти. Третий - поведение Bitrix24, RetailCRM и Yandex AI Studio в части отраслевых шаблонов. Если они начнут выпускать готовые шаблоны под конкретные ниши (стройка, медицина, ритейл), это сожмёт окно для универсальных агентств ещё на 6-9 месяцев. Если останутся на универсальных конструкторах - окно открыто чуть дольше. Четвёртый - публичные данные по запросам на «ИИ-скидку». Productive.io уже [зафиксировали тренд в США и Европе](https://productive.io/blog/agencies-in-the-ai-era/). Аналогичный замер в РФ появится в течение 2026 года, и его значение будет важнее, чем большинство инвесторских прогнозов. Пятый - динамика зарплат внутри ИИ-студий. Если в 2026-2027 средняя ставка инженера среднего уровня по интеграции LLM начнёт расти медленнее общего IT-индекса в РФ, это сигнал, что бюджеты на универсальную интеграцию ужимаются на стороне клиента. Та же метрика срабатывала в SEO в 2014–2015 годах за 9–12 месяцев до того, как сжатие маржи стало очевидным в публичных финансовых отчётах агентств. ## Что остаётся, когда обесценивающееся уходит вниз Главный практический вывод не в том, что ИИ-студии умрут к 2027 году: параллель с веб-разработкой показывает, что большинство выживает при падении среднего чека в 7-10 раз. Важнее, что между 2026 и 2028 рынок проходит через перераспределение выручки, и пропорция «универсальное против отраслевого» инвертируется. Универсальная интеграция ИИ к CRM - основная масса бизнеса в 2024-м - к 2027 году станет товаром внутри [Yandex AI Studio](https://vc.ru/life/2864011-integratsiya-yandex-ai-studio-v-crm), Bitrix24 AI и [RetailCRM](https://www.retailcrm.ru/chatbots), и маржа уйдёт в платформы. Отраслевой ИИ-контур с обязательствами по результату внутри одной отрасли, выглядевший узкой нишей в 2024-м, к 2027 году станет основной формой устойчивой маржи в секторе. ИИ-студии, которые рассчитывали «делать всё для всех», в этой рамке теряют экономику. Выживают те, кто готов сидеть внутри одной операционной реальности достаточно долго, чтобы накопить контекст, который не помещается в API. Про экономику без внешнего капитала в такой модели мы писали отдельно - «[Три клиента вместо раунда](/2026/04/bootstrapped-b2b-ai-retainer-vs-venture.html)». Узкий рынок, который большинство сейчас называет ограничением, через 24 месяца окажется единственным местом, где осталась маржа. Средний слой рынка исчезает не потому, что исчез спрос на ИИ в B2B, а потому, что спрос распался на товарный низ и отраслевой верх. ИИ-студия, которая перестаёт продавать «ИИ-интеграцию под ключ» и начинает продавать измеримый бизнес-результат в одной отрасли, попадает в верхний полюс до того, как этот полюс закроется. ## Главное - **280× за 23 месяца.** Стоимость работы моделей уровня GPT-3.5 упала с $20 до $0.07 за миллион токенов. Это S-образная кривая, из которой нет разворота. - **Нижняя планка абонемента уже уехала.** Yandex AI Studio, Bitrix24, RetailCRM закрывают базовые сценарии за 12-30 K ₽/мес - у клиента появился сравнительный ориентир, против которого он считает стоимость работы студии. - **Рынок раскалывается на два полюса.** Товарный низ дешевеет быстрее, отраслевой верх дорожает. Средний слой - «ИИ-интеграция под ключ» - исчезает. - **Что уцелеет.** Отраслевой верх с обязательствами по бизнес-результату, контекст и качество данных клиента, архитектура верифицируемых рабочих процессов, ответственность за бизнес-исход. Выбор модели и проектное внедрение - не уцелеют. ## Частые вопросы **Правда ли, что этап внедрения ИИ-проектов исчезнет к 2027 году?** Исчезнет не внедрение как таковое, а внедрение в нынешней форме «подключить LLM к CRM под ключ» за 150-350 K ₽. Под давлением управляемых платформ эта работа переводится в товарную нижнюю планку 30-80 K ₽. Премиальное внедрение сохранится только как «архитектурный аудит и проектирование рабочих процессов» внутри конкретной отрасли. **Чем абонемент в отраслевом верху отличается от «поддержки агента»?** Формой SLA. Не «бесперебойная работа бота» и «время ответа на тикеты», а измеримый бизнес-исход: время до первого контакта с лидом, конверсия на квалификации, доля реактивированных отказников, потерянные заявки в неделю. Часть вознаграждения, привязанная к результату, - обязательный элемент защиты от сравнения с управляемыми платформами. **Можно ли выжить как универсальная ИИ-студия?** Можно, но на порядок меньшей выручке и на рынке клиентов, которые сравнивают вас с Bitrix24 AI и Yandex AI Studio. Историческая параллель - агентства веб-разработки 2010-х, которые выжили как универсальные: их средний чек упал в 7-10 раз. **Применима ли эта логика к РФ в условиях 152-ФЗ и суверенизации стека?** Да. Yandex AI Studio, GigaChat и RetailCRM решают вопрос локализации и соответствия регулированию внутри управляемой платформы - то есть суверенизация сама по себе ускоряет товаризацию, потому что выбивает у универсального интегратора один из сильных аргументов. **Что делать сейчас, если вы — средняя универсальная студия?** Выбрать одну отрасль из тех, где уже есть 2–3 проекта. Закрыть в ней 1–2 операционных боли до измеримого результата. Переформулировать абонемент в обязательство по бизнес-результату. И в течение 12 месяцев накопить отраслевой контекст. --- ## Note 32: Три клиента вместо раунда: экономика bootstrapped B2B AI в 2026 **URL:** https://notes.temadev.org/2026/04/bootstrapped-b2b-ai-retainer-vs-venture.html **Published:** 2026-04-30 **Genre:** market-deep-dive **Tags:** bootstrapping, b2b-ai, unit-economics, retainer, vertical-ai, russia **Words:** 2016 **Summary:** 3–5 ретейнер-клиентов в одной вертикали дают основателям большую ожидаемую долю при выходе, чем seed-раунд $500K–1M в B2B AI в 2026 году. # Три клиента вместо раунда: экономика bootstrapped B2B AI в 2026 Команда из двух инженеров и одного оператора, ведущая трёх клиентов на ретейнере по 300–500 тыс. ₽ в месяц в одной вертикали, выходит на годовую выручку 10–18 млн ₽ с операционной маржой 55–65%. Та же команда, поднявшая seed-раунд $500K–1M на 15–20% долей, получает примерно тот же кэш на счёте, но другой набор обязательств: рост в 3–5 раз за 18 месяцев, найм, борд, отчётность. В 2025–2026 годах venture-фонды посеяли в B2B AI рекордные суммы — по данным [Crunchbase](https://www.crunchbase.com/) на ранние стадии AI пришлась рекордная доля seed-капитала в США, — и обычная медианная дилюция на seed для B2B AI остаётся в коридоре 15–22%. Арифметика простая: при выходе $20M по сценарию ретейнер-модели основатели держат 100%, при том же выходе после двух раундов — около 45–55%. Чтобы оправдать второй сценарий, исход должен быть кратно больше первого, и желательно — реалистично кратно. ## Где модель ретейнера переигрывает раунд Главный аргумент в пользу bootstrapped-пути для вертикального B2B AI лежит не в идеологии, а в структуре издержек. Современный AI-стек 2026 года сместил инженерную плотность вниз, к платформам: harness, память, оркестрация, маршрутизация инструментов теперь продаются как managed-сервисы тремя крупнейшими провайдерами. Команда, которая ещё в 2023 году тратила полгода на собственный orchestration-слой, теперь собирает его за неделю. Это меняет сам смысл «масштабирования»: то, что венчурный фонд оплачивает как «инженерный найм», у вертикального игрока схлопывается в две лицензии и одного техлида. При этом ретейнер 300–500 тыс. ₽ в месяц в нишевом сегменте перестал быть экзотикой. На смежных рынках — vertical SaaS, специализированные сервисы — устойчиво держится наблюдение, что узкая ниша платит премию 30–40% к универсальному продукту, потому что универсальный не закрывает граничные случаи. Jason Cohen, построивший за двадцать пять лет два «единорога» (один bootstrapped, один venture-funded), формулирует это в [серии эссе про стратегию](https://longform.asmartbear.com/categories/strategy/) одной фразой: bootstrapping — это не отсутствие капитала, это другая теория роста, в которой клиент платит за компанию через выручку, а не через раунд. И в этой теории первая задача — не «найти продакт-маркет фит», а удерживать узкую нишу достаточно долго, чтобы отчуждаемые ноу-хау превратились в неотчуждаемое представление о вертикали. ## Почему bootstrapping в B2B AI — стратегия, а не нехватка? Стоит сразу разделить два понимания. **Bootstrapping как нехватка** — это «у нас не получилось поднять раунд, мы крутимся как можем». В этом прочтении ретейнер выглядит бедной альтернативой — вынужденной формой выживания без инвесторского ресурса. **Bootstrapping как стратегия** — это сознательный выбор: оптимизировать ожидаемую долю основателя в исходе, а не темп роста. Эти траектории различаются не объёмом выручки, а тем, какая переменная считается константой. Венчурная компания фиксирует темп и подбирает капитал; bootstrapped-команда фиксирует капитал и подбирает темп под устойчивые unit-economics. Для B2B AI это различие усилено двумя факторами 2026 года. Первый — себестоимость инфраструктуры падает быстрее, чем растут потребности, так что capex-аргумент в пользу раунда («нам нужны деньги, чтобы построить продукт») у вертикальной команды слабый. Второй — exit multiples в B2B SaaS вернулись к 4–6× ARR на средних чеках, что делает арифметику долей решающей: выход $30M даёт основателю-100% в три раза больше, чем основателю-33% после трёх раундов. Эту арифметику любят прятать за разговорами про «мы строим что-то большое», но она железна. ## Что меняет вертикальная ниша Тезис «ретейнер сильнее раунда» работает не везде. Он работает там, где у клиента есть структурный switching cost к смене поставщика, а у поставщика — реалистичный путь его создать без масштабирования. Forbes в эссе [The Moat Is Moving](https://www.forbes.com/sites/sanjaysrivastava/2026/03/04/in-ai-the-moat-is-moving/) формулирует это сжато: в 2026 защитимыми остаются три слоя — институциональный регламент клиента, данные траекторий «вход → решение → исход» и глубокая интеграция в окружение. Все три слоя строятся через работу внутри клиента, не через найм. Здесь важная деталь, которую обычно пропускают сторонники венчурной модели. Эти три слоя нельзя купить через найм быстрее, чем через работу. Команда из двадцати инженеров не построит world model вертикали быстрее, чем команда из двух — потому что узким местом является не инженерный труд, а доступ к реальным операциям клиента. Foundation Capital в эссе [Service-as-Software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) описывает это как «кодификацию экспертизы»: продаётся не инструмент, а готовая работа, и качество готовой работы определяется глубиной погружения, а не размером команды. Из этого следует операционная арифметика, которая редко звучит в инвестиционных дисках. Если три клиента в одной вертикали приносят 12–18 млн ₽ в год при марже 55–65%, и каждый следующий клиент в той же вертикали даёт компаундирующий эффект на discovery следующего, то предельная стоимость пятого клиента в воронке оказывается ниже, чем первого. Это — обратная сторона CAC-кривой, которой нет у компании, продающей универсальный продукт. У вертикального игрока CAC падает с глубиной ниши; у горизонтального — растёт. Этот эффект перекликается с тезисом о том, что в 2026 году [валентность харнесса и операционного слоя разошлась](/2026/04/harness-commodity-operating-layer.html): инфраструктурный слой (managed orchestration, agent runtimes, vector storage) коммодитизировался, а операционный — представление клиента, его регламент и история решений — остался в руках того, кто работает внутри. Для бутстрап-команды это означает, что она играет на правильной стороне рынка: стоимость создаётся в работе с клиентом, а не в развороте платформы. Чем ближе команда к операциям клиента, тем сильнее её позиция. Капитал здесь не ускоряет работу — он либо переплачивает за ту же работу (больше людей на тот же клиент), либо пытается параллелизировать выход в новые вертикали раньше, чем рынок этого хочет. Первое размывает маржу, второе ломает глубину и откатывает команду к средним отраслевым показателям из венчурного сценария. ## Арифметика дилюции и реалистичные исходы Стандартный seed-раунд для B2B AI команды без revenue в 2025–2026 годах в Соединённых Штатах — это 15–22% дилюции по верхней границе. Если за seed следует Series A на 18–24% и затем поздние раунды плюс option pool, типовой основатель к моменту exit держит 25–40%. Harvard Business Review ещё в [Six Myths About Venture Capitalists](https://hbr.org/2013/05/six-myths-about-venture-capitalists) показал, что медианная доходность венчурного фонда в долгосрочном горизонте находится примерно на уровне публичного рынка; это значит, что распределение исходов сильно скошено: единицы возвращают фонд, остальные не возвращают. Для основателя это переводится в строгий язык: венчурный путь оправдан только если ваш ожидаемый исход кратно больше bootstrapped-исхода с поправкой на дилюцию. Конкретно. Если bootstrapped-сценарий реалистично выводит на ARR 30–50 млн ₽ за три года при 100% доле, ожидаемая стоимость доли основателя при выходе — порядка 120–250 млн ₽. Чтобы венчурный сценарий обогнал, при доле 30% после раундов компания должна стоить 400–800 млн ₽. Это не невозможно, но это — статистический отлёт, не базовый сценарий, и в B2B AI 2026 года таких выходов в России единицы. Для большинства команд второй сценарий хуже первого по математическому ожиданию, и это вопрос арифметики, а не самооценки. Отдельный аргумент — структура власти после раунда. [Сообщество Indie Hackers](https://www.indiehackers.com/) последние три года систематически документирует обратную сторону венчурной сделки: сменяемость планов, давление на найм, разрыв между темпом роста, который требует фонд, и темпом, который выдерживают unit-economics. Bootstrapped-команда оптимизирует под одного клиента; venture-команда вынуждена оптимизировать под третий и пятый раунды, которых ещё нет. Эта разница в горизонте формирует, какие решения вообще можно принимать. ## Как удерживать ретейнер дольше CFO-сезона Ретейнер-модель работает только при ответе на вопрос «что будет на 6-й и на 12-й месяц». В B2B AI churn концентрируется в двух окнах: месяц 4–6 («wow wore off», champion leaving, внутренние команды клиента считают, что справятся сами) и месяц 7–12 (бюджетный пересмотр, AI-fatigue, накопленные подписки, давление CFO). На западных рынках бенчмарк здоровой компании — Harvey в legal AI: gross revenue retention 98%, net dollar retention 167% при firmwide adoption и более ста новых функций в квартал. На российском рынке таких бенчмарков пока нет, и это означает, что играют сильнее не те, кто занимается «развитием продукта», а те, кто строит switching cost внутри клиента. Технически это сводится к трём слоям. Первый — workflow-замок: команда клиента ведёт работу через контур поставщика, не возвращаясь к старым таблицам и переписке. Второй — слой представления: какие сущности первичны, какие у них статусы, что считается дублем, что — исключением. Этот слой команда поставщика может выгружать как отдельный артефакт, и без него любая попытка перевести операции к конкуренту разрушает половину истории. Третий — траектории решений: закрытый цикл «вход → решение агента → исход через дни или недели». Эти данные нельзя восстановить копированием промпта, потому что они привязаны к конкретным операциям конкретного бизнеса. Bootstrapped-команда в этой модели имеет неочевидное преимущество. Венчурный игрок вынужден агрессивно расширять воронку, ставит цели по логотипам и теряет внимание к глубине внутри каждого клиента. Команда, у которой клиент = 20–30% выручки, вынуждена делать обратное: каждое внедрение — это инвестиция в multi-year retention, и качество слоя представления у такого игрока выше по структурным причинам. ## Тёплая сеть как канал, а не как недостаток Стандартный аргумент против bootstrapped-модели звучит так: «без капитала вы не построите воронку». Это утверждение основано на предположении, что воронка строится через performance-маркетинг, а не через сеть. В B2B AI 2026 года это предположение чаще ложно, чем истинно. Реферальные лиды конвертируются в три–четыре раза выше, чем платный трафик; B2B-команды, заходящие через тёплый контакт, имеют существенно более короткий sales-цикл и существенно более высокий retention в первые шесть месяцев. Эту картину последовательно показывают и западные публикации, и наблюдения в нишевых российских вертикалях, где первый клиент чаще приходит через рекомендацию, чем через холодный контакт. Для команды с 3–5 клиентами на ретейнере это означает, что воронка вообще не должна быть построена на оплачиваемых каналах. Достаточно тёплой сети первого клиента и одного-двух партнёров с релевантной отраслевой репутацией. Каждое успешное внедрение в одной вертикали кратно увеличивает доверие в этой вертикали — потому что в нишевых рынках все знают всех. Это и есть обратная сторона «недостатка масштаба»: то, что у горизонтального игрока становится узким местом, у вертикального — каналом. ## Что это значит для технического основателя сегодня Для команды, выбирающей между поиском seed-инвестора и поиском второго клиента весной 2026, полезно прогнать четыре проверки. Первая — на чём вы держите тезис о росте. Если он держится на «нам нужно собрать команду из 15 человек, чтобы построить продукт», стоит честно ответить, какая часть этой команды в 2026 году заменяется managed-сервисами и одной лицензией. Вторая — кто платит за время. В bootstrapped-модели за время платит клиент, через ретейнер; в венчурной — фонд, через дилюцию. Это разные обязательства и разная свобода маневра. Третья проверка — структура moat. Если ваш moat — это институциональный регламент клиента, данные траекторий и интеграция в его окружение, размер команды не делает moat быстрее. Он делает только дороже. Четвёртая — вероятность исхода. Bootstrapped-сценарий с 3–5 клиентами в одной вертикали через три года выходит на ARR, который реально продаваем стратегу или PE-фонду, и эта продажа возвращает основателю 100% доли. Венчурный сценарий требует исхода в три–шесть раз больше, чтобы окупить дилюцию. На большинстве рынков B2B AI в 2026 году этот множитель находится в области статистических хвостов. Если в такой команде нужен инженер, который доведёт этот AI-контур до рабочего состояния без раздувания штата — [как я встроюсь в команду](https://temadev.org/hire/?utm_source=geo_referral&utm_medium=ai&utm_campaign=bootstrapped-b2b-ai-retainer-vs-venture&utm_content=inprose). Для рынка в целом это значит, что роль вертикальных AI-команд недооценена. Венчурный нарратив 2024–2025 годов сделал «горизонтальные платформы» главным жанром, в котором ходили деньги. К 2026 году видно, что значительная часть прикладной ценности AI создаётся не там. Jack Dorsey в [акционерном письме Block](https://www.theguardian.com/technology/2026/feb/27/block-ai-layoffs-jack-dorsey) написал в феврале 2026, что «инструменты интеллекта изменили, что значит строить и управлять компанией», и сократил 4 000 позиций. Это иллюстрация большего сдвига: компании больше платят за готовую работу, не за инструмент. Готовую работу делают вертикальные команды. Венчурный капитал на горизонтальном уровне работает плохо. Стоит отметить, что эта логика не уникальна для AI. Jason Cohen в [разборе product-market fit](https://longform.asmartbear.com/product-market-fit/) и в [колонках по стратегии startup](https://longform.asmartbear.com/categories/strategy/) систематически показывает, что интересы фонда и интересы основателя оптимизируют разные функции полезности: фонд — распределение исходов по портфелю и «fat tail»-выбросы, основатель — ожидаемую долю в одном конкретном исходе своей компании. Эти функции совпадают только в узком коридоре hyper-growth-ставок, который в вертикальном B2B AI 2026 выпадает редко. Для основателя, оптимизирующего ожидаемую долю, рациональным является режим среднего роста, высокой маржи и отсутствия размывающего капитала. Ретейнер-модель в нише — довольно точный инструмент для именно этого режима. ## Главное - Для вертикальной B2B AI команды в 2026 году путь к 10–18 млн ₽ ARR через 3–5 ретейнер-клиентов даёт более высокую ожидаемую долю основателя в исходе, чем seed-раунд $500K–1M c дилюцией 15–22%, при сопоставимом кэше на счёте. - Падение себестоимости harness-слоя (managed-сервисы Anthropic, OpenAI, Google, AWS) уничтожило capex-аргумент в пользу раунда: масштабирование команды больше не строит moat быстрее, чем работа внутри клиента. - Switching cost в B2B AI создаётся в трёх слоях — workflow-замок, слой представления, траектории решений — и все три строятся через глубину, а не через найм. - Bootstrapped-команда структурно лучше удерживает ретейнер: 20–30% выручки в одном клиенте создают давление на качество слоя представления, которого нет у венчурного конкурента. - Тёплая сеть и реферальный канал в нишевых вертикалях обгоняют performance-маркетинг по конверсии и retention, что снимает главный аргумент против bootstrapped-модели — «нет денег на воронку». ## FAQ **Когда раунд всё-таки имеет смысл?** Когда продукт действительно горизонтальный, требует синхронного масштабирования инфраструктуры с ростом клиентской базы, и где скорость выхода на рынок критична из-за окна возможностей. В вертикальном B2B AI с retainer-моделью таких условий обычно нет. **Что если клиент уйдёт через 6 месяцев?** Это самый болезненный риск ретейнер-модели и единственный, который нужно решать инженерно, а не финансово. Окно churn концентрируется в месяцах 4–6 и 7–12. Защита строится через интеграцию в ежедневный workflow клиента, накопление траекторий с первого дня и проактивный ROI-обзор за месяц до бюджетного пересмотра. **Можно ли вырасти за пределы 3–5 клиентов без раунда?** Да, до 10–15 клиентов в одной вертикали при команде 4–6 человек — это устойчивый сценарий при марже выше 50% и реинвестировании в найм. Дальнейший рост требует либо прихода второго оператора (партнёра), либо осознанного перехода в платформенную модель — и тогда обсуждение раунда становится содержательным, потому что у компании уже есть данные траекторий и доказанный retention. **Как продать компанию из bootstrapped-модели?** Стратегу или PE-фонду по мультипликатору 4–6× ARR. Главный фактор оценки — качество retention и глубина switching cost, а не темп роста. Компания с 25 млн ₽ ARR при net dollar retention 110%+ и gross revenue retention 90%+ продаётся лучше, чем компания с 50 млн ₽ ARR при тех же метриках на уровне 95% и 75% соответственно. --- ## Note 33: Расписание важнее дорожной карты: где живёт работа в компании на агентах **URL:** https://notes.temadev.org/2026/04/raspisanie-vazhnee-dorozhnoj-karty.html **Published:** 2026-04-29 **Genre:** concept-piece **Tags:** ai-native, operations, cron, scheduling, agents, ops **Words:** 2480 **Summary:** В компании на агентах расписание точнее отражает операционную реальность, чем дорожная карта: агенты работают по циклам, а не по спринтам. # Расписание важнее дорожной карты: где живёт работа в компании на агентах ## Что показывает расписание команды из трёх человек В одной агентной команде, наблюдаемой с весны 2026, GitHub Issues открывают примерно раз в неделю. Расписание (`crontab`) смотрят каждый день. В нём 23 активные записи: проверка воронки в 9:00, ночной дайджест исследований в 02:00, проверка состояния агентов каждые два часа, еженедельный отчёт по базе знаний в понедельник в 7:30. Полный список покрывает примерно 80% работы, которая физически происходит в компании за неделю. Доска задач у той же команды содержит шесть активных карточек. Из них три не двигаются больше двух недель. Это не проблема дисциплины и не «надо подтянуть процессы». Это структурный сдвиг: дискретные задачи перестали быть основной единицей операции. Основной единицей стало расписание. ## Почему дорожная карта перестаёт отражать реальность В классической компании дорожная карта — это карта работы. У каждого проекта есть начало, конец, владелец, определение готовности. Если хочется понять, чем занят бизнес, достаточно посмотреть в Jira: список карточек примерно равен списку текущей работы. В компании на агентах эта карта систематически врёт в сторону недооценки. Большая часть операции выполняется не как набор тикетов, а как набор повторяющихся циклов, которые запускаются сами и завершаются сами. Никто не открывает карточку «прогнать дайджест исследований за вчера» — эту работу делает агент по расписанию. Никто не назначает владельца для «проверить здоровье воронки» — владелец это `0 9 * * *`. Сторонний наблюдатель видит шесть карточек и делает неправильный вывод: «команда мало делает». А команда за то же время выполнила 140 запусков процедур, из которых 12 потребовали человеческого вмешательства. Этот разрыв растёт по мере того, как управляемый контур исполнения (managed harness) становится стандартной частью стека. Платформы агентов — публичные материалы [Anthropic Engineering](https://www.anthropic.com/engineering), анонс [OpenAI про новые инструменты для агентов](https://openai.com/index/new-tools-for-building-agents/), [AWS Bedrock Agents](https://docs.aws.amazon.com/bedrock/latest/userguide/agents.html) — сводят стоимость запуска новой процедуры к одному файлу настроек. Это значит, что центр операционной массы быстро смещается от «человек делает задачу» к «расписание запускает агента, человек смотрит исключения». При таком распределении дорожная карта перестаёт быть основной картой работы — она становится картой исключений. Похожий сдвиг уже случался в инженерии данных. [dbt-core](https://github.com/dbt-labs/dbt-core) и [Apache Airflow](https://airflow.apache.org/docs/) превратили аналитику из «возьмите тикет, напишите запрос» в «определите модель, она пересчитывается по расписанию». Граф зависимостей расписания (directed acyclic graph, DAG) стал документом, который точнее описывает работу команды данных, чем проект в Jira. Компания на агентах повторяет эту траекторию на уровне всей организации, не только аналитики. ## Что меняется, когда работа становится расписанием? Самый короткий способ почувствовать сдвиг — выписать рядом две колонки: как описывается работа в проектной парадигме и как — в парадигме расписания. Различия не косметические; они затрагивают всё, начиная от найма и заканчивая отчётом инвестору. | Аспект | Парадигма проекта | Парадигма расписания | |---|---|---| | Единица работы | Дискретный тикет с началом и концом | Повторяющаяся процедура с триггером | | Главный артефакт | Дорожная карта, доска задач | Расписание, планировщик, реестр процедур | | Вопрос для статуса | «Что закрыли на этой неделе?» | «Что запускалось и что эскалировало?» | | Метрика прогресса | Velocity, story points (скорость и баллы) | Доля успешных запусков, доля эскалаций, свежесть данных | | Владелец | Человек на тикете | Человек на процедуре + сама процедура | | Что показывают инвестору | Список будущих функций | Список ежедневной автоматизированной работы | | Главный риск | Срыв сроков | Тихая деградация без сигнала | | Управленческий ритуал | Планирование спринта, ретроспектива | Ревью расписания, аудит «долга расписания» | Эта таблица не означает, что одна парадигма «лучше» другой. У них разные первичные объекты. В компании, где 80% работы — повторяющиеся циклы, описывать её через доску задач — то же самое, что описывать работу аналитической команды через тикеты «написать SQL»: формально можно, операционно — теряет половину сигнала. ## Где живёт работа в компании на агентах Если открыть условное расписание агентной команды, оно распадается на три слоя. Первый слой — **наблюдательные процедуры**. Циклы, которые периодически снимают состояние мира: воронка, продажи за сутки, состояние клиентского контура, свежие сигналы из исследований, ошибки в продакшене. Они не производят решений, они производят структурированный снимок. Этот снимок потом потребляется либо человеком, либо следующей процедурой. У наблюдаемой команды на этот слой приходится примерно треть записей расписания. Второй слой — **решающие процедуры**. Циклы, в которых агент применяет регламент (SOP): запускает повторный контакт, эскалирует зависшие тикеты, помечает устаревшие документы, переоценивает приоритеты задач. Это та работа, которая в классической компании размазана по людям и редко документируется явно. В агентной компании она кодифицирована — потому что иначе её не запустить по расписанию. Здесь живёт основной операционный слой компании, тот самый, про который мы писали в [заметке про harness как товар](/2026/04/harness-commodity-operating-layer.html): институциональный регламент перестаёт быть документом и становится исполняемой политикой. Третий слой — **поддерживающие процедуры**. Проверки здоровья, проверки целостности базы знаний, ротация логов, аудиты битых ссылок, перепроверка устаревших исследований. Этот слой невидим для бизнеса, но его отсутствие проявляется через два-три месяца как тихая деградация: дашборд начинает показывать неправду, агенты ссылаются на исчезнувшие документы, свежесть данных падает. Когда речь идёт про кокпит, который «не должен врать», именно эти процедуры отвечают за то, чтобы он не врал. Все три слоя имеют общее свойство: они описываются расписанием. Не «когда сделаем», а «когда запускается». Логика проекта «у задачи есть начало и конец» к ним применяется плохо. Их жизнь — это не движение от старта к финишу, а пульс. Поэтому расписание точнее описывает, что делает компания, чем дорожная карта. ## Почему расписание — это политический документ В классической компании главный политический документ — дорожная карта. Она отвечает на вопрос «что мы делаем в этом квартале» и согласовывается днями, потому что от неё зависит, что инвестор увидит на следующей встрече и что команда будет делать в понедельник. В компании на агентах главный политический документ — расписание. Каждая запись в расписании — это явное утверждение: «эта работа достаточно важна, чтобы запускать её каждый день, час или неделю автоматически, даже если никто не просил». Добавление записи — это решение примерно того же веса, что найм человека: запись будет работать, потреблять ресурсы и производить выводы, пока её явно не выключат. Удаление записи — это решение примерно того же веса, что увольнение: что-то, что компания делала каждый день, перестаёт делаться, и последствия проявятся через недели. Из этого следует операционная гигиена, которая в классической компании не нужна, а в агентной — критична. Каждая запись в расписании должна иметь явного владельца-человека, документированную цель, явный результат (куда пишется вывод) и явные условия деактивации. В наблюдаемой команде такой реестр живёт как отдельный документ; без него за полгода накапливается «долг расписания» — записи, про которые никто уже не помнит, зачем они нужны, но они продолжают что-то писать в файлы и иногда что-то ломать. Переход от прототипов к продакшен-системам в индустрии агентов — это переход к надёжности и наблюдаемости, не к новым функциям. Применительно к агентам продакшен — это надёжное расписание плюс мониторинг исключений. Агентная организация делает то же самое на уровне организационного дизайна: расписание становится первоклассным объектом управления, а не служебной деталью. ## Почему cron, а не очереди событий? Резонный вопрос: если работа повторяется, почему не описать её как реактивную систему — очереди, события, вебхуки? Событийная архитектура отлично работает там, где есть внешний триггер: пришёл клиент, изменился документ, упал сервис. Но большая часть операционного слоя агентной компании запускается не от внешнего события, а от внутренней необходимости периодически проверять состояние мира. Никто не присылает вебхук «пора провести аудит базы знаний». Эти процедуры инициируются временем, а не данными. Как отмечает Andrej Karpathy в публичных выступлениях про операционные особенности агентов: > «Большинство интересной работы агента — это не реакция на пользователя, а его собственный внутренний цикл размышления и проверки.» — Andrej Karpathy, ex-Director of AI, Tesla Если этот цикл живёт в коде, его естественная форма — расписание. Очереди событий хороши как транспорт между процедурами, но не как замена самим процедурам. На практике агентный стек обычно сочетает обе модели: cron инициирует «такт сердца», очереди и [долговечное исполнение](https://docs.temporal.io/temporal#durable-execution) платформы вроде Temporal обеспечивают надёжность отдельных шагов внутри. Расписание задаёт ритм; очереди — связность. Журнал событий показывает, что произошло; расписание — что компания делает всегда. ## Как отличить этот сдвиг от обычного DevOps? Существует контраргумент: «запланированные задачи всегда были, это просто DevOps в новой обёртке». Контраргумент верен наполовину. Технически — ничего нового. Концептуально — отличие в статусе и составе того, что попадает в расписание. В классическом девопс-сценарии в расписании живут служебные задачи: ротация логов, бэкап базы данных, проверки здоровья инфраструктуры. Это «системные функции», их пишут инженеры по надёжности, они редко обсуждаются на продуктовых синхронах. Процедура ничего не решает за бизнес; она поддерживает существование системы. В агентном сценарии в расписание попадает бизнес-логика: оценка лидов, повторный контакт с клиентом, дайджест исследований, обновление кокпита, аудит регламента. Это уже не системная функция, а часть продукта. Владелец таких процедур — не инженер по надёжности, а тот же человек, который раньше владел соответствующим бизнес-процессом вручную. Расписание становится местом, где живёт «как мы делаем бизнес», а не «как мы поддерживаем сервер». Эту разницу хорошо описывают практики наблюдаемости агентских систем. Как пишет Charity Majors в [блоге Honeycomb](https://www.honeycomb.io/blog), наблюдаемость нужна не за инфраструктурой, а за поведением системы — и в агентной операции это означает наблюдаемость за тем, что процедура реально делает с бизнесом, а не только за тем, что процесс не упал. Тот же сдвиг описан и в [материалах Мартина Фаулера про эволюционную архитектуру](https://martinfowler.com/articles/) и в практиках [инженерии надёжности из Google SRE Book](https://sre.google/sre-book/table-of-contents/): когда поведение системы определяется не одним релизом, а постоянным фоном изменений, главным артефактом становится механизм этих изменений, а не их слепок. Как говорит Charity Majors: > «Наблюдаемость нужна, чтобы задавать системе новые вопросы в продакшене, а не подтверждать заранее известные.» — Charity Majors, CTO, Honeycomb Перенося это на нашу задачу: расписание в агентной компании — это не «папка со скриптами», а механизм, через который компания задаёт миру свои вопросы каждое утро. Поэтому оно и становится политическим, а не служебным. ## Что это меняет для трёх типов читателей **Фаундер.** Если на питче инвестор спрашивает «расскажите про дорожную карту», полезный второй ответ — «вот наше расписание». Не вместо, а вместе. Разговор сдвигается от будущих обещаний к тому, что компания делает каждый день уже сейчас и где живут точки контроля. Тестовый вопрос: можете ли вы за 60 секунд показать список из 10–20 процедур с явным владельцем и явным результатом? Если ответ «у нас всё в Jira» — компания операционно не агентная, что бы ни было написано на сайте. **Операционный руководитель.** Главная управленческая работа в агентной компании — не приоритизация бэклога, а ревью расписания. Раз в две недели — пройти по расписанию или планировщику, отметить каждую запись как «оставляем», «удаляем», «меняем триггер», «передаём другому владельцу». Это занимает 30–60 минут и заменяет несколько часов планирования спринта. Тестовый вопрос: знаете ли вы, какая запись в расписании за последние два месяца ни разу не привела к человеческому действию? Если знаете — это либо ценная защита от ложноотрицательного, либо мёртвая процедура, которую пора удалять. Если не знаете — у вас нет наблюдаемости над собственной операцией. **Инженер.** Большая часть кода в агентной компании — это не функции в продукте, а процедуры: маленькие, надёжные, с понятным контрактом ввода-вывода, с идемпотентностью и плавной деградацией. Это близко к парадигме инженерии данных, далеко от парадигмы веб-разработки. Если выбираете команду по техническому стеку, проверьте, как у них устроен планировщик, есть ли наблюдаемость за выполнением процедур, как они откатывают сломанную запись, и сколько уходит времени от «нужна новая процедура» до «она в проде и работает». Хороший ответ — часы. Плохой — недели. Это часть [слоя представления](/2026/04/representation-layer-vertical-schema.html), которую агентная команда умеет строить, а классическая — нет. ## На какие сигналы смотреть дальше Несколько публичных индикаторов покажут, насколько сдвиг становится массовым. Первый — появление в основных инструментах управления проектами (Linear, Jira, Asana) явной поддержки «повторяющейся задачи агента» как отдельного типа сущности, наравне с тикетом и проектом. Когда станет встроенной концепцией, формализация «расписание как объект управления» закрепится. Второй — публичные кейсы компаний, которые ведут открытый список своих процедур как часть страницы «about/engineering». Это агентный эквивалент «we use Postgres and Kubernetes». Третий — рост MRR у инструментов класса оркестратор-для-агентов, заточенных не под конвейеры данных, а под рабочие потоки агентов. Если эти сигналы придут в ближайшие 12 месяцев, операционный язык индустрии успеет перестроиться. Позже — фаундеры, которые уже строят компанию вокруг расписания, получат окно фор-старта. Главный вопрос один: что у вас в расписании завтра в 9 утра, и почему именно это. ## Главное - В компании на агентах основная единица работы — повторяющаяся процедура, а не дискретная задача. Дорожная карта отражает исключения; расписание отражает реальность. - Расписание распадается на три слоя: наблюдательные, решающие, поддерживающие процедуры. Все три описываются расписанием, не сроками. - Расписание — политический документ. Добавление записи — это решение масштаба найма; удаление — масштаба увольнения. - Управленческая работа смещается от приоритизации бэклога к регулярному ревью расписания. Без этого появляется «долг расписания». - Расписание точнее показывает, чем компания реально занимается каждый день, чем любая дорожная карта или доска спринта. ## FAQ **Это значит, что управление проектами больше не нужно в агентной компании?** Нужно, но в другой форме. Проекты остаются для дискретных инициатив с началом и концом — запуск нового продукта, миграция, исследование вертикали. Просто проекты больше не описывают всю работу. Они описывают исключения над расписанием. Соотношение в наблюдаемых командах — примерно 20% работы в проектах, 80% в процедурах. **Что если бизнес по природе плохо ложится на расписание — например, консалтинг или редкие сделки?** Тогда часть работы остаётся в проектах, как и раньше. Но даже в таких бизнесах наблюдательный и поддерживающий слой обычно поддаётся логике расписания: ежедневный сбор сигналов о клиентах, еженедельный аудит воронки, ночная синхронизация CRM. Процедура не обязана охватывать ядро бизнеса, чтобы быть основным операционным артефактом — достаточно, чтобы она покрывала большую часть повторяющейся работы вокруг ядра. **Чем задача в расписании отличается от обычной запланированной задачи, которая и в классических компаниях есть?** Технически — ничем. Концептуально — статусом. В классической компании запланированные задачи — служебная деталь, спрятанная в DevOps. В агентной компании расписание поднято на уровень операционного артефакта: оно документировано, обсуждается на синхронах, имеет явных владельцев и реестр. Сдвиг — не в технологии, а в том, что считается «настоящей работой». **Как защититься от «долга расписания» — записей, которые никто не помнит, зачем нужны?** Минимум три практики: регулярное ревью расписания (раз в две недели достаточно), явный владелец и описание для каждой записи в едином реестре, и метрика «когда запись последний раз привела к действию». Записи, которые полгода ничего не запускали, — кандидаты на удаление. Это та же дисциплина, что в кокпите фаундера: операционный слой работает только если за ним есть петля проверки здоровья. **Можно ли называть компанию агентной, если у неё в расписании пять записей и команда из 50 человек?** Дело не в количестве записей, а в том, какая доля повторяющейся работы кодифицирована и запускается без участия человека. Агентность — не маркетинговый ярлык, а поддающееся измерению свойство: какая доля операционной работы живёт в расписании, а не в людях. **Что отличает хорошую процедуру от плохой?** Хорошая процедура идемпотентна (можно безопасно перезапустить), имеет явный результат в наблюдаемое место (файл, дашборд, канал), имеет явный запасной вариант при ошибке (тихо в лог, не падает на пользователя) и имеет владельца-человека, который получит сигнал, если процедура начнёт врать. Плохая процедура — это скрипт, про который через три месяца невозможно ответить, что он делает и куда пишет результат. --- ## Note 34: Не GigaChat против Claude. Моноархитектура против маршрутизатора **URL:** https://notes.temadev.org/2026/04/gigachat-yandexgpt-claude-b2b-russia-2026.html **Published:** 2026-04-28 **Genre:** market-deep-dive **Tags:** russia, llm, gigachat, yandexgpt, claude, b2b, ai-stack, routing **Words:** 2229 **Summary:** GigaChat, YandexGPT, Claude в 2026: реальный выбор не между провайдерами, а между моноархитектурой и роутером. # Не GigaChat против Claude. Моноархитектура против маршрутизатора ## Апрельский квартал, в котором провайдеры стали заменимы 8 апреля 2026 года Anthropic выпустил [Managed Agents](https://www.anthropic.com/engineering/managed-agents) — managed execution loop, persistent memory через `/memories`, sandboxing и multi-agent orchestration. В тот же месяц OpenAI отгрузил [AgentKit с визуальным Agent Builder, Connector Registry и встроенными Evals](https://openai.com/index/introducing-agentkit/). Сбер на портале [GigaChat API](https://developers.sber.ru/portal/products/gigachat-api) держит публичную тарификацию по пакетам токенов и три варианта развёртывания — облако, гибрид, on-prem. Yandex Cloud в [Foundation Models](https://yandex.cloud/ru/services/foundation-models) собрал YandexGPT в одну линейку с Object Storage, Logging и managed-инфраструктурой. Между этими четырьмя анонсами есть общая черта, которую обзоры обычно проходят мимо. Все четыре провайдера в 2026-м продают не модель, а стек: контракт API, managed orchestration, memory, observability. И как только стек становится частью продукта, цена ошибки выбора смещается с цены токена на стоимость переезда между стеками. Ровно поэтому сравнительные таблицы «GigaChat vs YandexGPT vs Claude» в 2026-м измеряют не то, что определяет экономику решения через год. ## Дешевизна моноархитектуры — в долг Базовый сценарий 2026-го у российской B2B-команды выглядит так. Команда выбирает одного провайдера — обычно по сочетанию цены, 152-ФЗ и удобства существующей инфраструктуры — и собирает на нём всё: парсинг входящих, классификацию, агентов с инструментами, summarisation. Это моноархитектура. Она экономит инженерные часы на старте: одна авторизация, один SDK, один формат tool calling, одна managed-память. Контр-тезис: моноархитектура не дешевле — она дешевле в первый год. На втором году стоимость моноархитектуры — это стоимость миграции, и она конечна, измерима и обычно недооценена. Migration debt появляется не от плохого выбора, а от того, что любая моноархитектура жёстко связывает четыре независимых решения: формат структурированного вывода, протокол tool use, схему памяти и operations-контур. Когда хотя бы одно из четырёх перестаёт устраивать, переезжать приходится сразу всем стеком. Альтернатива — роутер: внешний слой, который маршрутизирует запросы между провайдерами по типу нагрузки, чувствительности данных и стоимости. Роутер дороже в первый год — нужен evaluator-харнесс, единая schema domain-объектов, контракты между prompt-цепочкой и моделью. Но он линейно масштабирует решения второго года: смена одного провайдера меняет конфиг, а не архитектуру. В терминах [предыдущей заметки про harness commodity](/2026/04/harness-commodity-operating-layer.html), роутер — это та часть operating layer, которую provider-стеки в 2026-м начали поглощать, и которую командам выгодно не отдавать вверх по стеку без явного обмена. ## Четыре стыка, на которых ломается моноархитектура Чтобы увидеть, где конкретно моноархитектура накапливает долг, удобно смотреть не на «провайдеров вообще», а на стыки между подсистемами стека. ### Structured output: формат входит в каждый prompt OpenAI в [Function Calling](https://platform.openai.com/docs/guides/function-calling) с 2023-го фиксирует контракт, при котором модель возвращает строго типизированный JSON по объявленной схеме. Anthropic в [tool use](https://docs.claude.com/en/docs/build-with-claude/tool-use) реализует тот же контракт через `tool_choice` и явные input schemas. Это два формата, которые внешне делают одно и то же, но различаются в деталях: имена полей, форма передачи schema, поведение при несоответствии. На стороне Сбера механизм function calling в [портале GigaChat API](https://developers.sber.ru/portal/products/gigachat-api) и сопровождающих [технических разборах SberDevices на Хабре](https://habr.com/ru/companies/sberdevices/) представлен своим интерфейсом; у Yandex — своим. Команда, которая выбрала одного провайдера, кодирует именно его формат в каждый prompt и каждый валидатор. Через год, когда возникает сценарий с другим провайдером — например, reasoning-задача, где Claude даёт лучший результат на тех же примерах — миграция перетряхивает все места, где формат tool calling зашит. Это не «переписать промпты», это переписать тесты, евалуаторы, ретраи и логирование. Команда с роутером изначально держит структурированный вывод как domain-объект, а формат провайдера — как адаптер; миграция меняет адаптер. Конкретно это значит, что в репозитории есть два уровня: типизированные классы доменных объектов (карточка клиента, событие, эскалация, статус) — независимые от провайдера, и тонкий слой провайдер-специфичного кода, который только переводит между этими классами и форматом конкретного API. На длинных горизонтах поддержка двух адаптеров обходится дешевле одного жёстко прошитого формата, потому что оба адаптера обязаны проходить один и тот же evaluator-харнесс. ### Tool use: orchestration провайдера против внешнего роутера [Anthropic в инженерной заметке про Managed Agents](https://www.anthropic.com/engineering/managed-agents) формулирует суть managed-подхода: «self-evaluates and iterates until it reaches a result» — это описание execution loop, в котором провайдер берёт на себя оркестрацию и возвращает вызывающему коду только финальный результат. OpenAI в [AgentKit](https://openai.com/index/introducing-agentkit/) даёт визуальный Agent Builder с Connector Registry и встроенными Evals. Это два разных способа упаковать одну и ту же задачу: длинная цепочка вызовов инструментов с возвратом контроля внешнему коду. Российские провайдеры в публичных материалах 2026-го тоже движутся в эту сторону, но с разной плотностью документации и разной зрелостью контракта на длинных горизонтах. Команда, которая поверила, что «agent harness — это просто фича провайдера», и спроектировала flow внутри managed-конструкции, на втором году получает классическую vendor lock-in проблему. Смена провайдера здесь — это не «переключить ключ», это переписать саму форму orchestration: где живёт состояние, как оформлены retry, кто owns memory между шагами, как описан контракт инструмента. У каждого провайдера эти ответы разные, и в managed-продукте они зашиты в SDK, а не в коде команды. Команда с внешним роутером — наоборот, держит orchestration снаружи, а провайдерский harness использует только там, где экономия на инфраструктуре оправдывает связанность. На практике это означает, что роутер берёт на себя три роли: классификатор запроса по типу нагрузки и чувствительности данных, владелец схемы domain-объектов и evaluator. Managed harness провайдера в такой архитектуре — один из исполнителей, не источник правды. ### 152-ФЗ как архитектурный, а не комплаенс-вопрос Большинство обзоров обсуждают 152-ФЗ как фильтр между двумя множествами провайдеров: «российские можно, зарубежные нельзя для ПД». Это правда, но это не самый интересный уровень. Архитектурный уровень — что именно в стеке считается «обработкой ПД», и где проходит граница изоляции. [Документация GigaChat API](https://developers.sber.ru/portal/products/gigachat-api) предлагает три варианта развёртывания: облако Сбера, гибрид с данными на стороне клиента, on-prem. [Yandex Cloud Foundation Models](https://yandex.cloud/ru/docs/foundation-models/concepts/yandexgpt/models) даёт data residency «в РФ» как умолчание. Команда, которая делает 152-ФЗ-чувствительный продукт на моноархитектуре одного из этих провайдеров, имплицитно принимает решение: весь продукт работает в одном комплаенс-периметре. На горизонте года это означает, что если в продукт добавляется задача, требующая reasoning-возможностей зарубежной модели — а такие задачи в 2026-м появляются регулярно — переезд требует разделить пайплайн на ПД-чувствительный и обезличенный, что архитектурно эквивалентно построению роутера задним числом, только в стрессе и под deadline. Команда, которая с самого начала проектировала разделение по чувствительности данных как отдельную ось маршрутизации, ту же задачу решает добавлением ветки. 152-ФЗ перестаёт быть constraint на выбор провайдера и становится одним из measurable атрибутов запроса. ### SLA и поведение под нагрузкой У Anthropic и OpenAI публичные status-страницы и rate-limit-политики, описанные на уровне tier'ов. У GigaChat и Yandex Cloud публичная часть SLA на инференс LLM в 2026-м заметно беднее — корпоративные условия идут в индивидуальных договорах. Это не утверждение про качество, это утверждение про объём публичной информации, на которую может опираться внешний выбор. Моноархитектура на любом из четырёх провайдеров делает SLA провайдера потолком SLA продукта. Если у провайдера падает регион или меняется rate-limit-политика, продукт деградирует синхронно, без степеней свободы. Роутер — наоборот, делает SLA продукта функцией политики маршрутизации: при деградации одного провайдера запросы уходят на резерв, latency p95 поднимается, но контур не останавливается. Цена этой устойчивости — поддерживать как минимум двух работающих провайдеров и единый evaluator-харнесс, на котором обе стороны проверяются на одинаковом наборе кейсов. Дешёвой эта устойчивость не бывает; вопрос в том, что обходится дороже — её отсутствие или её содержание. На фоне этого Сбер в карточке GigaChat API пишет о ·«едином API для приложений и агентов», это сигнал: российские провайдеры движутся в ту же сторону. Как [отмечают в блоге SberDevices](https://habr.com/ru/companies/sberdevices/), «функциональный вызов и инструменты — это не фича, а основной режим работы модели в production-контуре» — формулировка, которая почти дословно повторяет Anthropic и OpenAI. Одна и та же идея, реализованная четырьмя разными способами, и каждый из этих способов — будущая точка миграции. ## Конкретные тесты для трёх ролей **Для CTO.** Возьмите три задачи из текущего бэклога: одну со structured output, одну с tool use на 5+ шагов, одну с длинным контекстом. Зафиксируйте, в скольких местах кода и в скольких тестах прописан конкретный формат текущего провайдера — имена полей tool calling, формат сообщений, идентификаторы моделей. Если число таких мест превышает несколько десятков на одну задачу, у вас моноархитектура, и стоимость её замены через год — это столько же изменений, помноженное на число задач. Решение — не «срочно мигрировать», а вынести формат провайдера в адаптер и держать domain-объекты типизированными. **Для Head of Product.** Запишите, какие фичи продукта зависят от поведенческих гарантий конкретного провайдера: структуры JSON, длины контекста, поведения tool calling на длинных горизонтах. Если таких фич больше трёх и все они сидят на одном провайдере, продукт зависит от его roadmap'а сильнее, чем от собственного. Тестовый сценарий: если завтра ваш текущий провайдер поднимет цену на 30% или удалит конкретную фичу — какие функции продукта перестают работать в течение недели. Это и есть продуктовая стоимость моноархитектуры, выраженная в feature-availability. **Для Tech Lead.** Постройте один проект так, чтобы провайдер был заменим: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 типичных кейсов с эталонными ответами. Это инвестиция в недели, а не в дни. Признак, что харнесс реальный, а не на бумаге: вы можете прогнать новую модель на нём за ночь и получить численный ответ — лучше, хуже, на каких подмножествах. Без такого харнесса любая дискуссия о смене провайдера ведётся в терминах ощущений, что само по себе — диагностика степени lock-in. Такой заменяемый контур — domain-схема, адаптеры и реальный харнесс — мы и собираем как рабочую систему, а не как пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=gigachat-yandexgpt-claude-b2b-russia-2026&utm_content=inprose). ## Что покажет 2026-й, и какие сигналы стоит фиксировать? Тренд имеет несколько проверяемых сигналов. Первый — появление managed-роутеров в публичных продуктах: внешних сервисов, которые принимают единый API и сами решают, какому провайдеру отправить запрос. Если такие продукты выходят в GA, моноархитектура становится анахронизмом, а вопрос смещается на политику маршрутизации. Второй — публикация официальных кейсов перевода production-нагрузок между российскими и зарубежными провайдерами без потери качества. Такой кейс — публичное доказательство, что архитектурно стек уже переносим, и оценочная стоимость миграции из моноархитектуры в роутер становится прозрачной величиной. Третий, обратный, — появление команд, которые публично возвращаются с роутера на моноархитектуру, объясняя это операционной сложностью. Это будет означать, что граница применимости роутера выше, чем сейчас принято считать, и что для значительной части B2B-задач достаточно одного провайдера и грамотных адаптеров. В любом сценарии вопрос «GigaChat или Claude» — не главный. Он выглядит как закупочный, но за ним стоит архитектурный, и именно архитектурный определяет, сколько будет стоить второй год. ## Главное - Сравнения LLM-провайдеров по цене и фичам в 2026-м воспроизводят ошибку обзоров BPM десять лет назад: они отвечают на закупочный вопрос вместо архитектурного. - Реальная развилка — моноархитектура или роутер. Моноархитектура дешевле в первый год и дороже на втором за счёт стоимости миграции; роутер — наоборот. - Стоимость моноархитектуры скрыта в четырёх стыках: формат structured output, протокол tool use на длинных цепочках, граница 152-ФЗ-изоляции, поведение под нагрузкой. - Минимальная архитектура, которая делает провайдера заменимым: единая schema domain-объектов, адаптеры под форматы провайдеров, evaluator-харнесс на 200–500 кейсов. - Сигналы 2026-го, на которые стоит смотреть: managed-роутеры в GA, публичные кейсы переноса production-нагрузок, обратные кейсы возврата на моноархитектуру. ## FAQ **Чем моноархитектура отличается от vendor lock-in?** Моноархитектура — это осознанный выбор одного провайдера ради скорости в первый год; vendor lock-in — следствие того, что при этом выборе команда не выделила domain-слой, и формат провайдера разлился по всему коду. Можно иметь моноархитектуру без lock-in, если domain-объекты типизированы и evaluator-харнесс реальный — это и есть разница между рабочей сборкой и долгом. Тест: сколько мест в коде нужно изменить, чтобы поменять провайдера? <100 — нормальная моноархитектура. >1000 — lock-in. **Когда роутер — переинжиниринг?** Роутер переинжиниринг, когда в продукте меньше трёх разных типов запросов, нет 152-ФЗ-чувствительных данных и объём инференса ниже ~10 000 запросов в день. Для таких команд правильный путь — один провайдер плюс правильные адаптеры. Роутер окупается от двух и более дифференцирующих факторов: хотя бы две роли LLM в продукте, две зоны чувствительности данных, или два критерия SLA. **Как оценить стоимость миграции с моноархитектуры?** Подсчитайте три числа: (1) сколько prompt-шаблонов содержат провайдер-специфичный формат, (2) сколько тестов предполагают конкретные имена полей tool calling, (3) сколько мест в коде ссылаются на идентификаторы моделей напрямую. Сумма этих трёх чисел, умноженная на ~2 часа на каждое место (типичная оценка для рефакторинга с проверкой тестами), даёт оценку миграционного долга в инженер-часах. Часто получается 500–1500 часов на средний продукт — то есть 3–9 человеко-месяцев. **Что выбрать команде, которая стартует сегодня — моно или роутер?** Стартовать с моноархитектуры на одном из российских провайдеров (152-ФЗ требует РФ-инфраструктуры в большинстве B2B-сценариев), но **сразу** заложить три инвестиции: типизированные domain-классы (карточка клиента, событие, эскалация), адаптер-слой между ними и API провайдера, evaluator-харнесс на 50–100 кейсов. Это превращает будущий переход в роутер в добавление второго адаптера, а не пересборку. Стоимость этих трёх инвестиций при старте — 2–4 недели, экономия на горизонте 12 месяцев — порядок тех же 500–1500 часов. **Какие задачи в B2B РФ-стеке оправданно отдавать зарубежным моделям через роутер?** Reasoning-задачи на длинных горизонтах (планирование, decomposition сложных кейсов, анализ длинных документов) — у Claude и GPT-5.5 в 2026-м преимущество подтверждается на публичных бенчмарках. Чувствительность данных снижается обезличиванием на стороне роутера: запрос уходит в зарубежную модель без ПД, ответ применяется в РФ-контуре с ПД. Для классификации входящих, summarisation отчётов, генерации шаблонных писем — российские провайдеры в 2026-м конкурентоспособны и выгоднее по стоимости и латентности. --- ## Note 35: Модель меняется за выходные, схема — за годы. Где на самом деле живёт стоимость переключения **URL:** https://notes.temadev.org/2026/04/representation-layer-vertical-schema.html **Published:** 2026-04-27 **Genre:** concept-piece **Tags:** ai-agents, representation-layer, data-moat, vertical-ai, operating-layer **Words:** 2244 **Summary:** Стоимость переключения вертикального AI-продукта определяется не моделью, а глубиной representation layer. Модель меняется за выходные, схема — за годы. # Модель меняется за выходные, схема — за годы. Где на самом деле живёт стоимость переключения ## Какую цену обычно недооценивают? Возьмём бюджет средней vertical-AI-компании, которая обслуживает auto-dealers или SaaS-поддержку: счёт за инференс к Anthropic или OpenAI — порядка $300–500 в месяц на одного активного клиента. Стоимость инженерной работы по описанию того, что в этом конкретном бизнесе считается лидом, какие у него валидные статусы, что считается дублем, кто имеет право пометить сделку как закрытую, — десятки тысяч долларов разовой работы плюс непрерывная доработка. Соотношение 1:100 в пользу схемы, не модели. И именно эта пропорция объясняет, почему вертикальные AI-продукты, проигрывающие на бенчмарках, выигрывают на удержании. В [предыдущей заметке](/2026/04/harness-commodity-operating-layer.html) мы констатировали факт: за один квартал четыре крупнейших провайдера схлопнули agent harness в managed-продукт, и сослались на три слоя, которые остались defensible: representation layer, trajectory data, institutional SOP. Эта заметка — глубокое погружение в первый. Мы утверждаем: стоимость переключения вертикального AI-провайдера прямо пропорциональна глубине интеграции representation layer в операционные процессы клиента, а не качеству модели, на которой он работает. ## Что именно мы называем representation layer Representation layer — это формальная модель домена, в терминах которой работает агент: набор сущностей бизнеса, их атрибутов, валидных состояний, инвариантов и правил перехода между ними, выраженный как явный, версионируемый, машинно-проверяемый артефакт. Это не «структура базы данных» в традиционном смысле и не онтология ради онтологии. Это контракт, по которому модель и операционные процессы понимают одно и то же под одним и тем же словом. Vertical schema — это representation layer, специализированный под конкретную отрасль: схема для auto-dealers фиксирует, что лид «горячий» при наличии тест-драйва, в SaaS-поддержке — при NPS-сигнале и определённой роли пользователя, в коммерческой недвижимости — при подписанной LOI. Универсальная схема CRM этих различий не делает; vertical schema их кодифицирует, потому что без них агент возвращает правдоподобную, но операционно неверную работу. | Параметр | Horizontal schema | Vertical schema | |----------|-------------------|-----------------| | Entity coverage | Общие сущности: lead, account, task | Отраслевые сущности: RFI, work order, test drive, LOI | | Switching cost | Миграция полей и интеграций за недели | Перенос инвариантов, trajectory hooks и SOP за месяцы | | Error surface | Ошибки выглядят как неточные ответы модели | Ошибки становятся нарушением бизнес-инвариантов | | Example | Generic CRM pipeline из 5 статусов | Схема auto-dealer, SaaS-support или commercial real estate | | Defensibility | Низкая: провайдеры копируют шаблон | Высокая: edge cases накапливаются в операции клиента | Здесь же мы можем зафиксировать ещё два понятия, которые в популярной прессе часто склеиваются. Data moat — это устойчивая разница между тем, что знает про домен ваш продукт, и тем, что знают конкуренты, при условии что разница не воспроизводится за разумные деньги и время извне. И switching cost — это совокупная цена для клиента покинуть текущего вендора: переписать интеграции, восстановить кодифицированные процессы, заново обучить людей и заново накопить операционную историю. У AI-продуктов основной вклад в switching cost даёт не контракт и не стоимость миграции данных, а именно потеря representation layer, которую невозможно «выгрузить в CSV». ## Почему модель — заменимая часть стека Бенчмарки последних восемнадцати месяцев показывают одну и ту же вещь: разрыв между frontier-моделями быстро схлопывается. Anthropic выпустил [Managed Agents](https://www.anthropic.com/engineering/managed-agents) в апреле 2026 с persistent memory и self-evaluation; OpenAI в это же время отгрузил [AgentKit](https://openai.com/index/introducing-agentkit/) с визуальным Agent Builder; AWS — [Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html) с Runtime, Gateway, Memory как managed primitive. Любая команда, которая использует одну из этих платформ, может переключиться на другую за выходные, если речь идёт только об инференсе и harness. Что не переключается за выходные — это смысловой контракт между текущей моделью и реальной операционной системой клиента. Когда агент в системе поддержки решает, что «тикет требует эскалации», он опирается на вертикальную схему: какие поля в тикете считаются обязательными, какие сочетания статусов означают SLA-риск, какой пользователь имеет право снять эскалацию. Эта схема накапливалась месяцами в коде, в промптах, в валидаторах, в правилах маппинга. Модель — её исполнитель, не носитель. [Jerry Chen из Greylock в эссе «The New Moats: Why Systems of Intelligence Are the Next Defensible Business Model»](https://greylock.com/greymatter/the-new-moats/) формулирует это как «системы интеллекта»: в эпоху, когда сами модели становятся горизонтальным API, защита смещается в системы, которые накапливают уникальные данные, feedback loops и контекст их применения. Через пять лет тезис не устарел — изменилась только точность. Уникальные данные сами по себе не moat: их надо описать на языке, который понимает бизнес, и в формате, который понимает агент. Этот язык и есть representation layer. ## Из чего реально состоит схема На уровне артефактов representation layer — это четыре слоя, которые в зрелом продукте живут в репозитории и обновляются как код. Первый — типы и сущности. JSON Schema или Pydantic-классы для основных объектов домена с явными атрибутами и связями. Например, в SaaS-поддержке: `Account`, `User`, `Ticket`, `Conversation`, `Escalation`, с типизированными ссылками между ними. Этот слой обычно выглядит дёшево — но именно его форма определяет, какие вопросы агент в принципе сможет задавать в данных. Второй — конечные автоматы и инварианты. Граф валидных переходов состояний (`new → triaged → in_progress → resolved → closed`), правила, при которых переход допустим, и условия, при которых сущность не имеет права существовать. Без этого слоя агент способен сгенерировать «правдоподобный» исход, который на проверке окажется операционно невозможным — и это самая частая причина отказа vertical-AI-продуктов на ранних этапах. Третий — события и trajectory hooks. Каждое значимое изменение состояния порождает событие с фиксированными `actor`, `timestamp`, `before`, `after`, `reason`. Этот слой непосредственно соединяется с тем, что мы в прошлой заметке называли trajectory data: без формализованной схемы событий замкнутая петля «вход → решение → исход» не собирается. [Open-source memory-стек, такой как Graphiti](https://github.com/getzep/graphiti) или [Letta](https://github.com/letta-ai/letta), даёт хранилище для таких событий и temporal reasoning поверх них, но не даёт самой схемы — её всё равно проектирует команда. Четвёртый — резолверы и валидаторы. Код, который превращает грязный вход реального мира — почту, чаты, формы, выгрузки — в сущности схемы и обратно. Это самая «грязная» часть representation layer и одновременно самая защищённая: чтобы её воспроизвести, конкурент должен не просто прочитать вашу схему, а заново пройти через все edge cases вашего домена. [Vendep в эссе «Forget the data moat, the workflow is your fortress in vertical SaaS»](https://www.vendep.com/post/forget-the-data-moat-the-workflow-is-your-fortress-in-vertical-saas) формулирует это резко: «moat — это не данные сами по себе, а то, как они вшиты в рабочий процесс». На уровне representation layer этот тезис конкретизируется: «вшиты в рабочий процесс» означает, что схема валидируется на каждом шаге, и любое расхождение между моделью и реальностью становится явным, а не молчаливым. ## Где это уже работает Зрелые vertical-SaaS-компании де-факто давно построили representation layer, просто не называли его так. Procore описывает строительный объект через типизированный набор RFI, submittals, change orders с явными статусами и инвариантами; ServiceTitan для home services формализует звонок, work order, наряд бригады и инвойс через типизированные сущности с явной историей переходов. На этом фундаменте AI-функции прирастают как естественное расширение, а не как отдельный продукт. Когда [Foundation Capital в эссе «AI Leads a Service-as-Software Paradigm Shift»](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) пишет про переход от продажи софта к продаже готовой работы, имплицитное условие этой модели — что «работа» формализована достаточно, чтобы её можно было поручить системе. Representation layer и есть инструмент такой формализации; без него service-as-software не выходит за пределы demo. Обратный пример полезен не меньше. [Forbes в марте 2026 описывал](https://www.forbes.com/sites/sanjaysrivastava/2026/03/04/in-ai-the-moat-is-moving/), как горизонтальные AI-«обёртки» над generic CRM теряют клиентов в пользу вертикальных продуктов с глубоким пониманием домена — несмотря на то, что качество моделей у обёрток часто выше. Причина прозаична: универсальная CRM-схема не различает реструктуризацию долга в B2B-кредитовании и продление подписки в SaaS, а вертикальный продукт различает, и его агент перестаёт делать абсурдные предложения. Это и есть видимая часть representation layer — она проявляется как «продукт просто понимает наш бизнес». ## Что это значит на практике **Для фаундера AI-продукта.** Тестовый вопрос для собственного продукта: если завтра OpenAI выпустит модель, которая на ваших задачах работает на 10% лучше, насколько изменится ваша экономика удержания? Если сильно — у вас, скорее всего, нет representation layer, у вас тонкая обёртка над API. Если почти не изменится — у вас есть слой, который компаундируется. Конкретный действие: перенесите одну центральную сущность вашего продукта (лид, тикет, ордер, контракт) из «свободно лежит в промптах и коде» в явную, версионированную схему с инвариантами. Через три месяца оцените, насколько чаще вы исправляете ошибки агента в коде валидаторов, а не в промптах. Этот сдвиг — самый ранний признак, что слой начал формироваться. Такие контуры вокруг одного измеримого процесса мы и собираем как рабочие системы, а не пилоты: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=representation-layer-vertical-schema&utm_content=inprose). **Для руководителя, выбирающего вендора.** На discovery-встрече задайте один вопрос: «покажите, как у вас описана сущность X в нашем бизнесе». Если ответ — «мы передадим это в промпт модели», вы покупаете harness, и ваша зависимость от вендора будет нулевой, а ценность — кратковременной. Если ответ — «вот версионированная схема, вот инварианты, вот резолверы, вот политика изменений», вы покупаете operating layer, у которого есть и глубина, и аудит, и опционально перенос. Второй важный вопрос: «при расторжении контракта что я получу обратно — дамп таблиц или работающую копию representation layer на стандартных форматах». Ответ на второй вопрос отличает зрелого вендора от оппортуниста. **Для инженера, выбирающего, где работать.** В команде, которая накапливает representation layer, ваша работа компаундируется: каждый новый клиент уточняет схему, каждый новый edge case добавляет валидатор, через два года вы один из немногих людей с реальным domain-driven understanding своей вертикали. В команде, которая занята прослойками поверх managed harness, через тот же срок вы — специалист по стеку, который провайдеры съели. На собеседовании смотрите, есть ли у команды отдельный артефакт «schema» или «ontology», кто им владеет, как часто он меняется. Если на этот вопрос команда не понимает, о чём вы спрашиваете, — это сигнал. ## На что мы будем смотреть дальше Если тезис верен, в течение ближайших 12–18 месяцев должны появиться три вещи. Первая — публичные стандарты для vertical schema по отдельным отраслям: не «общий JSON Schema», а конкретные онтологии для логистики, страхования, ритейла, согласованные между несколькими игроками. Сейчас этого нет, и каждый вендор изобретает свою. Вторая — рост сегмента ESB-подобных продуктов вокруг переноса representation layer между провайдерами, по аналогии с тем, как Open Banking стандартизировал API банков. Третья, самая важная — появление кейсов компаний, которые сменили модель и harness без потери operating-слоя: это будет публичным доказательством того, что слой действительно отделим и переносим. Если такие кейсы появятся, рынок vertical-AI окончательно перестанет конкурировать моделями. ## Главное - Representation layer — формальная схема сущностей, статусов и решений конкретного бизнеса — основной источник switching cost у вертикальных AI-продуктов; модель и harness заменимы, схема — нет. - Слой состоит из четырёх артефактов: типы и сущности, конечные автоматы и инварианты, события и trajectory hooks, резолверы и валидаторы. Все четыре живут в репозитории и обновляются как код. - Тестовый сигнал для продукта: если улучшение базовой модели не двигает удержание — у вас есть слой; если двигает сильно — вы продаёте обёртку. - Для покупателя AI-продукта главный вопрос — не «какая там модель», а «как описаны сущности моего бизнеса и что я унесу при расторжении». - В ближайшие полтора года индикатор зрелости рынка — появление публичных vertical-схем и переносимых operating-слоёв между вендорами. ## FAQ **Можно ли сделать representation layer переносимым между провайдерами?** Часть переносится, часть остаётся связанной с конкретной операцией. Схема, инварианты и валидаторы хранятся как код и не зависят от выбора модели. Переносимость ломается на двух стыках — на интеграциях с операционными системами клиента и на управляемой памяти провайдера, где формат событий и trajectory hooks часто проприетарен. Стандарт переноса появится не раньше, чем будет рыночное давление со стороны крупных покупателей. **Чем representation layer отличается от обычной схемы базы данных?** Схема БД описывает форму хранения; representation layer описывает смысловой контракт между бизнесом и агентом. У него обязательно есть инварианты, конечные автоматы и резолверы — слои, которые в традиционной БД-разработке либо живут в коде приложения, либо отсутствуют вовсе. Кроме того, representation layer проектируется так, чтобы его читала и писала и модель, и человек, и валидатор — и расхождения между ними становились видимыми. **Почему vertical schema дороже модели?** Модель можно заменить через API-router или weekend migration, если surface вокруг неё стабилен. Vertical schema создаётся через discovery, интеграции, чистку грязных данных и десятки edge cases в операции клиента. Поэтому экономический вес смещается с inference bill на артефакты, которые описывают бизнес как исполняемую систему. **Когда representation layer не создаёт moat?** Он не создаёт moat, если схема остаётся generic и не получает данных из реального workflow. Таблица с сущностями без инвариантов, событий и валидаторов легко копируется конкурентом. Moat появляется только там, где 3-6 месяцев operation history превращают схему в набор проверенных правил и исключений. **Как измерить зрелость representation layer?** Минимальный тест: посчитать, сколько ошибок агента исправляется изменением схемы или валидатора, а не переписыванием промпта. Если через 90 дней большинство исправлений всё ещё живёт в prompt text, слой незрелый. Если изменения идут в типы, конечные автоматы, resolvers и trajectory hooks — representation layer начал компаундиться. **Сколько времени занимает первый рабочий слой?** Для узкого workflow первый production-grade slice обычно занимает 4-8 недель: 1-2 недели на entity discovery, 1-2 недели на dirty-data resolvers, 2-4 недели на валидаторы и trajectory hooks в реальной операции. Быстрее можно собрать demo, но demo не создаёт switching cost. Переключательные издержки появляются только после того, как схема пережила десятки реальных случаев и начала ловить ошибки до того, как их увидит человек. На второй итерации слой обычно расширяют не шириной, а глубиной: добавляют 5-10 новых инвариантов, 2-3 события в trajectory log и один новый resolver для самого частого грязного входа. Это важнее, чем подключить ещё одну модель. Модель улучшает ответ; representation layer уменьшает число ситуаций, где неправильный ответ вообще возможен. В этом и состоит экономическая разница между API-обёрткой и operating layer. --- ## Note 36: Когда harness становится товаром: что отделяет агентную компанию от агентского агентства **URL:** https://notes.temadev.org/2026/04/harness-commodity-operating-layer.html **Published:** 2026-04-25 **Genre:** contrarian-take **Tags:** ai-agents, operating-layer, commoditization, ai-native **Words:** 2668 **Summary:** Harness (контур исполнения агентов) стал товаром: четыре провайдера выпустили его как managed-продукт за квартал. Защитимым остаётся слой выше. # Когда harness становится товаром: что отделяет агентную компанию от агентского агентства ## Что изменилось за один квартал? 8 апреля 2026 Anthropic выпустил [Managed Agents](https://www.anthropic.com/engineering/managed-agents) — управляемый цикл исполнения, постоянную память через интерфейс `/memories`, песочницу, мультиагентную оркестрацию, агентов, которые «self-evaluate and iterate until they reach a result». В публичном API beta header — `managed-agents-2026-04-01` ([Claude API docs](https://platform.claude.com/docs/en/managed-agents/tools)). 22 апреля на Cloud Next Google переименовал Vertex AI в [Gemini Enterprise Agent Platform](https://cloud.google.com/products/gemini-enterprise-agent-platform) — Agent Builder, Agents Gallery, A2A protocol, $750M партнёрский фонд. В тот же день AWS отгрузил управляемый harness (контур исполнения) в preview-режиме в Bedrock AgentCore — Runtime, Gateway, Identity, Memory, Observability как управляемые примитивы ([AWS docs](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html)). OpenAI в это время добивал AgentKit — Agent Builder с визуальным холстом, реестром коннекторов, ChatKit, встроенными проверками и ограничениями ([OpenAI](https://openai.com/index/introducing-agentkit/)). За один квартал четыре крупнейших провайдера независимо схлопнули в managed-продукт тот самый слой, который ещё в марте называли «agentic moat» ([businessengineer.ai](https://businessengineer.ai/p/the-harness-as-the-agentic-moat)). На рынке, который год назад продавал «настройку агента» за сотни тысяч рублей, теперь это `npm install` плюс конфиг в облачной консоли. Это не прогноз. Это то, что произошло. ## Что сломалось у «AI-агентств» за один квартал Бизнес-модель студии, продающей «AI-бота под клиента», держится на одной арифметике: harness (память, маршрутизация инструментов, оркестрация, проверки, ограничения) — это инженерный труд, который можно перепродать с маржой. Когда Anthropic берёт на себя цикл исполнения, OpenAI — реестр коннекторов, AWS — память и наблюдаемость, вся себестоимость, на которой строилась цена, испаряется. Не потому что заказчик стал умнее, а потому что у него теперь есть кнопка «Agent Builder» бесплатно или почти бесплатно. Разговор в октябре 2025, который в растущем сообществе вокруг агентных стеков звучал как откровение — «модель — товар, harness определяет успех агентов» — за полгода устарел. Harness теперь тоже товар. И это меняет не одну строчку в P&L, а весь жанр: студия, которая продаёт «соберём вам агента», в 2026 — это студия, которая в 2018 продавала «настроим вам Kubernetes». Ещё работает, но потолок виден. Производное следствие важнее самого факта. На воронке такой студии теперь стоит не «вам нужен бот?», а «вам нужен бот, или ваш CTO уже открыл AgentKit и собрал его за вечер?». В обоих случаях продаваемая ценность — не в harness. Она где-то ещё. Вопрос только в том, понимает ли студия, где именно, до того как закроется следующий квартал. ## Что именно стало товаром Имеет смысл смотреть не на «агентов» вообще, а на компоненты. Маршрутизация инструментов и function calling — нативная часть API всех четырёх провайдеров; это больше не код, это конфиг. Память краткосрочная и долгосрочная — управляемый интерфейс у Anthropic, AgentCore Memory у AWS, управляемый контекст у Google; кастомные RAG-конвейеры теряют ROI на глазах. Многошаговая оркестрация — Agent Builder у OpenAI, AgentCore Runtime у AWS, A2A protocol у Google ([TNW](https://thenextweb.com/news/google-cloud-next-ai-agents-agentic-era)). Проверки и самоверификация — OpenAI Evals с оценкой трасс, AgentCore Observability с записью сессий и воспроизведением. Ограничения и PII detection — открытый код у OpenAI, встроенные у Google, AgentCore Identity у AWS. Стопка компонентов, которую год назад студия описывала клиенту как «наша архитектура», теперь почти полностью совпадает с прайс-листом Bedrock и таблицей возможностей AgentKit. Это и есть определение коммодитизации: универсальная форма, которую любой может купить за деньги, а не за время. Anthropic не случайно переименовал Claude Code SDK в Claude Agent SDK — это сигнал, что вся стопка теперь продукт, а не пример кода. То, что **не** провалилось внутрь платформы, тоже понятно. Институциональное знание — то, как именно конкретная компания принимает решения, какие у неё граничные случаи, кто и когда эскалирует. Данные траекторий (trajectory data) — закрытый цикл «вход → решение агента → исход через N дней», который восстанавливается только через работу, не через промпт. Глубокая интеграция в окружение клиента — 1С, amoCRM, отраслевые API, legacy. Эти три слоя в [Forbes-эссе Sanjay Srivastava](https://www.forbes.com/sites/sanjaysrivastava/2026/03/04/in-ai-the-moat-is-moving/) названы non-absorbable не из стилистических соображений, а потому что их нельзя упаковать в SDK, не имея доступа внутрь компании клиента. ## Три слоя, которые нельзя купить через npm Названия здесь важны, потому что от их понимания зависит, чем компания будет заниматься следующие два года. | Слой | Что теперь товар | Что остаётся защитимым | |------|----------------------|--------------------------| | Harness | Маршрутизация инструментов, управляемая память, проверки, ограничения у 4 провайдеров | Не даёт клиенту собственного операционного слоя | | Слой представления | Типовые CRM-объекты и шаблонные схемы | Вертикальная схема сущностей, статусов и граничных случаев клиента | | Данные траекторий | Логи, трассы и воспроизведение в управляемой наблюдаемости | Закрытый цикл вход → решение → исход через дни или недели | | Регламент | Документы и промпт-правила | Исполняемая политика компании с журналом аудита и версиями | **Слой представления (representation layer).** Это то, как бизнес моделируется в данных. Какие сущности первичны — лид, актив, контрагент, событие. Какие у них статусы. Что считается дублем. Что считается просрочкой. У большинства компаний это знание не лежит в одном месте: оно размазано между CRM, табличкой в Google Sheets, головой менеджера и чатом в WhatsApp. Когда компания строит AI-контур, она впервые вынужденно фиксирует слой представления как явный, структурированный объект — вертикальную схему. И этот объект, в отличие от модели, не товар: его нельзя скачать с Hugging Face, потому что он точен ровно настолько, насколько точно описывает конкретную операционную реальность. Gartner прогнозирует, что через 2026 год 60% AI-проектов будут свёрнуты из-за недостаточного качества данных — именно потому что слой представления не формализован. Жанр такой работы ближе к тому, что [Foundation Capital в эссе про service-as-software](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) называет «кодификацией экспертизы», чем к традиционной разработке. **Данные траекторий (trajectory data).** Закрытый цикл. Что агент сказал → что человек сделал → что произошло через час, день, неделю. Бенчмарки 2025–2026 (BEAM из UAlberta, MemoryAgentBench из UCSD, LongMemEval) показали, что окно контекста в 1M токенов не равно 1M-токенной памяти: модели деградируют именно на задачах разрешения противоречий, упорядочивания событий и обновления знания во времени. Это значит, что временная траектория — отдельная архитектурная задача, и [open-source memory-стек](https://github.com/getzep/graphiti) (Graphiti, Letta, Cognee) её решает только частично: он даёт хранилище, но не данные. Данные появляются от того, что агент работает в реальной операции, а не на синтетике. Их нельзя восстановить задним числом без месяцев работы в том же контексте — это и есть структура издержек на смену поставщика. **Институциональный регламент (institutional SOP).** Операционный плейбук компании, превращённый в исполняемую политику. Не «инструкция в Notion», а граф решений: триггеры повторного контакта, правила ценообразования, пороги эскалации, кто имеет право подписать скидку, какие исключения допустимы, какие нет. До AI это знание жило в людях. Когда оно становится частью контура агента, происходит смена носителя: регламент теперь не «как мы тут работаем», а артефакт, который компания владеет, версионирует и аудирует. Как формулирует [Vendep в эссе про вертикальные рабочие потоки](https://www.vendep.com/post/forget-the-data-moat-the-workflow-is-your-fortress-in-vertical-saas): forget the data moat, the workflow is your fortress — и это не маркетинг, это описание того, что именно остаётся, когда модель и harness уходят вниз по стеку. Эти три слоя не покупаются через `npm install`. Их строят. Медленно, по одному клиенту, по одной вертикали. И их главное свойство — они компаундируются: каждое следующее внедрение делает следующий точнее. ## Агентная компания как сборка этих слоёв Эти три слоя — не дополнительные возможности поверх агента. Они — форма самой компании, которая их использует. Именно про это говорит Andrej Karpathy, когда называет LLM «kernel of a new operating system» в своём [докладе 2023 года «Intro to Large Language Models»](https://www.youtube.com/watch?v=zjkBMFhNj_g) — где «LLM OS» выделен как отдельная глава. Именно про это Jack Dorsey написал в [акционерном письме Block](https://www.theguardian.com/technology/2026/feb/27/block-ai-layoffs-jack-dorsey) в феврале 2026: «Intelligence tools have changed what it means to build and run a company» — и срезал 4 000 позиций (40% штата), обосновав это напрямую как операционную перестройку под AI. И это же — основная мысль [Foundation Capital](https://foundationcapital.com/ideas/ai-leads-a-service-as-software-paradigm-shift) про переход от SaaS к service-as-software: AI продаёт не инструмент, а готовую работу. Пока этот паттерн собирают по частям, но не как целое. Описать его можно тремя сменами акцента. **Cron вместо проекта.** В классической компании работа упакована в проекты — сущности с началом, концом, бюджетом и менеджером проекта. В агентной компании ключевая единица — повторяющийся цикл. Агент, который каждое утро в 9:00 проверяет состояние воронки и эскалирует то, что зависло. Агент, который раз в час пробегает по тикетам поддержки и помечает то, что требует человека. Cron-задачи — не вспомогательные скрипты, а основная операционная ткань. Проекты остаются для исключений; рутина живёт в расписании. **Память вместо документа.** Документ оптимизирован под человека: его читают глазами, забывают, переписывают по поводу. У агента есть структурированная память — вертикальная схема плюс темпоральный граф знаний — которая обновляется непрерывно, держит valid_at и invalid_at, разрешает противоречия не «последний прав», а с историей. Продуктовая документация, инструкции для саппорта, описание процессов — всё, что в обычной компании живёт в Notion и устаревает за квартал, в агентной компании живёт как структурированная память, которая обновляется в момент выполнения работы. **Роль вместо штатной единицы.** В классической компании единица найма — место. Junior support, middle sales, senior PM. В агентной компании единица — роль с явным контрактом: что роль делает, какие у неё входы и выходы, какие пути эскалации, какая память. Один человек может занимать несколько ролей. Часть ролей делают агенты. Часть — гибрид. Дорожная карта ролей похожа не на оргструктуру, а на список сервисов в Kubernetes: версии, зависимости, наблюдаемость. Это не теория. Klarna, по собственному заявлению, заместил порядка 40% штата AI-системами. Salesforce сократил 4000 позиций под тем же предлогом. Sam Altman публично сделал ставку на появление в течение года первой компании-юникорна с одним человеком в штате. Это можно считать пиаром, но направление одно. И направление состоит не в том, что «AI помогает работать», а в том, что операционная единица другая: cron, память, роль. Связка трёх слоёв — слой представления, данные траекторий, регламент — собирает этот другой тип компании в нечто, что можно строить. Не как метафору, а как архитектуру. Harness стал товаром → выживает не тот, кто продаёт агентов, а тот, кто строит операционный слой → агентная компания и есть тот операционный слой. Эта связка объясняет, почему рынок «AI-агентств» в 2026 раздваивается: на тех, кто всё ещё продаёт harness (и закрывается), и тех, кто продаёт операционную систему для конкретной вертикали (и масштабируется). ## Что это значит для трёх типов читателей **Фаундер AI-проекта.** Если ваш текущий продукт — это «обёртка над API провайдера, упрощающая сборку агента», у вас 6–12 месяцев. Это не угроза, это просто календарь: управляемый harness уже идёт в GA у трёх из четырёх крупных провайдеров. Действие — не «придумать что-то ещё», а посмотреть, какой из трёх слоёв (слой представления, данные траекторий, регламент) у вашего продукта и ваших клиентов уже накапливается без вашего участия, и переинвестировать туда. Если ни один не накапливается — это сигнал, что вы строите типовой harness, и пора пересобирать гипотезу. Конкретно: если вы не можете внятно описать, какой маховик данных запускается у вашего клиента в первые 30 дней работы продукта, — у вас нет соответствия продукт-рынок (product-market fit), у вас есть демо. **Руководитель компании, думающий про AI.** Главная ошибка 2026 года — покупать «AI-бота» как изолированный SaaS, отдельно от своих процессов. Это эквивалент покупки CRM в 2010-х в надежде, что она «улучшит продажи»: сама по себе не улучшит. Покупать стоит операционный слой — поставщика, который интегрируется в ваш контур и помогает вам кодифицировать регламент, накопить данные траекторий и зафиксировать слой представления. Тестовый вопрос на discovery-встрече: «через 6 месяцев работы с вами что у меня есть, чего не было?». Если ответ — «у вас работает бот», это продавец harness. Если ответ — «у вас есть структурированный операционный слой, который вы можете аудировать, версионировать и при необходимости перенести на другого провайдера», — это поставщик другого жанра. Заодно проверьте контракт: фиксирует ли он провайдера. Если да — это не защитимая часть, это привязка, и при следующем шаге провайдеров вверх по стеку вы будете платить за это снова. Именно такой операционный слой — берём один измеримый процесс и собираем вокруг него AI-контур, который ведёт его сам, — мы строим как рабочую систему, а не пилот: [посмотреть, как это устроено](https://ai.temadev.org/?utm_source=geo_referral&utm_medium=ai&utm_campaign=harness-commodity-operating-layer&utm_content=inprose). **Инженер, выбирающий, где работать.** Большая часть инженерных команд в AI-агентствах сейчас занята тем, что превращается в ETL-работу нового поколения: интеграция управляемых компонентов друг с другом плюс прослойки, которые не выживут до 2027. Это не плохая работа — но она не компаундируется. Команды, где компаундируется опыт, — это те, кто работает в одной вертикали достаточно глубоко, чтобы накапливать слой представления и данные траекторий. Признак: команда не описывает свою работу в терминах «мы интегрируем GPT/Claude», а в терминах «мы строим операционный слой для X». Если на собеседовании вам показывают архитектуру вокруг harness, а не вокруг домена — это команда, которая через год будет делать миграцию своего же стека на управляемый harness и думать, чем заняться. Если вокруг домена — у вас есть шанс проработать там пять лет и выйти с компетенцией, которой не будет ни у кого, кроме людей с этим же опытом. ## На какие сигналы смотреть Тренд имеет несколько проверяемых траекторий, по которым видно, ускоряется он или нет. Первая — появление управляемого harness агентов у не-западных провайдеров. GigaChat и YandexGPT в РФ, Qwen и Doubao в Китае. Если в течение Q3–Q4 2026 в их продуктах появляется визуальный конструктор агентов и управляемая память — это сигнал, что коммодитизация harness вышла на глобальный уровень и больше не зависит от географии. Вторая — появление маркетплейсов вертикальных шаблонов от провайдеров: «готовые наборы регламентов под ритейл, страхование, логистику». Если такие маркетплейсы открываются, нижний сегмент вертикального AI становится неустойчивым, и операционный слой как сервис должен сместиться вверх по среднему рынку. Третья, обратная — появление публичных кейсов компаний, которые ушли с управляемого harness обратно в собственный стек. Если такие кейсы будут — значит, либо managed-продукт упёрся в потолок применимости, либо стоимость выхода оказалась выше, чем казалось при подключении. Это интересный сигнал для всех, кто сейчас выбирает между «строить» и «купить». В любом сценарии главный вопрос остаётся одним и тем же. Не «какого агента построить», а «какой операционный слой вокруг агентов мы собираем за следующие 24 месяца, и кому мы будем им владеть к 2028». Это вопрос о форме компании, не о технологии. Технология уже общая. ## Главное - Harness агентов (память, оркестрация, проверки, ограничения) стал товаром: Anthropic, OpenAI, Google, AWS выпустили managed-продукты за один квартал. - Защитимыми остаются три слоя: слой представления (вертикальная схема данных), данные траекторий (закрытый цикл вход→решение→исход), институциональный регламент (политика компании как исполняемый граф решений). - Агентная компания — это не метафора, а архитектура: cron вместо проекта, память вместо документа, роль вместо штатной единицы. - Рынок AI-агентств раздваивается: те, кто продаёт harness — закрываются; те, кто строит операционный слой для вертикали — масштабируются. ## FAQ **Что такое harness в контексте AI-агентов?** Harness — это контур исполнения вокруг модели: маршрутизация инструментов, память, песочница, оркестрация, проверки, ограничения и наблюдаемость. В 2025 этот слой ещё выглядел как инженерная дифференциация. В апреле 2026 четыре крупных провайдера вынесли его в managed-продукты, поэтому продавать один harness как главную защитимую часть стало слабой позицией. **Почему управляемый harness обесценивает AI-агентства за квартал?** Потому что он забирает себестоимость, на которой держалась цена агентства: сборку памяти, вызова инструментов, оркестрации и базовых проверок. Если клиент может получить 70-80% этого слоя в AgentKit, Managed Agents или AgentCore, агентство должно продавать не «бота», а кодификацию бизнеса. Иначе discovery-встреча превращается в простое сравнение поставщиков. **Чем слой представления отличается от обычной CRM-схемы данных?** CRM-схема хранит поля и статусы; слой представления фиксирует смысловой контракт бизнеса: какие сущности первичны, какие переходы валидны, что считается ошибкой, дублем или эскалацией. Для AI-агента это не справочник, а рабочий язык. Именно поэтому слой представления нельзя купить через SDK провайдера. **Данные траекторий — это просто логи или что-то ещё?** Нет. Лог фиксирует, что произошло в системе; данные траекторий связывают вход, решение агента, вмешательство человека и бизнес-исход через час, день или неделю. Эта петля нужна, чтобы учить регламент и валидаторы на реальной операции. Управляемая наблюдаемость даёт трассы, но не создаёт клиентскую историю исходов. **Как отличить настоящий операционный слой от обёртки над API?** Спросите, что останется у клиента через 6 месяцев, если модель и провайдер поменяются. У обёртки останется набор промптов и интеграций. У операционного слоя останутся вертикальная схема, история траекторий, исполняемый регламент, журнал аудита и понятный план переноса на другой слой инференса и harness.