Закрытый контур ИИ: что это и зачем компании собственная нейросеть

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

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

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

Локальный ИИ выполняет вычисления на выбранном оборудовании компании. On-premise обычно описывает размещение в её инфраструктуре. Private AI может обозначать разные варианты выделенного или контролируемого доступа. Эти термины полезны для первого разговора, но недостаточны для проверки решения.

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

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

Второй — local-first с управляемыми исключениями. Типовые операции выполняются внутри, а внешняя модель используется только для разрешённых категорий данных и задач. Маршрут должен быть виден и контролироваться правилами, а не включаться незаметно при первом сложном вопросе.

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

Представим, что договор загружается в локальный чат. Языковая модель работает в офисе, но распознавание скана отправлено во внешний OCR-сервис. Или текст остался внутри, а эмбеддинги для поиска рассчитаны через облачный API. В обоих случаях расположение LLM не описывает полный маршрут данных.

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

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

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

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

Дообучение — отдельный инструмент для определённых задач. Оно не заменяет актуальную базу документов, права доступа и обновление сведений. Для первого проекта полезнее проверить качество поиска и стандартной модели на реальных сценариях, чем сразу обещать «обучить свой ИИ на всём бизнесе».

Даже программное обеспечение для запуска моделей может сочетать локальные и облачные функции. Например, FAQ Ollama отдельно описывает локальную работу, облачные возможности и сетевые настройки. Поэтому проверять нужно фактический режим выбранного стека и модели, а не только название программы. Ollama · FAQ ↗

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

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

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

NIST SP 800-207 описывает принцип отсутствия неявного доверия только на основании сетевого или физического расположения. Для локального ИИ это означает, что размещение внутри компании не подменяет аутентификацию и разрешения на ресурсы. NIST · SP 800-207 Zero Trust Architecture ↗

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

Вредная инструкция может оказаться внутри разрешённого документа или письма. Это риск prompt injection: содержимое, которое система должна анализировать как данные, пытается изменить её поведение. OWASP рассматривает такие атаки и рекомендует сочетать разделение инструкций и данных с ограничением инструментов и другими мерами защиты. OWASP · Prompt Injection Prevention ↗

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

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

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

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

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

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

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

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

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

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

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

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

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