Локальный AI на сервере компании: архитектура и ограничения

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

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

Что здесь называется локальным и суверенным AI

Термины локальный AI, on-premise AI, AI в закрытом контуре и суверенный AI часто используют как синонимы, хотя между ними возможны различия. На ez.by определение прикладное:

Суверенный AI – это AI-сервис, у которого вычисления и корпоративные данные находятся в инфраструктуре, контролируемой компанией, а обращения к внешним моделям не требуются для рабочего сценария.

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

• интерфейс сотрудника;
• API и AI-шлюз;
• модель распознавания или генерации;
• поисковый индекс и векторное хранилище;
• исходные документы и временные файлы;
• история запросов и результатов;
• очередь задач и интеграционные журналы.

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

Из каких компонентов состоит рабочий контур

Минимальная архитектура – это не «чат плюс видеокарта». Обычно нужны несколько слоёв.

1. Локальный интерфейс. Пользователь входит под своей корпоративной учётной записью, видит доступные сценарии и историю операций.
2. AI-шлюз. Проверяет пользователя, ограничивает размер и тип данных, выбирает модель и записывает технический журнал.
3. Модельный сервер. Выполняет генерацию, распознавание речи, OCR или создание эмбеддингов на CPU/GPU.
4. Контур знаний. Хранит документы, индекс, метаданные, версии и правила доступа.
5. Интеграционные модули. Получают минимально необходимые данные из 1С, CRM, системы задач и других программ.
6. Проверки вне модели. Валидируют суммы, даты, идентификаторы, права и допустимость действия обычным кодом.
7. Наблюдение. Показывает нагрузку, ошибки, очередь, версию модели и качество на контрольном наборе.

Языковая модель находится внутри этой системы, но не является системой целиком.

Что означает «работает автономно»

У автономности есть как минимум три уровня, и их нельзя смешивать.

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

Почему локальное размещение не равно гарантии от утечки

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

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

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

Рабочая защита строится вокруг модели:

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

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

Как выбирается сервер с видеокартой

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

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

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

В совместном проекте ООО «Доктор Сервер» отвечает за подбор, установку и обслуживание серверной инфраструктуры. Я отвечаю за прикладной слой: модели, AI-шлюз, интерфейс, обработку данных и интеграции.

Что проверять в пилоте

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

До пилота фиксируются:

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

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

Когда локальный AI подходит

Подход оправдан, если одновременно выполняются несколько условий:

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

Когда лучше обычная автоматизация

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

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

Вывод

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

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