Локальный ИИ-агент: модель, инструменты и данные внутри периметра

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

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

Что делает ИИ-агента локальным: модель, инструменты, память и журналы

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

На странице Yandex AI Studio on-premises, прочитанной 19 октября 2026 года, вендор описывает три варианта размещения: на вашей собственной инфраструктуре Kubernetes, на Yandex Cloud Stackland и гибридный формат поставки. В гибридном формате в вашей инфраструктуре стоят компоненты, чувствительные с точки зрения безопасности. Доступ к моделям Alice AI LLM, Qwen или DeepSeek и к веб-поиску при этом идёт «в облаке с использованием частных эндпоинтов без выхода в интернет». Чувствительные компоненты размещены у вас, а большие модели и поиск остаются у вендора.

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

Пять точек, через которые данные агента выходят из контура

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

1. Модель. Модель генерирует ответ на вашем сервере, в облаке вендора через частное подключение или через публичный API. Спросите, на каком сервере и в чьей юрисдикции модель обрабатывает запросы вашего сценария.
2. Инструменты и MCP-серверы. По облачной документации MCP Hub в Yandex AI Studio на 19 октября 2026 года, к агенту подключают внешний MCP-сервер или создают собственный, например на основе функции Yandex Cloud Functions. Серверы там бывают приватными и публичными, и к публичному серверу, по той же документации, могут обращаться любые агенты без аутентификации. Инструмент, который вызывает внешний API, передаёт туда данные даже при локальной модели, поэтому спросите, куда отправляет запросы каждый инструмент и кто его подключил.
3. Веб-поиск. В гибридном формате Yandex AI Studio поиск выполняется в облаке вендора, как и запросы к большим моделям. В поисковый запрос попадает формулировка задачи, а в ней бывают название клиента, продукта или детали ещё не объявленного запуска. Вопрос к вендору здесь такой: где выполняется поиск и сохраняются ли поисковые запросы.
4. Память между сессиями. MWS AI 17 сентября 2026 года сообщила, что агенты на её платформе запоминают факты о собеседнике между сессиями. Такая память становится ещё одним хранилищем данных клиента, и правила хранения и удаления для неё нужны те же, что для документов. Спросите, где лежит память, как она разделена между клиентами и кто может её очистить.
5. Песочница для кода и журналы. По тому же сообщению MWS AI, агенты исполняют написанный ими код в изолированной песочнице, которая по данным вендора разворачивается вместе с платформой внутри контура заказчика. В документации Stackland 26.3, проверенной 19 октября 2026 года, на каждую активную сессию Code Interpreter заложено примерно 2,1 vCPU и 4,1 ГБ оперативной памяти. Журналы хранят промпты и ответы модели, то есть те же данные клиента, поэтому для них нужно выяснить, где они лежат, как долго хранятся и у кого есть к ним доступ.

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

Форматы поставки в контур у российских платформ

Четыре российские платформы из материала о выборе вендора описывают поставку агентов в контур заказчика с разной подробностью. В таблице для каждой платформы приведены формат поставки и место работы модели со ссылкой на источник и дату; сами платформы мы не оцениваем. Сравнение платформ как вендоров приведено в материале «Какой ИИ-агент лучше для агентства: чек-лист выбора вендора».

Цену поставки в контур не публикует ни один из четырёх вендоров. На странице Stackland сказано, что платформа лицензируется по количеству ядер CPU, а для AI Studio нужна отдельная лицензия, но сумм там нет. Цена поэтому остаётся запросом к вендору, а метод расчёта затрат на агента описан в материале «Сколько стоит ИИ-агент».

Модель в контуре: сервер, открытые веса и лицензии

Официальные цифры оборудования для агентной платформы в контуре нашлись у одного вендора. В документации Stackland 26.3, проверенной 19 октября 2026 года, минимальный кластер для AI Studio рассчитан на одновременную работу модели YandexGPT 5 Lite, модели эмбеддингов Embeddings и модели проверки безопасности запросов Ethics. В нём 3 узла управления, 3 рабочих узла без GPU, один узел с 1 × NVIDIA A100 80 GB и один узел с 2 × NVIDIA H100 80 GB. В сумме это 136 vCPU, 648 ГБ оперативной памяти и около 4,1 ТБ дискового пространства.

Ресурсы каждой включённой модели добавляются к ресурсам самой платформы, которой без моделей по той же документации нужно 24 vCPU, 54 ГБ оперативной памяти и 93 ГБ диска. YandexGPT 5 Lite и Alice 30B требуют по 1 × H100 80 GB, а YandexGPT 5.1 Pro и Alice Flash по 2 × H100 80 GB. Для моделей с двумя GPU оба ускорителя по документации должны стоять на одном узле. В карточках открытых моделей, которые мы прочитали, требований к оборудованию нет. Выбор облачных серверов с GPU для модели разобран в материале «Self-hosted AI на Yandex Cloud: архитектура для агентств».

Если модель для агента разворачивается из открытых весов, условия лицензии стоит прочитать до запуска на материалах клиента. В таблице собраны данные из карточек моделей на Hugging Face на 19 октября 2026 года, без оценки качества моделей.

В лицензии YandexGPT 5 Lite порог считается по выходным токенам за месяц. Агентство, у которого один агент обслуживает нескольких клиентов, складывает их объёмы, поэтому месячный расход токенов стоит отслеживать с первого месяца работы. Остальные параметры модели собраны в справочнике «YandexGPT 5 и 5.1: контекстное окно, лимиты, цены и версии».

ФСТЭК № 117 и 152-ФЗ: что из этого касается агентства

Приказ ФСТЭК России № 117 от 11 апреля 2025 года адресован государственному сектору, и частное агентство в нём не названо. По п. 1 Требований они применяются к государственным информационным системам и к иным информационным системам государственных органов, государственных унитарных предприятий и государственных учреждений. Приказ зарегистрирован Минюстом 16 июня 2025 года под № 82619 и вступил в силу 1 марта 2026 года. Регистрация и изменения, внесённые приказом № 137 от 8 мая 2026 года, указаны по КонсультантПлюс; цитаты ниже приведены по тексту Требований на сайте ФСТЭК в первоначальной редакции, и перед проектом их стоит сверить с действующим текстом.

Агентство встречается с этим приказом как подрядчик государственного заказчика. П. 2 Требований касается случая, когда из государственной системы передаётся информация ограниченного доступа. В этом случае «информационная система, в которую передается информация ограниченного доступа, должна соответствовать требованиям о защите информации…».

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

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

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

Для персональных данных клиентов основная рамка задаётся 152-ФЗ. По ч. 3 ст. 12 уведомление Роскомнадзора о намерении осуществлять трансграничную передачу оператор направляет до её начала, и значение имеет страна, куда попадают данные, а не происхождение модели. Ч. 5 ст. 18 о размещении баз данных в России действует в новой редакции с 1 июля 2025 года. По разъяснению Stonebridge Legal, эта норма распространяется и на лицо, обрабатывающее данные по поручению оператора. Таблицы решений по типам данных собраны в материале «152-ФЗ и AI: что можно и что нельзя выгружать».

243-ФЗ вступил в силу 1 сентября 2026 года, а его нормы о суверенных и национальных моделях применяются с 1 марта 2027 года. Подготовка ответов и хранение данных в центрах обработки данных на территории России, которыми владеют российские юридические лица, входит в число условий такого статуса. Штрафы по ст. 13.11 КоАП перечислены в материале «Какой ИИ-агент лучше для агентства: чек-лист выбора вендора». Применение этих норм к конкретному договору оценивает юрист.

Риски агента с инструментами по классификации OWASP

Локальная модель не устраняет рисков, которые OWASP описывает для приложений на LLM и для агентов. В Top 10 for LLM Applications редакции 2026 года, опубликованной в августе 2026 года, первые четыре места занимают Prompt Injection, Sensitive Information Disclosure, Excessive Agency и Supply Chain. Для агента с инструментами важнее всего три группы рисков.

1. Непрямая инъекция промпта, LLM01. Инструкции злоумышленника приходят не от пользователя, а из внешнего источника, например с веб-страницы или из файла, который агент читает по ходу задачи. В описании риска OWASP разбирает сценарий, в котором данные выводятся наружу через адрес изображения. Среди мер защиты названы минимальные права, одобрение человеком действий с высоким риском и отделение недоверенного содержимого от остального.
2. Excessive Agency, LLM03:2026 (LLM06 в редакции 2025 года). OWASP называет три причины этого риска: «excessive functionality; excessive permissions; excessive autonomy», то есть лишние функции, лишние права и лишнюю самостоятельность агента. Меры защиты включают сокращение расширений до необходимых, отказ от открытых расширений вроде команд оболочки или загрузки произвольного адреса, минимальные права, одобрение пользователем и ограничение частоты действий.
3. Риски из отдельного списка для агентов. Top 10 for Agentic Applications 2026 объявлен 9 декабря 2025 года. Первую половину списка составляют ASI01 Agent Goal Hijack, ASI02 Tool Misuse & Exploitation, ASI03 Identity & Privilege Abuse, ASI04 Agentic Supply Chain Vulnerabilities и ASI05 Unexpected Code Execution. Вторую составляют ASI06 Memory & Context Poisoning, ASI07 Insecure Inter-Agent Communication, ASI08 Cascading Failures, ASI09 Human-Agent Trust Exploitation и ASI10 Rogue Agents.

Агентству с агентом в контуре ближе всего три пункта списка для агентов: злоупотребление инструментами (ASI02), уязвимости цепочки поставок агента, к которой относятся и подключаемые к нему сторонние компоненты (ASI04), и отравление памяти и контекста (ASI06). Ни одна из перечисленных мер защиты не зависит от того, где работает модель. Агент внутри периметра, у которого есть доступ к командам оболочки и непроверенный MCP-сервер, остаётся уязвим для тех же сценариев, что и облачный.

Где проходит периметр в наших системах

В одной из наших систем маршрут запроса зависит от того, насколько чувствительна задача. Документы и векторный индекс хранятся в Yandex Cloud в регионе ru-central1, генерацию выполняет YandexGPT или Qwen, который мы разворачиваем сами, а n8n управляет сценарием в том же периметре. Так эта схема описана в материале «Self-hosted AI на Yandex Cloud: архитектура для агентств» от 12 мая 2026 года. Та же схема приведена в материале «Можно ли использовать ChatGPT для бизнеса в России» от 12 июня 2026 года.

Периметр этой схемы маршрутизации составляют управляемые сервисы Yandex Cloud в регионе ru-central1 и компоненты, которые мы разворачиваем сами. Агента на собственных серверах клиента или в закрытом контуре клиента мы не запускали.

На случай отказа модели в нашей системе работы с документами предусмотрено отдельное переключение. Основной моделью там служит YandexGPT, резервной служит DeepSeek, и переход между ними выполняется автоматически. О каждой смене состояния команда узнаёт из уведомления, а частота таких уведомлений ограничена; так переключение описано в материале «Какой ИИ-агент лучше для агентства: чек-лист выбора вендора» от 19 октября 2026 года.

Что оставить внутри контура: сводная таблица

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

Границы. Локальный агент сам по себе не гарантирует, что данные останутся внутри периметра: инструменты, MCP-серверы и веб-поиск проверяются по одному. Какие вызовы инструментов агент выполняет без одобрения, решает человек, а для журналов и памяти нужны правила хранения. Названные платформы и модели мы не тестировали, не сравнивали и не ранжировали, и их описания приведены по материалам вендоров с датами. Раздел о ФСТЭК, 152-ФЗ и 243-ФЗ описывает круг применения норм и не заменяет юридическую консультацию. Описанная выше схема маршрутизации работает в Yandex Cloud в регионе ru-central1 и на компонентах, которые мы развернули сами, а агентов на серверах клиентов мы не запускали.

Раскрытие интереса. Мы собираем и продаём агентов, которые работают в Yandex Cloud, поэтому нам выгодно, чтобы облачный периметр в российской юрисдикции выглядел достаточным. Нейтральной стороной в этом вопросе нас считать нельзя. Если клиент требует закрытый контур, решение остаётся за ним, а вопросы из сводной таблицы стоит задать и нам.

Что читать дальше

Как устроен стек в российской юрисдикции на уровне всей инфраструктуры, разобрано в материале «Суверенный AI-стек: как выстроить работу с ИИ в российской юрисдикции». Правовая рамка для данных клиентов собрана в материале «152-ФЗ и AI: что можно и что нельзя выгружать». Коммерческий обзор суверенной архитектуры — варианты развёртывания и сравнение уровней — на странице «Суверенный AI для российских предприятий».

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