ИИ-ассистент первой линии IT-поддержки — jbln К содержимому
jbln. Заявка
← Все кейсы

Компания с внутренней IT-поддержкой сотрудников

ИИ-ассистент первой линии IT-поддержки

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

Рутинные обращения закрываются без инженера: от диагностики VPN до смены пароля

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

Задача

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

Цель проекта — снять с инженера этот рутинный слой. Не «чат-бот с готовыми ответами», а ассистент, который понимает суть обращения, сам собирает факты из инфраструктуры и либо решает вопрос, либо доводит его до состояния, когда человеку остаётся один клик.

Что получилось

Ассистент работает в двух каналах (Telegram и электронная почта) на едином «мозге» и умеет:

  • вести свободный диалог на IT-темы — модель отвечает по существу, с учётом того, кто именно спрашивает (его логин, рабочий компьютер, статус VPN, срок действия пароля подставляются в контекст автоматически);
  • разбирать скриншоты ошибок — фото уходит в OCR, распознанный текст анализирует модель и объясняет, что пошло не так;
  • диагностировать удалённый доступ — по одной кнопке бот проверяет реальные факты: есть ли у сотрудника право на VPN, поднята ли сессия на роутере, включён ли его рабочий компьютер, и выдаёт понятный вердикт;
  • самостоятельно менять пароль в домене — первая и главная операция записи: сотрудник в пару тапов получает новый рабочий пароль прямо в чат;
  • отдавать персональные инструкции — по настройке почты, VPN и удалёнки, с подстановкой личных данных пользователя и отправкой готового письма на его рабочий ящик.

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

Роль ИИ: «факты — код, слова — модель»

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

Модель отвечает за язык: понять вопрос, поддержать диалог, объяснить ошибку, обратиться к человеку по имени, «перевести» технический результат в понятную речь. Но модель не принимает решений о фактах и не выполняет действий сама. Всё, что критично — статус учётной записи, наличие VPN-сессии, доступность компьютера, право на смену пароля — считает код, обращаясь к инфраструктуре напрямую. Модель получает уже готовый вывод и только озвучивает его.

Этот принцип решает главную проблему LLM в проде — галлюцинации. Несколько примеров, где он сработал:

  • Сверка учётных данных на скриншоте. Код вынимает адрес из распознанного текста регулярным выражением и посимвольно сравнивает с эталоном из каталога. Модель не замечает разницы в одну букву в логине — код замечает всегда.
  • Диагностика сети. Отдельные пинги по имени и по IP дают детерминированный диагноз («компьютер выключен» / «проблема с разрешением имён» / «дело не в компьютере»). Модель не гадает — она получает готовую классификацию.
  • Пошаговые инструкции. По настройкам с точными командами и ключами модель намеренно не пересказывает инструкцию по памяти (это привело бы к ошибкам в параметрах), а направляет пользователя к выверенному тексту из базы знаний.

Языковая модель здесь — не автопилот, а интерфейс: она делает систему человечной, а надёжность обеспечивает код. Function calling в модели есть, но на текущем этапе гибрид оказался предсказуемее и безопаснее.

Мультимодальность и контекст

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

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

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

Автоматизация: от ручных операций к самообслуживанию

Акцент проекта — не только на «поговорить», но на том, чтобы закрывать задачи без человека.

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

Диагностика по кнопке. Сценарий «помоги подключиться из дома» раньше означал серию проверок вручную. Теперь один вызов собирает всё: право на VPN → живая сессия на роутере → доступность рабочего ПК — и выдаёт готовый вердикт.

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

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

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

Всё существенное пишется в журнал аудита (кто, когда, что, с каким результатом) — он копится с первого дня и служит основой для будущей статистики и сводок.

Архитектура: разделение как граница безопасности

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

Пользователь ─(Telegram / почта)─► узел-БОТ ◄──API──► узел-ИИ (облачная LLM)
                                       ▲
                          исходящий канал (узел-ТП сам ходит наружу)
                                       │
                                    узел-ТП (офис, только чтение)
                                       │
             ┌──────────────┬──────────┴───────┬────────────────┐
          Каталог AD      Роутер          Рабочие ПК         Почтовый
        (статус, пароль) (VPN, логи)    (пинг имя/IP)         сервер
  • Узел-БОТ смотрит в интернет и не хранит ничего чувствительного — ни паролей домена, ни базы, ни привязок. Его задача — принять сообщение, положить задание в очередь, показать ответ. Даже при полной компрометации этого узла злоумышленник не получает доступа к домену.
  • Узел-ТП стоит внутри офиса и содержит всю «начинку»: доменные проверки (только чтение), авторизацию, отправку почты, локальную базу с привязками. Это единственный узел с доступом во внутреннюю сеть.
  • Узел-ИИ — облачная языковая модель, внешний «интеллект».

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

Транспорт устроен нетривиально. Прямой VPN-туннель между узлами оказался нежизнеспособен — популярные протоколы туннелирования в среде эксплуатации блокируются на уровне сигнатуры. Решение — очередь заданий поверх обычного HTTPS, где инициатор всегда внутренний узел: он сам ходит наружу (long-poll), забирает задание, выполняет локально, возвращает результат. Порты внутрь офиса не открываются вообще. Такой канал не отличим от обычного веб-трафика и не требует никаких исключений на периметре.

Безопасность в деталях

  • Всё общение с инфраструктурой — только на чтение. Единственная операция записи (смена пароля) выделена, обложена повторными проверками и делегирована минимально необходимой учётке.
  • Функции-инструменты принимают идентичность, а не цель. Бот не умеет пинговать произвольный адрес или выполнять произвольную команду — цель проверки он вычисляет сам из данных авторизованного пользователя. Внешний ввод в запросы к каталогу экранируется.
  • Принцип «только про себя». После привязки бот отвечает на запросы только о самом пользователе: его логин берётся из проверенной связки, а не из текста сообщения.
  • Авторизация по коду на корпоративную почту доказывает, что за аккаунтом в мессенджере стоит владелец рабочего ящика. Предусмотрен и крайний случай: если у сотрудника истёк пароль и почта недоступна, личность подтверждается голосом по телефону, а одноразовый код с увеличенным сроком жизни уходит администратору.
  • Секреты доступа в сеть не попадают в облако. Общие ключи из инструкций показываются пользователю в чат, но в базу знаний для модели уходит версия без ключей — облачная LLM их не видит.

Результат

Проект собран и проверен на боевых данных от края до края: вход из мессенджера → авторизация → данные из каталога → диагностика VPN → диалог с ИИ → разбор скриншотов → самостоятельная смена пароля. Система работает автономно, как набор служб с автозапуском, ведёт журнал и сама рапортует администратору.

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

Стек

СлойТехнологии
«Мозг»Облачная LLM (генеративная модель + vision/OCR), контекст пользователя, база знаний (RAG)
БэкендPython, FastAPI + Uvicorn, очередь заданий поверх HTTPS
ИнфраструктураActive Directory (LDAP/LDAPS), роутер по REST API, почтовый сервер, DNS
ХранениеSQLite (привязки, коды, журнал аудита, инструкции)
ЭксплуатацияLinux, systemd, nginx, автопродление TLS-сертификатов, секреты в защищённых env-файлах
КаналыTelegram, электронная почта

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

Услуги в этом кейсе

Похожая задача?

Оставить заявку