Внедрение ИИ в бизнес: почему чаще всего не доходит до результата

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

Что теперь можно отдать машине

Автоматизировать раньше можно было в основном однозначные операции: случилось X — сделай Y. Пока данные лежат по полям и правило записано, машина работает быстрее и точнее человека.

Но огромная часть работы в любой компании состоит из шагов другого рода:

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

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

На примере найма

Проще всего это видно на найме. Разложим процесс на шаги:

1. Понять, кого мы ищем: на какой процесс берём человека, какие у него обязанности, какая мотивация, что он должен делать. И из этого сформировать вакансию.
2. Разместить вакансию.
3. Собрать отклики и следить за ними.
4. Прочитать резюме и понять, подходит человек или нет.
5. Связаться: позвонить, договориться о встрече или отправить тестовое.
6. Проверить тестовое.

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

А всё остальное обычным способом — правилами — не автоматизировалось:

• прочитать резюме;
• оценить, подходит нам человек или нет;
• списаться с ним и договориться о встрече;
• довести переписку до тестового задания;
• проверить это тестовое.

Причина у всех пяти одна.

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

А теперь попробуйте выписать правило, по которому вы решаете, что кандидат толковый. Решение вы принимаете секунд за десять и чаще всего попадаете — а условиями его не запишете. Философ Майкл Полани описал это ещё в 1966 году одной фразой: мы знаем больше, чем можем рассказать. Его пример — умение водить машину не заменишь основательным изучением теории автомобиля. С тех пор это так и называют, парадоксом Полани.

Через полвека из этого парадокса вывели практическое следствие. Экономист Дэвид Отор в 2014 году показал, что вся история компьютеризации им и объясняется: машине давалось то, что описывается явной повторяемой процедурой, и не давалось то, что требует гибкости, суждения и здравого смысла — то есть навыков, которыми мы владеем, но объяснить не умеем. Дело не в мощности компьютера. Программисту просто нечего запрограммировать.

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

Вот вам и граница в найме. Разместить вакансию — правило выписывается. Решить по резюме, годится человек или нет, — не выписывается. Один пишет «руководил отделом продаж», второй «выстроил коммерческую функцию с нуля», третий вместо резюме прикладывает презентацию. Смысл один, слова разные, и заранее перечислить все варианты невозможно. С перепиской ещё сложнее: отвечать надо на то, что человек написал, а написать он может что угодно.

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

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

Вот это и изменилось — не сам принцип, а его цена. Учиться на примерах модели умели и тогда. Разница в том, что раньше модель надо было обучать под вас и на ваших данных, а теперь она приходит уже обученной. Ей достаточно объяснить задачу словами, как объяснили бы новому рекрутеру, — и дальше она работает с текстом, который каждый раз написан по-новому. Так же ведёт переписку с кандидатом, договаривается о времени и разбирает присланное тестовое.

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

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

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

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

Компания не знает, как устроен её процесс

Приходит запрос: хотим автоматизировать вот этот участок с помощью ИИ. Начинаешь разбирать процесс — и выясняется, что:

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

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

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

Самая банальная история. Приходят: сделайте нам ИИ, который будет разбирать входящие заявки. Начинаем смотреть, что на входе. Заявки стекаются в CRM из десятка источников — сайт, реклама, площадки, почта, — и нигде не настроена проверка на дубли. Один и тот же человек попадает в систему несколько раз, и сидит отдельный сотрудник, который как-то пытается эти заявки между собой соединить. Под это в компании даже завели отдельный этап воронки.

А теперь возникает идея: давайте сделаем ИИ-агента, который будет искать дубли.

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

Мысль, вообще говоря, не новая. Майкл Хаммер писал в Harvard Business Review ещё в 1990 году: автоматизируя бардак, получаешь автоматизированный бардак. И там же — пора перестать асфальтировать коровьи тропы. Тридцать пять лет прошло, поменялся только инструмент.

«Automating a mess yields an automated mess»— Майкл Хаммер, Harvard Business Review, 1990

Причин, по которым процесс остаётся неописанным, я вижу две.

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

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

«У нас всё уникально, это невозможно описать»

Дальше идёт разговор с тем, кто на этом шаге сидит. И звучит он предсказуемо: это невозможно формализовать, каждый случай индивидуальный, тут нужен опыт.

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

А когда начинаешь разбирать, что человек делает на самом деле, почти всегда получается одно и то же:

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

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

С чем вы сравниваете

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

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

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

ИИ почему-то требуют сравнивать со стопроцентным идеальным процессом. Хотя внедряется он не вместо идеального процесса, а вместо реального.

Считают ошибки вместо денег

Это отдельная болезнь, хотя выглядит похоже.

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

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

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

Критиковать, конечно, надо. Только взвешивать критику по объёму: три ошибки из ста — это три ошибки из ста, и рядом надо положить, сколько на той же сотне делал человек. Обычно этого никто не считал. А раз не считал, то «ИИ не работает» — заявление ровно такого же качества, как «ИИ решит все ваши проблемы». Проверять надо оба. Как раз про это — почему результат в отделе продаж выглядит случайным: пока никто не измерял, что делают люди, любой разговор о качестве упирается в мнения.

Данные, по которым всё это считается

ИИ анализирует ровно те данные, которые ему дали. Если решение принимается по данным из CRM, качество решения упирается в качество этих данных.

Такую сверку мы делаем на каждом подключении: Bewise разбирает по сделке все звонки, переписки и встречи и кладёт рядом то, что менеджер записал про них в карточке. Дальше видно, где одно расходится с другим. Расхождение получается от 20 до 60 процентов в зависимости от компании.

Из чего это расхождение складывается:

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

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

И это только про то, что записано неверно. Есть ещё общение, которое в CRM не попадает вовсе. Начинаешь собирать картину сделки — и выясняется, что часть переписки менеджер увёл в личный телеграм или на почту. Клиент в итоге не купил, а почему — не разберёшь, половины истории в системе просто нет. Руководитель при этом делает вывод, что аналитика не работает. А не работает дисциплина, с которой эту историю фиксируют.

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

Мы тут, к слову, не одиноки. В 2025 году опросили 602 компании про качество их CRM-данных — 76 процентов признали, что точны и полны меньше половины. Опрос делала Validity, американский разработчик программ для чистки данных, так что интерес у них тут понятный: спрашивают про проблему, которую сами же и лечат. Но порядок цифр сходится с тем, что видим мы.

Заниматься внедрением внутри компании обычно некому

Всё, что выше, — про внедрение, которое хотя бы началось. Чаще бывает иначе.

Возьмём небольшую компанию, выручка условно до миллиарда. Человека, который запускал бы новые проекты и отвечал за то, как в компании меняется работа, там нет — отдела тем более. Собственник увидел где-то кейс, ролик в ленте или съездил на конференцию. Загорелся. Передал задачу РОПу.

А у РОПа своя операционка, которую он тянет так, как привык. И теперь от него одновременно требуется:

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

Сколько внедрений умирает именно на этом, никто не считал. Но есть цифра про общий отсев — её собрала исследовательская группа MIT, которая изучает, что происходит с корпоративным ИИ. Инструменты присматривали 60 процентов компаний, до пилота дошли 20, до постоянной работы — 5. Почти все застревают между «потыкали» и «пользуемся каждый день». Считали, правда, по крупным компаниям США, Европы и Азии — как и почти вся статистика на эту тему. Сопоставимых цифр по российскому среднему бизнесу нет ни у кого, и выдумывать я их не буду.

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

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

Что со всем этим делать

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

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

Поэтому и вопрос, с которого начинают, чаще всего неправильный. Спрашивают: куда бы нам внедрить ИИ?

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

Ровно это тридцать пять лет назад и написал Хаммер, только тогда покупали большие корпоративные системы. Deloitte в 2026 году насчитал 84 процента компаний, которые купили новые инструменты, но саму работу под них так и не переделали, — и там же прямо сказано, что ИИ, навешенный на сломанный процесс, проблемы только усиливает.

Кто в этот момент садится и разбирается, как у него всё устроено, тот получает результат — и часто не столько от самого ИИ, сколько от этого разбора. У остальных начинается поиск виноватого: модель плохая, подрядчик плохой, сотрудники саботируют.