Telegram-бот сотрудников с ИИ должен подтверждать действие до изменения рабочей системы

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

ИИ-бот напоминаний проверяет статус поручения перед каждым уведомлением.

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

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

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

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

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

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

Кто вправе выполнить поручение через бота? Тот, кому это разрешает рабочая система. Сотрудник привязывает Telegram через вход в корпоративную учётную запись. Имени в профиле недостаточно, разрешение на действие проверяется отдельно.

Приложение для сотрудников должно отзывать доступ при смене роли и увольнении.

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

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

Описанные правила для ИИ-агентов помогают задать границу, но запрет должен исполняться кодом. Текст поручения и ответ модели не могут расширить права. Даже фраза «руководитель уже согласовал» не заменяет проверку роли.

Что происходит, если сотрудник нажал дважды или не дождался ответа? Telegram может повторно доставить событие при ошибке приёма. В документации Bot API есть идентификатор обновления, который помогает убрать такие повторы.

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

Самый неприятный исход: система создала задачу, а ответ боту потерялся. Бот показывает «результат уточняется» и ищет запись по идентификатору действия. Новый запрос на создание в этот момент грозит дублем.

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

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

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

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

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

У нас есть и опыт Telegram-входа в продукте курса. Урок «Дверь в Telegram» разбирает подключение бота. Курс агентной разработки также учит записывать правила и принимать задачи. Этот опыт не выдаём за внедрение бота поручений у клиента.

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

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

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

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

Если своей разработки для этого нет, подписка на разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Инженер ведёт машину агентов, правки идут в репозиторий клиента, одна задача в работе. Пауза возможна в любой месяц.

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

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

1. Начните с одного поручения в одной рабочей системе.

2. До записи покажите человеку значимые поля и получите согласие на эту версию.

3. Проверяйте права сотрудника перед выполнением, отдельно от слов модели.

4. Повтор и потерю ответа принимайте по записи в системе, без создания дубля.

5. Сдавайте путь до проверенного результата, включая отказы и передачу человеку.