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

Приватный ИИ – это альтернатива: такой же ассистент, но работающий в ваших стенах. В этом руководстве мы объясняем, что это значит на практике: какие сценарии выигрывают больше всего, какие открытые модели достаточно хороши, какое оборудование нужно, как соотносятся затраты с облачным ИИ, как обеспечить точность и безопасность ответов и как локальная LLM сочетается с GDPR.

Что такое приватный ИИ?

Приватный ИИ – это ИИ, который целиком работает в инфраструктуре под вашим контролем. Языковая модель, ваши документы, поисковый индекс и чат-интерфейс находятся на ваших собственных серверах или в выделенном частном облаке. Запросы и ответы никогда не покидают вашу сеть, и никто не использует ваши данные для обучения своих моделей.

На практике это обычно модель с открытыми весами (open-weight) – такую модель можно скачать и запустить самостоятельно – в сочетании с поисковым слоем поверх ваших данных. Ваша команда получает ассистента в духе ChatGPT, а ИТ-отдел и специалисты по защите данных – полный контроль над тем, куда уходит каждый байт.

ваша_сеть/
Локальная LLM
Документы
Данные CRM
Доступ и журналы
Публичный ИИ-API✕ данные не покидают периметр
fig.01 · Главная идея: модель приходит к вашим данным, а не наоборот.

Почему компании отказываются от публичных ИИ-инструментов?

Причины, которые мы слышим чаще всего, на удивление совпадают:

  • Теневой ИИ. Сотрудники уже вставляют внутренние данные в публичные чат-боты, потому что одобренной альтернативы нет. Запреты редко помогают; помогает более удобный внутренний инструмент.
  • Защита данных и договоры с клиентами. GDPR, NDA и договоры с клиентами часто запрещают передавать определённые данные третьим лицам – особенно за пределы ЕС.
  • Зависимость от поставщика. Цены, условия, лимиты запросов и поведение модели могут измениться в одночасье. Процессы, построенные на одном провайдере, ломаются вместе с ними.
  • Стоимость при масштабировании. Оплата за токены дёшева для экспериментов и дорога для ежедневного использования во всей компании.

Каким сценариям приватный ИИ приносит больше всего пользы?

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

СценарийТипичные данныеЧто нужноРазмер модели
Поиск по внутренней базе знанийВики, руководства, регламенты, проектные файлыХорошие коннекторы к документам, поиск с учётом прав доступа, ответы со ссылками на источникиМалая или средняя
Анализ договоров и документовДоговоры, коммерческие предложения, тендеры, NDAНадёжная работа с длинными документами, извлечение положений в фиксированные поля, проверка человекомСредняя или большая
Ассистенты для HR и финансовРегламенты, вопросы по зарплате, счета, бюджетыСтрогие правила доступа, короткий срок хранения журналов, чёткие границы того, на что ассистент может отвечатьМалая или средняя
Анализ маркетинговых данныхРезультаты кампаний, выгрузки из CRM, отзывы клиентовСтруктурированный доступ к данным, резюме отзывов в свободной форме, сверка цифр с источникомСредняя
Черновики ответов в поддержкеОбращения, письма клиентов, знания о продуктеПоиск по вашей базе знаний, ваш стиль общения, человек, который утверждает ответ перед отправкойМалая или средняя

Поиск по внутренней базе знаний обычно лучший первый проект: польза очевидна («где актуальное положение о командировках?»), риск невелик, и он вынуждает навести порядок в источниках данных и правах доступа – а эта база нужна для любого следующего сценария.

Анализ договоров лучше всего работает как извлечение данных, а не как свободный чат: модель заполняет фиксированный набор полей – стороны, срок, срок уведомления, лимит ответственности, необычные положения, – а человек проверяет результат. Ассистенты для HR и финансов – область, где приватный ИИ важнее всего, ведь эти данные относятся к самым чувствительным в компании. Черновики ответов в поддержке часто становятся шагом к агенту, который общается с клиентами напрямую; как это выглядит в работе, мы описываем в статье о нашем работающем ИИ-агенте поддержки, который решает 80% запросов.

Достаточно ли хороши открытые модели для бизнес-задач?

Для большей части повседневной работы – да. Семейства моделей с открытыми весами, такие как Llama, Mistral, Qwen, Gemma и DeepSeek, во многом сократили отставание от крупных проприетарных моделей. Уступают они пока в самых сложных многошаговых рассуждениях, а внутренний ассистент редко занимается этим целыми днями.

Малые (7–9B)Средние (20–35B)Большие (70B+)
Поиск и ответы по документам
Резюме и протоколы встреч
Черновики писем и текстов
Классификация и извлечение данных
Сложные многошаговые рассуждения
Помощь в программировании
fig.02 · Насколько хорошо открытые модели разного размера справляются с типичными бизнес-задачами – по опыту наших проектов. Пять квадратов – готово к продакшену для большинства команд.

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

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

Какое оборудование нужно для локальной LLM?

Меньше, чем ожидает большинство. Главное ограничение – память GPU, а она зависит от размера модели и от того, сколько людей пользуются системой одновременно. Приблизительные ориентиры для квантованных моделей:

Размер моделиТипичный объём памяти GPUДля чего подходит
Малая (7–9B)16–24 ГБ, один GPUПрототипы, отдельные команды, классификация и извлечение данных
Средняя (20–35B)24–48 ГБАссистент для всей компании: поиск, резюме и черновики
Большая (70B+)48–80 ГБ и больше, часто два GPUСложные рассуждения, много одновременных пользователей

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

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

Как устроена система приватного ИИ?

  1. Ваши источники данных
  2. Поисковый индекс
  3. Локальная LLM
  4. Ассистент для вашей команды
  5. Контроль доступа и журнал аудита
fig.03 · Типичная архитектура. Все пять компонентов работают внутри вашей инфраструктуры.

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

Модель запускают с помощью таких инструментов, как Ollama или vLLM; поиском занимается векторная база данных. Ничто из этого не требует отправлять данные наружу. Если ассистенту нужно запускать действия – создать обращение, обновить запись в CRM, – это тоже может сделать развёрнутый у вас инструмент автоматизации внутри вашей сети; варианты мы сравниваем в статье n8n vs. Make vs. Zapier.

Как обеспечить точность ответов приватного ИИ?

Большинство неверных ответов вызвано не моделью. Их причина – этап поиска, который передаёт модели не те фрагменты или вообще ничего. Точность складывается из трёх вещей:

1. Качество поиска

Документы делятся на осмысленные разделы – по заголовкам или пунктам, а не по произвольному числу символов – и индексируются с метаданными: датой, отделом, типом документа. Сочетание поиска по ключевым словам с семантическим (векторным) поиском помогает находить артикулы, номера договоров и имена, которые чисто семантический поиск часто упускает. Таблицы, прайс-листы и отсканированные PDF требуют особой обработки – именно на них типовые решения ломаются чаще всего. А устаревшие версии нужно удалять из индекса, иначе ассистент с готовностью процитирует прошлогодний регламент.

2. Ссылки на источники и правило «нет источника – нет ответа»

Каждый ответ должен ссылаться на фрагменты, на которых он основан, чтобы пользователь мог проверить его в один клик. Не менее важно: если поиск не нашёл ничего релевантного, ассистент должен честно об этом сказать, а не импровизировать. Чёткое «Я не нашёл этого в доступных документах» вызывает больше доверия, чем гладкая догадка.

3. Набор для оценки

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

  1. Реальные вопросы вашей команды
  2. Ответы ассистента
  3. Проверка по источникам
  4. Анализ ошибок
  5. Улучшение поиска, промптов или данных
fig.04 · Цикл оценки, который мы проводим перед запуском и после каждого изменения модели, промпта или индекса.

Как защитить систему приватного ИИ, помимо самой модели?

Хранение данных на собственных серверах решает вопрос третьих лиц, но не решает всего остального. Четыре области заслуживают не меньше внимания, чем выбор модели:

  • Права доступа при поиске. Правила доступа должны применяться в момент поиска по документам, а не через просьбу к модели «игнорировать документы, которые пользователю видеть нельзя». Если этап поиска вернёт конфиденциальный HR-файл, модель им воспользуется. Права из ваших файловых хранилищ, вики или системы документооборота должны переноситься в индекс и оставаться синхронизированными.
  • Prompt injection. Документы, письма и веб-страницы могут содержать текст, который выглядит как инструкции для ИИ. Приватная модель уязвима к этому так же, как публичная. Относитесь к найденному контенту как к данным, давайте ассистенту только те инструменты и права, которые ему действительно нужны, и требуйте подтверждения человеком для действий с последствиями.
  • Журналирование. Журналы необходимы для аудита и отладки, но запросы и ответы сами часто содержат персональные данные. Определите, кто может читать журналы, как долго они хранятся и как с ними обращаться при запросах на доступ и удаление.
  • Обновления. Модель, ПО для её запуска, векторная база данных и интерфейс нуждаются в патчах. Скачивайте модели только из надёжных источников, проверяйте их и прогоняйте набор для оценки после каждого обновления.

Как мы обращаемся с данными, доступом и хостингом в наших собственных проектах, описано на нашей странице о безопасности.

Соответствует ли локальный ИИ требованиям GDPR?

Локальный запуск ИИ сам по себе не делает систему соответствующей требованиям, но снимает несколько самых сложных вопросов:

  • Нет передачи в третьи страны. Если данные не покидают вашу инфраструктуру в ЕС, не нужно обосновывать передачу ИИ-провайдеру за пределами ЕС.
  • Нет дополнительного обработчика для инференса. Поставщик модели никогда не видит ваших данных, поэтому для этого шага не нужен дополнительный договор об обработке данных.
  • Минимизация данных и безопасность под вашим контролем. Вы решаете, что индексируется, кто имеет доступ и как долго хранятся журналы.

Вам по-прежнему нужны правовое основание для обработки, чёткие правила доступа, концепция удаления данных и – для обработки с высоким риском – оценка воздействия на защиту данных. Если вы пользуетесь услугами провайдера частного облака, он является обработчиком, и с ним, как с любым другим хостинг-сервисом, нужен договор об обработке данных. В Германии производственный совет, как правило, имеет право голоса, если систему можно использовать для контроля за поведением сотрудников, – а журналы использования это позволяют. И если ассистент общается не с сотрудниками, а с клиентами, в игру вступают требования прозрачности EU AI Act – см. наше руководство по статье 50 для чат-ботов.

Мы проектируем систему вместе с вашим специалистом по защите данных. (Это общая информация, а не юридическая консультация.)

Сколько стоит приватный ИИ по сравнению с облачным?

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

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

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

Облачный APIЧастное облакоOn-premise
Низкие начальные затраты
Предсказуемые ежемесячные расходы
Низкая стоимость каждого доп. запроса
Низкие трудозатраты на обслуживание
Контроль над данными
fig.05 · Чем различаются профили затрат и контроля у трёх вариантов – качественное сравнение по нашим проектам, а не прайс-лист. Больше квадратов – выгоднее.

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

Локально, частное облако или гибрид – что выбрать?

ВариантКонтрольНачальные затратыЛучше всего подходит для
On-premiseМаксимальный – ничто не покидает ваше зданиеПокупка оборудованияОсобо чувствительных данных, регулируемых отраслей
Частное облако в ЕСВысокий – выделенная изолированная инфраструктураНизкие, ежемесячная платаБыстрого старта без собственной серверной
ГибридПравила для каждой задачиСредниеЧувствительные задачи – локально, всё остальное – в облаке

Гибрид часто оказывается прагматичным ответом: данные клиентов и HR остаются на локальной модели, а для нечувствительных задач можно использовать большую облачную модель – по чётким и принудительно соблюдаемым правилам о том, что куда направляется. Ключевое слово здесь «принудительно»: маршрутизация должна происходить в самой системе, исходя из источника данных или группы пользователей, а не зависеть от того, помнят ли сотрудники, каким инструментом пользоваться.

Какие ошибки при внедрении приватного ИИ встречаются чаще всего?

  • Покупка оборудования до тестирования. Правильный размер модели зависит от ваших задач, языков и числа пользователей. Сначала тестируйте, потом подбирайте оборудование.
  • Выбор самой большой модели по умолчанию. Средняя модель с хорошим поиском обычно превосходит большую модель с плохим поиском – и требует гораздо меньше оборудования.
  • Индексация всего сразу. Старые черновики, дубликаты и устаревшие версии ухудшают ответы. Начинайте с отобранных актуальных источников.
  • Права доступа «на потом». Встраивать контроль доступа в уже работающую систему мучительно, а один утёкший список зарплат разрушает доверие ко всему проекту.
  • Нет набора для оценки. Без реальных тестовых вопросов никто не может сказать, улучшило изменение ситуацию или ухудшило.
  • Отношение к проекту как к чисто ИТ-задаче. Специалист по защите данных, производственный совет (там, где он есть) и команды, которые будут пользоваться системой, должны участвовать с самого начала.
  • Нет ответственного после запуска. Кто-то должен поддерживать источники в актуальном состоянии, разбирать неудачные ответы и планировать обновления. Без этого качество постепенно падает.

С чего начать внедрение приватного ИИ?

  • Выберите один сценарий с чувствительными данными и понятной пользой – например, поиск по внутренним документам
  • Составьте список источников данных и определите, кто к чему имеет доступ
  • Протестируйте 2–3 открытые модели на 50 реальных вопросах вашей команды
  • Выберите on-premise, частное облако или гибрид в зависимости от чувствительности данных
  • Запустите систему для одной команды, измерьте использование и качество ответов, затем расширяйте
fig.06 · Старт в пять шагов, после которого первая команда начинает продуктивно работать уже через несколько недель.

Самый быстрый путь – небольшой, но настоящий пилот, а не масштабное решение о платформе. 50 вопросов из третьего шага становятся вашим набором для оценки, а правила доступа из второго шага – моделью прав для всех последующих сценариев. Если вы хотите выяснить, какая модель и какое оборудование подходят для вашей задачи, запишитесь на бесплатный звонок или узнайте больше о нашем приватном ИИ (часть наших индивидуальных ИИ-решений).