Внедрение корпоративного ИИ начинается не с выбора «самой умной модели», а с ответа, какой процесс вы меняете и какие данные туда нельзя пускать. Пока этого нет, компания получает набор чатов и счетов, а не систему.
Ниже — порядок, который проходит security review чаще, чем программы из десяти рабочих групп. Он совместим с поставкой ИИ как сервис: сначала контроль и один сценарий, потом каталог моделей и масштаб.
Шаг 0. Посмотреть, что уже происходит
В большинстве компаний ИИ уже есть: личные ChatGPT, GigaChat, браузерные расширения, ключи в CI. Это теневой контур. Его не нужно стыдить, его нужно увидеть: какие отделы, какие данные, какие карты.
Без этой картинки пилот на официальном шлюзе будет жить рядом с обходным путём. Сотрудники останутся там, где привыкли, потому что «там быстрее».
Шаг 1. Один сценарий вместо платформы для всех
Хороший первый сценарий узкий: разбор типовых заявок, извлечение полей из счетов, черновик ответа оператору, поиск по внутренним регламентам. Плохой — «ассистент для всей компании».
У сценария должен быть владелец, система-источник (ITSM, CRM, файловое хранилище) и метрика, которую можно снять до и после: время обработки, доля ручного ввода, число эскалаций. Готовые контуры — на страницах решений, но внедрять сразу все пять не нужно.
Шаг 2. Правила данных до выбора модели
CISO обычно блокирует не модель, а неизвестность: куда ушёл текст, хранится ли он у поставщика, можно ли выгрузить журнал. Зафиксируйте классы данных: публичные, внутренние, персональные, коммерческая тайна. Для персональных — отдельный режим, см. DLP и 152-ФЗ.
Если правило «во внешние модели ничего из CRM», это должно стоять в шлюзе, а не в памятке на портале. Памятки не читают под дедлайном.
Шаг 3. Канал доступа, а не десять ключей
Продуктивный контур — это ИИ-шлюз: ключ выдаёт компания, квота видна финансисту, запрос пишется в журнал. Личный аккаунт директора по развитию для пилота допустим на две недели. Дальше это дыра в учёте.
Единого API ко всем моделям ждать не стоит. Единым должен быть вход: кто вызывает, с каким лимитом, под какой политикой. Модели при этом остаются разными.
Шаг 4. Пилот с датой окончания
Четыре–восемь недель достаточно, чтобы понять, врёт модель на ваших документах или нет. Дольше — значит никто не решился сказать «не взлетело». На входе: набор примеров, критерии ошибок, бюджет в ИИ-кредитах или иной понятной единице.
На выходе — go / no-go / переделать постановку. Не «продолжить эксперимент». Эксперименты без даты размножаются и размывают бюджет.
Шаг 5. Масштаб — это второй и третий сценарий
Когда первый сценарий живёт в проде, второй подключается к тем же политикам и тому же договору. В этом смысл платформы: не собирать заново ИБ и биллинг. Если каждый отдел тащит своего подрядчика, через год вы вернётесь к шагу 0, только дороже.
Модель можно менять. Процесс владения данными и ключами — нет, его перекладывать больнее. Как сравнивать поставщиков на этом этапе — в чеклисте выбора AIaaS.
Типичные срывы
Пилот на синтетических текстах: в проде модель встречает кривые сканы и обрывает ответы. Отсутствие владельца: ИТ «поддерживает», бизнес «пользуется», за качество не отвечает никто. Запрет ИБ без альтернативы: люди уходят в личные чаты.
Ещё один срыв — демо без интеграции. Красивый чат на сайте вендора не доказывает, что заявка из вашей системы доедет до модели и вернётся в карточку.
Коротко
Порядок такой: увидеть теневой ИИ → выбрать один процесс → поставить правила данных → провести доступ через шлюз → закрыть пилот решением → копировать практики, а не чаты.
Если нужен контур поставки сразу: что такое AIaaS и запрос консультации.
Частые вопросы
С инвентаризации того, что уже используют сотрудники, и с одного сценария, у которого есть владелец, данные и способ измерить эффект. Параллельно — правила: какие данные нельзя отправлять во внешние модели. Расширять каталог чатов до политик бессмысленно.
Нужен контур решений: кто владелец платформы, какие данные запрещены, как платить. Годовая «стратегия ИИ» из слайдов обычно отстаёт от смены моделей. Лучше короткий регламент и пилот на 4–8 недель.
Владелец процесса, а не «центр инноваций». Если заявки принадлежат ИТ-директору поддержки, пилот ведёт он. ИБ и платформа задают ограничения, но не придумывают сценарий вместо бизнеса.
Когда есть журнал запросов, роли, лимит расхода, понятный источник данных и критерий качества, который выдерживается не одну неделю. Если пилот живёт на личном ключе руководителя проекта — это ещё не продуктив.