Искусственный интеллект постепенно переходит из области экспериментов в корпоративные и государственные информационные системы. Организации создают ассистентов для работы с внутренними знаниями, автоматизируют обработку документов, используют языковые модели при разработке программного обеспечения и строят агентные сценарии, способные выполнять последовательности действий. В инфраструктуре с высокими требованиями к безопасности для этого недостаточно подключить внешнюю модель через API. Необходимо контролировать размещение данных, исполнение запросов, полномочия ИИ-агентов, доступ к внутренним сервисам и регистрацию действий системы.
На этом фоне формируется отдельный класс решений - корпоративные ИИ-платформы и профильные фреймворки, рассчитанные на эксплуатацию внутри управляемого контура. Один из российских примеров - экосистема "Астра ИИ". В её состав заявлены "Астра ИИ [Хаб]", "Астра ИИ [Платформа]", "Астра ИИ [Код]", "Астра ИИ [Цифровой офис]" и "Астра ИИ [Агент Икс]". Последний разработчик определяет как профильный фреймворк для создания ИИ-решений и безопасную среду исполнения пайплайнов для платформы.
Зачем ИИ-системе нужен профильный фреймворк
В обычной разработке фреймворк задаёт набор компонентов и правил, на которых строится приложение. Для ИИ-систем его роль шире: требуется организовать взаимодействие с моделями, данными, инструментами, политиками доступа и средствами наблюдаемости. Особенно это важно для агентных систем, где модель может не только формировать текст, но и обращаться к внутренним источникам и сервисам.
Профильный фреймворк в такой архитектуре помогает стандартизировать ИИ-пайплайны. Пайплайн можно представить как последовательность операций: принять запрос, проверить права, получить релевантные данные, сформировать контекст, обратиться к модели, при необходимости вызвать разрешённый инструмент, проверить результат и вернуть его пользователю. Если каждая команда реализует эти шаги самостоятельно, появляются разные правила безопасности, неодинаковое журналирование и сложности сопровождения.
Для защищённой инфраструктуры ценность фреймворка определяется возможностью применять единые правила исполнения: разграничивать полномочия, контролировать компоненты, вести аудит и переносить решения между средами.
Роль "Астра ИИ [Агент Икс]"
Публичное описание "Астра ИИ [Агент Икс]" пока не раскрывает детальную внутреннюю архитектуру, перечень API и состав библиотек. Подтверждённая роль компонента сформулирована как профильный фреймворк для разработки ИИ-решений и безопасная среда исполнения пайплайнов для "Астра ИИ [Платформы]". Поэтому корректнее рассматривать его как технологический слой исполнения, а не как самостоятельное пользовательское приложение.
"Астра ИИ [Платформа]" описывается как low-code-система для создания ИИ-решений: в ней можно визуально представлять и дорабатывать агентов на уровне принципиальных схем. "Астра ИИ [Код]" ориентирован на инженерную работу с агентами на уровне кода. Таким образом, в экосистеме разделяются визуальное проектирование, программная разработка и исполнение сценариев.
Такое разделение принципиально для безопасности. Визуальный конструктор сам по себе не делает сценарий защищённым: реальный уровень контроля зависит от того, где исполняется пайплайн, какие ресурсы доступны его шагам, какие сетевые соединения разрешены и как фиксируются действия.
Экосистема вместо отдельного чат-бота
Корпоративный ИИ редко ограничивается одним чат-интерфейсом. Нужны модели, вычислительные ресурсы, среда разработки, пользовательские приложения и средства администрирования. В "Астра ИИ" эти функции распределены между компонентами. "Астра ИИ [Хаб]" заявлен как инференс-платформа для хранения моделей, управления ролями и распределения ресурсов. "Астра ИИ [Цифровой офис]" представляет пользовательский уровень - корпоративное приложение для повседневных задач и работы с агентами платформы.
Такая схема отделяет модель от конкретного прикладного сценария. Одна инфраструктура инференса может использоваться для разных задач: поиска по внутренним знаниям, помощи разработчику, классификации документов или агентной автоматизации. Это создаёт основу для централизованного управления ресурсами и правилами допуска моделей в эксплуатацию.
Закрытый контур и контроль данных
Одно из центральных требований для ИИ в чувствительной инфраструктуре - локализация обработки. "Группа Астра" указывает, что экосистема может работать внутри инфраструктуры заказчика без выхода в интернет, а большие языковые модели - разворачиваться на оборудовании организации. Также заявлены варианты поставки на серверах заказчика, в составе программно-аппаратного комплекса и через Astra Cloud.
Закрытый контур уменьшает зависимость от внешних облачных API, но сам по себе не обеспечивает безопасность. Внутри периметра всё равно требуется контролировать учётные записи, привилегии сервисов, журналы событий, сетевые взаимодействия, доступ к хранилищам и секретам. Отдельными рисками остаются промпт-инъекции, недостоверные ответы моделей, загрязнение базы знаний и чрезмерные полномочия агентов.
Поэтому ключевой вопрос для профильного фреймворка - не только где работает модель, но и что разрешено делать пайплайну. Чем больше автономности получает агент, тем важнее принцип минимально необходимых прав и контролируемый доступ к инструментам.
Безопасность агентных действий
Пример того, как этот принцип реализуется в прикладном сценарии, даёт "Астра ИИ [Код]". По описанию разработчика, клиентская часть размещается на рабочем месте инженера, а модели и контур безопасности могут находиться в закрытой сети или защищённом облаке. Агент способен анализировать код, формировать план, писать и изменять файлы, запускать тесты и взаимодействовать с файловой системой. Для снижения риска опасных действий заявлены согласование плана, журналирование, права только на чтение для дочерних агентов по умолчанию и блокировка ряда потенциально разрушительных команд.
Общий принцип здесь состоит в том, что модель не должна автоматически получать полномочия пользователя или администратора. Между решением модели и действием в инфраструктуре нужен контролируемый исполнительный слой. Именно здесь применяются ограничения операций, сетевого доступа, проверка параметров вызова и требования к ручному подтверждению.
Та же логика относится к бизнес-агентам. Если система работает с документами, заявками или внутренними базами, право на чтение, изменение или передачу данных должно определяться политиками информационной системы, а не возможностями языковой модели.
RAG и корпоративные базы знаний
Один из типовых сценариев корпоративного ИИ - RAG, то есть генерация ответа с использованием найденных фрагментов внутренней базы знаний. "Астра ИИ" приводит интеллектуального ассистента инженера с корпоративной базой знаний как один из примеров применения.
С точки зрения безопасности RAG требует контроля не только модели, но и источников. В индекс могут попасть устаревшие документы, сведения с разными уровнями доступа или некорректный контент. Поэтому промышленная система должна учитывать происхождение документа, его актуальность, владельца и права конкретного пользователя.
Фреймворк в такой схеме помогает унифицировать разрешённые источники, поиск с учётом полномочий и регистрацию использованных документов. Это не гарантирует истинность ответа, но делает процесс его формирования наблюдаемым.
Регуляторные требования
Для государственных информационных систем существенное значение имеет приказ ФСТЭК России № 117 от 11 апреля 2025 года, вступивший в силу 1 марта 2026 года. Документ устанавливает требования к защите информации, а отдельные положения относятся к применению искусственного интеллекта: предусматривают меры против несанкционированного доступа и воздействия, ограничения при работе с информацией ограниченного доступа и контроль использования ИИ.
Нормативная база продолжает развиваться. В августе 2026 года подготовлен проект изменений к приказу № 117, в котором предлагается конкретизировать защиту моделей и ИИ-агентов, сегментирование, многофакторную аутентификацию привилегированного доступа, фильтрацию запросов и ответов, квотирование и управление правами агентов. Поскольку это проект, его положения нельзя представлять как уже действующие нормы.
На странице "Астра ИИ" разработчик заявляет соответствие решения приказу № 117, рекомендациям по проектированию ИИ-систем и требованиям, связанным с КИИ, а также указывает на сертификацию ключевых компонентов средств защиты информации. Для конкретного внедрения такие заявления не заменяют обследование системы, моделирование угроз и проверку фактического состава поставки. Итоговое соответствие зависит также от архитектуры, настроек, интеграций и организационных мер заказчика.
Связь ИИ с безопасным жизненным циклом разработки
ИИ-решения остаются программными системами, поэтому им необходимы контроль версий, тестирование, управление зависимостями, CI/CD, разделение сред и аудит изменений. Дополнительно появляются специфические артефакты: версии моделей, промптов, баз знаний, индексов и конфигураций агентных инструментов.
В экосистеме "Группы Астра" эту задачу можно рассматривать вместе с Astra Developer Platform. ADP позиционируется как платформа полного цикла SDLC и безопасной разработки с порталом самообслуживания, репозиториями, CI/CD и базовыми практиками SAST, DAST, SCA/OSA и политиками Kyverno. В её архитектуре также указан слой разработки с LLM и агентами.
Для ИИ-команд это важно потому, что изменение модели, системного промпта или подключённого инструмента способно повлиять на поведение сервиса не меньше, чем изменение кода. Значит, такие изменения также должны проходить разработку, тестирование, проверку безопасности, согласование и контролируемую публикацию.
Что проверять перед промышленным внедрением
При выборе ИИ-фреймворка для защищённого контура следует оценивать не только демонстрационные возможности, но и эксплуатационные свойства. Сначала необходимо определить модель угроз и категории данных. Затем - проверить, какие компоненты способны работать без внешнего доступа, где хранятся модели, запросы и журналы, какие соединения нужны для обновлений и как управляются секреты.
Отдельно оценивается управление агентами: разграничение доступа к инструментам, подтверждение критических операций, сетевые и файловые ограничения, журналирование многошаговых действий. Для RAG важны наследование прав на документы, обновление индекса, удаление данных и возможность определить, какие источники использовались при ответе.
Не менее важны нагрузочные испытания. Локальные модели требуют значительных вычислительных ресурсов, а итоговая производительность зависит от размера модели и контекста, аппаратной конфигурации, механизма инференса, числа одновременных пользователей и сложности пайплайнов. Результаты пилотного стенда поэтому нельзя автоматически переносить на промышленную среду.
Поэтапное внедрение
Практический проект целесообразно начинать с ограниченного сценария и измеримого результата, а не с выбора самой большой модели. Это может быть поиск по инженерной документации, подготовка черновиков по внутренней базе знаний или помощь в анализе кода. Для каждого сценария заранее определяются границы автоматизации и операции, требующие участия человека.
Далее готовятся данные и инфраструктура: источники классифицируются, настраиваются роли, выделяются вычислительные ресурсы и проектируется сетевая схема. Пилотный пайплайн тестируется не только на качестве ответа, но и на негативных сценариях - попытках получить запрещённые сведения, выполнить недопустимое действие, обойти инструкции или использовать неактуальные данные.
После пилота необходим эксплуатационный контур: мониторинг, аудит, управление версиями и процесс реагирования на инциденты. Для генеративного ИИ отдельно определяется, как регистрировать ошибочные ответы, кто отвечает за актуальность базы знаний и когда агент обязан передать задачу человеку.
Ограничения и критерии зрелости
Локальная модель, low-code-конструктор и специализированный фреймворк не устраняют фундаментальные ограничения генеративного ИИ. Модель может формировать недостоверные ответы, неправильно интерпретировать инструкции и непредсказуемо реагировать на нетипичный ввод. Поэтому результат модели следует рассматривать как недоверенный до прохождения предусмотренных проверок.
Зрелая корпоративная ИИ-среда отличается тем, что организация знает, какие модели используются, к каким данным они имеют доступ, кто публикует агентов, какие действия разрешены каждому агенту, как откатывается версия и где хранится история выполнения. Фреймворк полезен тогда, когда превращает эти требования в повторяемые технические правила, а не остаётся средством быстрого прототипирования.
Для "Астра ИИ [Агент Икс]" публично заявленная роль безопасной среды исполнения пайплайнов указывает на такой архитектурный подход. Но оценивать применимость продукта в конкретной организации следует по технической документации, результатам испытаний в целевой инфраструктуре, интеграциям и требованиям информационной безопасности.
Заключение
Профильный фреймворк для разработки ИИ-решений в защищённой инфраструктуре - это не просто средство обращения к языковой модели. Его задача - сделать создание и исполнение ИИ-сценариев управляемым: связать модели, данные и инструменты, установить единые правила доступа, обеспечить наблюдаемость и встроить ИИ-сервисы в существующий жизненный цикл разработки и эксплуатации.
Экосистема "Астра ИИ" разделяет эти функции между несколькими уровнями. "Хаб" связан с моделями и ресурсами, "Платформа" - с low-code-созданием агентных решений, "Код" - с инженерной разработкой, "Цифровой офис" - с пользовательским доступом, а "Агент Икс" заявлен как профильный фреймворк и среда исполнения пайплайнов. Такая архитектура соответствует общему переходу от единичных ИИ-ассистентов к централизованным средам, где безопасность и управление жизненным циклом становятся частью платформы.
Для инфраструктуры с высокими требованиями к защите главным критерием остаётся не сам факт локального развёртывания ИИ, а способность контролировать весь путь данных и действий - от пользовательского запроса до обращения к модели, инструменту и конечной информационной системе. Именно здесь профильный фреймворк может выполнять роль базового технологического слоя для промышленного применения искусственного интеллекта.
