Управление ИИ-проектами 2026: методология, этапы, команда

ИИ-проекты ведутся не как обычные IT-проекты. Главное отличие — высокая неопределённость на этапе R&D: пока модель не обучена и не оценена, нельзя сказать, будет ли работать вся идея. Поэтому стандартный Scrum/Kanban с фиксированными спринтами проваливается. Нужны другие этапы, другая команда, другие метрики. В этой статье — методология управления ИИ-проектами под российские реалии 2026: этапы, команда, риски, KPI и то, что отличает PM в ИИ от PM в обычной разработке.

Кто такой AI PM и чем отличается от обычного product-менеджера

AI Product Manager ведёт продукты, где ядро ценности создаётся ML-моделью или генеративной нейросетью. Обычный PM управляет требованиями к коду; AI PM — требованиями к данным и модели, и заранее не известно, получится ли требуемое качество.

Три практических отличия:

• Жизненный цикл модели вместо линейного roadmap. AI PM планирует Discovery → Data → PoC → Pilot → Production → Evolution с заложенной неопределённостью R&D.
• Две метрики вместо одной. Связка «ML-метрика ↔ бизнес-метрика». Высокий F1 без эффекта на выручку — провал. Бизнес-метрика без устойчивой ML-метрики рассыпется через 3-6 месяцев.
• Go/No-go после PoC. AI PM закрывает проект, если метрика не достигается. Обычный PM такого решения почти не принимает.

Навыки AI PM: формулировать бизнес-задачу под ML-постановку, читать confusion matrix, оценивать качество данных с DE, выбирать между API / fine-tuning / RAG, понимать стоимость inference и planning под latency. Программировать не нужно — понимать, что делают инженеры, обязательно.

Жизненный цикл ИИ-проекта одной картой

Сквозной цикл: проблема → данные → модель → MVP → evaluation → продакшен → мониторинг → итерация. На каждом переходе — gate: продолжаем, возвращаемся, закрываем.

Стадия	Главный вопрос	Артефакт
Проблема	Есть ли бизнес-задача с ROI?	PRD + ROI-гипотеза
Данные	Хватает данных, доступны, размечаемы?	Каталог источников + sample
Модель	Достижима ли target-метрика?	PoC-notebook + отчёт
MVP	Работает ли на реальных пользователях?	Сервис + A/B-тест
Evaluation	Связывается ли ML-метрика с бизнес-метрикой?	Eval-pipeline + отчёт
Продакшен	Стабильна ли эксплуатация?	SLO + on-call
Мониторинг	Деградирует ли модель?	Drift-дашборд + алерты
Итерация	Что улучшаем дальше?	Roadmap

Подробнее — ниже.

ИИ-проект vs обычный IT-проект — главные отличия

Параметр	Обычный IT	ИИ-проект
Неопределённость	низкая (требования = код)	высокая (модель может не научиться)
R&D этап	минимальный	30-50% бюджета
Данные	конфигурация	критический ресурс
Метрика успеха	работает / не работает	accuracy, precision, recall, ROI
Команда	разработчик, тестер, дизайнер	DE, ML, MLOps, domain expert
Версионирование	git	git + DVC + model registry
Деплой	образ + контейнер	модель + сервинг + мониторинг drift
Срок до production	1-3 месяца	3-9 месяцев
«Закрытие» проекта	релиз и поддержка	эволюция и retraining

Вывод: на R&D нельзя обещать сроки. Можно обещать сроки до решения «идём дальше / останавливаемся».

Этап 0. Discovery и оценка реалистичности

Самая критичная фаза — здесь решается, есть ли смысл начинать.

Что делаем: описываем business problem и ROI-гипотезу; проверяем достаточность данных; прикидываем baseline и target; выбираем стек (open-source vs vendor, on-premise vs cloud); фиксируем команду и бюджет. Артефакт: PRD на 5-15 страниц с задачей, данными, метриками, ресурсами.

Чек-лист готовности к старту

Прежде чем выйти из Discovery в Data, должно быть закрыто:

• Бизнес-задача оцифрована — ROI-гипотеза с диапазоном
• Известен baseline: качество текущего процесса без ИИ
• Зафиксирован target: на сколько ИИ должен превзойти baseline
• Доступ к данным подтверждён юридически и технически
• Объём данных достаточен для обучения / fine-tuning / RAG
• Есть план разметки и бюджет на domain expert
• Определён стек: open-source vs vendor, on-premise vs cloud
• Зафиксирован owner со стороны бизнеса
• Спонсор готов к no-go после PoC

Если не закрыто три и более пункта — переходить рано, риск дорогого R&D без выхода в production.

Этап 1. Подготовка данных

Самая длительная фаза в большинстве ИИ-проектов — 30-50% бюджета.

Что включает: сбор из источников (БД, CRM, файлы, логи), очистка (дубликаты, пропуски, выбросы), нормализация форматов, разметка для supervised-задач, split на train / validation / test (70/15/15 или 80/10/10), версионирование через DVC или MLFlow.

Кто делает: Data engineer — пайплайны выгрузки и очистки; Domain expert — разметка; ML engineer — split и feature engineering.

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

Этап 2. Прототип модели (PoC)

Цель — доказать реализуемость на ограниченном scope.

Что делаем: baseline-модель (logistic regression, KNN или API Claude / GigaChat) → 2-3 кандидата сложнее (XGBoost, нейросеть, fine-tuned LLM) → сравнение на validation → анализ ошибок. Срок: 2-6 недель. Артефакт: notebook + отчёт с рекомендацией «идём дальше / меняем подход / останавливаемся».

Go/No-go: если PoC показал, что метрика не достигается — лучше остановиться, чем тащить в production «недотянутую» модель.

Этап 3. MVP и пилот

Цель — превратить notebook в сервис и протестировать на реальных пользователях.

Что включает: inference-сервис (FastAPI, Triton, BentoML), интеграция с продуктовыми системами, UI, мониторинг latency, A/B vs baseline. Срок: 1-3 месяца.

Метрики пилота: business (revenue, conversion, time-to-action), ML (precision, recall, F1), operational (uptime, latency, cost per inference).

Готовность к production: business-метрика подтвердилась в A/B, стабильность доказана, команда сопровождения определена.

Этап 4. Production и MLOps

Запуск в полный масштаб + поддержка. Что включает: деплой (контейнеры, Kubernetes / managed), мониторинг drift, retraining-пайплайн, A/B-платформа, on-call процедура отката. Срок настройки: 1-3 месяца.

Без MLOps модель проваливается через 6-12 месяцев из-за data drift, и никто не понимает почему. С MLOps — drift детектируется заранее, retraining автоматический.

Этап 5. Эволюция

ИИ-проект не «закрывается» как обычный. После production — эксперименты с новыми моделями, расширение scope, оптимизация cost и latency, адаптация под регуляторику и новые сегменты. Это постоянный roadmap, не задача с deadline.

Эволюция MVP → продакшен → масштабирование

Запуск не заканчивается на «модель крутится в продакшене». Стандартная траектория:

Фаза	Что входит	Срок
Pilot	один сегмент, ручной откат, человек в петле для critical-кейсов	2-3 месяца
Expansion	смежные сегменты, частичная автоматизация откатов, A/B-платформа	3-6 месяцев
Full integration	модель во всех сценариях, retraining-pipeline автоматический	6-12 месяцев
Platform	модель как внутренний сервис с SDK, biling по inference	непрерывно

Антипаттерн — прыжок с pilot сразу на full integration без expansion. На pilot 50 пользователей с активной обратной связью. Без промежуточной фазы команда не видит edge case’ы масштаба — full integration оборачивается откатом.

Фреймворки: ML Canvas, AI Project Canvas, AI Opportunity Canvas

В отличие от Lean / Business Model Canvas, AI-canvas включают блоки про данные, модель и метрики.

Фреймворк	Когда применять	Главные блоки
ML Canvas	внутренняя ML-задача (классификация, прогноз)	value proposition, prediction task, data sources, features, evaluation
AI Project Canvas	продукт на базе генеративной модели или агента	задача, данные, модель, UX, метрики, риски, бюджет
AI Opportunity Canvas	приоритизация портфеля идей	impact, feasibility, data readiness, regulatory exposure
AI Use Case Map	разбор «где в компании применим ИИ»	процессы, болевые точки, кандидаты, expected uplift

Практический рецепт: на Discovery — AI Use Case Map → AI Opportunity Canvas → ML или AI Project Canvas для выбранного проекта. Canvas не заменяет PRD, а готовит к его написанию.

Команда ИИ-проекта

Роль	Что делает	Когда нужен	Зарплата ₽/мес 2026
Product Manager (AI PM)	бизнес-логика, метрики, приоритеты	с этапа 0	250-500К
Data Engineer	пайплайны данных, ETL	с этапа 1	200-400К
Data Scientist / ML Engineer	модели, эксперименты	с этапа 2	250-500К
MLOps Engineer	деплой, мониторинг, retraining	с этапа 3	250-450К
Backend Engineer	сервинг, интеграция	с этапа 3	200-400К
Domain Expert	разметка, проверка качества	с этапа 0	150-300К
QA с уклоном в данные	тестирование ИИ-сервисов	с этапа 3	150-300К

Минимум для пилота: 3-4 человека (PM + DS + DE + Backend), 5-10 млн ₽/год. Production-сервис: 5-8 человек, 15-30 млн ₽/год.

RACI по этапам — кто за что отвечает

R — делает, A — отвечает за итог, C — консультирует, I — информируется.

Этап	PM	Domain	DE	DS/ML	MLOps	Backend
0. Discovery	A,R	C	C	C	I	I
1. Data	A	R	R	C	I	I
2. PoC	A	C	C	R	I	I
3. MVP / Pilot	A	C	C	R	C	R
4. Production	A	I	C	C	R	R
5. Evolution	A	C	C	R	R	C

Главная ошибка — A на всех этапах вешают на DS. На самом деле A — PM: он отвечает перед бизнесом за исход. DS отвечает за качество модели, не за судьбу проекта.

Метрики ИИ-проекта

Уровень	Что измеряем
Business	revenue / cost saved, conversion / churn, time-to-action
ML	accuracy / precision / recall / F1 (классификация), MAE / RMSE / MAPE (регрессия), BLEU / ROUGE / human eval (генерация)
Operational	latency (p50, p95, p99), uptime, cost per inference, drift score

Без всех трёх уровней «модель работает» — иллюзия. Точность хорошая, latency проваливается — на проде непригодна.

Бюджетирование ИИ-проекта: модели, инфра, команда

Бюджет складывается из трёх компонент: команда, инфраструктура (compute + хранилища), inference при использовании внешних моделей.

Компонент	Доля бюджета пилота
Команда (PM, DE, DS, MLOps, Backend, domain expert)	60-75%
Инфраструктура (GPU/CPU, хранилища, БД, мониторинг)	10-20%
Inference / API (Claude, GigaChat, YandexGPT, embeddings, vector store)	5-15%
Разметка (domain expert или внешний сервис)	5-10%

Часто забывают: хранение версий моделей и датасетов, drift-мониторинг, retraining раз в 1-3 месяца, on-call. Если планировать только обучение и сервинг — реальный счёт в 1.5-2 раза выше.

Правило: пилотный бюджет фиксируется до Go/No-go gate. До gate тратится максимум 20-30% годового бюджета — остальное, только если PoC подтвердил гипотезу.

Как объяснить ИИ-проект стейкхолдерам

ИИ-проекты гибнут не из-за модели, а из-за коммуникации. AI PM переводит ML-язык в язык денег и сроков.

Что работает:

• Сравнение с baseline. Не «accuracy 87%», а «модель отвечает правильно в 87% случаев против 62% у текущего ручного процесса. На объёме обращений это N сэкономленных часов».
• Диапазоны вместо точек. На R&D — «эффект попадёт в диапазон X-Y, точную цифру скажем после пилота». Точные обещания на PoC — путь к недоверию после запуска.
• Сценарии вместо обещаний. Пессимист / реалист / оптимист — стейкхолдер сам выбирает горизонт планирования.
• Demo, а не слайды. На каждый go-gate — живая демонстрация на 5-10 реальных кейсах. Метрики на слайдах хвалят все; demo ставит на место.
• Чёткие go/no-go условия. До Discovery: «если ML-метрика < X, закрываем». Страхует от давления «уже потратили, надо доделать».

Не делать: precision/recall/F1 без перевода в бизнес-эффект; обещать сроки до gate Data; показывать accuracy без confusion matrix — спонсор не увидит, какие ошибки критичные.

Внутренняя разработка vs partnership vs SaaS

Не каждый ИИ-проект требует своей модели. В 2026 три рабочих режима:

Режим	Когда подходит	Срок до production	Главный риск
Внутренняя разработка	уникальная задача, свои данные, регуляторные ограничения	6-12 месяцев	дорого, нужна сильная команда
Partnership	домен внутри, ML-экспертиза снаружи (интегратор, вуз)	4-8 месяцев	зависимость от партнёра, IP
SaaS / API	типовая задача (саппорт, классификация), данные не критичны	1-3 месяца	vendor lock-in, цена inference на масштабе

Практика: для NDA-чувствительных данных (медицина, банки, оборонка) — внутренняя или on-premise. Для типовых сценариев — старт с SaaS-API, чтобы за 4-6 недель доказать гипотезу, потом при росте объёмов оценить миграцию на свою модель.

152-ФЗ и регуляторика для ИИ-продуктов

Работа с персональными данными регулируется 152-ФЗ, с 2023 года — ужесточёнными требованиями к локализации и отчётности (нарушения — крупные оборотные штрафы). Минимум для ИИ-проекта на персданных:

• Согласие на ИИ-обработку. Отдельное согласие, не общий чекбокс. В формулировке — цель обработки и тип модели (своя или сторонний сервис).
• Локализация. Сбор и первичное хранение персданных граждан РФ — на серверах в РФ. Западные облака отпадают; Yandex Cloud, VK Cloud, MWS — подходят.
• Отчётность в Роскомнадзор. Уведомление об обработке, при необходимости — оценка воздействия на персданные.
• Право на возражение и удаление. Данные пользователя исключаются из train-выборки на следующем retraining.
• Российские модели как опция. Для критических кейсов — GigaChat, YandexGPT, локальные open-source (Saiga, Vikhr). Снимает риск отключения западных API.

Отраслевые требования: банки — ЦБ-указания по моделям рисков, медицина — Росздравнадзор, госорганы — ФСТЭК. AI PM не юрист, но знает, кто в команде закрывает регуляторный блок.

Главные риски ИИ-проектов

Риск	Чем опасен	Митигация
Качество данных	большинство провалов начинается здесь	разметка с domain expert + data quality checks
Drift модели	распределение меняется, модель деградирует	мониторинг + retraining pipeline
Регуляторика	152-ФЗ ограничивает использование данных	анонимизация, синтетика, on-premise
Vendor lock-in	риск приостановки доступа к Claude / OpenAI	мульти-вендор, локальные модели в резерве
Невозможность интерпретации	стейкхолдер не понимает, почему модель предсказала так	SHAP, LIME, простые модели где возможны
Hallucinations	LLM придумывает факты	RAG, fact-checking, человек в петле
Сопротивление команды	сотрудники видят в ИИ угрозу	обучение, «инструмент, не замена»

Методологии — что работает

Чистый Scrum не работает на R&D: «definition of done» эксперимента дать невозможно. CRISP-DM хорош как backbone, но не покрывает MLOps. ML Project Lifecycle (Andrew Ng) — «scope → data → model → deploy → monitor» — стандарт индустрии. В РФ-реалиях 2026 работает гибрид: Kanban на Data и PoC + Scrum на MVP и Production.

Методология	Когда применять
Waterfall	государственные регуляторные проекты
Scrum	MVP / Production
Kanban	Data и PoC
CRISP-DM	backbone для DS-команды
ML Project Lifecycle	production-ИИ
Гибрид Kanban + Scrum	стандарт 2026

ИИ-инструменты для самого AI PM

Сам PM использует ИИ для рутины:

Задача	Инструмент
Транскрипция и резюме встреч	Whisper + Claude или YandexGPT
Автогенерация тикетов из заметок	LLM-шаблон → Jira / Yandex Tracker
Статус-отчёты по проекту	Claude с MCP-сервером для трекера
Анализ velocity и блокеров	Custom-скрипт на YandexGPT
Кластеризация багов из соцсетей	LLM + embeddings
Поиск по Confluence, Notion	Notion AI или GigaChat с RAG
Прогноз срыва дедлайнов	Классический ML на трекерных данных

Что НЕ делегируем: конечное go/no-go, переговоры со спонсором, найм, оценку доменного эксперта. Модель ассистирует, отвечает PM. Эффект — 5-10 часов в неделю экономии на рутине.

Best practices эксплуатации: A/B промптов, red teaming, evaluation pipeline

К 2026 году сложился набор практик, без которых LLM-сервис считается сырым:

• A/B-тесты промптов. Каждая правка системного промпта — через offline-сравнение на eval-выборке + online A/B на части трафика. Без этого «улучшил формулировку» портит метрики, а команда узнаёт через неделю по жалобам.
• Evaluation pipeline. Фиксированная выборка из 200-2000 кейсов с reference-ответами, прогон при каждом релизе. Метрики — комбинированные: автоматические (BLEU, ROUGE, embedding-similarity) + human-eval на сэмпле + специфические (factual accuracy, refusal rate).
• Red teaming. Регулярная попытка пробить модель: jailbreak-запросы, токсичный контент, утечка системного промпта, вынос персональных данных. Лучше команда найдёт сама, чем пользователь.
• Human in the loop для critical-кейсов. Для решений с высокой ценой ошибки модель готовит вариант, финал — за человеком. Полный автомат — после стабильной работы 3-6 месяцев.
• Fallback на детерминированную логику. При low confidence — правила или человек. Без fallback’а LLM-сервис тихо возвращает уверенные галлюцинации.
• Канареечный деплой. Новая модель — на 1-5% трафика, мониторинг 24-72 часа, потом расширение. Прыжок на 100% — источник большинства прод-инцидентов.
• Версионирование промптов и моделей. Git для кода + промпт-registry с историей. Без этого «почему вчера работало, сегодня нет» становится археологией.

Кейсы ИИ-проектов в РФ

Крупные российские компании за 2024-2026 годы опубликовали достаточно деталей, чтобы по ним учиться:

• Яндекс — YandexGPT, Алиса, Поиск. Цикл от собственной языковой модели до интеграции в десятки сервисов. Урок — приоритет инфраструктуры и UX-паттерны (Алиса-навыки, генеративные ответы в поиске).
• Сбер — GigaChat и AI-фабрика. Core-LLM как платформа для десятков внутренних команд и внешних B2B-клиентов через API (GigaCode, SaluteSpeech).
• T-Банк — Олег и риск-модели. Комбинация generative-ассистента и classical ML на скоринге, антифроде, in-app коммуникации под продуктовые KPI.
• VK / MWS — рекомендации и корпоративные AI-инструменты. Рекомендации как самостоятельный AI-продукт со своей командой и SLA.
• Avito — ML на безопасности и модерации. Урок — критичность precision при высокой цене ложного срабатывания.

Общее: каждая компания инвестировала в собственный ML-стек до продуктового расширения. Без инфраструктуры на масштабе не сработало ни у кого.

Где ИИ-проект провалится: ранние признаки

Большинство ИИ-проектов закрывается на Discovery и PoC — это нормально. Хуже, когда проект тянется до production и проваливается там. Ранние индикаторы:

• Нет владельца со стороны бизнеса. Без одного ответственного за business-outcome проект превращается в технический эксперимент, gate’ы никто не закрывает.
• Критерий успеха — «попробовать ИИ». Технология как цель вместо бизнес-результата — гарантированный провал.
• Данных нет, «соберём по ходу». Если на Discovery нет sample и плана сбора — Data-этап растянется и съест бюджет до PoC.
• DS работает отдельно от продуктовой команды. Notebook’и в Jupyter, требования в Jira, связи нет — PoC уходит «в стол».
• Стейкхолдер не готов к no-go. «Мы должны запустить» вместо «мы хотим понять, имеет ли смысл» — закрыть проект после PoC будет политически невозможно.
• PoC переезжает в production как есть. Notebook становится сервисом без рефакторинга — каскад инцидентов через 2-4 недели.
• Нет бюджета на эксплуатацию. MLOps не наняли, retraining не настроили — модель деградирует, проект умирает через 6-12 месяцев.

Если три и более индикатора видны на Discovery — остановиться и устранить, не тащить в Data.

Антипаттерны управления ИИ-проектами

• «Сначала модель — потом задача» — техническое демо без бизнеса.
• PoC без go/no-go даты — эксперимент тянется месяцами, бюджет утекает.
• Оценка качества без бизнес-метрики — F1 вырос, выручка не сдвинулась.
• Деплой без мониторинга drift — модель тихо деградирует, никто не замечает.
• Один senior DS закрывает всё — без DE и MLOps выхода в production не будет.
• Скрытие провала PoC — провал откладывается до прода, обходится в три раза дороже.
• Игнор регуляторики до production — 152-ФЗ запрещает использовать собранные данные, всё переделывается.

FAQ

Сколько времени занимает ИИ-проект от идеи до production?

Стандартно — 6-12 месяцев для среднего пилота. Полное внедрение в production — 12-24 месяца. Discovery (1-2 месяца) → Data (2-3) → PoC (1-2) → Pilot (2-3) → Production (1-3).

Какая команда нужна для пилота ИИ-проекта?

Минимум — 3-4 человека: AI PM, Data Engineer, Data Scientist, Backend. Бюджет — 5-10 млн ₽ на год. На production вырастает до 5-8 человек.

Можно ли вести ИИ-проект без data scientist’а?

Для простых задач (классификация, базовая регрессия) — да, через AutoML или API LLM (GigaChat, Claude). Для production — нет, нужен инженер, понимающий ML.

Сколько стоит AI PM в 2026?

В Москве — 250-500К ₽/мес для senior, удалёнка из регионов — 200-350К ₽.

Какие KPI у ИИ-проекта?

Три уровня: business (revenue, ROI), ML (accuracy, F1), operational (latency, drift). Без всех трёх «модель работает» — иллюзия.

Можно ли применять Scrum для ИИ-проекта?

Частично. На R&D — не работает (эксперимент не оценить в стори-поинтах). На MVP и Production — да, стандартный Scrum.

Как принимать go/no-go решение после PoC?

Три условия одновременно: достигнут target по ML-метрике на validation, в анализе ошибок нет critical edge case’ов, оценка эксплуатации показывает положительный ROI. Если не выполнено хотя бы одно — no-go или возврат на этап данных.

Что делать, если PoC показал, что метрика не достигается?

Сначала проверить три гипотезы: данных мало, данные грязные, выбрана слабая модель. Если на новых данных результат не растёт за 2-4 итерации — закрывать честно. Тянуть «недотянутый» PoC дороже, чем закрыть и переориентироваться.

С чего начать в компании, где ИИ-проектов ещё не было?

С одного маленького кейса с понятным ROI и доступными данными — автоматизация саппорта, классификация заявок, извлечение полей из документов. Не строить сразу «корпоративную AI-платформу». Один успешный пилот за 3-6 месяцев даёт мандат на платформенные инвестиции.

Нужно ли AI PM программировать?

Прод-код — нет. Читать notebook’и, делать промт-эксперименты в ChatGPT/Claude, понимать SQL и confusion matrix — обязательно. AI PM, который не может посмотреть 50 примеров ошибок модели, теряет связь с продуктом.

Сколько стоит запустить MVP на ИИ?

SaaS / API-интеграция на готовой модели — от 1-3 млн ₽ на 2-3 месяца. Внутренняя разработка с fine-tuning — от 5-10 млн ₽ на 4-6 месяцев. Исследовательская разработка «с нуля» — от 15-30 млн ₽ и 6+ месяцев. Точная цифра — после Discovery.

Как объяснить ИИ-проект CFO, который не верит в технологию?

Через сравнение с baseline и сценарии. Не «нейросеть улучшит процесс», а «в текущем процессе из 100 заявок 38 обрабатываются с задержкой более суток. Пилот на 5% трафика покажет, сократит ли это до 15-20. Бюджет — N млн ₽, gate на закрытие — через 4 месяца». CFO покупает оценимые риски, не магию.

Что считать MVP в ИИ-проекте?

Минимальную версию, которую можно показать пользователям и измерить business-метрику. Это не notebook, а сервис с UI, мониторингом и A/B-сравнением с baseline. MVP без замеренной бизнес-метрики — это демо.

Что делать с галлюцинациями LLM?

Слоистая защита: RAG с проверяемыми источниками, citation-блок в ответе, fallback на детерминированную логику при low confidence, human in the loop для critical-кейсов, регулярный red teaming. Полностью убрать галлюцинации нельзя — можно снизить частоту и сделать их явными.

Можно ли вести ИИ-проект без своих GPU?

Да. Для API-режима GPU не нужны. Для fine-tuning — арендуются у Yandex Cloud, VK Cloud, MWS. Свои GPU оправданы при больших объёмах inference или жёстких требованиях к локализации.

Как часто переобучать модель?

Мониторить drift и переобучать при превышении порога + плановый retraining раз в 1-3 месяца. Для статичных задач — раз в 6-12 месяцев, для динамичных (e-commerce) — еженедельно.

Дальше

Управление ИИ-проектами 2026 — другая методология, а не Scrum с тегом «AI». Этапы: Discovery → Data → PoC → Pilot → Production → Evolution. Отличия от обычной IT-разработки — высокая неопределённость R&D, критическая роль данных, две связанные метрики (ML + бизнес), регулярные go/no-go gate’ы.

Связанные материалы: про ИИ-агентов — как AI PM работает с автономными системами, про промт-инженера — отдельная роль в команде ИИ-проекта, про ИИ-профессии без программирования — куда переходят PM без кода, про выбор курса по ИИ — если нужно прокачать навык системно. Стратегия для CEO — внедрение ИИ в компании. Смежная роль — нейросеть для аналитика. Кейсы — База идей.