Когда полезный ИИ-агент становится проблемой для компании

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

Менеджер подключает почту к CRM, чтобы не переносить обращения вручную. HR-специалист собирает помощника для первичного разбора резюме. Финансовый сотрудник настраивает сверку выписок и счетов. Технолог загружает инструкции в базу знаний, чтобы быстрее находить нужный пункт.

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

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

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

— «Это просто помощник для отдела продаж. Он читает письмо, вытаскивает контакты и создаёт сделку в CRM».

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

На первый взгляд всё сходится.

Через две недели в CRM появляется 47 сделок с неверным источником обращения. В части карточек бот подтянул данные из старой переписки. В шести случаях создал дубликаты: клиент сначала оставил заявку на сайте, потом ответил в почте, а система не распознала, что это один и тот же запрос.

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

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

Я часто вижу именно такую последовательность. Сначала сотрудник находит способ убрать несколько ручных действий. Потом коллеги просят дать им доступ. Затем решение получает данные из CRM, почты или корпоративной папки. И в какой-то момент компания уже зависит от инструмента, который никто специально не принимал в работу.

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

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

Граница проходит в другом месте. Я бы проверяла три вопроса:

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

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

В резюме — ФИО, телефон, электронная почта, город, опыт работы, иногда дата рождения, ссылки на социальные сети и рекомендации. Сотрудник хотел быстрее просматривать поток откликов. Это понятная задача.

Но дальше я бы остановилась не на качестве ответа модели, а на других вопросах:

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

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

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

Проверка начинается именно здесь: какие права действительно нужны помощнику для одной конкретной операции?

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

Затем сотрудник уходит в отпуск. Через три дня меняется пароль от его учётной записи. Скрипт перестаёт работать.

И выясняется, что никто не знает:

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

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

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

Первый вариант готовит менеджеру текст письма. Менеджер проверяет условия, срок, цену, исключения по договору и нажимает «отправить».

Второй сам отправляет письмо клиенту, меняет статус сделки, создаёт заказ, назначает исполнителя или формирует заявку на закупку.

Во втором случае ошибка быстро выходит за пределы одного экрана.

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

Чем выше цена ошибки, тем важнее оставить контрольное действие человеку.

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

После нескольких таких случаев руководитель может решить: запретить сотрудникам создавать ботов и подключать AI-сервисы.

Я понимаю эту реакцию. На бумаге она выглядит безопасной. В работе обычно происходит другое.

Менеджер продолжает копировать фрагменты писем в личный помощник, чтобы быстрее подготовить ответ. HR-специалист тестирует сервис на резюме. Руководитель отдела ведёт собственную таблицу с макросами. Сотрудники не перестают искать способ убрать ручное копирование между почтой, Excel, CRM и внутренними системами. Они просто перестают обсуждать это с компанией.

В результате у руководителя становится меньше контроля, а не больше.

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

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

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

Когда сотрудник показывает руководителю помощника, который разбирает обращения клиентов и готовит карточку сделки, я бы не начинала с вопроса: «Можно ли это использовать?»

Сначала стоит проверить саму задачу. Сколько обращений проходит через процесс? Где сотрудники тратят время на перенос данных? Какие ошибки повторяются? Что именно будет считаться хорошим результатом?

Затем — определить границы данных. Достаточно ли тестовой выборки? Нужны ли помощнику персональные данные, цены, договоры и история переписки? Может ли он работать только с одной папкой или одним полем CRM?

После этого — проверить действие. Помощник предлагает черновик карточки или сам создаёт её? Может ли отправить письмо? Имеет ли право менять статус заказа? Какие действия нельзя выполнять без подтверждения сотрудника?

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

Например, менеджер тратит 7 минут на создание карточки по входящему обращению. Помощник сокращает операцию до 2 минут с обязательной проверкой. Экономия составляет 5 минут на одну заявку. При 400 заявках в месяц это 2 000 минут, или около 33 часов в месяц. За квартал — около 100 часов. За год — около 400 часов.

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

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

После пилота появляется основание для решения:

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

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

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

Если его автор завтра не выйдет на работу, кто поймёт, какие данные он использует, где лежат доступы, как проверить результат и как восстановить процесс?

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