Telegram MCP — это MCP-сервер, через который ИИ-ассистент читает рабочие переписки сотрудника и готовит ответы, а отправляет их только после явного разрешения человека. Читать историю чатов можно лишь от имени пользовательского аккаунта, поэтому такой доступ шире, чем у бота, и требует жёстких границ. Схема подходит внутреннему контуру: служебные чаты в доступе, личные диалоги вне его, кнопка отправки у сотрудника.
Что умеет связка
MCP-сервер для Telegram отдаёт ассистенту инструменты чтения — список чатов, историю диалога, поиск по переписке — и отдельный инструмент отправки, привязанный к подтверждению человека. Состав инструментов зависит от конкретного сервера: их пишут сторонние авторы.
Типовые задачи контура: «прочитай переписку с поставщиком за март и вытащи согласованные сроки», «подготовь черновик ответа клиенту по шаблону», «своди обращения из группы поддержки за день по темам». Каждая задача держится на чтении как фундаменте и на отправке как редкой операции под контролем. Подключение MCP-клиента к серверу описано в материале про настройку MCP-подключений, здесь разбираем мессенджерный контур.
Отличие от чат-бота принципиальное. Бот ведёт диалог с клиентом сам по сценарию, а ассистент помогает живому сотруднику внутри его переписки. Сборку бота на Claude через n8n разбирает статья про подключение Claude к Telegram-боту. Здесь бота нет, зато есть чтение чужих сообщений, и вся безопасность строится вокруг этого факта.
Бот или аккаунт
Первый вопрос при выборе сервера — от чьего имени он ходит в Telegram. У Bot API ограничения жёсткие: по документации Telegram бот в группе с включённым режимом приватности получает только команды, адресованные ему, и ответы на свои сообщения. Метода для чтения истории в Bot API нет, а написать человеку первым бот может лишь после обращения самого человека.
Поэтому серверы, которые умеют искать по старой переписке, работают от имени пользовательского аккаунта через MTProto. Такой сервер видит всё, что видит владелец аккаунта: личные диалоги, закрытые группы, чаты с руководством. Для доступа нужны собственные API-учётные данные приложения. Условия Telegram API запрещают действия от имени пользователя без его ведома и согласия, а также использование данных Telegram для обучения моделей. Чтение по запросу сотрудника ради ответа — другой режим, но границу с юристом проверьте заранее.
| Способ доступа | Что видит ассистент | Главный риск |
|---|---|---|
| Бот через Bot API | Сообщения чатов, куда его добавили, с учётом режима приватности; истории нет | Узкий охват: задачи по старой переписке недоступны |
| Личный аккаунт сотрудника через MTProto | Всё, что видит владелец аккаунта, включая историю | Слишком широкий охват и зависимость от стороннего сервера |
| Отдельный служебный аккаунт | Только чаты, в которые его добавили | Нужны владелец аккаунта и утверждённый перечень чатов |
Для внутреннего контура разумный выбор — отдельный служебный аккаунт, добавленный только в рабочие чаты: охват задаётся составом чатов, а личная переписка сотрудника остаётся вне доступа. Сторонний сервер получает доступ к аккаунту, поэтому перед запуском читайте его исходный код, запускайте на своей стороне, а ключи сессии храните в хранилище секретов.
Чтение с границами
Чтение — массовая операция: ассистент обращается к истории много раз на один ответ, поэтому правила чтения проектируются первыми. Две практики закрывают большую часть рисков до технических мер: минимизация охвата, когда ассистент состоит только в служебных чатах, и обезличивание, когда телефоны, паспортные данные и реквизиты вырезаются до передачи текста модели. Подход к персональным данным разобран в материале о загрузке персональных данных в нейросеть.
- Составьте перечень чатов контура и владельца каждого: ассистент читает только чаты из перечня.
- Настройте вырезание чувствительных данных до отправки текста модели: телефоны, документы, банковские реквизиты.
- Ведите журнал обращений: какой чат, какой запрос, какой объём текста ушёл в модель.
- Раз в месяц сверяйте перечень с реальностью: чаты добавляются чаще, чем обновляются регламенты.
| Категория данных | Допуск в контур | Правило обработки |
|---|---|---|
| Служебная переписка без персональных данных | Чтение разрешено | Стандартный журнал обращений |
| Переписка с клиентами | Чтение по перечню чатов | Обезличивание до передачи модели |
| Данные документов и реквизиты | Чтение запрещено | Вырезание на входе, эскалация человеку |
| Переписка руководства | Вне контура | Доступ закрыт технически |
Правовая рамка сводится к двум опорам: у компании есть полномочия обрабатывать переписку в отобранных чатах, а объём данных в каждом запросе минимален для задачи. Согласия и положения об обработке персональных данных оформляются с юристом отдельно. Ассистент добавляет технический слой, который обязан уметь доказать, что увидел и что передал, и журнал нужен именно для этого: по записи восстанавливается цепочка «чат — запрос — объём — ответ». Срок хранения журнала и доступ к нему задайте так же, как для других рабочих данных: журнал содержит выдержки из переписки и сам становится объектом защиты.
Отправка с разрешением
Отправка сообщения — единственная операция контура с внешним эффектом, и вся конструкция безопасности сходится здесь в одну точку. Черновик готовит ассистент, текст с получателем показывается сотруднику в карточке подтверждения, кнопкой «отправить» владеет только человек. Автоматической отправки в этом контуре нет по самому его устройству: любой сценарий, где модель пишет в чат сама, переходит в класс чат-ботов с их регламентами и согласиями.
- Сотрудник просит ассистента подготовить ответ по переписке или шаблону.
- Ассистент собирает контекст из разрешённых чатов и формирует черновик с указанием получателя.
- Карточка с текстом приходит сотруднику: прочитал, поправил при желании, нажал «отправить».
- Факт отправки и итоговый текст фиксируются в журнале рядом с исходным запросом.
Кто именно нажимает кнопку, решается заранее: у каждого чата есть владелец, и подтверждает отправку он сам, даже если черновик просил другой сотрудник. Так журнал отвечает на вопрос, кто отправил сообщение клиенту, без споров.
Кто в команде подтверждал бы отправку сообщений?
Границы ассистента
Один служебный чат и один сценарий чтения, например сводка обращений за день, — достаточный старт. Черновики ответов добавляйте с обязательным подтверждением, прогоните их на реальной переписке и лишь затем расширяйте перечень чатов.
Три сигнала говорят, что пора расширять: сотрудники сами просят добавить новые чаты, доля черновиков, уходящих без правок, вышла на устойчивый уровень, журнал за месяц чист от инцидентов. Обратные сигналы тоже показательны: споры о том, кто отвечал в диалоге, жалобы на промахи в адресатах, запросы на автоматическую отправку «как у ботов». Последний случай — повод передать сценарий в класс чат-ботов: варианты и состав работ описаны на странице про чат-ботов для бизнеса.
Ещё одна граница — зависимость от стороннего сервера. Он может перестать обновляться, а Telegram может изменить правила доступа. Заложите замену: описание задач контура и журнал держите независимыми от конкретного сервера, чтобы ассистента можно было подключить к другому серверу без пересборки процесса и без повторного согласования задач с владельцами чатов.