Из пяти тезисов, которые продавались вместе с ИИ последние годы, полностью не подтвердился один: модель не учится на ваших данных сама. Три подтвердились, но не в той формулировке, в которой их произносили. Один оказался верным по сути и неверным по срокам. Всё, что ниже, — по состоянию на сентябрь 2026 года.
Разбор нужен не ради справедливости к технологии. Формулировка ожидания определяет три практических вещи: как считается бюджет, что записывается в приёмку и по какому признаку проект считается удавшимся. Компания, которая купила «замену отдела», не примет систему, снявшую очередь, — хотя именно это и есть нормальный результат. Компания, ожидавшая точности 99 %, не построит процесс разбора ошибок — и через полгода получит систему, которой никто не доверяет.
Ниже — пять тезисов подряд, с расчётом там, где расчёт возможен, и с честной пометкой там, где мы даём оценку, а не измерение. В конце — три вещи, которые за последние два года действительно стали дешевле и надёжнее, и признаки, по которым будет видно, что этот текст пора пересматривать.
Пять тезисов и что с ними стало
Сводка ниже — рабочая рамка, а не отраслевая статистика. Она собрана из того, как выглядят проекты в эксплуатации, и из формулировок, которые чаще всего встречаются в коммерческих предложениях. Правая колонка — то, что имеет смысл писать в договоре вместо исходного обещания.
| Тезис | Что подтвердилось | Что не подтвердилось | Как формулировать сейчас |
|---|---|---|---|
| «ИИ заменит отдел» | Снятие очереди и повторяющейся части работы | Исчезновение ролей и сокращение штата | Освободит долю ставки на повторяющихся задачах, роли останутся |
| «Внедрение за две недели» | Техническая сборка действительно занимает 2–3 недели | Проект целиком: данные, регламент, люди | Демонстрация за 2–3 недели, эксплуатация через 3–5 месяцев |
| «Модель научится на ваших данных» | Поиск по вашей базе знаний работает и стоит недорого | Модель ничему не учится от того, что вы загрузили документы | Модель отвечает по вашей базе, но не запоминает её |
| «Точность 99 %» | На узкой задаче и чистой выборке такая цифра бывает | Цифра не переносится на ваш реальный поток | Точность измеряется на вашей выборке, с указанием краевых случаев |
| «Окупится за месяц» | Окупаемость 3–6 месяцев при верно выбранном процессе | Месяц — срок запуска, а не срок возврата вложений | 3–6 месяцев при потоке выше порога, иначе не окупится вовсе |
Сравнение в две колонки на пять строк. Левая колонка «Как обещали»: заменит отдел; внедрение за две недели; модель научится сама; точность 99 %; окупится за месяц. Правая колонка «Как это работает»: освобождает 0,43 ставки; демонстрация 2–3 недели, эксплуатация 3–5 месяцев; отвечает по базе, но не запоминает; точность считается на вашей выборке; окупаемость 3–6 месяцев. Между колонками — вертикальная линия с пометками: одна строка перечёркнута полностью, четыре помечены знаком уточнения. Чертёжный стиль, подписи по-русски.
«Заменит отдел»: что произошло с четырьмя операторами
Самый громкий тезис проверяется быстрее всех, потому что у него есть измеримое следствие: если отдел заменён, фонд оплаты труда должен упасть. Возьмём модельную поддержку компании на 80 человек: четыре оператора, 1 800 обращений в месяц. Часть вопросов повторяется дословно — сроки, статусы, реквизиты, порядок возврата. Именно эту часть закрывает чат-бот поддержки вместе с классификацией обращений, которая раскладывает поток по темам.
Для компании на 30–100 человек вывод из этой арифметики прямой и он меняет решение уже сейчас. Считать эффект надо не в людях, а в часах и рублях: доли ставки складываются, ставки — нет. Четыре освобождённые доли по 0,4 в разных отделах дают полторы ставки экономии, но не дают ни одного сокращения — люди в этих отделах просто перестают работать очередью. Если бюджет проекта обоснован увольнением, проект не примут: увольнения не будет.
Столбчатая диаграмма из четырёх столбцов с подписями: «Все обращения — 1 800», «Повторяющиеся, 55 % — 990», «Закрыто ботом, 70 % от повторяющихся — 693», «Осталось людям — 1 107». Последний столбец выделен другим тоном. Под диаграммой строка: «69,3 освобождённых часа = 48 510 ₽ = 0,43 ставки». Оси подписаны: обращения в месяц. Чертёжный стиль, всё по-русски.
Два обещания про скорость: «две недели» и «научится сама»
Обещание про две недели не выдумано. Собрать работающий прототип с поиском по документам действительно можно за 2–3 недели, и три года назад это заняло бы месяцы. Подмена происходит в другом месте: срок сборки выдают за срок проекта. Между прототипом и эксплуатацией лежат три этапа, к скорости модели отношения не имеющие, — мы разбирали их порядок в материале о том, как устроен проект внедрения.
- 1Техническая сборка — 2–3 недели
Модель, поиск по базе, интерфейс, подключение к одной системе. Та самая часть, которая попадает в демонстрацию и в обещание «за две недели».
- 2Данные — 3–6 недель
Выгрузка, чистка, разбор дублей, приведение справочников к одному виду. Срок зависит не от подрядчика, а от состояния учёта: это единственный этап, который заказчик может ускорить сам.
- 3Процесс и регламент — 2–4 недели
Кто проверяет ответ, что делать при отказе системы, куда уходит спорный случай. Без этого этапа система работает, но ей не пользуются.
- 4Опытная эксплуатация — 4–8 недель
Реальные обращения вместо тестовых, разбор ошибок, правка инструкций. Здесь появляется большая часть доработок, которых не было в смете.
Этапы частично идут внахлёст, поэтому в календаре получается не сумма, а 3–5 месяцев — тот самый средний срок комплексного проекта. Обещание «за две недели» становится честным ровно в одном случае: когда речь идёт о готовом SaaS-решении без интеграций, за подписку. Как только появляется связка с вашей учётной системой, срок возвращается к трём месяцам.
Горизонтальная лента времени на 3–5 месяцев с четырьмя полосами внахлёст: «Техническая сборка — 2–3 недели» (выделена контуром и подписью «то, что показывают в демонстрации»), «Данные — 3–6 недель», «Процесс и регламент — 2–4 недели», «Опытная эксплуатация — 4–8 недель». Справа отметка «эксплуатация: 3–5 месяцев от старта». Чертёжный стиль, шкала в неделях, подписи по-русски.
Когда вы загружаете в систему регламенты и договоры, модель их не запоминает. Документы кладутся в отдельное хранилище, и при каждом вопросе система находит нужные куски и передаёт их модели вместе с вопросом. Это называется поиском по базе знаний. Дообучение — другая процедура: меняются веса самой модели, нужна размеченная выборка, отдельные вычисления и повторная проверка качества. Разницу мы подробно разбирали в материале про дообучение или поиск по базе.
«Система обучится на ваших данных» в коммерческом предложении — признак того, что либо подрядчик упрощает, либо не различает эти две вещи сам. Спросите прямо: загрузка в базу знаний или изменение весов модели. Если второе — попросите показать, где берётся размеченная выборка и кто оценивает качество после дообучения. Ответ на этот вопрос стоит недели переговоров и экономит месяцы спора на приёмке.
Два обещания про цифры: «99 %» и «окупится за месяц»
Оба тезиса ломаются одинаково: верная цифра берётся из чужого контекста и переносится в ваш. С точностью это выглядит так — производитель измерил её на своей выборке, где документы одного типа, ровно отсканированы и заполнены по шаблону. Ваш поток другой: печати поверх текста, дописки от руки, факсовые копии. На распознавании счетов и актов разница между витринной и вашей выборкой доходит до десятков процентных пунктов, и узнать её можно только на своей пачке документов.
- Точность без выборки — не число. Требуйте замера на 200–300 ваших документах и раздельных цифр по типам: счета, акты, накладные ведут себя по-разному. Одна общая цифра прячет провал на самом сложном типе.
- У остатка ошибок должна быть процедура. Даже 97 % на потоке в 3 000 документов в месяц — это 90 документов с ошибкой. Вопрос не в проценте, а в том, кто их видит и за сколько минут исправляет. Если процедуры нет, точность не имеет значения.
- Месяц — это срок запуска. Возврат вложений начинается после того, как система вышла в эксплуатацию, то есть на третьем-пятом месяце. Типичная окупаемость при верно выбранном процессе — 3–6 месяцев; порядок расчёта разобран в методике окупаемости.
- Срок удлиняют три вещи: грязные данные, отсутствие описанного процесса и низкий поток. Первые две лечатся работой, третья не лечится ничем — ниже порога объёма проект не окупается ни за какой срок.
Что за два года действительно сбылось
Инвентаризация нечестна, если считать только несбывшееся. Три вещи за последние два года стали заметно дешевле и надёжнее, и это меняет решения компаний на 30–100 человек прямо сейчас.
- Поиск по собственной базе знаний перестал быть проектом. То, что раньше требовало отдельной команды и месяцев работы, сейчас собирается в пределах базовой вилки 150 000–200 000 ₽ за 3–8 недель. Именно на этом стоит корпоративная база знаний и большая часть внутренних помощников.
- Распознавание типовой первички стало рутиной. Счета, акты, накладные и УПД в российском стеке разбираются надёжно, и спор идёт уже не о том, работает ли это, а о проценте краевых случаев и о том, кто их разбирает.
- Повторное применение подешевело. Второй и третий однотипный процесс в той же компании обходятся ощутимо дешевле первого: связка с учётной системой уже построена, регламент проверки уже написан, люди уже привыкли. Дешевеет не первый проект, а следующий — и это единственная скидка, которую стоит планировать заранее.
Что из этого устареет первым и как это заметить
Первым устареет тезис про две недели, и устареет он в сторону обещания. Техническая сборка продолжает дешеветь и ускоряться; при этом этапы данных, регламента и опытной эксплуатации не сокращаются вовсе — они упираются в людей и в состояние учёта. Значит, разрыв между демонстрацией и эксплуатацией будет только расти, а не сокращаться, и подмена одного срока другим станет встречаться чаще.
- Как заметить, что сборка снова подешевела: попросите у подрядчика оценку прототипа отдельной строкой. Если доля этой строки в смете за год упала, а общий чек не изменился — деньги переехали в данные и эксплуатацию, и это нормально.
- Что устареет вторым: цифры точности. Их надо перепроверять на своей выборке при каждом обновлении модели, а не при каждом чтении статьи. Модель меняется чаще, чем выходят обзоры.
- Что не устареет: разница между базой знаний и дообучением, необходимость процедуры для остатка ошибок и связь окупаемости с объёмом потока. Это свойства арифметики, а не текущего поколения технологий.
- Признак, что пора перечитать эту статью: в вашем следующем коммерческом предложении появился новый тезис, который вы не можете проверить расчётом. Проверять надо не тезис, а способ его измерения.
Когда ожидание надо не переформулировать, а отменить
Есть четыре ситуации, в которых уточнение формулировки не спасает и правильный ответ — не начинать. Мы называем их до договора, а не после приёмки.
- Бюджет обоснован сокращением людей. Если экономия в расчёте появляется только после увольнения двух человек, проект не окупится: увольнения не будет, а расходы будут. Пересчитайте на освобождённых часах — и решение изменится само.
- Поток ниже порога. На 200 обращениях в месяц любая связка с учётной системой окупается годами: сборка стоит столько же, сколько при двух тысячах. Дешевле оставить руками и вернуться, когда поток вырастет втрое.
- Процесс меняется каждый месяц. Автоматизировать нечего: вы зафиксируете черновик и будете платить за переделки. Сначала устойчивый регламент хотя бы на квартал, потом система — этот же порядок разобран в материале о том, почему проекты автоматизации проваливаются.
- Цена ошибки высокая, а процедуры разбора нет. Там, где ошибка стоит денег или репутации, система без человека на выходе не запускается. Если организовать проверку некому — это не проект про ИИ, это проект про людей, и начинать надо с него.
Обещание, которое нельзя проверить расчётом, — не обещание, а формулировка для презентации.
