Мы внедряли ИИ-агентов, а переучиваться пришлось самим: почему одних интеграций недостаточно

Еще вчера мы замирали от восторга, когда ИИ писал за нас письма. Сегодня негодуем: почему он сам не догадался кому их отправить? Не перенес саммари встречи в документы и не обновил задачу в трекере. Пока ты сам в этом разбираешься, приходят итоги следующей встречи, письма и новые таски.

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

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

Что требуется от UC с ИИ

Концепция объединенных корпоративных коммуникаций (UC) была призвана собрать разные каналы связи в одной среде. Нужен чат — разворачиваем мессенджер, почта — ставим почтовый сервер, затем добавляем ВКС, телефонию… Затем собираем все в одном окне, и все довольны. По данным исследования К2Тех и VK Tech ^[1], 56% опрошенных ожидают (участвовало более 800 представителей крупных российских компаний), что в ближайшие три–пять лет на предприятиях появится полноценная экосистема «все в одном», но даже с одним окном на сотруднике все еще остается много работы с контекстом задач по типу: какое решение уже согласовали и где зафиксированы актуальные сроки. 

Есть и другая проблема — растущий информационный поток. С помощью ИИ можно быстрее написать письмо, быстрее подготовить документ или отчет, но разбирать все это потом приходится коллегам. Исследователи BetterUp и Stanford Social Media Lab называют это workslop ^[2]: внешне убедительный ИИ-текст, после которого получателю приходится самому разбираться, что хотел сказать автор, и что с этим делать. Причем даже хорошая, качественная саммаризация, хотя и экономит время, сама по себе не снимает информационную перегрузку. Текст становится короче, а информация в нем упакована плотнее: в небольшой выжимке могут оказаться сразу несколько решений, каждое из которых нужно обдумать и проверить. 

В эксперименте с Microsoft 365 Copilot ^[3], охватившем 7137 сотрудников 66 компаний, пользователи инструмента во второй половине эксперимента тратили на почту примерно на два часа в неделю меньше, но при этом исследователи не обнаружили существенных изменений в количестве или составе выполненных задач. 

Поэтому от действительно полезного ассистента ждешь помощи и с приоритетами: что требует твоего внимания ^[4] сейчас, к какой встрече нужно подготовиться, какие договоренности предстоит выполнить. А для радикального повышения эффективности использования агентов стоит разобраться, какую работу можно вообще не перекладывать на человека, а полностью доверить агентам.

Что уже работает у нас

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

Боты ежедневно разбирают почту и фильтруют задачи. Например, возьмем саммаризацию встреч. Это суперудобная штука, ведь бот не только пересказывает содержание беседы, но и заводит в корпоративной базе знаний отдельную страницу и по шаблону выписывает туда участников, обсуждавшиеся боли ^[5] и то, кто какие тезисы вносил. Ключевые архитектурные решения он выносит отдельно, в так называемые ADR^{[1] [6]}.

Дошло до того, что мне пришлось перестроить собственную речь. На совещаниях я вслух проговариваю: «Здесь пометка для агента», «Это важная мысль, нужно обратить на нее внимание». Кто под кого подстраивается…

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

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

Появился соблазн занять освободившееся время новыми задачами. Исследовательницы Berkeley Haas в ходе восьмимесячного наблюдения в одной технологической компании ^[7] увидели именно это: сотрудники расширяли круг работы и вели больше процессов одновременно. За всеми этими процессами тоже нужно следить, иначе можно весь день переключаться между результатами работы своих помощников.

От итогов встречи к выполненной задаче

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

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

Платформа и интеграции

За этими сценариями стоит работа с разными корпоративными системами. Раньше для создания единой корпоративной инфраструктуры нужно было написать и внедрить массу разных коннекторов. Это привязывало заказчиков к выбранным решениям и вынуждало инженеров изобретать велосипеды, чтобы интегрировать системы разных вендоров между собой. Теперь же у нас есть MCP (Model Context Protocol) и коннекторы на его основе. Он унифицирует подключение инструментов к агентам, но интеграцию по-прежнему нужно отладить.

Кроме самого доступа, нужно разобраться в смысле данных. Выигранная сделка в CRM еще не означает, что проект выполнен, а статус «закрыт» может требовать проверки документов. Эту проблему коллеги подробно разбирали на примере поиска проектного опыта ^[8]. Агенту нужно объяснить связи между записями и то, в каком источнике искать ответ на конкретный вопрос. Наличие коннектора само по себе этого не обеспечивает.

Эти требования приходится учитывать при сборке всей системы. Расскажу, как она устроена у нас. В ее основе находится SamurAI — платформа от AIDA tech для создания и работы с корпоративными ИИ-агентами на базе больших языковых моделей. Она включает в себя более 100 встроенных инструментов для работы с документами, поиска информации и взаимодействия с корпоративными системами. Кроме того, пользователям доступна библиотека из более чем 580 готовых навыков, которые объединяют инструменты в различные конфигурации. Решение позволяет быстро настраивать агентов, централизованно управлять ими, разграничивать права доступа и вести журнал их действий. Для особо важных операций предусмотрено согласование с оператором. При этом платформа поддерживает более 10 LLM-провайдеров, в том числе локальные.

К SamurAI подключена масса прикладных сервисов: ERP, трекеры задач, СЭД, базы знаний, календари и почта. Однако сотрудники работают со всем этим богатством через корпоративный мессенджер. В нашем случае это eXpress. У каждого там есть персональный ассистент, доступный в одном из чатов, который можно настроить под свои потребности ^[9] — написать кастомные навыки и сценарии, которые мы потом масштабируем на всю компанию — от отдела продаж до юридического департамента.

Обязательные шаги для агента

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

Границы самостоятельности

Конечно, степень делегирования необходимо тщательно выбирать и оценивать в зависимости от сценария использования агента. Она определяется прежде всего ценой ошибки ^[10]. Черновик письма можно проверить и исправить до отправки, а вот вернуть деньги после ошибочной транзакции может оказаться гораздо сложнее.

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

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

Готовность рынка

Чтобы все это работало бесшовно и выглядело для сотрудника, как обычный чат, нужно много интеграций. В своих проектах мы пока регулярно упираемся в ограничения отечественных платформ корпоративных коммуникаций. У части вендоров еще нет собственных MCP-коннекторов. Нередко у продукта нет даже внятной и документированной спецификации API. Конечно, мы можем разобраться и написать коннектор сами, но без официальной поддержки такое решение может перестать работать после очередного обновления.

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

У заказчика при этом обычно уже есть почта, мессенджер и ВКС. Поэтому сначала нужно проверить, как развивать существующую среду. При выборе платформы я бы смотрел прежде всего на API и возможности интеграции. Можно ли подключить свою модель, дать ей контекст из корпоративных источников через RAG, развернуть решение локально? И сохранятся ли при этом права доступа и аудит действий? Для коммуникационной части можно рассмотреть три примера:

1. VK WorkSpace, так как у VK Tech есть платформа ИИ-агентов VK AI Space, а в публичных материалах вендора ^[11] описано подключение агентов к WorkSpace через MCP. Это сочетание стоит рассмотреть, если компания планирует использовать агентов в корпоративных коммуникациях. Доступность нужных функций придется проверить для конкретной версии и варианта развертывания.

2. CommuniGate Pro — это давно существующая платформа с публичным и подробно документированным API ^[12], который упрощает разработку и поддержку коннекторов.

3. Вышеупомянутый eXpress, который удобен прежде всего как единый интерфейс для общения сотрудников с ботами и корпоративными приложениями.

Агентный слой подбираем под задачи и инфраструктуру заказчика. Выше я показал, как это устроено на примере SamurAI. По нашему опыту ^[13], готовых сквозных решений, подходящих под процессы конкретной компании, пока немного.

После выбора коммуникационной платформы нужно разобраться, какие корпоративные системы предстоит подключить, что у них с API, какие коннекторы придется написать и кто будет поддерживать их после обновлений. Отдельный вопрос в том, где запускать модели и хватит ли для них вычислительных ресурсов. Мы можем собрать и эту часть: развернуть оборудование и программную платформу для работы с моделями.

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

Дефицит смыслов, а не технологий

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

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

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

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

1. ADR (Architecture Decision Record) — запись архитектурного решения: его контекста, выбранного варианта и обоснования. ↩ ^[14]