«ИИ нельзя, у нас данные закрытые» — можно. Разбираю, как собрать ассистента в закрытом контуре

Почти в каждом проекте, где я помогал внедрять ИИ‑ассистента, был один и тот же момент. Бизнес горит идеей: разгрузить поддержку, автоматизировать вычитку и проверку документов, перестать сводить отчеты руками. А потом в разговор заходит безопасность — идея потухает на требовании «нашим данным нельзя наружу».

Дальше обычно есть два стула. Либо проект хоронят целиком (значит, ИИ нам не подходит), либо линейные сотрудники втихую используют Чат ГПТ, и через полгода случайно выясняется, что куски договоров и персональные данные клиентов утекли на чужие серверы.

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

Сразу оговорюсь: пишу из личного опыта, не претендую на истину в последней инстанции. Где‑то намеренно упрощаю. В комментариях welcome, если вы не согласны.

Глава 1. Где физически живет ИИ

Первое, о чем надо подумать при внедрении ИИ — где будет жить модель (желательно ориентироваться на требования безопасности и исходить из чувствительности ваших данных). Вариантов проживания ИИ, по сути, четыре, от самого открытого к самому закрытому:

1. Публичное облако (внешний API). Самый быстрый способ получить качество топовых моделей. Но каждый запрос уходит наружу вместе с содержимым. Годится для прототипа на обезличенных или синтетических данных. 

2. Ваш облачный контур. Модель разворачивается в вашем аккаунте у облачного провайдера, которому вы и так доверяете инфраструктуру (если вы и так обрабатываете данные клиентов на внешнем сервере, почему бы не обрабатывать их там же?). 

3. Серверы компании. Инференс на вашем железе в вашем дата‑центре. Данные физически не покидают периметр. Такая конфигурация используется в сферах финансов, медицины, госсекторе и всех, у кого присутствует режим коммерческой тайны.

4. Локально на машине. Модель запускается прямо на устройстве сотрудника, полностью офлайн. Чтобы задать вопрос ИИ даже интернет включать не надо.

Глава 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, что логируется — это стоит согласовать с безопасностью на берегу и записать. Дешевле договориться до интеграции, чем разбирать инцидент после.