Запрос «хотим свой ИИ, а не публичный чат» стал обычным пунктом в переговорах. За ним стоят три разные причины: данные нельзя отправлять наружу, ответы должны опираться на внутренние регламенты, а расходы на сторонние сервисы хочется сделать предсказуемыми. Причины разумные, но решения за ними прячутся очень разные — от настройки доступа до обучения собственной модели, и стоят они несопоставимо. Разберём, что на самом деле скрывается за словами «корпоративный ИИ» и как выбрать вариант под задачу.
Что обычно имеют в виду под собственной моделью
Почти никто не обучает языковую модель с нуля: это требует вычислительных мощностей и объёмов данных, которых у обычной компании нет. Под корпоративным ИИ на практике понимают одно из четырёх решений.
- Публичный сервис с корпоративным тарифом. Тот же чат, но с договором, отключённым обучением на ваших данных и управлением доступами сотрудников.
- Приложение на внешнем программном интерфейсе. Модель остаётся у поставщика, но логика, интерфейс и работа с документами — ваши.
- Открытая модель на своей инфраструктуре. Модель разворачивается на вашем сервере или в облаке, данные из контура не выходят.
- Дообучение открытой модели. К предыдущему добавляется адаптация под предметную область и стиль компании.
Разница между первым и четвёртым пунктом — не в качестве ответов, а в контроле над данными, стоимости и сроках запуска. Начинать имеет смысл с той ступени, которая закрывает требования по данным, а не с самой сложной.
Данные: главный аргумент в пользу своего контура
Отправляя запрос во внешний сервис, компания передаёт третьей стороне фрагмент внутренней информации. Для маркетингового текста это не проблема, для выгрузки с персональными данными клиентов или содержимого договоров — уже вопрос, на который придётся отвечать перед проверяющими и перед самими клиентами.
Практический подход такой: разделите задачи по чувствительности данных. Черновики писем, идеи заголовков, разбор публичных материалов спокойно живут во внешнем сервисе. Работа с документами, содержащими персональные данные, коммерческие условия или технические доступы, должна оставаться в контуре компании. Такое разделение обычно снимает большую часть возражений и заметно снижает стоимость решения — переносить внутрь нужно не всё.
Четыре варианта и что они стоят
| Вариант | Где данные | Срок запуска | Кому подходит |
|---|---|---|---|
| Корпоративный тариф публичного сервиса | У поставщика, обучение отключено договором | Дни | Общие задачи, нечувствительные данные |
| Своё приложение на внешнем интерфейсе | У поставщика, но передаётся только нужное | Недели | Ассистент по базе знаний, обработка обращений |
| Открытая модель на своих серверах | Полностью в контуре компании | Недели плюс закупка оборудования | Персональные данные, закрытый контур, отраслевые требования |
| Дообучение открытой модели | Полностью в контуре компании | Дольше всех, нужен размеченный набор данных | Узкая предметная область, устойчивый формат ответов |
Из доступных инструментов компании чаще смотрят на открытые модели семейств Llama, Mistral и Qwen для развёртывания у себя, а из российских сервисов — на YandexGPT и решения облака Сбера, когда важно, чтобы обработка шла внутри страны. Выбор конкретной модели вторичен: они меняются быстрее, чем внедряется решение, и архитектуру стоит строить так, чтобы модель можно было заменить.
Почему дообучение нужно реже, чем кажется
Распространённое ожидание: обучим модель на наших документах, и она будет всё про нас знать. На деле для задачи «отвечать по внутренним материалам» дообучение обычно не требуется. Работает другая схема: документы разбиваются на фрагменты, складываются в поисковый индекс, и к запросу пользователя подставляются найденные куски. Модель отвечает по ним и может дать ссылку на источник.
У такого подхода есть практические преимущества. Обновить знания — значит переиндексировать документ, а не переучивать модель. Ответ проверяем: видно, на каком регламенте он основан. Права доступа сохраняются: сотрудник получает ответы только по документам, к которым допущен. Дообучение остаётся нужным там, где важен устойчивый формат вывода или узкая терминология, которую модель путает.
Из чего складывается стоимость владения
При сравнении вариантов считают обычно только оплату сервиса, а расходы шире.
- Инфраструктура: серверы с ускорителями либо аренда мощностей, если модель разворачивается у себя.
- Подготовка данных: сбор документов, чистка, разграничение доступа. Обычно это самая трудоёмкая часть.
- Разработка: интеграции с почтой, CRM, базой знаний, интерфейс для сотрудников.
- Сопровождение: обновление моделей и библиотек, переиндексация, разбор жалоб на неверные ответы.
- Работа людей: кто-то должен поддерживать базу знаний в актуальном состоянии, иначе ассистент начнёт отвечать по устаревшим регламентам.
Последний пункт недооценивают чаще всего. Качество ответов упирается не в модель, а в порядок во внутренних документах: если действующий регламент лежит в трёх версиях в разных папках, ассистент честно выдаст любую из них.
С чего начинать внедрение
Мы советуем идти от одной измеримой задачи, а не от платформы. Выберите процесс, где потери времени очевидны и результат легко проверить: ответы на типовые вопросы сотрудников, первичная классификация обращений, подготовка черновиков коммерческих предложений, поиск по технической документации.
Дальше порядок такой: собрать набор реальных вопросов с эталонными ответами, запустить решение на ограниченной группе, сравнить ответы с эталоном, зафиксировать, где модель ошибается, и только после этого расширять охват. Пилот на одном процессе показывает и реальную пользу, и требования к данным — с этими цифрами разговор о полноценном внедрении становится предметным.
Своя модель полезна ровно настолько, насколько чисты данные, на которых она учится. Обычно порядок обратный привычному: сначала информационные системы для бизнеса — учёт, заявки и документы в одном контуре, — и только потом корпоративный ИИ поверх них.
Ошибки, которые мы видим при внедрении
- Начинают с выбора модели. Вопрос, какая модель лучше, обсуждают месяцами, не сформулировав задачу.
- Своя модель ради самой идеи. Инфраструктура разворачивается под задачи, которые не содержат чувствительных данных.
- Нет проверки качества. Без набора эталонных вопросов невозможно понять, стало лучше или хуже после обновления.
- Ассистент отвечает по устаревшим документам. Никто не отвечает за актуальность базы знаний.
- Нет человека в контуре. Ответы уходят клиенту без проверки там, где цена ошибки высока.
- Не описаны права доступа. Ассистент выдаёт сотруднику документы, которые ему не положены.
Если вы взвешиваете публичный сервис и решение в своём контуре, начните с разбора задач и данных — это определяет вариант точнее любых сравнений моделей. Мы внедряем корпоративные AI-ассистенты: подберём схему под ваши требования к данным и соберём пилот на одном процессе.
