Почти в каждом проекте, где я помогал внедрять ИИ‑ассистента, был один и тот же момент. Бизнес горит идеей: разгрузить поддержку, автоматизировать вычитку и проверку документов, перестать сводить отчеты руками. А потом в разговор заходит безопасность — идея потухает на требовании «нашим данным нельзя наружу».
Дальше обычно есть два стула. Либо проект хоронят целиком (значит, ИИ нам не подходит), либо линейные сотрудники втихую используют Чат ГПТ, и через полгода случайно выясняется, что куски договоров и персональные данные клиентов утекли на чужие серверы.
Оба варианта происходят от непонимания, что внедрить ИИ и отправлять данные в чужое облако это не одно и то же. Модель может работать там, где вы скажете, вплоть до ноутбука сотрудника без выхода в интернет. Ниже я разбираю, из чего собирается такой закрытый контур
Сразу оговорюсь: пишу из личного опыта, не претендую на истину в последней инстанции. Где‑то намеренно упрощаю. В комментариях welcome, если вы не согласны.
Глава 1. Где физически живет ИИ
Первое, о чем надо подумать при внедрении ИИ — где будет жить модель (желательно ориентироваться на требования безопасности и исходить из чувствительности ваших данных). Вариантов проживания ИИ, по сути, четыре, от самого открытого к самому закрытому:
Публичное облако (внешний API). Самый быстрый способ получить качество топовых моделей. Но каждый запрос уходит наружу вместе с содержимым. Годится для прототипа на обезличенных или синтетических данных.
Ваш облачный контур. Модель разворачивается в вашем аккаунте у облачного провайдера, которому вы и так доверяете инфраструктуру (если вы и так обрабатываете данные клиентов на внешнем сервере, почему бы не обрабатывать их там же?).
Серверы компании. Инференс на вашем железе в вашем дата‑центре. Данные физически не покидают периметр. Такая конфигурация используется в сферах финансов, медицины, госсекторе и всех, у кого присутствует режим коммерческой тайны.
Локально на машине. Модель запускается прямо на устройстве сотрудника, полностью офлайн. Чтобы задать вопрос ИИ даже интернет включать не надо.
Глава 2. Доступ к данным — это не одна кнопка
Если вы определились с местоположением модели — поздно расслабляться, ибо все только начинается. Безопасники уже бегут рассказывать Вам про все возможные проблемы от выдачи доступа ИИ к данным вашей конторы.Однако, обычно, что вы, что безопасники обсуждаете доступ ИИ к данным как единый рубильник. А доступов на самом деле три, и это архитектурно разные вещи с разными рисками:
Read — система читает данные, чтобы на их основе отвечать и готовить черновики.
Write — система пишет изменения обратно (обновляет карточку, статус, запись в БД).
Execute — система выполняет действия с внешними последствиями (отправляет письмо, проводит платеж, дергает внешний API).
Когда СБ слышит «ИИ будет работать с нашими данными», в голове у нее обычно сразу третий, самый страшный сценарий — робот, который сам все меняет и рассылает. Но для 80% реальной пользы достаточно Read. Ассистент, который читает базу знаний и регламенты и готовит проект ответа для оператора, физически не имеет прав ничего менять и никому ничего слать — у него просто нет соответствующих инструментов.»
Как только это разложено явно, половина возражений снимается сама: «читать регламенты» и «самому проводить платежи» перестают быть одной строчкой в согласовании.
Глава 3. Где система работает сама, а где зовет человека
Все слышали про рецепт свиных крылышек. Так как же мы можем быть уверены, что ИИ не напортачит и не отправит договор другому контрагенту или выставит неправильный счет.
К счастью, у меня есть ответ на этот вопрос. Он простой и понятный — НИКАК. Все,ч то мы можем — это явно прописать, что модель может делать сама, а для чего потребуется согласование человека. Ошибка при составлении внутреннего письма о корпоративе и неверные данные в счете‑фактуре, который уже отправлен партнеру — проблемы совсем разного масштаба.
Пример
В рамках согласованных правил ИИ работает сам — разбирает заявки, готовит документы, сводит отчеты. Но на все, что попадает в разряд Execute с необратимыми последствиями, ставится human‑in‑the‑loop: система подготовила действие → человек подтвердил → действие выполнилось. Плюс несколько технических предохранителей, которые я бы закладывал по умолчанию:
Лимиты и пороги. Сумма платежа, число рассылок, тип операции — выше порога уходит на подтверждение автоматически.
Идемпотентность. Действия с внешним эффектом должны быть защищены от повторного выполнения (ключ идемпотентности), иначе ретрай на таймауте отправит письмо дважды.
Полный аудит‑лог. Кто (какой агент/сессия), что, когда, на основании каких данных — все пишется в неизменяемый журнал. Это нужно и безопасности для разбора инцидентов, и вам для понимания, почему модель приняла то или иное решение.
Кнопка стоп. Возможность разом отозвать Execute‑права, не выключая весь сервис.
Это снимает ложную дилемму «либо ИИ все делает сам, либо не внедряем». На практике всегда нужна золотая середина: рутину агент забирает целиком, а на развилках, где нужна ответственность, отдает решение человеку.
Глава 4. Качество работы локальных моделей
Модели, которые все мы используем (ГПТ, Клод, Гемини) — огромные, они развернуты на бесконечного размера кластерах. Как моделька, развернутая на моем личном ноутбуке может конкурировать с ней в производительности, скорости и качестве ответов?
На самом деле, это сильно зависит от задачи, и для большинства бизнес‑сценариев вам не нужна модель на триллионы миллионов параметров. Вам нужна модель, которая уверенно читает ваши документы, держит контекст и отвечает по вашим правилам. С этим современные open‑weight модели (семейства Llama, Qwen, Mistral и российские варианты вроде GigaChat/YandexGPT) справляются в разы лучше, чем принято думать.
Несколько практических моментов, которые сильно влияют на результат:
RAG важнее размера модели. В большинстве корпоративных сценариев качество ответа определяет не столько сама модель, сколько то, насколько хорошо вы достаете релевантный кусок из вашей базы знаний и кладете его в контекст.
Дообучение — не первый инструмент, а последний. Файнтюн нужен, когда надо зашить стиль, формат ответов или узкую доменную специфику, которую не покрыть промптом и контекстом..
Квантизация делает локальный запуск реальным. INT8/INT4-квантизация роняет требования к VRAM в разы при небольшой потере качества. Модель, которая в fp16 не влезала в вашу видеокарту, в 4-битном варианте вполне живет на одной‑двух картах, а то и на топовом ноутбуке.
Модель — сменный компонент. Если строить решение так, что модель прячется за унифицированным интерфейсом, ее можно заменить на более свежую или дообученную без переписывания остального. Это страховка и от привязки к вендору, и от того, что через полгода выйдет что‑то лучше.
Бонус
Пара вещей из практики, которые всплывают уже после запуска:
Ops‑стоимость закрытого контура. Своя инференс‑инфраструктура — это GPU, их обновление, мониторинг, дежурство. Для одной модели на пару департаментов это может оказаться дороже, чем облачный API по токенам. On‑prem оправдан требованиями безопасности, но считать TCO надо честно, а не только «на облаке дорого».
Данные для RAG — это отдельный проект. Регламенты в разных форматах, устаревшие версии документов, дубли, сканы без текстового слоя. Пока это не приведено в порядок, ассистент будет уверенно цитировать неактуальную инструкцию. Часто 70% работы — не про модель, а про подготовку и поддержание базы знаний в живом состоянии.
Границы автономности лучше зафиксировать письменно до старта. Что система делает сама, где human‑in‑the‑loop, что логируется — это стоит согласовать с безопасностью на берегу и записать. Дешевле договориться до интеграции, чем разбирать инцидент после.