Как построить команду AI-автоматизации с нуля: опыт, ошибки, собеседования

В 2019 году один крупный телеком-оператор запустил проект Internal Digital Automation. Идея была простой: вместо того чтобы нанимать ещё двадцать человек для кликанья по кнопкам в древнем софте, автоматизировать эти процессы. Аудиторы посчитали — много кадровых ресурсов утилизируется на рутину, которую можно оцифровать.

Прошло семь лет. Проект эволюционировал от RPA-роботов до AI-агентов с MCP и RAG. И главный вопрос, который встал на этом пути: кого брать в команду, которая будет всё это строить?

Сегодня разбираем реальный опыт построения команды AI-автоматизации с нуля — от критериев найма до устройства команды как центра компетенций. Этот опыт лёг в основу направления AI-автоматизации в MWS — компании, которая сегодня помогает бизнесу внедрять ИИ-агентов и автоматизировать процессы.

Путь от ручного управления к AI-агентам

Прежде чем говорить о команде, стоит понять контекст. В 2015 году один инженер поддерживал 700 физических серверов — всё в консоли, всё на ручном управлении. «Усталость и лень победили», — рассказывает Никита Казарян, руководитель направления AI-автоматизации в MWS. Подтянули Git, начали вкатывать DevOps-практики.

К 2018 году раскатали пять кубовых кластеров и перетащили всю телеком-нагрузку на Kubernetes. Разработки были с собственными управляющими шинами и протоколами вроде двойного TCP (SCTP), который жил только в телекоме.

В 2019-м перешли к автоматизации бизнес-процессов. RPA-роботы — это агенты, которые встают на компьютер и нажимают мышкой на кнопки в устаревшем софте. Экранные формочки, кнопочки, которые надо заполнить. Мысли об API нет. Приходят мощные дядьки-роботизаторы, ставят отдельную тачку, агента, который тыкает по кнопкам. «Страшно звучит, но это даёт выхлоп», — отмечает Казарян.

Триггером для нового витка развития стала поездка руководства в Китай в 2025 году, где показали self-hosted AI, работающий практически в каждой школе. Встала задача: построить команду, которая создаст платформу для AI-автоматизации.

Каких людей искать?

Ключевой принцип найма в AI-команду формулируется неожиданно. «Я ищу достаточно простых, базовых и понятных ленивых инженеров», — говорит Казарян.

Это не про лень в бытовом смысле. Это про людей, которые не хотят делать руками то, что можно автоматизировать. Тех, кто смотрит на повторяющийся процесс и думает: «А можно сделать так, чтобы это работало само?»

Два профиля в команде:

По сути, это инженеры с навыками Python или питонисты с навыками инженерки. Профили очень близки: Python, базовая инженерка для работы с хранилищами и API. «Самая жирная часть успеха всей этой истории — это знания, это сбор, подготовка, очистка и качество этих данных», — подчёркивает Казарян. Именно поэтому дата-инженер — критичная роль, а не «приятное дополнение».

Системное мышление — вторая критичная компетенция. Участник AI-команды должен видеть не отдельную задачу, а процесс целиком: от входных данных до результата для бизнеса. Без этого ИИ может начать масштабировать ошибки или делать ненужный процесс ещё быстрее.

Как собеседовать: критерии и антипаттерны

Рынок AI-специалистов — это лотерея. Резюме массово галлюцинируют годами опыта, а найм одного липового сеньора может стоить от трёх до шести месяцев слитого пилотного проекта.

Что спрашивать:

Вместо LeetCode-задач — бить по болевым точкам эксплуатации. Дифференцированная метрика «лени»: с чего кандидат начнёт? Сделает велосипед или поищет готовое? Человек, который в балансе между первым и вторым, но ближе к «лени», — это ваш человек.

Ключевой вопрос: как кандидат дебажит пайплайн? Если он сразу тащит тяжёлый трансформер — это тревожный сигнал. Правильный ответ начинается с эвристик, простых проверок и фиксации бейзлайна перед сжиганием GPU.

Антипаттерны:

• Человек, который всегда делает велосипед, даже когда есть готовое решение
• Человек, который не может переобучиться на Python, если пришёл из другого стека
• Отсутствие инженерного мышления

«Я видел людей, которые из фронт-джаваскрипта переходили в типизированные языки. Мир изменчив, это нормально», — говорит Казарян.

Ещё один важный сигнал: как кандидат разбирается в чужом коде? Если начнёт переписывать всё с нуля на свой любимый фреймворк — это катастрофа для команды.

Что искать в кандидатах:

Итеративность и терпимость к неопределённости. AI-решения редко строятся по принципу «написали ТЗ — получили идеальный результат». Команда должна уметь работать короткими циклами, быстро собирать обратную связь и спокойно относиться к несовершенной первой версии.

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

Как устроена команда

Ключевая модель: команда AI-автоматизации не описывает все процессы сама.

«Снова-таки, как и шесть лет назад, это будет история, где конечные бизнес-девы в конечных подразделениях», — объясняет Казарян. HR, закупки, сетевики — они знают свой процесс лучше. Они выступают в роли продукт-оунера, бизнес-заказчика.

«Внутри команды ты не построишь людей, которые понимают во всех сферах, никогда и никак», — добавляет он.

Команда AI-автоматизации — это платформа и рельсы, по которым бизнес запускает свои автоматизации. Роль команды:

• Центр знаний: рассказываем, что и как можно применить
• Центр компетенций: помогаем заэкзеютить в реальности
• Платформа: даём инструменты, на которых бизнес строит свои решения

Это не модельная история про «мы наняли гениев, и они всё сделают». Это история про инфраструктуру для автоматизации, которую используют все.

Именно такой подход реализован в MWS: компания выпустила модуль платформы MWS AI Agents Platform, который позволяет создавать ИИ-агентов по текстовому описанию задачи. Пользователь формулирует, что нужно автоматизировать, — система сама проходит полный цикл от уточнения требований до публикации готового сценария. Путь от идеи до рабочего прототипа сокращается до нескольких часов.

Реальные кейсы автоматизации

HR-бот на RAG. Проблема: сотрудники мучают HR-специалистов типовыми вопросами — «как сделать ДМС для жены и ребёнка?». Ответ есть в локальном нормативном акте, но каждый просит дополнительный вопрос, который лежит глубоко в документе. Решение: RAG-бот с базой знаний. Векторизация регламентов, объектное хранилище, подключение LLM. Q&A-система: сотрудник спрашивает — бот отвечает по шагам. HR-специалисты не отвлекаются на типовые вопросы.

Агент для сбора документов. Проблема: разработчик собирает пакет документов для визы, не помнит, что нужно и где брать. Решение: MCP-инструмент над сервис-деск-порталом. Агент сам запрашивает справку 2-НДФЛ, ждёт согласования, отправляет. «Всё это делаешь через MCP. Ты делаешь MCP инструмент над своим сервис-деск-порталом. После чего у искусственного интеллекта получаются ручки, чтобы что-то делать. Это уже по сути агент», — объясняет Казарян.

MCP для NetBox. Проблема: сетевой инженер ищет информацию о железе, серийниках, адресации. NetBox — учётная система на Python, DCIM и IPAM, учёт железа в стойках и сетевой адресации. Решение: MCP на чтение из NetBox. Бот отвечает на вопросы «где воткнуто, какой серийник».

Оценка false positive в SOC. Проблема: SOC-аналитики тонут в тысячах алертов. Решение: LoRA-адаптер для LLM. Модель автономно оценивает, false positive это или нет. «Кейс сводится к оценке фолс-позитивов. LM-ка которая автономно и быстро закрывает тебе вопрос», — говорит Казарян.

RAG vs Fine-tuning vs LoRA: что выбрать

Один из главных вопросов при построении AI-автоматизации: как «подружить» LLM с данными компании. Есть два стула — RAG и дообучение.

RAG (Retrieval-Augmented Generation) — семантический поиск с обширным дополнительным контекстом, который не влияет на основную модель. Ты векторизуешь знания с использованием AI, кладёшь в объектное хранилище, подключаешь LLM. Получаешь Q&A-систему. «Базовый RAG — это вот такая прямо детская игрушка», — но быстрый выхлоп.

Fine-tuning и LoRA. Когда говорим про дообучение, есть два варианта. LoRA-адаптеры — дополнительный слой над моделью. Переиспользует базовую модель. Если у тебя высокочастотная история с сильной спецификой — например, оценка алертов в SOC — можно «просадить» все остальные параметры модели. Ей не нужно быть сильно улыбчивой или юморной. Ты её окачиваешь по определённой ветке.

Переобучение модели — более жёсткая история, когда меняешь веса модели. Это нужно для очень узких, специфичных вещей. «Я их ещё не видел», — признаётся Казарян.

Экономика LoRA: «Говорящие видеокарты» стоят полтора-два миллиона рублей, местами до пяти. У них есть память. LoRA-адаптер постоянно находится в памяти видеокарты. Несколько адаптеров переиспользуют одну базовую модель — это экономичнее переобучения, но дороже RAG. RAG дешевле, потому что контекст загрузился, выгрузился — память освободилась.

MCP: как дать LLM «лапки»

MCP (Model Context Protocol) — стандарт, который превращает чат в агента. Раньше LLM генерирует код, ты сам разбираешься, почему не работает. Теперь LLM может сама писать, запускать, проверять, исправлять.

Технически это работает так: MCP Server — независимый процесс, который предоставляет набор Tool/Resource/Prompt. LLM через MCP Client вызывает эти инструменты: получает данные из базы, выполняет API-вызовы, запускает код.

«Anthropic приехал и подарил нам историю с модулем контекста протокола и function calling. Это звёздочка, которую нам подарила Клодия», — говорит Казарян.

MCP превращает LLM в агента с «ручками». Ты делаешь MCP-инструмент над сервис-деск-порталом — и LLM может сама запросить справку. Делаешь MCP над NetBox — и сетевой инженер спрашивает через бота.

«По сути, это лапки для LM-ки. У модели есть ручки, ножки. Она может ходить, спотыкаться, понять, что споткнулась, встать, отряхнуться, пойти дальше», — объясняет Казарян.

От прототипа к продакшену: как масштабировать нейросеть с малых данных на полные

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

Что нужно понять на старте:

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

Подготовка данных — самая жирная часть работы. «Самая жирная часть успеха всей этой истории — это знания, это сбор, подготовка, очистка и качество этих данных», — подчёркивает Казарян. Нужно собрать все источники, очистить от дубликатов и противоречий, векторизовать, настроить регулярное обновление. Без дата-инженера любая LLM будет галлюцинировать.

Выбор подхода зависит от масштаба. На малых данных хватает RAG. На полных может понадобиться LoRA-адаптер (если задача узкая и высокочастотная) или MCP-инструменты (если нужны действия, а не только ответы). Гибрид RAG для знаний + MCP для действий — рабочая схема.

Инфраструктура масштабируется нелинейно. Малые данные — одна GPU, один инстанс. Полные данные — несколько GPU, балансировка, кэширование. LoRA-адаптеры переиспользуют базовую модель — экономичнее, чем переобучение.

Для развёртывания моделей в продакшене существуют готовые платформы. Например, Inference Valve от MWS позволяет развернуть LLM или CV-модель за несколько часов вместо недель, автоматизируя до 70% рутинных задач по настройке. Платформа поддерживает мониторинг качества, отслеживание дрейфа моделей и интеграцию с CI/CD.

Продакшен — это продукт, а не проект. Нужен мониторинг качества ответов, обратная связь от пользователей, регулярный пересбор эмбеддингов, безопасность (LLM не должна выдавать ПДн). Модель — это не «сделали и забыли», это постоянная работа.

AI-хайп или революция

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

Аналогия с радиацией: когда её открыли, бизнес пихал во всё — в зубную пасту, в шампуни. Сработало не везде. AI сейчас — та же история: все пихают, не понимая, как работать. Эксперименты привели к GPU. «Спасибо OpenAI, которые подарили нам эти говорящие видеокарты, которые внятно собирают текст с предложениями, с общим смыслом», — отмечает он.

Хайп не лопнул за семь лет. Но «пихать везде» — не работает. Реальный выхлоп — в автоматизации конкретных процессов.

Почему ЦОДы — главная проблема AI

«Выкидывать будем деньги. Ещё раз. Деньги — на видеокарты, на энергетику, на обслуживание ЦОДов», — говорит Казарян.

Самая большая проблема AI — это ЦОДы: места, каналы, энергетика. «Мне очень импонируют ребята, которые запартнёрились с гидроэлектростанциями на востоке страны и строят там ЦОДы. У тебя есть близкая энергетика, стабильная. Постоянный прогон воды — охлаждение на халяву. Единственное, что сложно — это каналы. Но каналы строятся гораздо дешевле, чем выкопать реку, построить ГЭС и получать электроэнергию», — объясняет он.

AI-автоматизация — это про людей

Построить команду AI-автоматизации с нуля — это не про найм гениев. Это про поиск «ленивых инженеров» с правильным мышлением: тех, кто хочет автоматизировать, а не делать руками.

Команда — это центр компетенций, который даёт платформу и рельсы. Бизнес-подразделения сами знают свои процессы и строят на этой платформе автоматизации.

Технологии — RAG, MCP, LoRA — это инструменты. Главное — культура, процессы и люди. Технологиям можно научиться за несколько месяцев. Пониманию конкретного бизнеса иногда приходится учиться годами. Именно поэтому рескиллинг существующих сотрудников часто работает лучше, чем найм «готовых» специалистов со стороны.