Привет, Хабр! Я Надежда Погина, руководитель проектов в блоке CTO в Cloud.ru. Мы — блок информационных технологий, наша команда из 300+ человек отвечает за строительство инфраструктуры для наших облаков.
В июне 2025 года перед нами, как перед одним из самых технологичных блоков компании, поставили амбициозную цель — не просто внедрить искусственный интеллект в нашу работу, а построить AI-first команду, чтобы стать примером для всех. Такая цель предполагает полноценный процесс, поэтому мы поставили перед собой ряд задач: в первую очередь — понять реальную картину и оценить текущий уровень зрелости команды, затем как-то вовлечь коллег, учитывая их высокую загрузку, регулярно измерять прогресс и в итоге превратить искусственный интеллект из игрушки для энтузиастов в рабочий инструмент для каждого сотрудника.
С чего мы начали и какие были сходные данные
В целом технический профиль команды давал хороший старт, но при этом сам по себе высокий уровень инженерной экспертизы еще не создавал общего ИИ-процесса.
Мы столкнулись с двумя барьерами, которые еще и взаимно влияли друг на друга.
Первый — у коллег нет понимания того, какими инструментами пользоваться, что актуально, а что нет, на что тратить свой ресурс.
Второй — у них нет времени на поиск этого самого понимания. Информации по теме очень много, она постоянно обновляется, сотрудники захлебываются в этом потоке.
А вот четыре опоры трансформации, которые мы положили в основу нашей стратегии:
Измеряемость, чтобы бороться с неопределенностью — мы приготовились регулярно замерять каждый шаг трансформации: уровень зрелости, частоту использования ИИ, барьеры, запросы на обучение в команде и т.д.
Прозрачность в выборе при создании портфеля проектов — каждая инициатива и каждая идея достойны рассмотрения и объективной оценки со всех ключевых сторон: бизнес ценность, технологичность и т.д.
Собственная обучающая среда — для обучения и развития команды отталкиваться от реальных задач блока, которые существуют здесь и сейчас, чтобы выращивать внутренних практиков.
Информационное поле и культура, чтобы бороться с сопротивлением через создание собственного и безопасного пространства для экспериментов, разбора ошибок и обмена опытом.
Эти опоры в итоге развернулись в пять практических инструментов, о которых и расскажу дальше. Но самое важное управленческое решение появилось в самом начале: мы разрешили себе менять план, исходя из реальной картины в каждом моменте. Результаты опросов влияли на фокус обучения и коммуникацию, интервью с авторами меняли приоритезацию в портфеле проектов и порядок запусков, обратная связь после запусков пилотов возвращала проекты к доработкам исходных данных и архитектуры и т.д.
Инструмент 1. Диагностика, которая меняет план
Итак, чтобы задать правильные рельсы ИИ-трансформации, мы начали путь с определения общей картины ИИ-зрелости в нашем блоке. Ничего более подходящего, чем старый добрый опрос, для такой задачи мы не придумали. Зная, как «любят» сотрудники отвечать на опросы, тем более на открытые вопросы в них, чтобы получить большую релевантную выборку мы подключили руководство: директор блока лично и многократно рекомендовал сотрудникам его пройти. В итоге 80% команды довольно качественно прошли опрос.
Причем опросов было несколько. Первый мы провели в июне (когда появилась наша глобальная цель), второй — через полгода в декабре.
Мы измеряли несколько вещей:
самооценку знаний об ИИ по шкале от 1 до 5;
регулярность использования ИИ;
барьеры: знания, время, безопасность и качество;
желаемые форматы обучения (в итоге, кстати, мы разработали свой курс);
примеры неудачных кейсов;
ощущаемое влияние ИИ на рабочую эффективность.
Особенное внимание мы уделили конструктивному негативу в ответах — он часто дает больше материала для решения, чем общий высокий балл. Например, комментарий про медленный ответ ведет к инфраструктуре, жалоба на неточность — к данным и оценке качества, а фраза «у меня нет времени» — к организации работы.
За полгода по результатам второго опроса мы увидели, что доля сотрудников, использующих ИИ, выросла с 72% до 84%. Доля тех, кто считал себя новичком, наоборот, снизилась с 39% до 15%. Средняя самооценка знаний поднялась с 2,0 до 3,0. А доля респондентов, которые видели повышение рабочей эффективности, выросла с 67% до 84%.
Все эти цифры помогли нам сначала (в июне) построить стратегию трансформации, а затем (в декабре) скорректировать ее. Например, за полгода сменились барьеры: если в июне большинство сотрудников называли ограничением недостаток знаний, то в декабре им стала нехватка времени. Таким образом мы поняли, что люди освоили базовые подходы и захотели решать более сложные задачи, на что, конечно, требуется больше времени, доступ к инструментам и экспертам.
Был еще один любопытный эффект, который мы заметили благодаря опросам. Сотрудники, которые уже разрабатывали агентов, иногда оценивали свою зрелость ниже коллег с небольшим опытом — практика показала им масштаб неизвестного. Поэтому самооценку полезно читать вместе с поведением, результатами проектов и качественными комментариями.
Диагностика работает как навигация. Один опрос в начале дает снимок, повторный замер показывает, как изменилась сама проблема.
Инструмент 2. Скоринг, который превращает очередь идей в портфель
Параллельно с диагностикой, мы начали перепись всех инициатив и не пропустили ни одной, даже самой неочевидной в плане эффекта. В итоге получился список из более чем 40 инициатив.
Далее мы собрали рабочую группу, разработали достаточно простую форму, позволяющую описать потенциальный проект с разных сторон, и начали проводить глубинные интервью с каждым автором, выставляя оценки от 1 до 5 по четырем критериям:
техническая реализуемость,
бизнес-ценность,
риски, включая безопасность и зависимости от API,
сроки.
Итоговый балл считали как среднее арифметическое.
Четырех критериев оказалось достаточно, чтобы провести содержательный разговор и сравнить проекты. Большая модель оценки, напротив, создала бы иллюзию точности и усложнила бы интервью.
Интервью давало больше, чем просто оценку, ведь во время беседы мы челленджили автора по разным аспектам потенциального развития его инициативы — начиная от пользовательского пути и заканчивая ожидаемыми бизнес-ценностями и допустимыми рисками. Некоторые сотрудники в процессе сами снимали свои идеи, когда видели слабые места. Другие сужали слишком широкую задумку до конкретного сценария.
Прозрачность помогла сохранить доверие. Мы показали команде, почему в первую волну запусков вошли не все проекты. При этом остальные инициативы остались в портфеле и могли перейти в следующую волну после доработки.
В результате такого глубинного анализа нам еще удалось выделить три крупные смысловые группы проектов :
ИИ-ассистенты для поддержки, поиска и рутинных вопросов;
автоматизация процессов, включая CRQ, change management и code review;
мониторинг и безопасность, включая работу с инцидентами и алертами.
Такая классификация полезна для повторного использования. Проекты с разными бизнес-целями часто требуют похожих компонентов, подходов к данным и проверкам качества.
От скоринга к продакшену
По результатам скоринга у нас получился шорт-лист из восьми проектов, и за шесть месяцев мы запустили все из них. Вот несколько примеров, которые хорошо передают разнообразие портфеля.
Анализатор CRQ автоматически проверяет планы работ, оценивает их и возвращает автору комментарии. Раньше задача с планом работ неделями ходила между участниками согласования. Предварительная автоматическая проверка сократила число возвратов и ускорила процесс.
HelpDesk-ассистент уровня L1 отвечает на внутренние вопросы по типовым процессам. Именно здесь особенно ярко проявилась зависимость качества от исходных данных.
Агент «Гипович» помогает инженерам в проектной работе.
Alert Management Correlation обрабатывает контекст инцидентов.
GitLab AI assistant работает со сценариями code review и генерации тестов.
У каждого проекта свои метрики. Для CRQ важны сроки и число возвратов с согласования. Для HelpDesk-ассистента — качество ответа, скорость и пользовательская оценка. Для работы с инцидентами важны точность подсказки и время реакции. Для code review можно смотреть на скорость разработки и качество найденных проблем.
Единой формулы измерения эффективности для всего ИИ-портфеля у нас не появилось. Наоборот, еще раз мы убедились, что каждый проект должен заранее описать собственную бизнес-ценность и способ измерения результата реализации.
Что объединяло все проекты — это технические дашборды, которыми мы замеряли время отклика, качество ответа и динамику ошибок. Для критичных сценариев мы добавляли ручную валидацию. Например, агент для работы с инцидентами опирался на исторические данные, а его подсказки проверяли специалисты. Уровень контроля всегда зависел от цены ошибки.
Ошибка модели часто начинается до модели
Самый дорогой урок мы получили на данных. Для HelpDesk-ассистента около четырех месяцев ушло на переформатирование описаний процессов. Материалы существовали, но их структура, актуальность и однозначность мешали стабильным ответам.
На старте один из сценариев давал качество около 6 баллов из 10. Мы добавили валидацию, предварительную очистку данных, скоринг качества и ручной аудит части кейсов. Для этого сценария ориентир ручной проверки составил 10%.
Информационная безопасность тоже влияла на архитектуру. Для части экспериментов внешние LLM были недоступны, поэтому команды работали с локальными моделями. Параллельно на уровне компании развивался внутренний контур Foundation Models и ИИ-песочница, согласованные с ИБ.
Подход к моделям получился прагматичным. Мы смотрели на задачу, доступный контур, качество и устойчивость. Гонка за каждой новой моделью добавляет миграции и повторные проверки. В продакшене зрелость данных и процесса часто дает больший результат.
Еще один урок связан с ожиданиями пользователей. Если первый ответ агента слабый, доверие падает моментально и вернуть его очень тяжело. Команде проекта важно заранее объяснить пилотный статус, способ обратной связи и критерий готовности. Пользователь должен видеть, что происходит с его замечанием и когда ждать улучшения.
Инструмент 3. Фабрика экспертов и безопасная среда
Важным процессом трансформации стало повышение экспертизы наших сотрудников, чтобы образовать ту самую фабрику экспертов, которая позволит реализовывать большее количество проектов. Мы вовремя поняли, что изобилие внешних курсов по ИИ не поможет с решением этой задачи: чтобы получить достаточно экспертных знаний и перейти к самостоятельной разработке агентов, нужно перебрать кучу разных программ. Сомнительно, что такие концентрированные программы вообще нашлись бы.
Поэтому мы собрали собственный курс с профильным отбором, регулярными встречами и разбором домашек. Программа курса буквально дышала: каждый следующий модуль учитывал результаты предыдущего, темы менялись местами, что-то исключалось, что-то добавлялось в зависимости от реакций слушателей и их успехов. Если группе было сложно, мы упрощали шаг, добавляли разборы домашек и возвращались к теме с другой стороны.
Углубленный курс по разработке агентов мы создавали вместе с внутренними энтузиастами, которые уже прошли практический путь. В пилотную группу отбирали участников через интервью — так мы снижали риск отторжения из-за сложности и собирали людей, готовых довести домашние задания до рабочего результата.
Выпускники стали основой нашей виртуальной ИИ-команды блока СТО, к которой теперь можно прийти с бизнес-идеей и получить помощь в проработке или реализации.
При этом мы также вкладывались в построение собственного сообщества вокруг ИИ-повестки. Успех его развития основан на пяти принципах:
Регулярность. Встречи сначала проходили каждую неделю, затем мы разделили их на общие и встречи лидеров с периодичностью раз в две недели каждая. На них разбирали удачные и неудачные кейсы, приглашали внешних экспертов, делились новостями и опытом. В итоге в регулярных встречах участвовали 86% сотрудников блока.
Прозрачность. Сотрудники знали, куда принести идею, как устроен скоринг, кто отвечает за обучение и где найти помощь.
Безопасная среда. Ошибку можно было разобрать публично и превратить в материал для других команд. Так, например, пришлось полностью переписать один проект с уровня архитектуры. Этот опыт сохранил ценность, потому что команда поняла причины и поделилась ими.
Карьерный трек. Участник мог вырасти в эксперта, войти в виртуальную команду, начать помогать другим и выступать на внутренних митапах.
Готовые рецепты. Мы собирали шаблоны, промпты, чек-листы и проверенные компоненты. Автору новой идеи уже не надо было погружаться во все детали разработки агента.
Кроме того, очень важно было создать безопасную среду, включая заботу о темпе. Энтузиасты часто совмещали эксперименты с основной работой и доходили до выгорания. В одном случае, например, я попросила автора проекта несколько недель не возвращаться к ИИ-задачам. Пауза сохранила человека и проект.
Основа успеха здесь состоит в создании тыла: выделять пространство для работы, помогать автору объяснить идею, защищать команду от лишнего организационного шума и давать право на откат. Эксперты растут постепенно. Сначала им нужна уверенность в собственной практике, затем возможность рассказывать о ней коллегам.
Инструмент 4. Информационное поле вместо потока сухих новостей
Даже внутри одного блока люди могут одновременно решать похожие задачи и повторять одинаковые ошибки. Мы запустили внутренний дайджест «AI Inside CTO», по сути, e-mail, сверстанный в корпоративном стиле, который рассылал лично директор блока СТО.
Любой сотрудник может заполнить форму и рассказать о чем-то своем. В дайджесте мы рассказываем про стратегию и анонсы, успех недели, ход проектов, истории людей, мировые тренды, новости виртуальной команды, безопасность и комплаенс.
Сотрудники видели в дайджесте свои имена и результаты коллег. У них появлялись точки входа для разговора на встрече.
Поддержка директора блока усилила доверие к информации внутри дайджеста. Присутствие на регулярных встречах было максимальным и в какой-то степени стало почетным, так как приглашения на встречи и ключевые коммуникации шли от первого лица.
Материальной мотивации у участников не было, но очень хорошо работала стимуляция любопытства, признания и ощущения, что у эксперимента есть организационная защита.
Со временем наша маленькая «фабрика экспертов» стала заметна за пределами СТО. На внутренние митапы стали приходить коллеги из других блоков, а наши практики начали использовать другие технологические команды.
Инструмент 5. Вредные советы, которые мы проверили на себе
Пятый инструмент появился из накопленного опыта. Мы собрали действия, которые повышают стоимость трансформации и замедляют команды.
Запускайте проект без оценки исторических данных. Команда потратит месяцы на исправление проблем уже после первых негативных отзывов.
Меняйте модель вслед за каждой новинкой. Большая часть времени уйдет на повторную интеграцию и регрессионную проверку.
Обещайте точность 100% с первого дня. Первый реальный сбой разрушит доверие и сделает обсуждение качества эмоциональным.
Оставляйте эксперименты на свободное время. Энтузиасты выгорят, а проекты будут двигаться рывками.
Храните метрики в головах. Через несколько месяцев команда потеряет исходную точку и спор о результате станет бесконечным.
Оставляйте пользователей без сопровождения. Даже технически сильный проект останется без регулярного применения.
Такой список удобно использовать перед стартом новой волны. Он переводит разговор с общего энтузиазма на готовность данных, ресурсы, метрики, коммуникацию и поддержку.
Как встроить локальную инициативу в общий ИИ-трек
Бонусный эффект для ИИ-трансформации блока мы получили благодаря тому, что всегда оставались открытыми для взаимодействия с другими командами: мы не замыкались на своем собственном опыте, всегда делились наработками, активно включались в общекорпоративный ИИ-трек. Это расширило возможности для команды:
влиять на состав моделей в нашем внутреннем контуре,
доступ к ИИ-песочнице для проведения различных экспериментов
к программе AI-чемпионов с баллами в качестве мотивационной составляющей,
внутреннему ИИ-радару для повышения собственной visibility на уровне всей компании
влияние на механизмы и внутренние процессы для упрощения реализации идей (fast track).
Руководству стало проще принимать решение о выделении ресурсов, когда видны объем спроса, приоритеты и ожидаемая ценность.
Интеграция с общекорпоративным ИИ-треком дала двусторонний эффект. Наш блок CTO получил инфраструктуру и общие механизмы. Компания получила проверенные практики, банк решений и внутренних экспертов. После шестимесячного этапа фокус расширился на два направления: технический трек с проектами и компетенциями, а также ИИ-менталитет для всех сотрудников, подразумевая разный уровень их технологической подготовки.
Масштабирование требует разных форматов коммуникации для повышения экспертности и уровня зрелости. Технической аудитории подходят практические работы и разборы архитектуры. Сотрудникам из других функций нужен знакомый рабочий сценарий. Поэтому теперь мы придумываем новые форматы взаимодействия.
Например, практический игровой челлендж (Capture The Flag) без кода, где сотрудник общается с автономным DevOps-агентом, у которого есть доступ к инфраструктуре и секретам (например, ключам Kubernetes) и который знает больше, чем должен. Задача участника — только с помощью текстовых запросов заставить агента выдать конфиденциальную информацию.
Что можно повторить в своей команде
Если собрать наш путь в последовательность, получится рабочий цикл:
Проведите диагностику. Измерьте использование ИИ, знания, барьеры, форматы обучения и примеры неудач.
Соберите все идеи. Проведите интервью с авторами, оцените реализуемость, ценность, риски и сроки.
Выберите первую волну. Объясните решение всей команде и сохраните остальные идеи в портфеле.
Опишите метрики каждого проекта. Добавьте исходную точку, критерий качества, скорость и пользовательский показатель.
Проверьте данные до разработки. Оцените актуальность, полноту, структуру и доступность источников.
Выделите время на эксперимент. У проекта должен быть ресурс, владелец и допустимый коридор ошибок.
Создайте фабрику экспертов. Учите на внутренних кейсах, собирайте виртуальную команду и готовые компоненты.
Сделайте опыт видимым. Регулярно показывайте запуски, ошибки, выводы и людей, которые их получили.
Повторите диагностику. Новый барьер станет основанием для следующей версии программы.
За шесть месяцев доля сотрудников, использующих ИИ, достигла 84%, регулярные встречи охватили 86% блока, а в прод вышло как минимум восемь проектов. При этом самым ценным результатом я считаю переход от отдельных энтузиастов к среде, где идея получает понятный маршрут, эксперт — поддержку, а ошибка становится общим опытом.
У нас в Cloud.ru есть принцип «все начинается с людей», и наш кейс его подтвердил. ИИ-трансформация начинается с людей, времени и умения учиться на ошибках. Технология ускоряет этот путь, а систему создают управленческие решения и ежедневная практика команды.