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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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