Между публичным чатом и собственным сервером есть несколько вариантов
Выбор обычно описывают как противостояние облака и on-prem. На практике корпоративная архитектура содержит больше вариантов, и границы между ними не всегда очевидны.
Публичный ИИ-сервис — это готовое приложение, которым сотрудники пользуются через браузер. Компания почти не управляет его архитектурой, поэтому такой вариант подходит для открытых данных и некритичных задач, если использование сервиса разрешено внутренними правилами.
Модель через корпоративный облачный API работает иначе. Сотрудник не общается с публичным интерфейсом напрямую: запросы проходят через приложение компании, где можно управлять доступом, обезличивать данные, ограничивать сценарии и сохранять аудит действий.
Частное облако или изолированный сетевой контур добавляет собственные правила сети, закрытые точки подключения, корпоративную идентификацию и контролируемые хранилища. Вычисления остаются в облачной инфраструктуре, но путь данных и права доступа становятся значительно более управляемыми.
On-prem означает, что модель, хранилища и прикладные компоненты работают на инфраструктуре компании или в выделенном центре обработки данных. Такой вариант даёт больше технического контроля, но одновременно передаёт компании ответственность за оборудование, обновления, резервирование и эксплуатацию.
Наконец, существует гибридная архитектура, в которой чувствительные данные, поиск и бизнес-правила остаются внутри компании, а внешняя модель получает только разрешённый контекст. Для многих корпоративных процессов именно этот вариант оказывается практичнее попытки поместить всё решение в одну среду.
Что на самом деле означает закрытый контур
Фраза «нам нужен ИИ в закрытом контуре» звучит понятно, пока не начинаешь задавать уточняющие вопросы. Для одной компании это запрет передавать документы во внешние сервисы, для другой — физически изолированная инфраструктура без доступа в интернет, а для третьей — облачная среда с частной сетью и корпоративным управлением доступом.
Поэтому закрытый контур нужно описывать не названием, а конкретными ограничениями. Важно определить, где хранятся исходные данные, кто имеет к ним доступ, сохраняются ли запросы и ответы, какие журналы ведутся и через какие сетевые узлы проходит информация.
Отдельно нужно проверить резервные копии, технические логи, системы мониторинга и инструменты поддержки. Основная база может находиться внутри компании, но фрагменты документов иногда появляются в журнале ошибок, системе наблюдаемости или обращении к внешней технической поддержке.
On-prem не устраняет эти риски автоматически. Локальное решение также использует операционную систему, библиотеки, драйверы, средства обновления и учётные записи администраторов, а каждый из этих компонентов требует отдельного контроля.
Корпоративные облачные сервисы, в свою очередь, отличаются от публичных пользовательских приложений. Например, Microsoft указывает, что данные, запросы и ответы клиентов Azure Direct Models не используются для обучения моделей без разрешения клиента (Microsoft Learn).
AWS сообщает, что Amazon Bedrock изолирует содержимое клиента и не использует его для улучшения базовых моделей (AWS Prescriptive Guidance). Google Cloud также заявляет, что данные Vertex AI не используются для обучения без предварительного разрешения, но отдельно описывает сценарии и условия временного хранения данных (Google Cloud).
Эти заявления не заменяют изучения договора, настроек конкретного сервиса и требований компании. Они показывают другое: слово «облако» само по себе ещё ничего не говорит о реальном режиме обработки данных.
Пять вопросов перед выбором архитектуры
Выбирать локальный или облачный ИИ удобнее не по общему уровню тревоги, а по конкретным характеристикам процесса. Я бы начинал с пяти вопросов.
Какие данные получает система? Открытые инструкции и опубликованные каталоги можно обрабатывать не так, как медицинские документы, записи разговоров, платёжные сведения или материалы судебного дела. Важно учитывать не только отдельный документ, но и возможность восстановить чувствительную информацию из нескольких связанных фрагментов.
Что система может сделать с результатом? Подготовка черновика внутреннего текста несёт один уровень риска, а автоматическая отправка клиенту, изменение карточки в CRM или запуск платежа — другой. Чем значимее и менее обратимо действие, тем строже должны быть изоляция, аудит и человеческий контроль.
С какими системами нужно интегрироваться? Если ИИ должен работать с внутренней ECM, 1С, медицинской системой или хранилищем документов, сетевой маршрут может оказаться важнее места запуска модели. Иногда безопаснее оставить данные и интеграции внутри компании, передавая внешней модели только минимальный обезличенный контекст.
Какая нагрузка и скорость ответа требуются? Для нерегулярных запросов облачная модель может быть экономичнее собственной инфраструктуры, которая большую часть времени простаивает. Для стабильного большого потока или работы без связи локальный контур может оказаться предсказуемее.
Кто будет поддерживать систему? On-prem требует специалистов, способных обновлять модели и библиотеки, контролировать уязвимости, следить за производительностью и восстанавливать сервис после сбоя. Если этой роли в компании нет, сервер в собственной стойке создаёт ощущение контроля, но не сам контроль.
Ответы на эти вопросы обычно заметно сужают выбор. Иногда после них выясняется, что компании не нужен полностью локальный ИИ, а достаточно корпоративного API с обезличиванием и закрытыми интеграциями.
Когда облачный ИИ оправдан
Облако удобно для быстрой проверки гипотезы, особенно если задача ещё не доказала экономический эффект. Компания получает доступ к сильной модели и масштабируемым вычислениям без закупки оборудования, которое может оказаться ненужным через несколько месяцев.
Такой подход подходит для обработки открытых данных, внутренних материалов с допустимым уровнем риска и сценариев, где данные можно надёжно обезличить. Он также полезен при непостоянной нагрузке, когда собственная инфраструктура будет использоваться лишь несколько часов в неделю.
Облачная модель позволяет быстрее сравнить несколько вариантов и обновлять решение без сложной миграции оборудования. Но скорость запуска не освобождает от необходимости настроить доступ, журналирование, ограничения запросов и правила использования данных.
Особенно важно не смешивать корпоративный облачный API с личными аккаунтами сотрудников в публичных сервисах. Это разные схемы управления, даже если в основе используется модель одного разработчика.
Когда on-prem действительно нужен
Локальный ИИ оправдан, если правила компании или отраслевые требования запрещают передачу определённых данных во внешнюю инфраструктуру. Он также нужен для изолированных объектов, систем без стабильного подключения и процессов, где компания должна полностью контролировать хранение, сетевые маршруты и журналирование.
On-prem может быть разумным при постоянной предсказуемой нагрузке. Если модель обрабатывает большой поток однотипных документов круглосуточно, собственная инфраструктура иногда даёт более понятную стоимость операции и меньшую зависимость от внешнего тарифа.
Есть и задачи, для которых достаточно относительно компактной локальной модели. Классификация документов, извлечение реквизитов, поиск по внутренним знаниям или подготовка структурированного ответа не всегда требуют самой крупной доступной LLM.
Но локальное развёртывание — это не разовая установка программы. Модель нужно обновлять, тестировать после обновлений, защищать от несанкционированного доступа, наблюдать за производительностью и резервировать критичные компоненты.
Если компания покупает оборудование, но не определяет владельца системы и бюджет эксплуатации, через год она получает дорогой сервер с устаревшей моделью. Формально данные остались внутри, а фактически решение перестало развиваться.
Почему гибридный контур часто оказывается практичнее
Полностью локальная или полностью облачная схема удобна своей простотой на архитектурной диаграмме. Реальные корпоративные процессы редко бывают такими однородными.
В гибридной системе документы могут храниться и распознаваться внутри компании, а внешней модели передаются только обезличенные фрагменты. В другом варианте локальный RAG ищет информацию с учётом прав сотрудника, после чего облачная модель формирует ответ на основании найденного контекста.
Можно разделить и сами сценарии. Некритичные обращения обрабатываются в облаке, а документы с определёнными категориями данных автоматически направляются в локальный контур или сотруднику.
Такая архитектура позволяет использовать преимущества сильных внешних моделей, не передавая им весь корпоративный архив. Одновременно она сложнее в проектировании, потому что необходимо точно определить, какой компонент видит данные на каждом этапе.
Главная опасность гибридного подхода — размытая ответственность. Если никто не владеет полной схемой движения данных, безопасные по отдельности компоненты могут образовать небезопасный процесс.
Считать нужно не стоимость сервера и не цену запроса
При сравнении облака и on-prem часто сопоставляют стоимость оборудования с тарифом за токены. Такой расчёт выглядит убедительно, но не учитывает большую часть расходов.
Для локального контура нужны резервирование, хранение, электроэнергия, охлаждение, мониторинг, обновления и специалисты. Также необходимо учитывать простой оборудования и последующую замену ускорителей.
В облаке к цене запросов могут добавиться выделенная мощность, сетевой трафик, хранилища, поиск, мониторинг и сервисы безопасности. Стоимость также зависит от длины контекста, количества повторных обращений и того, насколько хорошо приложение отбирает данные для модели.
Сравнивать нужно полную стоимость одного рабочего сценария. Например, сколько стоит обработать тысячу комплектов документов с нужной скоростью, уровнем доступности, аудитом и допустимой долей передачи человеку.
Если процесс пока не измерен, точный расчёт всё равно будет предположением. Поэтому для первого этапа разумнее собрать прототип, замерить реальную нагрузку и только после этого выбирать промышленную инфраструктуру.
Безопасность не заканчивается выбором контура
Даже правильно выбранная архитектура не решает проблему безопасности раз и навсегда. Нужно управлять доступом, контролировать источники, защищаться от вредоносных инструкций в документах и отслеживать действия системы после запуска.
NIST относит к рискам ИИ не только конфиденциальность, но также целостность и доступность системы, её входных и выходных данных, программного обеспечения и оборудования (NIST). Это хороший ориентир: защищать нужно весь процесс, а не только канал связи с моделью.
В промышленной системе должны сохраняться сведения о том, кто отправил запрос, какие источники использовались, какой результат вернула модель и какое действие было выполнено. Для критичных операций также нужны ограничения полномочий, сценарий безопасного отказа и возможность остановить автоматическую обработку.
Локальный контур без аудита и разграничения доступа может быть опаснее правильно настроенного корпоративного облака. Облачный сервис без контроля запросов и интеграций, в свою очередь, не становится безопасным только благодаря сертификатам провайдера.
Начинать нужно с пути данных
Выбор между облачным и локальным ИИ нельзя сделать по одному признаку. Он зависит от чувствительности данных, последствий действий, нагрузки, интеграций и способности компании поддерживать выбранную инфраструктуру.
Поэтому первый шаг — нарисовать путь данных от источника до результата. После этого становится видно, какие части процесса должны оставаться внутри компании, что можно вынести в облако и где потребуется гибридная схема.
Хорошая архитектура не обязана быть самой закрытой или самой современной. Она должна давать достаточный уровень контроля, не разрушая экономику и скорость внедрения.