Начать с наименее рискованного сценария с измеримым выходом — единственная тактика, которая стабильно работает в корпоративном контексте. Звучит банально, но на практике большинство команд делают наоборот: берутся за самый амбициозный кейс («заменим колл-центр», «автоматизируем весь документооборот»), тратят полгода на пилот и получают негативный результат, который на несколько лет тормозит все последующие инициативы.

Как выбрать первый сценарий

Хороший первый use case обладает тремя свойствами: данные уже существуют и доступны, результат поддаётся количественной оценке, цена ошибки невысока. Под эти критерии попадают задачи классификации входящих обращений, извлечения структурированных данных из документов, автогенерации черновиков типовых текстов (коммерческих предложений, ответов на запросы, внутренних сводок).

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

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

Для российских компаний дополнительный параметр отбора — требования к локализации данных. Задачи, где обрабатываются персональные данные граждан РФ, автоматически попадают под 152-ФЗ и требуют хранения данных на серверах в России. Это сужает выбор облачных провайдеров до тех, кто работает из российских ЦОД: Yandex Cloud, SberCloud, Selectel, MTS Cloud.

Build vs buy и API vs self-hosted

Решение «строить самим или покупать» в контексте ИИ распадается на два вложенных вопроса: использовать ли готовую модель (foundation model) через API или развернуть её собственно, и писать ли прикладную логику самостоятельно или использовать платформу.

API-доступ к модели — самый быстрый путь к работающему прототипу. Для большинства задач классификации и генерации текста GPT-4o, Claude 3.5 Sonnet или YandexGPT через API дают результат, сопоставимый с дообученной специализированной моделью, при несопоставимо меньших первоначальных затратах. Проблема API — зависимость от внешнего провайдера, сложность с передачей чувствительных данных и переменная задержка.

Self-hosted развёртывание оправдано в нескольких случаях: данные не могут покидать периметр (банки, госструктуры, медицина), объём запросов настолько высок, что собственный инференс дешевле API при горизонте 12+ месяцев, или требуется дообучение (fine-tuning) на специфическом корпусе. Для self-hosted в России основные варианты — открытые модели (LLaMA 3, Mistral, Qwen) на собственном железе или через Yandex DataSphere, а также GigaChat API от Сбера, который работает полностью из российской инфраструктуры.

Промежуточный вариант — managed inference: компания арендует GPU-мощности у облачного провайдера и запускает на них выбранную open-weight модель. Это снимает проблему обслуживания железа, сохраняет контроль над данными и позволяет масштабировать нагрузку. Selectel GPU Cloud и аналогичные предложения других российских провайдеров покрывают этот сценарий.

По прикладной логике: низкоуровневая разработка (прямые вызовы API, собственные промпты, собственный RAG) даёт максимальный контроль и минимальную стоимость при масштабировании, но требует ML-инженерных компетенций. Платформы наподобие LangChain, LlamaIndex или отечественных решений ускоряют старт, но добавляют слой абстракции, который при сложных кейсах становится источником проблем.

Стоимость: цена за токен, инференс, совокупные затраты

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

Прямые затраты на инференс зависят от модели и объёма. Для ориентира: GPT-4o стоит около $2,50 за миллион входящих токенов и $10 за миллион исходящих (цены меняются). Claude 3.5 Sonnet — $3/$15 соответственно. Для задач с большим объёмом дешевле смотреть на модели меньшего класса: GPT-4o mini ($0,15/$0,60), или открытые модели на арендованном GPU. Миллион токенов — это примерно 750 тысяч слов, то есть небольшой роман. Для корпоративного use case с тысячей документов в день это вполне достижимые цифры.

Скрытые затраты, которые часто не попадают в первоначальный расчёт:

  • Разработка и интеграция: написание промптов, построение пайплайна, интеграция с внутренними системами — часто 60–70% от суммарного бюджета первого года.
  • Верификация и контроль качества: для большинства задач нужен human-in-the-loop хотя бы на этапе пилота. Это время сотрудников.
  • Хранение и обработка данных: векторные базы данных (Qdrant, Weaviate, pgvector), препроцессинг документов, логирование запросов.
  • Мониторинг и поддержка: модели дрейфуют — то, что работало в феврале, может деградировать к июлю без изменений в коде.

При self-hosted развёртывании добавляются затраты на GPU: A100 80GB стоит в аренду от $2–3 в час у западных провайдеров, российские предложения в пересчёте сопоставимы. Для постоянной нагрузки имеет смысл считать ROI от покупки собственных карт, но порог входа высок — одна A100 стоит от 3 до 5 млн рублей на вторичном рынке.

Измерение отдачи и безопасность данных

ROI от ИИ-внедрения считается через одну из трёх метрик: экономия времени сотрудников (FTE-эквивалент), снижение стоимости единицы операции, рост качества выхода (конверсия, NPS, точность классификации). Ни одна из них не работает без базовой линии — замера текущего состояния до внедрения. Это звучит очевидно, но на практике базовую линию фиксируют меньше половины команд, что делает оценку результата невозможной.

Горизонт окупаемости для корпоративных ИИ-проектов в реалистичном сценарии — от 9 до 18 месяцев для хорошо подобранного use case. Ожидания «отобьётся за квартал» почти никогда не оправдываются из-за недооценки интеграционных затрат.

Безопасность данных — не финальный чеклист, а архитектурное решение, которое принимается в начале. Ключевые вопросы: попадают ли данные в обучающую выборку провайдера (большинство enterprise-тарифов это исключают, но нужно проверять явно в договоре), кто имеет доступ к логам запросов, как обеспечивается изоляция тенантов при multi-tenant развёртывании.

Для задач с персональными данными минимальная мера — деперсонализация перед отправкой в модель. Это не всегда возможно (иногда контекст требует имён или реквизитов), поэтому альтернатива — self-hosted модель в закрытом контуре. Yandex Foundation Models и GigaChat предлагают варианты развёртывания в изолированной среде для enterprise-клиентов, что закрывает вопрос трансграничной передачи данных.

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

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