ИИ-агенты · в вашей системе · данные остаются у вас
ИИ-агенты работаютв вашей системе.Самостоятельно и вместе с вашей командой.
Каждый агент работает только на своём участке. Агент по возвратам не может менять цены, а агент поддержки — договоры с партнёрами. Агенты выполняют процессы в фоне, по расписанию или при наступлении событий. Когда кому-то из команды нужен ответ, агент находит и собирает данные. Сотрудники тратят время на решения, а не на переходы между экранами.
Мы внедряем агентов поэтапно, на платформе, которой можно доверить работу с системой вашего бизнеса.
Только свой участок
Агент получает доступ к конкретным действиям и данным. Всё остальное для него недоступно.
Внедрение под контролем
Пока ИИ не доказал правильность своих решений в вашем процессе, человек видит каждое из них до выполнения. Ошибочное решение не попадает в систему.
Гарантии обеспечивает платформа
Каждое изменение проверяется до отправки и записывается в журнал вместе с прежними значениями, чтобы ошибочную правку можно было откатить.
Задачи агентов
Работают в фоне и отвечают, когда нужно быстро разобраться.
Два режима на одной платформе, с одинаковыми гарантиями. Агенты выполняют процессы по расписанию и при наступлении событий. А любой сотрудник может попросить агента найти и собрать данные из системы, электронной почты и обращений клиентов. Вместо фильтров, списков и двенадцати экранов — ответ, на основе которого можно принять решение. Команда продолжает работать в привычных инструментах.
В фоне
Агенты выполняют процессы сами
Входящие документы
Претензии, жалобы и запросы на возврат, которые приходят по электронной почте. Агент читает письма и вложения, обновляет записи и запрашивает у отправителя недостающие документы.
Обращения клиентов
На типовые вопросы агент отвечает по вашей базе знаний и шаблонам ответов. Вторая модель независимо оценивает каждый ответ.
Работа с партнёрами
Поставщики, подрядчики и посредники. По их письмам и уведомлениям агент обновляет условия, прайс-листы, данные о доступности и контакты. Каждое изменение фиксируется в журнале.
По запросу
Агент находит, человек решает
Поиск без ручного перебора
«Какие партнёры в этой стране изменили условия за прошлый месяц?» Агент просматривает списки и записи и собирает ответ. Вместо получаса работы с фильтрами — минута, а сотрудник сосредотачивается на выводах.
Вся ситуация в одном ответе
Заказ, обращение клиента, переписка с партнёром и настройки, которые на них повлияли, — в одном ответе со ссылками на записи в вашей системе.
От поиска к исправлению
По найденным данным агент может сразу подготовить сценарий изменений в пределах своего участка. Платформа проверит его и выполнит.
Участок агента
Каждый агент работает только на своём участке.
Агент для одного вида задач не может менять данные другого. Его участок задаёт допуск — перечень разрешённых действий и типов данных. Отдельный API для агентов не нужен. Агент работает через тот же API, что и экраны вашей системы.
Данные за пределами участка недоступны.
Сценарий, который затрагивает данные вне допуска, не запустится. Проверка допуска и запуск выполняются одним шагом, поэтому изменить допуск между ними невозможно.
Свой аккаунт, если он вам нужен.
Агенту можно создать отдельную учётную запись в вашей системе, как новому сотруднику. Тогда система тоже проверяет его права и указывает агента как автора действий в своём журнале.
Видно, кто что сделал.
Журнал платформы показывает, кто и когда выдал агенту допуск и какие сценарии агент выполнил с этим допуском.
Допуск отзывается сразу.
Допуск меняется или отзывается одной кнопкой. При следующем запуске уже действуют новые правила. Отозванный допуск восстановить нельзя.
| Агент | Запросы на возврат | Обращения клиентов | Условия партнёров | Цены | Платежи |
|---|---|---|---|---|---|
| Агент по возвратам | Разрешено | только ответы | Нет доступа | Нет доступа | Нет доступа |
| Агент поддержки | Нет доступа | Разрешено | Нет доступа | Нет доступа | Нет доступа |
| Агент по партнёрам | Нет доступа | Нет доступа | Разрешено | только скидки | Нет доступа |
Пример матрицы допусков. Вы составляете её вместе с ответственными за каждый процесс и меняете без программирования.
Почему пилоты буксуют
Пилоты буксуют на том, что нужно построить вокруг модели.
Модель справляется с задачей достаточно хорошо. Пока агент только читает и советует, всё работает. Но когда ему нужно самостоятельно менять данные в системе, на которой работает ваш бизнес, возникают вопросы, на которые демонстрация не отвечает.
Что агенту разрешено?
Доступ к API обычно означает доступ ко всему API, а общая служебная учётная запись видит все данные сразу.
Кто отвечает за изменение?
Если все агенты работают под одним аккаунтом, журнал вашей системы не покажет, кто что изменил.
Что будет, если связь оборвётся на полпути?
Половина изменений применена, половина — нет, а повторная попытка создаёт дубликаты.
Как исправить ошибку?
Если прежние значения никто не сохранил, откатываться не к чему.
Куда уходят данные?
Персональные данные клиентов в чате стороннего ИИ-сервиса — вопрос для ваших юристов.
Как не допустить ошибочных решений ИИ?
Пока агент не проверен на реальных случаях, доверять ему рабочую систему нельзя. А бесконечно утверждать каждый шаг слишком дорого.
Как это работает
Каждый из этих рисков устраняем в коде и базе данных.
Эти решения позволяют допустить агентов к рабочей системе. Они действуют независимо от того, договорились ли люди быть осторожными.
Агент делает то, что ему не разрешено
Каталог операций вместо открытого доступа к API.
Агент выбирает действие из заранее описанного списка и заполняет параметры. Если действия нет в каталоге, агент не может его выполнить.
Для каждой операции заданы поля, допустимые значения и правила. Неизвестную операцию нельзя ни проверить, ни откатить, поэтому в каталог её не включаем.
Агент выходит за пределы своего участка
Допуск к действиям и данным.
У каждого агента свой перечень разрешённых действий. Агент для одного вида задач не может менять данные другого.
Платформа проверяет допуск в момент запуска. Если у агента есть свой аккаунт, ваша система тоже проверяет его права.
Ошибка, которую обнаружит только система
Проверка до отправки.
Сценарий проверяется ещё при подготовке: форматы, справочники, ссылки на существующие записи, дубликаты, правила взаимосвязи полей. Изменение, которое ничего не меняет, не создаётся.
Отказ посреди массового изменения обходится дороже, чем дополнительное чтение данных при подготовке.
Сбой посреди массового изменения
Выполнение продолжается после сбоев.
Сценарий из сотен операций может прервать перезапуск сервера, обновление вашей системы или обрыв связи. После этого выполнение продолжается с того же места.
Каждый шаг сохраняется вместе с записью в журнале. Шаг с неясным исходом проверяется по данным системы перед повтором.
Повторная попытка создаёт дубликаты
Ничего не записывается дважды.
Если система не ответила, платформа сначала снова читает данные и повторяет только то, что не дошло. Письмо клиенту с неизвестным результатом отправки повторно не отправляется. Его передают на проверку человеку.
У создания, изменения и удаления свои правила. Если нет однозначного ответа, выполнение шага останавливается без попыток угадать исход.
Ошибку уже не исправить
Журнал и откат правок.
Для каждого шага платформа сохраняет запрос, ответ системы и прежние значения, чтобы ошибочную правку можно было откатить. Из журнала строится новый сценарий отката, который проходит те же проверки. Отмену заказа у партнёра или отправку письма клиенту откатить нельзя. Для таких действий предусмотрен этап проверки решений.
В журнале видно, какая операция изменила конкретную запись, какой агент её выполнил и при каком запуске.
ИИ принимает неверное решение
Проверка перед запуском на этапе внедрения.
Пока процесс не доказал надёжность, человек видит каждое решение агента в виде «было → станет» и может отклонить весь сценарий. Необратимые действия, например отмену заказа у партнёра, подтверждают для каждой записи отдельно.
Выполняется именно проверенная версия. Если агент изменил её или запись в системе изменилась, проверка начинается заново.
ИИ уверенно пишет клиенту бессмыслицу
Вторая модель проверяет первую.
Другая модель оценивает ответы клиентам по заданным критериям, показывает степень своей уверенности и отмечает фрагменты, которые стоит перечитать.
Агент никогда не оценивает сам себя. Оценки накапливаются по каждому процессу и служат одним из оснований для перехода к самостоятельной работе агента.
Письмо злоумышленника управляет агентом
Письма — данные, а не инструкции.
Агент читает подключённые почтовые ящики, но ничто в письме не считается командой. Подозрительные действия, например массовую выгрузку справочников, агент помечает для аудита.
Фиксируется каждый вызов агента и каждый запрос к системе. Отметки о подозрительных действиях получают ответственные сотрудники.
Внедрение
Сначала ИИ доказывает надёжность, затем работает сам.
Главный риск при внедрении ИИ — серия ошибочных решений. Она опаснее любого технического сбоя. Поэтому новый процесс начинается с проверки: человек видит каждое решение до выполнения, а ошибочное не попадает в систему. Проверка — этап внедрения. Он заканчивается, когда решения агента проходят без исправлений. После этого агент работает самостоятельно.
- Этап 1
Поиск и анализ
Агент находит и собирает для команды данные из системы, электронной почты и обращений клиентов. Сам ничего не меняет. Приносит пользу с первого дня, без риска.
- Этап 2
Проверка решений
Агент готовит изменения. Человек видит «было → станет» и запускает сценарий или отклоняет его. В систему попадают только проверенные решения.
- Этап 3
Самостоятельно на своём участке
Там, где решения агента подтверждены практикой, он сам выполняет процесс в пределах допуска. Допуск отзывается одной кнопкой.
- Цель
Агенты работают в фоне, команда — вместе с ними
Процессы, доказавшие свою надёжность, переводятся на автоматический запуск. Агенты выполняют их по расписанию и при наступлении событий, каждый на своём участке. Сотрудники с помощью агента разбираются в данных и начинают новую работу. Новые процессы по-прежнему начинаются с проверки.
Журнал, откат, проверки до отправки и аудит одинаковы на всех этапах. Меняется то, кто запускает сценарий и в каких пределах.
Пример · Европейский онлайн-агрегатор аренды автомобилей
Платформа агентов для операционной команды
Наш клиент, агрегатор аренды автомобилей, работает в большой системе собственной разработки: партнёры с их условиями и прайс-листами, правила продаж, возвраты, претензии и обращения клиентов. Операционная команда часами вносила однотипные правки на десятках экранов и разбирала электронную почту.
Цель — агенты, которые сами выполняют операционные процессы, и быстрый доступ команды к данным системы через агента. Для этого мы построили MCP-платформу, через которую агенты работают с системой. Её веб-портал нужен на этапе внедрения, чтобы видеть каждое предложенное агентом изменение, а также для настройки доступа и интеграций и для аналитики. Агент находит и собирает данные из системы, электронной почты и обращений клиентов, избавляя сотрудников от поиска по экранам. Если нужны изменения, агент готовит сценарий, а платформа проверяет и выполняет его в пределах допуска агента.
С чем работают агенты
- Условия и прайс-листы партнёров
- Скидки и лимиты продаж
- Каталог и справочные данные
- Возвраты
- Претензии
- Обращения клиентов
- Письма клиентам
- Операции с заказами
- Тексты и переводы
- ≈90экранов бизнес-системы, доступных агентам через единый каталог операций
- ≈50инструментов агента: бизнес-система, обращения клиентов, электронная почта, документы, навыки
- 2 месяцаот первого коммита до ежедневной работы команды с платформой; за это время — 219 релизов
- Сотниопераций за один запуск, с возобновлением после сбоя
Сейчас команда работает через агента и проверяет каждое решение до выполнения. Фоновая работа агентов по расписанию — следующий этап.
Одно изменение от начала до конца
- 01 · Агент
Читает
Записи в системе, письма, обращения клиентов, вложения. Каждый вызов попадает в журнал аудита.
- 02 · Агент
Готовит сценарий
Только операции из каталога и только в пределах своего допуска.
- 03 · Платформа
Проверяет
До отправки находит всё, что система отклонила бы: форматы, справочники, дубликаты, ссылки.
- 04 · Человек при внедрении
Проверяет решение
«Было → станет» понятным языком. Ошибочное решение отклоняется до выполнения.
- 05 · Платформа
Выполняет
Шаг за шагом, записывая в журнал значения до каждого изменения.
Отличия
Чем это отличается от подключения чат-бота к API.
Как работает
Чат-бот отвечает по документации
Агенты выполняют процессы в фоне и находят актуальные данные в системе, чтобы команда могла принимать решения
Что разрешено агенту
Весь API под общей служебной учётной записью
Только свой участок: допуск к конкретным действиям и данным, при необходимости — свой аккаунт
Роль человека
На каждом шаге навсегда или вообще без участия
Проверка каждого решения, пока ИИ не доказал надёжность в процессе, затем процесс выполняется сам
Сбой посреди операции
Человек вручную выясняет, что успело примениться
Выполнение продолжается с места остановки, а шаг с неясным исходом проверяется по данным системы
Ошибка
Находят в журналах и исправляют вручную
Прежние значения сохранены в журнале, правка откатывается новым сценарием
Ответы клиентам
Модель проверяет себя сама или не проверяет никто
Независимая оценка второй моделью
Аудит
Журналы модели, если они есть
Каждый вызов агента, каждый запрос к системе, какой агент что выполнил и с каким допуском
Знания о процессе
В промпте одного человека
В навыках с версиями и вариантами, общих для команды и агентов
Данные и GDPR
Чувствительные данные остаются в вашей инфраструктуре.
Платформа развёртывается в вашей инфраструктуре: Kubernetes, Azure, AWS или на ваших серверах. Данные о запусках, журналы и данные аудита хранятся у вас, вне чата стороннего ИИ-сервиса. Доступ к ним определяется вашими правилами.
- Модель выбирается под задачу и юрисдикцию. В описанном проекте агент работает на Claude, а независимую проверку выполняет другая модель. Модель можно заменить без перестройки платформы.
- К вашей бизнес-системе может обращаться только один сервис. Её адрес и ключи никогда не попадают ни к агенту, ни в браузер.
- Портал доступен только из вашей внутренней сети. Вход — через учётные записи бизнес-системы, разрешены только домены компании.
- Программные зависимости устанавливаются не раньше чем через неделю после публикации версии — это защищает от скомпрометированных пакетов.
- Мы документируем права доступа и сроки хранения каждого вида данных, при необходимости готовим техническую часть оценки воздействия на защиту данных.
Запускаете модель на Azure? Место обработки промптов и ответов зависит от типа развёртывания больше, чем от региона ресурса. Типы развёртывания и GDPR в Azure
С чего начать
Один процесс с замерами до и после. Самостоятельная работа — после подтверждения надёжности на практике.
- 01
Выбираем процесс
Вместе с людьми, которые делают эту работу, считаем затраченные часы и определяем участок будущего агента: какие действия и данные ему понадобятся.
1 неделя
- 02
Поиск и анализ через агента
Подключаем систему, электронную почту и обращения клиентов. Команда сразу начинает поручать агенту поиск и подготовку сводок, а мы видим реальные вопросы.
1–2 недели
- 03
Проверка решений ИИ
Создаём каталог операций для процесса, проверки, журнал и откат. Человек видит каждое решение агента до выполнения и отклоняет ошибочные до того, как они попадут в систему.
3–4 недели
- 04
Самостоятельная работа
Сравниваем затраченные часы, ошибки и время ответа, считаем решения агента, прошедшие без исправлений. Когда процесс доказал надёжность, переводим его на автоматический запуск, и агент выполняет его сам. Если это не окупается, мы так и говорим.
Дальше — по одному процессу
Вопросы
Что у нас обычно спрашивают
Нужно ли строить отдельный API для агентов?
Нет. Агент работает через тот же API, что и экраны вашей системы. При необходимости он получает свой аккаунт, как сотрудник, и система проверяет его права. Если в API не хватает возможностей для процесса, мы укажем, каких методов недостаёт, и сможем их разработать.
Как вы не даёте агенту выйти за свой участок?
Платформа выдаёт каждому агенту допуск — перечень действий и типов данных. Агент для одного вида задач не может менять данные другого: такой сценарий не запустится. Допуск проверяется и при подготовке изменений, и в момент запуска. Если у агента есть свой аккаунт, ваша система тоже проверяет его права.
Что делает фоновый агент, если не может принять решение?
Останавливается и передаёт задачу человеку вместе с уже собранными данными. То же происходит, когда исход операции неизвестен: если система не подтвердила отправку письма клиенту, письмо не отправляется повторно, а передаётся человеку на проверку. Если ошибочное действие нельзя отменить, платформа не гадает.
Почему не дать агенту делать всё с самого начала?
Никто заранее не знает, насколько хорошо ИИ будет принимать решения именно в вашем процессе. Этап проверки снимает этот риск: человек видит каждое решение и отклоняет ошибочное до выполнения. Когда практика показывает, что решения агента проходят без исправлений, проверка заканчивается.
Почему не сделать это в Copilot Studio или n8n?
Для простых цепочек вроде «прочитать письмо, создать задачу» они подходят, и мы их предложим. Когда агенты в фоне массово меняют денежные суммы, цены и заказы, нужны каталог операций, допуски, продолжение после сбоя, проверка шагов с неясным исходом и откат. В таких конструкторах этого нет.
Следующий шаг
Расскажите, какой процесс отнимает больше всего времени.
За 30 минут мы расскажем, какие части процесса агент может выполнять сам, где поможет команде быстрее находить ответы, каким будет его участок и во сколько обойдётся первый этап. Покажем работу платформы на реальном примере.
Опишите один процесс
Удобнее обсудить?
Запишитесь на 30-минутный разговор с нашим генеральным директором. Расскажите о процессе, мы зададим вопросы.
Записаться на 30 минутЭлектронная почта
sergey@binitex.comRiga · Daugavpils, Latvia