Каждый второй стартап сейчас где-то в середине разговора произносит: «и вот тут мы добавим ИИ». Звучит хорошо. Потом начинается спринт, в котором ИИ «добавляется» три месяца, а в продакшн так и не уходит. Либо уходит, но с ключом прямо в мобильном приложении и без обработки ошибок.

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

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

Шаг 1. Выбрать одну узкую задачу

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

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

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

Шаг 2. Собрать 20-30 реальных примеров

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

Это не «тестовый датасет» в академическом смысле. Это просто: вот реальный тикет от пользователя — правильная категория «баг с оплатой». Вот карточка товара — вот описание, которое одобрил бы редактор.

Зачем это нужно прямо сейчас, а не потом? Потому что без примеров вы будете оценивать модель интуитивно, а интуиция здесь обманывает. Модель может хорошо отвечать на красивые демо-запросы и плохо справляться с грязными, реальными данными вашего продукта.

Шаг 3. Выбрать модель под задачу и проверить её на своём наборе

Модели сильно отличаются по характеру: одни лучше рассуждают и следуют инструкциям, другие быстрее и экономичнее по расходу баланса, третьи хороши в коде или структурированном выводе.

Грубое правило: для рутинных задач с чётким форматом (классификация, краткое резюме, извлечение полей) берите лёгкие модели — Gemini Flash, DeepSeek, GPT-4o-mini. Они тратят баланс заметно меньше, а качество на простых задачах часто неотличимо от тяжёлых. Для сложных рассуждений, длинного контекста, генерации кода — Claude Sonnet, GPT-5.5 и выше. Claude Opus и GPT-5.6 — это тяжёлая артиллерия, которая тратит баланс заметно быстрее; их имеет смысл подключать там, где качество критично и задача это оправдывает.

Прогоните две-три модели на своих 20-30 примерах. Посчитайте процент правильных ответов. Выберите ту, которая даёт приемлемое качество при разумном расходе. Это займёт несколько часов, но сэкономит недели разочарований в продакшне.

Для подключения к разным моделям через единый интерфейс удобен OpenAI-совместимый шлюз. NeuroZal API даёт доступ к 46 моделям — OpenAI, Anthropic, Google, xAI, DeepSeek и другим — через один base_url: https://api.neurozal.ru/v1. Один ключ, один SDK, весь каталог.

Важно: NeuroZal API — это ключ для программ, редакторов кода, ботов и автоматизации. Это не аккаунт ChatGPT с логином и паролем, он не подключается в мобильном приложении ChatGPT и не заменяет подписку Plus. Модель выбирает разработчик: один ключ открывает весь каталог.

Шаг 4. Завернуть вызов в свой бэкенд. Ключ — не в клиенте

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

Правило простое: API-ключ живёт только на сервере. Клиент обращается к вашему бэкенду, бэкенд — к модели. Точка.

Минимальная схема:

Клиент → ваш API-эндпоинт → NeuroZal API → модель → ответ обратно

На вашем эндпоинте вы контролируете: кто может делать запросы, сколько запросов в единицу времени, что именно уходит в промпт, что возвращается пользователю. Без этого слоя вы не контролируете ничего.

Промпт тоже держите на бэкенде. Если он зашит в мобильное приложение или фронтенд, любое изменение — это релиз. Это медленно и неудобно. На бэкенде промпт можно поменять без деплоя клиента.

Шаг 5. Логировать запросы, токены и ошибки

Без логов вы слепы. Вы не знаете, какие запросы приходят, какие ответы даёт модель, где она ошибается, сколько тратится токенов и на что.

Минимальный набор для лога каждого запроса:

NeuroZal предоставляет журнал запросов в личном кабинете (https://api.neurozal.ru/panel) — там видно расход по каждому ключу. Но собственные логи на стороне приложения всё равно нужны: только вы знаете, какой запрос принадлежит какому пользователю и какому сценарию.

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

Шаг 6. Предусмотреть деградацию

Модель может быть недоступна. Может отвечать медленно. Может вернуть ответ, который не проходит вашу валидацию. Что в этот момент видит пользователь?

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

Таймауты обязательны. Если вы не поставили таймаут на запрос к модели, один зависший запрос может держать соединение открытым бесконечно. Устанавливайте разумный таймаут (обычно 15-30 секунд в зависимости от задачи) и обрабатывайте его явно.

Валидация ответа тоже нужна. Если вы ожидаете JSON с определёнными полями — проверьте, что он пришёл именно таким. Если ожидаете категорию из списка — проверьте, что модель вернула одну из допустимых категорий, а не что-то своё. Доверять ответу модели без проверки — это ещё одни грабли, о которых ниже.

Шаг 7. Выкатить на часть пользователей

Не запускайте ИИ-функцию сразу на всю аудиторию. Начните с малой доли — 5-10% пользователей или отдельный сегмент. Это даст реальные данные без риска испортить опыт всей базы.

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

После стабилизации расширяйте аудиторию. Если что-то пошло не так — откат на малую долю или полное отключение должны занимать минуты, не часы.

Таблица: этапы запуска ИИ-функции

Этап Что делаем Как понять, что этап пройден
1. Задача Формулируем одну конкретную функцию с чётким входом и выходом Задачу можно описать одним предложением, результат оценивает человек за секунду
2. Примеры Собираем 20-30 реальных пар вход/ожидаемый ответ Набор собран, ожидаемые ответы согласованы с командой
3. Модель Тестируем 2-3 модели на своём наборе, считаем точность Выбрана модель с приемлемым качеством, задокументирован выбор
4. Бэкенд Вызов к API идёт только через свой сервер, ключ не в клиенте Ключ нигде не фигурирует в клиентском коде, промпт на бэкенде
5. Логи Логируем запросы, токены, ошибки Есть дашборд или хотя бы файл логов с нужными полями
6. Деградация Есть таймауты, валидация ответа, фолбэк для пользователя Протестированы сценарии: таймаут, невалидный ответ, ошибка API
7. Выкатка Запуск на 5-10% аудитории с мониторингом метрик Функция работает у части пользователей, метрики собираются

Честные грабли: где обычно ломается

Ключ уехал в мобильное приложение

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

Нет обработки таймаутов

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

Нет лимитов на пользователя

Один активный пользователь может сгенерировать сотни запросов за минуту — случайно или намеренно. Без rate limiting вы не контролируете расход. Добавьте ограничение на количество запросов в единицу времени на уровне вашего бэкенда.

Промпт зашит в код и правится только релизом

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

Доверие к ответам модели без валидации

Модель может вернуть что угодно. Если вы ожидаете структурированный ответ — JSON, список, категорию из перечня — всегда проверяйте его перед использованием. Передавать непроверенный ответ модели напрямую в бизнес-логику или показывать пользователю без фильтрации — это путь к неприятным сюрпризам.

Итог: минимальный набор для запуска

Вот что нужно, чтобы выйти в продакшн с ИИ-функцией, не наступив на главные грабли:

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

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

Если вы на этапе выбора API-шлюза, посмотрите на NeuroZal API: единый ключ, 46 моделей, OpenAI-совместимый интерфейс. Личный кабинет и документация — на https://api.neurozal.ru/panel и https://neurozal.ru/docs. Вопросы — на support@neurozal.ru.