Содержание
Читайте в Telegram
|
Разбор трех кейсов интеграции нейросетей в работу группы компаний «Слетать.ру» от руководителя по внедрению ИИ Александра Быстрова.
Когда в компании только начинают пользоваться ИИ, почти все выглядит довольно предсказуемо. Кто-то открывает ChatGPT, кто-то Claude, кто-то Gemini. Люди быстро находят себе локальные сценарии: написать текст, собрать сводку, ускорить поиск информации, помочь с кодом или аналитикой. На этом этапе кажется, что внедрение уже началось и дальше оно будет просто расширяться само собой.
На практике это работает только до определённого масштаба. Пока ИИ остаётся набором внешних чатов, он помогает отдельным сотрудникам, но почти не становится частью самой компании. В этот момент становится видно, что один ChatGPT на всех — это не стратегия внедрения, а стартовая точка.
В Слетать.ру этот переход хорошо виден именно как инженерная, а не маркетинговая история. С одной стороны, сотрудники уже активно пользуются внешними инструментами. С другой — внутри компании за последний год начал складываться собственный ИИ-контур: корпоративная платформа, автооценка качества, SQL-ассистент, внутренние сервисы и решения, встроенные в отдельные процессы. Следующий шаг при этом: не запускать бесконечное количество новых ботов, а собрать управляемую архитектуру данных, метрик и единых стандартов.
На этом фоне особенно интересно посмотреть не на весь ландшафт сразу, а на три конкретных кейса.
От внешних чатов к корпоративному слою
Почти любая компания сначала заходит в ИИ через людей, а не через систему. Это нормальный и даже полезный этап. Он даёт быстрый сигнал, что технология вообще применима, где сотрудники сами видят ценность и какие сценарии действительно всплывают в работе без давления сверху. Но ровно эта же модель довольно быстро упирается в предел.
Проблема не в том, что внешние сервисы плохие. Проблема в том, что компания в такой схеме ничего не собирает в единый контур. У неё нет общего слоя доступа, нет повторяемости, нет нормального способа подключать внутренние знания и данные, нет общей аналитики по использованию. А главное — почти невозможно перейти от личной продуктивности к системному эффекту.
В Слетать.ру это уже хорошо заметно по самому характеру развития. ИИ не остался на уровне “пусть каждый пользуется чем хочет”. Внутри компании параллельно вырос корпоративный слой, который нужен не для того, чтобы заменить все внешние сервисы, а для того, чтобы собрать управляемую среду поверх реального набора инструментов. На карте внедрения это и описано как переход от набора решений к архитектуре: с вниманием к доступам, данным, метрикам и единым правилам работы.
Это, пожалуй, и есть первый важный тезис. На масштабе компании вопрос звучит уже не как “какая модель лучше”, а как “в каком контуре всё это вообще должно жить”. Пока ИИ остаётся только внешним инструментом, бизнес им пользуется. Когда появляется внутренний слой, бизнес начинает им управлять.
Кейс 1. Корпоративная платформа как общий вход
Самый важный кейс в этой логике — корпоративная платформа. Это единый интерфейс для доступа к LLM, внутренним ассистентам, SQL и связанным сервисам без VPN. Внутри уже есть разные модели, SQL-помощник, работа с графиками, изображения и слой аналитики использования.
Когда у компании появляется такой слой, ИИ перестаёт быть историей отдельных энтузиастов и начинает превращаться в корпоративную среду. Через неё можно не только давать доступ к моделям, но и постепенно подключать внутренние данные, собирать ассистентов под конкретные задачи, считать использование, понимать, какие сценарии реально приживаются, а какие живут только в презентациях.
Отдельно показательно, что платформа в вашем случае уже не существует сама по себе. Вокруг неё собирается и внутренний ИИ-хаб, то есть среда, в которой новые сервисы можно запускать не как штучные поделки, а как повторяемые решения. На карте это отдельно зафиксировано: уже собраны единый API, репозиторий сервисов и фронт для ассистентов.
Кейс 2. Автооценка качества как рабочий сервис, а не демонстрация
Если платформа — это базовый слой, то автооценка качества уже показывает, как ИИ начинает работать не по запросу пользователя, а как часть регулярного процесса.
Этот кейс мне кажется особенно важным, потому что он сильно отличается от самых популярных публичных сценариев. Обычно, когда говорят про ИИ, обсуждают генерацию текста, изображений или кода. Но в операционной реальности одна из самых сильных его ролей — сделать наблюдаемыми и масштабируемыми те процессы, которые вручную всегда остаются частично закрытыми.
Контроль качества — ровно такой случай. Его можно выстроить вручную, но он почти всегда будет дорогим, точечным и ограниченным по объёму. Даже сильная команда качества физически не может одинаково глубоко и регулярно смотреть всё. Поэтому ручной контур почти неизбежно начинает работать по выборке.
В Слетать.ру автооценка уже используется как ежедневная автоматическая оценка общения сотрудников. Сейчас этот контур работает в нашем туроператоре Let`s Fly, а следующим этапом обозначено масштабирование на сервис бронирования туров. На общей карте внедрения этот кейс прямо назван одним из самых сильных прикладных сценариев по качеству и масштабу применения.
Но по-настоящему важен здесь не сам факт, что модель умеет что-то оценивать. Важнее то, что вокруг этого появляется управленческий контур. ИИ здесь полезен не как замена отдела качества и не как волшебный автоматический судья. Он полезен как инструмент, который позволяет перейти от редкой ручной проверки к системному наблюдению за качеством на масштабе.
Кейс 3. Анализ заявки как работа с бизнес-объектом
В туристическом контуре заявка живёт долго. Она редко сводится к одному действию и почти никогда не укладывается в один момент времени. Всё начинается с первого обращения — звонка, сообщения, визита в офис — а дальше вокруг этой заявки постепенно накапливается история: подбор, уточнения, изменения, согласования, документы, статусы, комментарии, иногда сопровождение по ходу поездки и работа после возвращения клиента.
Для сотрудника это означает довольно простую, но дорогую проблему: контекст по заявке нужно каждый раз восстанавливать. Причём это не один документ и не один диалог, а длинная цепочка действий, решений и оговорок. В таких местах ИИ становится полезным как механизм сборки рабочего контекста.
Если внутренний сервис может посмотреть заявку целиком и собрать по ней ключевую информацию, то он помогает быстрее понять ситуацию.
Следующий этап
Когда в компании появляются рабочая платформа, несколько встроенных сервисов и понятный спрос со стороны бизнеса, становится ясно, что дальше наращивать внедрение точечно уже не очень эффективно.
Следующий этап почти всегда выглядит более скучно и более правильно одновременно: этап архитектуры. Не в смысле большой абстрактной схемы, а в смысле нормального инженерного контура: где какие данные, какие словари нужны, как подключаются сервисы, как считаются метрики, как управляются доступы, как переиспользуются компоненты, что становится стандартом, а что остаётся экспериментом.
Именно это у вас и обозначено как следующий шаг — переход от набора решений к управляемой архитектуре данных, метрик и единых стандартов.
Один ChatGPT на всех — это хороший старт. Иногда даже необходимый. Но реальная зрелость начинается позже: когда у компании появляется собственный пользовательский слой, когда ИИ начинает работать внутри процессов и когда вокруг него строится не только набор кейсов, но и инфраструктура.
