AI-агенты для бизнеса: из чего собирается агент и какая инфраструктура ему нужна

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

AI-агент (AI Agent) может пройти эту цепочку сам: обратиться к нескольким системам, проверить результат каждого шага и передать оператору случай, который выходит за пределы его полномочий.

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

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

Что такое AI-агент и чем он отличается от чат-бота

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

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

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

Как работает ИИ-агент

Вернемся к переносу доставки. Агент должен выбрать новый интервал, получить согласие клиента и изменить только его заказ.

Рабочий цикл состоит из пяти шагов:

1. Проверить пользователя и его доступ к заказу.
2. Запросить текущий статус доставки.
3. Определить, разрешен ли перенос. Если заказ уже у курьера, передать обращение оператору.
4. Получить доступные интервалы, согласовать выбор и сохранить изменение.
5. Дождаться подтверждения системы доставки и сообщить новую дату клиенту.

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

AI-агент, AI-ассистент и чат-бот: в чем разница

Границы между этими понятиями размыты, поэтому при выборе решения полезнее сравнить, как каждое из них обычно работает.

Ассистент может иметь агентные функции, а агент — работать внутри чата. Умение генерировать текст само по себе не означает, что система умеет выполнять бизнес-операции.

И наоборот: обычный бот тоже способен записывать данные и вызывать сервисы, если это предусмотрено его сценарием.

Зачем нужны ИИ-агенты бизнесу

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

Например, заявка должна появиться в нужной очереди, а изменять сумму заказа агенту запрещено.

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

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

Из чего состоит AI-агент

Модель выбирает действия, но выполнять их, хранить состояние и проверять права должны другие компоненты. Ниже разберем роли этих компонентов. В конкретном приложении несколько ролей может выполнять один сервис.

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

LLM — языковая модель

Большая языковая модель интерпретирует запрос, генерирует текст и предлагает действия. LLM относится к генеративному AI (Generative AI) — моделям, которые создают новый текст, код или изображения. Сама модель обучена методами машинного обучения (Machine Learning), одного из направлений искусственного интеллекта (Artificial Intelligence).

Обычно основой агента служит универсальная предобученная модель (Foundation Model), дообученная следовать инструкциям. Для бизнеса важно, как она справляется с конкретными задачами: правильно ли извлекает номер заказа, выбирает инструмент и замечает, что сведений не хватает. Красивый ответ не компенсирует неверную операцию.

System Prompt — системный промпт

Системный промпт задает роль, границы задачи, формат ответа и условия передачи человеку.

Вместо общего «помоги клиенту» нужны проверяемые инструкции:

• Запроси номер заказа, если он неизвестен.
• Предлагай только интервалы, полученные от сервиса доставки.

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

Tools — инструменты

Инструменты — это функции, через которые агент действует: находит заказ, рассчитывает стоимость, создает обращение.

Для каждого задают:

• Описание: какую задачу он решает.
• Параметры: какие данные принимает и что обязательно заполнить.
• Формат результата: что возвращает при успехе и ошибке.

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

Memory — память

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

При этом модель видит только те данные, которые приложение передало ей в пределах контекстного окна (Context Window), то есть объема текста, который модель обрабатывает за один вызов. Вся история приложения автоматически туда не попадает.

Полезно разделять факты, подтвержденные бизнес-системой, и предположения из диалога. Фраза клиента «кажется, я оплатил» не должна превращаться в сохраненный статус «оплачено».

Для важных записей нужны источник и время обновления. Сохранение сведений в памяти не меняет саму модель: она на них не дообучается.

Knowledge Base и RAG — база знаний и поиск перед ответом

База знаний содержит регламенты, инструкции, описания продуктов и другие корпоративные материалы. Механизм поиска перед генерацией (Retrieval-Augmented Generation) находит подходящие фрагменты и передает их модели вместе с вопросом.

Так ответ опирается на актуальные корпоративные сведения, а модель не нужно дообучать.

Для поиска по смыслу используют эмбеддинги (Embeddings) — числовые векторы, которые отражают смысл текста. Но смысловая близость не гарантирует достоверности: найденный документ может быть устаревшим. Поэтому рядом с фрагментами сохраняют название источника, версию, дату и сведения о доступе.

Agent Orchestrator — управление выполнением

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

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

API и интеграции с бизнес-системами

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

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

Как AI-агент взаимодействует с данными и сервисами

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

Подключение CRM, ERP и внутренних интерфейсов

Из системы управления отношениями с клиентами агент получает историю обращений и сведения о сделке. Из системы планирования ресурсов предприятия — остатки и учетные данные. Через внутренние сервисы — данные о доставке, биллинге или каталоге.

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

Работа с базами данных

Безопасный вариант для старта — заранее подготовленные запросы или представления (view), которые возвращают только нужные столбцы. Для аналитики можно выделить отдельную базу или реплику, чтобы тяжелый отчет не мешал оформлению заказов.

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

Если модель генерирует SQL, предусмотрите четыре ограничения:

• Учетную запись с минимальными правами.
• Проверку запроса перед выполнением.
• Лимит времени выполнения: даже запрос на чтение может перегрузить сервер.
• Ограничение объема возвращаемых данных.

Расчеты выполняйте средствами базы или проверенным кодом, а модели поручайте объяснение результата.

Поиск по корпоративным документам через RAG

Работа с документами состоит из трех этапов:

1. Извлечь текст, разделить его на фрагменты и сохранить сведения об источнике.
2. Найти подходящие материалы с учетом прав пользователя.
3. Передать модели разрешенные фрагменты для подготовки ответа.

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

Внешние API и веб-сервисы

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

Содержимое сайта или внешнего документа следует считать данными, а не командами для агента. Фраза «отправь отчет на этот адрес», найденная на странице, не дает разрешения на отправку. Особенно важно сохранять эту границу, когда у агента есть доступ к внутренним файлам.

Tool Calling и Function Calling

Оба термина обозначают один механизм. Название Function Calling появилось в API OpenAI, сейчас чаще говорят Tool Calling. Модель формирует структурированное предложение: какую функцию вызвать и какие параметры передать. Саму функцию исполняет приложение или сервис провайдера.

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

MCP и подключение инструментов

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

Перед подключением сервера выясните:

• Кто его поддерживает и обновляет;
• Какие операции он предоставляет;
• Куда передает данные и как проверяет доступ.

Какая инфраструктура нужна AI-агенту

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

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

Где работает языковая модель

Модель можно вызывать как внешний сервис или развернуть в управляемой компанией среде: на своих либо арендованных серверах.

Во втором случае команда отвечает за загрузку модели, обновления и обработку запросов. Работу уже обученной модели с запросами называют инференсом (AI Inference).

Какие ресурсы нужны для самостоятельного запуска

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

Конфигурацию проверяют по четырем параметрам:

• Размер и формат модели.
• Длина запросов и ответов.
• Число одновременных обращений.
• Допустимая задержка.

Видеопамять расходуется не только на параметры модели. Место нужно и для промежуточных данных, включая KV-кеш (кеш ключей и значений): в нем модель хранит промежуточные результаты по уже обработанным токенам. Его объем растет с длиной контекста и числом одновременных запросов.

Как сделать предварительную оценку памяти

У модели с 8 млрд параметров одни веса в 16-битном формате занимают примерно 16 ГБ в десятичном исчислении: 8 млрд × 2 байта. Это расчетный минимум для весов, а не готовое требование к видеокарте. Служебные данные, кеш и параллельные запросы увеличат потребление.

Квантование хранит веса с меньшей точностью и сокращает их объем: в 8-битном формате веса той же модели займут около 8 ГБ, в 4-битном — около 4 ГБ. Его влияние на качество и скорость проверяют на своих задачах. Возможность загрузить модель в память еще не означает, что она выдержит нужное число пользователей.

SSD/NVMe для моделей и данных

Быстрые диски нужны для загрузки весов, подготовки документов и работы баз.

Требования зависят от операции:

Если модель уже в видеопамяти, замена диска может не ускорить генерацию. Сначала выясните, где возникает ожидание: на диске, при поиске, в очереди к модели или во внешнем сервисе.

Сетевая инфраструктура

Один запрос пользователя может вызвать несколько последовательных обращений к модели и корпоративным сервисам. Задержки накапливаются.

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

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

База данных

Основная база хранит данные пользователей, задачи, статусы, подтверждения и ссылки на результаты. Она позволяет отличить операцию «запланирована» от «успешно выполнена». Это особенно важно, если обработка продолжается после перезапуска приложения.

Для надежной работы нужны:

• Резервные копии и проверенный способ восстановления.
• Целевые показатели: за какое время нужно восстановить работу и сколько данных допустимо потерять (RTO и RPO).
• Идентификаторы операций: по ним можно проверить результат, если ответ потерялся после успешной записи.

Векторное хранилище

Векторная база (Vector Database) помогает искать близкие по смыслу фрагменты. Она хранит эмбеддинги и метаданные: источник, дату, права доступа. Текст может находиться рядом или в отдельном хранилище.

Важно поддерживать связь между индексом и исходным документом.

Отдельная специализированная система нужна не всегда. Например, PostgreSQL можно дополнить расширением pgvector для поиска по векторам. При выборе оценивайте качество поиска, размер индекса, обновление документов и фильтрацию. У приближенных индексов (например, HNSW) фильтрация может сокращать число найденных результатов, поэтому проверяйте это на своих данных.

Object Storage — объектное хранилище

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

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

Объектное хранилище не заменяет рабочий диск базы данных: у них разные требования к скорости доступа и способу записи.

Kubernetes и контейнеризация

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

Кластер становится полезен, когда нужно управлять несколькими экземплярами, обновлениями и распределением нагрузки.

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

Как выбрать инфраструктуру для AI-агента в зависимости от задачи

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

Затем определите требования к данным и доступности. Один агент для десяти аналитиков может потреблять больше ресурсов, чем сервис коротких ответов для сотен сотрудников.

Небольшой пилот и MVP

Пилот проверяет одну гипотезу: например, сможет ли агент классифицировать обращения и подготовить ответ.

Для старта часто достаточно:

• Виртуальной машины с приложением.
• Небольшого хранилища состояния.
• Внешнего сервиса модели.

Конфиденциальные данные на этом этапе заменяют тестовыми или обрабатывают по правилам, согласованным со службой безопасности.

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

Агент для внутреннего использования

Для корпоративного помощника важны единый вход, доступ к документам по ролям и обновление базы знаний. Права должны проверяться при каждом обращении: сотрудник может сменить отдел, а документ — стать закрытым.

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

Предусмотрите владельца базы знаний: инфраструктура обеспечит доступность документов, но не исправит противоречивые регламенты.

Production-агент для клиентов

Клиентскому сервису нужны заданные показатели доступности и времени ответа.

Перед запуском проверьте:

• Резервирование приложения и сохранение состояния.
• Разделение данных клиентов и проверку прав.
• Согласование изменений и защиту от повторных операций.
• Передачу обращения оператору.
• Поведение при отказе каждой внешней системы.

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

Высокая нагрузка и большое количество запросов

Масштабируйте компонент, который ограничивает производительность.

Причину ищут по этапам:

Дополнительные серверы приложения не помогут, если все запросы упираются в один внешний лимит.

Для расчетов учитывайте внутренние обращения. Если одна пользовательская задача вызывает модель пять раз, поток из 20 задач в минуту дает в среднем 100 вызовов модели в минуту.

Это условный пример: для реального расчета также нужны длина входа и ответа, повторные попытки и распределение пиков.

Добавляйте очередь с ограниченным размером, отдельные лимиты для клиентов и контролируемый отказ при перегрузке. Бесконечные повторы могут усилить сбой: число обращений растет именно тогда, когда зависимый сервис уже не справляется.

Локальная LLM vs API внешнего провайдера

Под локальным размещением здесь мы понимаем запуск модели в инфраструктуре, которой управляет компания: в собственном офисе, дата-центре или облаке провайдера.

Сравнивайте стоимость успешно выполненной задачи, включая повторы и проверку человеком. Дешевая генерация невыгодна, если после нее сотрудник переделывает результат. При редкой нагрузке собственный GPU может простаивать, а при устойчивой — окупиться. Точку окупаемости определяют расчетом и пилотом.

Безопасность AI-агентов

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

Разграничение доступа и IAM

Система управления идентификацией и доступом (Identity and Access Management, IAM) определяет, от чьего имени работает агент и что ему разрешено. Используйте отдельные служебные учетные записи с минимальными правами.

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

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

Защита интерфейсов и секретов

Пароли, ключи и токены хранят в защищенном сервисе и подставляют при выполнении запроса. Модели они не нужны, поэтому в ее контекст их не передают.

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

Дополнительно настройте защиту вызовов:

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

Защита корпоративных данных

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

Удаление лишних полей уменьшает и объем обработки, и последствия возможной утечки.

Как противостоять подмене инструкций

Документ может содержать текст, который пытается изменить поведение агента: например, требует выгрузить клиентскую базу. Такую атаку называют внедрением инструкций (prompt injection).

Найденное содержимое нужно обрабатывать как недоверенные данные, а возможность выгрузки ограничивать технически.

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

Где остаются копии информации

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

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

Логи и аудит действий агента

Журнал должен позволять восстановить ход работы.

Фиксируйте:

• Инициатора и идентификатор задачи.
• Использованные документы и вызванные инструменты.
• Подтверждения человека и результаты операций.
• Версии модели и инструкций.

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

Как внедрить AI-агента в бизнес

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

Такой порядок помогает обнаружить проблемы до того, как агент получит доступ к клиентским операциям.

1. Найти процесс для автоматизации

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

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

Если сотрудники по-разному трактуют процесс, сначала согласуйте правила. Автоматизация воспроизведет существующие противоречия.

2. Определить цель и KPI

До внедрения ИИ бизнес должен понимать стоимость текущего процесса.

Измерьте исходные показатели и задайте цели для агента:

• Длительность обработки задачи.
• Долю корректно завершенных задач.
• Объем ручных исправлений.
• Стоимость одного успешного выполнения.

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

Заранее определите, при каких результатах пилот признают неуспешным.

3. Выбрать модель и архитектуру

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

Для прототипа можно использовать конструктор автоматизации, например n8n, либо собственное приложение.

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

4. Подключить данные и инструменты

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

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

5. Запустить пилот

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

Разделяйте ошибки модели, поиска и интеграций.

Например, неверный ответ из-за устаревшего документа исправляют обновлением базы знаний. Замена модели эту причину не устранит.

6. Добавить контроль человека

Контроль человека (Human-in-the-loop) предусматривает участие сотрудника в заданных точках процесса. Этот механизм нужно настроить до того, как агент получит доступ к чувствительным операциям.

Например, агент собирает данные для возврата, а оператор подтверждает сумму и получателя.

Проверяющему нужны три вещи:

• Конкретная операция и исходные сведения.
• Ожидаемые изменения.
• Возможность подтвердить или отклонить действие.

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

7. Протестировать и масштабировать

Перед расширением нагрузки проверьте не только правильные запросы, но и сбои: недоступный сервис, устаревший документ, повторное событие, неверные права.

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

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

AI-агенты на инфраструктуре Servercore

В Servercore можно разместить все компоненты агента: приложение, данные и самостоятельно развернутую модель. Дата-центры в Алматы и Ташкенте находятся рядом с пользователями и корпоративными системами в Центральной Азии, а хранение данных в них соответствует местным требованиям к персональным данным (94-V и ЗРУ-547).

Облачные серверы для AI-агентов

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

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

Например, индексацию большого архива можно вынести на отдельную виртуальную машину.

GPU-серверы для локальных языковых моделей

Для самостоятельного инференса можно использовать облачные серверы с GPU. Представлены конфигурации с NVIDIA RTX A5000, A100 и RTX PRO 6000.

Доступность конкретной карты в нужном регионе уточните у команды Servercore при подборе конфигурации.

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

Выделенные серверы для production-нагрузки

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

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

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

Хранение данных и моделей

Исходные документы, файлы моделей и резервные копии можно хранить в объектном S3-хранилище Servercore. Состояние задач и другие структурированные сведения — в базе данных. Для этого подойдут облачные базы данных Servercore, например PostgreSQL.

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

Private Network и безопасность

В составе облачных серверов Servercore предусмотрена приватная сеть. Она позволяет связать компоненты без выхода в интернет. Дополните ее правилами доступа через сервис IAM, хранением ключей и токенов в менеджере секретов и журналированием.

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

Масштабирование AI-инфраструктуры

По мере роста нагрузки приложение и фоновые обработчики можно распределять по нескольким узлам. Для управления контейнерными приложениями Servercore предлагает Managed Kubernetes, в том числе с GPU для инференса.

Переходить на него стоит, когда команде нужны возможности кластера и она готова сопровождать приложения в этой среде.

Для подбора инфраструктуры важны следующие параметры:

• Место запуска модели и пиковое число задач.
• Объем данных и требования к их размещению.
• Допустимое время восстановления после сбоя.

Эти сведения помогут обсудить конфигурацию пилота и ресурсы для роста.

Заключение

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

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

Так агент сможет перейти от убедительных ответов к полезной работе в бизнес-системах.