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

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

В Redpanda мы создали именно такого ИИ-ассистента для корпоративного клиента. В Microsoft Teams ассистент считывает IT-формы компании, собирает недостающие данные и отправляет запросы через существующие рабочие процессы ITSM (IT Service Management). Пользовательская интеграция применяет правила рабочих процессов клиента, а существующая ITSM-платформа сохраняет все свои записи, права доступа и согласования.

За первую неделю наш ИИ-ассистент самостоятельно ответил на 36% запросов сотрудников, используя существующие статьи базы знаний. Эти запросы никогда не превращались в тикеты и не требовали участия людей.

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

Почему старый процесс приема заявок оказался неэффективным

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

Автоматизация этой работы требовала большего, чем просто заполнение формы. ITSM-платформа уже определяла формы, допустимые значения, правила маршрутизации и согласования, причем эти правила могли меняться в зависимости от типа запроса и предыдущих ответов. Доступ также был неравномерным. Сотруднику могло быть разрешено создать запрос без возможности прочитать каждое поле, хранящееся в нем, поэтому успешный ответ API не доказывал полноту записи.

Клиент также установил четкие границы для ассистента:

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

Эти требования определили как саму интеграцию, так и средства контроля вокруг нее, как показано в следующих разделах.

Как работает ИИ-ассистент

Ассистент работает в существующей у клиента среде Microsoft Teams. Когда сотрудник отправляет запрос, ассистент сначала определяет, задает ли он вопрос, сообщает об инциденте или заказывает что-то из каталога услуг, так как для каждого направления требуется разная информация и свой способ отправки.

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

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

Поскольку интеграция считывает определения форм при каждом поступлении запроса, ИТ-отдел продолжает обслуживать формы в ITSM-платформе так же, как и раньше. Когда ИТ-отдел изменяет поддерживаемое правило формы, ассистент следует ему без отдельного релиза.

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

Как проверяется каждый запрос

Мы создали ИИ-ассистента с использованием Redpanda Agentic Data Plane — уровня управления и выполнения для ИИ-агентов. Этот уровень располагается между агентами и всеми данными, инструментами, идентификаторами и моделями, к которым они обращаются.

Каждый вызов модели и инструмента от ИИ-ассистента проходит через AI Gateway платформы Redpanda Agentic Data Plane. Вместо того чтобы предоставлять модели открытый доступ к ITSM-платформе, мы создали собственный сервер протокола Model Context Protocol (MCP), который предоставляет доступ только к определенным ИТ-задачам, таким как поиск статьи, чтение формы или создание инцидента. У него нет общего инструмента запросов к таблицам платформы, что ограничивает операции, которые может попытаться выполнить ассистент, теми, которые определяет сервер.

На следующей схеме показан логический путь запроса и распределение зон ответственности:

У каждого шага своя задача. Модель выбирает задачу и предлагает аргументы, а шлюз проверяет, можно ли выполнять вызов. Сервер MCP превращает задачу в проверенный запрос приложения. Затем ITSM-платформа применяет собственные разрешения, логику отправки и рабочие процессы утверждения, оставаясь при этом системой учета.

Как управлять возможностями ИИ-ассистента

Redpanda Agentic Data Plane дает администраторам контроль над тем, кто может использовать ассистента, какие инструменты он может вызывать и какие данные эти вызовы могут отправлять или возвращать.

Примечание. Средства управления Redpanda Agentic Data Plane зависят от конфигурации и версии. В этом разделе описывается то, что поддерживает платформа, и не все элементы управления, описанные здесь, были включены в развертывание у клиента.

Сохранение личности сотрудника при операциях записи

Любое изменение, производимое ассистентом, использует собственную учетную запись сотрудника, поэтому он может делать только то, что этот сотрудник мог бы сделать сам. Redpanda Agentic Data Plane проверяет, может ли вызывающий абонент использовать модель или инструмент, а затем ITSM-платформа определяет, что учетная запись может читать или изменять.

Redpanda Agentic Data Plane выбирает OAuth-подключение сотрудника из хранилища токенов на основе его аутентифицированной личности. Хранилище шифрует токены, изолирует их по арендаторам и пользователям, а также управляет обновлением токенов, поэтому учетным данным не нужно появляться в инструкциях агента или аргументах инструментов.

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

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

Ограничьте набор инструментов для каждого пользователя

Администраторы могут разрешить всем выполнять поиск по базе знаний, одновременно ограничивая инструменты, которые создают или изменяют записи. Redpanda Agentic Data Plane использует политики Cedar, которые проверяют, кто отправляет запрос, какое действие требуется выполнить и на какой ресурс оно влияет. Условия могут использовать членство в группах и поддерживаемые атрибуты ресурсов, поэтому группа поддержки может вызывать выбранные инструменты, не имея возможности изменять их конфигурацию.

Правила Cedar носят явный характер. Если ни одна политика не разрешает запрос, он отклоняется, а совпадающее правило запрета (forbid) имеет приоритет над любым разрешением (permit). В Redpanda Agentic Data Plane правило запрета, вычисление которого завершилось с ошибкой, также приводит к отклонению запроса. Все это происходит до запуска инструмента. Обновления политик распространяются асинхронно, поэтому проверяйте их применение после внесения изменений.

Ознакомьтесь с документацией Redpanda по политикам доступа для получения информации о полной модели политик.

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

Ограничение аргументов инструментов и возвращаемых данных

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

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

См.: документация по политикам данных

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

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

Проверка входных и выходных данных модели

Системы защиты (Guardrails) позволяют администраторам проверять содержимое беседы, а также доступ к инструментам. Redpanda Agentic Data Plane поддерживает защитные ограждения для провайдеров больших языковых моделей (LLM), которые сканируют промпты и ответы на наличие конфиденциальной информации, запрещенных тем и атак на промпты. В зависимости от политики они могут обнаруживать или блокировать соответствующий контент либо редактировать конфиденциальный вывод.

Документированной бэкенд-системой являются Amazon Bedrock Guardrails, даже если модель размещена у другого провайдера. В этом случае шлюз отправляет текст в Bedrock для оценки, поэтому включите его пункт назначения и регион в отчет о проверке обработки данных. Если обязательная проверка защитным ограждением завершается с ошибкой, шлюз отклоняет запрос.

См.: Документация по Guardrails

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

Отслеживание действий и расследование сбоев

Если сотрудник говорит, что запрос пропал, операторам необходимо отследить произошедшее за пределами чата. OpenTelemetry связывает активность агента, вызовы моделей и вызовы инструментов. При включенной записи аудита события безопасности используют стандарт Open Cybersecurity Schema Framework (OCSF) для фиксации субъекта, операции, ресурса и результата. Путь аудита MCP шлюза записывает решения об авторизации и результаты, включая отказы, а настроенные производители событий публикуют их в топиках Redpanda для хранения и анализа.

См.: Документация по наблюдаемости

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

Управление расходами на модели

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

См.: Документация по бюджетам

Создание собственного IT-ассистента

С помощью ассистента сотрудники нашего корпоративного клиента могут находить ответы и подавать IT-запросы, не покидая Teams, при этом IT-отдел по-прежнему контролирует формы, разрешения и согласования.

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

Но сначала самое главное. Чтобы создать собственного агента на базе Redpanda Agentic Data Plane, начните отсюда: