Я не внедряю ИИ как отдельный проект: сначала ищу решение, за которое по-прежнему отвечает человек

Я не внедряю ИИ как отдельный проект. Формулировка «давайте добавим ИИ» звучит современно, но не отвечает на главный вопрос: какое решение в рабочем дне станет лучше и кто по-прежнему отвечает за его последствия.

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

Начинать стоит не с модели, а с решения

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

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

Я сначала записываю простую фразу: «Сотрудник выбирает X, чтобы получить Y». Потом проверяю, можно ли помочь именно в этом шаге: собрать факты, подсветить расхождения, предложить черновик ответа или напомнить о правилах. Решение не исчезает у человека, зато у него появляется более ясная опора.

У совета должен быть владелец

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

Без этого появляется опасная фраза: «так решила система». Она удобна, потому что снимает спор с сотрудника. Но бизнесу от неё не легче: клиент всё равно ждёт ответа, склад всё равно отправляет товар, а руководитель всё равно отвечает за последствия.

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

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

Где ИИ действительно помогает

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

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

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

Границы данных важнее эффектной демонстрации

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

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

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

Проверять нужно на реальном рабочем дне

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

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

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

Право не согласиться — часть дизайна

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

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

Мой короткий список перед стартом

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

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

Не все решения одинаково рискованны

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

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

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

Нужно договориться, что считать ошибкой

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

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

Почему команда должна участвовать с самого начала

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

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

Что я проверил бы через месяц

• Сократился ли поиск и ручная подготовка именно в выбранном шаге.
• Стало ли меньше возвращённых на уточнение решений.
• Могут ли сотрудники объяснить, когда помощнику верить, а когда проверять.
• Не возник ли новый обходной путь вне системы.
• Есть ли понятный владелец улучшений и разбор ошибок.

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

В итоге я не жду от ИИ самостоятельной мудрости. Я жду, что он поможет человеку увидеть факты быстрее, принять решение спокойнее и оставить проверяемый след. Тогда компания получает не модную витрину, а управляемый инструмент.

Не прятать решение за красивой формулировкой

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

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

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

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

Короткая договорённость до первого запуска

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

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

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