Привет, Хабр читатели!

Меня зовут Алексей, и я руковожу направлением искусственного интеллекта в одном из крупнейших федеральных холдингов России — более 15k сотрудников, работающих от Калининграда до Владивостока. Компания — лидер в своей отрасли, обладает развитой автоматизацией, но не является IT-компанией. И это меняет всё.

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

Если ты будешь выполнять свою работу неверно — от того, как ты внедряешь ИИ в компании с большим количеством людей — ты будешь сеять настроение и отношения к искусственному интеллекту. А это может определить, будет ли ИИ в вашей компании развиваться — или останется "магией", которой боятся.


1. Введение: Моя роль и контекст

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

? Не «создать систему» — а создать стратегию, которая позволит нам показать, что ИИ — это не магия, а удобный, полезный и понятный инструмент.

Организация не имела представления о том, что такое ИИ. Никто не мог ответить: «Что такое нейросеть? Как она работает? Что она может сделать для нас?»

Даже популярные LLM (Large Language Models) были «черным ящиком» — пока не покажешь, не поверят.

Но здесь есть нюанс: люди были очарованы генеративными моделями, которыми пользовались в повседневной жизни. Они видели, как модель генерирует текст, рисует картинки, пишет письма — и думали: «Это же просто!»

Но они не понимали нюансов:

Модели могут галлюцинировать.
Они могут выдавать правдоподобную, но ложную информацию.
Они могут «забывать», «путать» или «выдумывать» факты.

И это было важно показать — не как недостаток, а как особенность. Чтобы люди начали понимать: «ИИ — это помощник, но не замена разума».


2. Первоначальная ошибка: попытка внедрить ИИ без подготовки

Я предполагал, что можно сразу приступить к внедрению ИИ-решений. Ошибка.

Формула ошибки:
E = I × C
где
E — эффективность внедрения,
I — инвестиции в технологии,
C — культура восприятия технологий.
При C ≈ 0, даже I → ∞ даёт E ≈ 0.

Люди не готовы к ИИ — значит, нужно начинать не с кода, а с образования и доверия.


3. Диагностика и образование: как я стал "переводчиком"

Я провёл серию презентаций и встреч с каждым отделом. Цель: объяснить, что такое ИИ, какие типы ИИ существуют, и как они могут быть применены.

Разбил задачи по типам:

  • Компьютерное зрение — работа с изображениями и видео.

  • Звуковой анализ — обработка аудио, распознавание речи, сегментация.

  • Предиктивные модели — прогнозирование будущего на основе прошлых данных.

? Важное уточнение:
Очень многие хотят начать именно с предиктивных моделей — ведь всем хочется знать, что будет впереди, чтобы сделать правильный выбор сегодня.
Но здесь кроется опасность: люди часто довольствуются теми данными, которые у них есть, считая, что этого достаточно для прогноза. А на самом деле — это иллюзия.
Построить адекватную предиктивную модель на исторических данных за 2 года — практически невозможно. Особенно если данные разреженные, неполные или не покрывают полный цикл.
Даже если модель покажет высокую точность (например, 95% accuracy), она может быть неадекватной — то есть не отражать реальную картину.
Что значит «адекватная точность»? Это когда модель не просто точно предсказывает, показывая стремящуюся к 99.999% точность, а при этом опирается и оперирует всеми влияющими факторами — сезонностью, внешними событиями, внутренними процессами.
Например: если вы собрали данные за весну, лето и осень — и пытаетесь предсказать зиму — даже при высокой метрике, результат будет недостоверным. Потому что зима — это другой режим работы системы.
Есть исключения — например, сезонные явления: летом ёлки не продаются, а в декабре — продаются очень хорошо. Здесь модель может работать, но только если учтена сезонность.
Так что — да, хочется сразу строить «магические» предиктивные модели. Но без понимания данных и контекста — они станут не помощниками, а источником ложного доверия.


4. Сбор требований и построение дорожной карты

Собрал заявки от отделов — около 50+ идей. Классифицировал их по:

  • Типу задачи (например, классификация, регрессия, генерация)

  • Сложности реализации

  • Бизнес-эффекту

Применил принцип Парето (80/20):

20% задач дадут 80% эффекта — сосредоточился на них.

? Формула выбора задач:
S = Σ(w_i × e_i)
где
w_i — вес задачи (по важности для бизнеса),
e_i — ожидаемый эффект (экономия времени, снижение ошибок, рост удовлетворённости).
Выбирал задачи с максимальным S.

Но то, что я думал, можно будет реализовать и доказать, что это необходимо, оказалось совсем не так.
На все мои аргументы были ответы:

«Это долго»,
«Это дорого»,
«У нас нет времени».

Поэтому задачи выбирались так, чтобы можно было сделать быстро — и при этом показать эффект.
Не идеально, не масштабно — но видимо и ощутимо.


5. Адаптация стратегии: от «большой машины» к «маленьким шагам»

Получил обратную связь от руководства: «Не нужно большую машину — нужен быстрый результат».

Понял, что в не-IT компании результат должен быть видимым уже через 2–4 недели.

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

⚙️ Методология:
Применил итеративный подход с MVP на каждом этапе — каждый бот, каждая модель становилась частью единой архитектуры.

После этого пришлось собрать множество маленьких проектов — и выстроить из них логическую схему, которая позволила бы потом объединить их в нечто большое, что может принести большой эффект.

И вот это хорошо сработало.


6. Прототипирование до MVP: как я "показывал, а не рассказывал"

Организация не имела представления о LLM, нейросетях, GPU — пока не увидят, не поверят.

Решил: делать прототипы за 1–2 недели, чтобы показать эффект.

Пример: прототип Telegram-бота, который автоматически создаёт документ — показал эффект за 7 дней.
Это дало доверие и позволило двигаться дальше.

? Цикл прототипирования:
Идея → Прототип (1–2 недели) → Демо → Фидбэк → MVP


7. Архитектура системы: как я соединил маленькие решения в единое целое

Создал центральный сервер с микросервисами — каждый сервис отвечает за свою нейросеть.
Интегрировал интерфейсы: Telegram, Android-приложения, веб-панели.
Реализовал унифицированный API для взаимодействия с легаси-системами.

? Системная архитектура:
User Interface → API Gateway → Microservices (AI Models) → Legacy System
Каждый компонент может развиваться независимо, но работает в единой экосистеме.

Ох сколько на этом этапе пришлось съесть собак/лягушек и пудов соли— ну это уже прошлое.

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

Не потому что нет возможностей — а потому что:

  • В каждом отделе свои планы.

  • В каждой структурной единице — своя работа, свои сроки.

  • Где-то перерабатывают, потому что физически не успевают исполнять все задачи.

И это нормально — так устроены большие компании.
Но это делает интеграцию сложной, медленной и требующей терпения, гибкости и постоянного диалога.


8. Управление ограничениями: финансовые, временные, человеческие и технологические

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

Финансовые ограничения

Бюджет на создание полноценной команды из 15 джунов? Нет.
Поэтому я использовал гибридный подход:

  • Внутренние сотрудники — для поддержки и управления проектами.

  • Аутсорсинг и фриланс — для выполнения специфических задач. Это позволило мне сохранить контроль над качеством, не перегружая бюджет.

Человеческие ресурсы

Обучал внутренних сотрудников, создавал «ядро» команды — людей, которые понимают ИИ, могут общаться с разработчиками и объяснять бизнесу, что происходит «под капотом».
Это было ключевым — без этого даже самые крутые модели не будут приняты.

Временные ограничения

Фокусировался на быстрых победах — потому что в бизнесе результат должен быть видимым уже через 2–4 недели.
Если не показать эффект — проект умрёт.

Технологические ограничения: GPU, облака и открытые модели

Здесь — самая большая боль для разработчика ИИ.

? В компании отсутствуют GPU-серверы — и это не ошибка, а осознанный выбор.
Для бизнеса они не нужны — пока.
Но для работы нейросетей — они строго необходимы.

Чтобы решить эту проблему, пришлось:

  1. Выбрать облачные провайдеры, которые соответствуют требованиям безопасности и аккредитации компании.

  2. Пройти сложную процедуру аккредитации — это отдельная история, требующая недель работ с юристами, ИБ-специалистами и аудиторами.

  3. Отказаться от идеи собирать свои модели с нуля — хотя именно этого я хотел больше всего.

Почему? Потому что:

? Я — разработчик нейросетей. Я хочу собирать свои модели, обучать их на своих данных, чтобы они работали именно в тех условиях, в которых это требуется компании — по всей её широте и долготе, от Калининграда до Владивостока.

Но реальность была жесткой: экспериментов не было. Нельзя было потратить несколько месяцев на обучение модели и сотни Килорублей, если нужно показать результат за 2 недели.

Поэтому пришлось пойти на компромисс:

Использовать предобученные модели с открытыми лицензиями — те, что можно бесплатно использовать, модифицировать и внедрять в коммерческие проекты.


? Конкретные примеры предобученных моделей (с открытыми лицензиями)

?️ Компьютерное зрение:

  • YOLOv8 (Ultralytics) — MIT License — легковесная, быстрая, отлично работает на мобильных устройствах.

  • EfficientDet (Google) — Apache 2.0 — точная модель для детекции объектов.

  • MobileNetV3 — Apache 2.0 — оптимизирована для мобильных устройств и edge-вычислений.

?️ Звуковой анализ:

  • Whisper (OpenAI) — MIT License — распознавание речи, работает на русском.

  • Vosk — Apache 2.0 — лёгкая библиотека для распознавания речи, работает офлайн.

  • SpeechBrain — Apache 2.0 — фреймворк для задач обработки речи.

? Текст / NLP:

  • Sentence Transformers (SBERT) — Apache 2.0 — для семантического поиска и сравнения текстов.

  • FastText (от запрещенной в РФ компании КнигиЛиц) — MIT License — классификация текста, работа с морфологией.

  • ONNX Runtime — MIT License — позволяет запускать модели на любом устройстве, включая мобильные.


Эти модели стали основой нашей системы — они работают быстро, легко интегрируются, и главное — не требуют GPU. Мы используем их в облаке, на CPU, и они дают достаточный результат для бизнес-задач.

Да, это не «идеальные» модели — но они работают здесь и сейчас.
А это — главный критерий успеха в крупной компании.


? Мой вывод как разработчика ИИ:
Иногда лучшее — враг хорошего.
Когда ты хочешь собрать свою модель, но бизнес требует результата — ты выбираешь то, что работает.
И это — не слабость. Это — стратегия.


9. Минимизация человеческих ошибок: стратегия для центрального офиса

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

Применил подход: автоматизация повторяющихся действий.

Пример: бот, который автоматически проверяет фото и выдаёт предварительный вывод — эксперт лишь подтверждает.

? Цель:
Minimize(Error Rate) = f(Automation Level, Human Oversight)
Автоматизация должна быть достаточной, чтобы снизить ошибки, но не полной — эксперт остаётся контролёром.


10. Научный подход к управлению: метрики, гипотезы, итерации

Для каждой задачи формулировал гипотезу: «Если мы внедрим X, то Y увеличится на Z%».
Измерял результаты: время выполнения, количество ошибок, удовлетворённость пользователей.
Корректировал подход на основе данных — это был экспериментальный цикл.

? Цикл научного управления:
Гипотеза → Эксперимент → Измерение → Анализ → Корректировка


11. Результат: как компания начала понимать ИИ

Сотрудники перестали бояться ИИ — начали видеть его как инструмент, а не угрозу.
Появилось понимание: «ИИ — это не замена, а усиление».

? Метафора:
«ИИ забирает у человека мотыгу и даёт ему пульт от дистанционно управляемого трактора» — это стало внутренним слоганом.


12. Выводы и перспективы

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

? Главный вывод:
От тебя зависит, будут ли сотрудники бояться ИИ или доверять ему.
Если ты внедряешь ИИ как "волшебную палочку" — люди будут бояться.
Если ты внедряешь ИИ как "инструмент, который делает их работу проще" — они будут его любить.

Сейчас мы строим платформу для масштабирования ИИ-решений по всему холдингу.

? Перспективы:

  • Автоматизация 80% рутинных операций.

  • Внедрение Generative AI для создания документов.

  • Создание внутреннего центра компетенций по ИИ.


Если эта история была тебе интересна — подписывайтесь, будет ещё больше кейсов из мира внедрения ИИ в крупные компании!

Комментарии (1)


  1. NeriaLab
    10.10.2025 14:46

    Да, LLM можно "сделать" за 1-2 недели, но такое не "прокатит" с LBS и CESP системами, они годами создаются, если всё делать с 0. Или, можно взять один из форков Soar и сделать его "под себя", за месяц. У LBS/CESP систем гигантские преимущества перед LLM: им не надо "вычищать" данные; их обслуживание в разы дешевле, от 10 до 100 раз; работают с большим объёмом данных; быстрее; "умнее" и т.д.