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

Что именно должна делать система, кому она поможет и какую бизнес-задачу решит — вопросы на потом. Главное, чтобы ИИ был.

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

Типовой разговор на старте выглядит примерно так:

— Хотим сервис с ИИ.
— Что он должен делать?
— Предлагать что-нибудь пользователям.
— Что именно и на основании каких данных?
— Давайте вы нам расскажете. Но ИИ нужен обязательно.

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

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

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

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

Хорошо, с рецептом разобрались. Но при чём здесь интернет-магазин? Представим, что покупатель пишет в чат консультанта на сайте: «Нужен телевизор до 60 тысяч рублей для светлой комнаты — чтобы не бликовал и было удобно смотреть кино». Сайт принимает сообщение, находит в каталоге телевизоры с подходящей ценой и наличием, затем отправляет нейросети запрос покупателя вместе с характеристиками найденных моделей. Нейросеть сравнивает варианты и простыми словами объясняет, чем они отличаются и какой лучше соответствует пожеланиям.

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

Теперь посмотрим, какие задачи нейросеть может решать в e-commerce.

В интернет-магазинах есть три распространенных сценария использования ИИ:

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

ИИ умеет многое, но сам по себе перечень возможностей ещё не определяет, что нужно конкретному проекту. Поэтому дальше стоит перейти от вопроса «что умеет нейросеть?» к вопросу «какую проблему бизнеса она должна решить?».

Есть простой тест. Уберите из постановки задачи слова «ИИ» и «нейросеть». Если после этого ничего не осталось — задачи пока нет. Например:

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

• с какими системами предстоит интеграция;
• где хранятся характеристики товаров, цены и остатки;
• к какому готовому API подключаемся;
• кто выбирает модель и отвечает за её работу, как предполагается оплачивать нейросеть (к сожалению, лучшие решения сейчас — зарубежные, а оплатить их без танцев с бубном никак не получится, а через бухгалтерию компании и подавно);
• какие данные разрешено передавать нейросети (это важно — трансграничная передачи личных данных пользователей тот еще квест);
• что увидит пользователь при ошибке (а ошибки при такой интеграции могут быть крайне разнообразны);
• кто после запуска контролирует расходы, качество и доступность сервиса.

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

Представим интернет-магазин, где половина товаров лежит не в тех категориях, характеристики заполнены через одну, поиск выдаёт чайники по запросу «кофемолка», а условия возврата спрятаны в PDF 2019 года. Добавим туда AI-консультанта — и он с энтузиазмом начнёт пересказывать покупателям весь этот хаос:

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

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

Никто не пишет нейросети с нуля. Для отдельного бизнеса это неподъемная и бессмысленная задача. Так что для разработчика готовая нейросеть — это внешний API: код сайта отправляет во внешнюю систему запрос и получает ответ. Само подключение обычно не самая сложная часть работы. Основная разработка начинается до отправки запроса и продолжается после получения ответа.

Допустим, покупатель пишет в чате интернет-магазина: «Нужен телевизор до 60 000 рублей, диагональю не больше 50 дюймов, с доставкой завтра».

Один из возможных вариантов работы выглядит так:

В этой схеме код сайта обращается к нейросети дважды:

—  Сначала он передаёт сообщение покупателя и просит выделить условия поиска: цену, диагональ и срок доставки. Получив эти параметры, код ищет подходящие товары в каталоге. Затем он отправляет нейросети сведения о найденных позициях, чтобы она сравнила их и подготовила ответ.

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

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

Именно эта логика вокруг нейросети и составляет основную часть разработки. Со стороны сайта мы определяем, какие данные можно отправить в API нейронки, составляем инструкции для обработки запроса, проверяем полученный ответ и предусматриваем действия на случай ошибки. Если нейросеть должна работать с заказами, код сайта также проверяет права пользователя и определяет, какие операции можно выполнить автоматически, а какие потребуют подтверждения.

Объём этой работы зависит от задачи. Для подготовки «черновика» описания товара достаточно передать характеристики и вернуть текст на проверку сотруднику. Для AI-консультанта, который работает с каталогом, заказами и персональными данными, понадобятся дополнительные интеграции, проверки и ограничения.

Отправить запрос в API — относительно простая задача. Создать на его основе надёжную функцию для интернет-магазина — уже полноценная разработка.

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

Ошибки тоже бывают разными. Неверно подобрать цвет футболки неприятно. Придумать несуществующую скидку — уже дороже. Отменить не тот заказ — совсем другой уровень последствий.

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

Полностью исключить ошибки нейросети нельзя. Но можно ограничить их вероятность и последствия:

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

Поэтому обещание «ИИ отвечает правильно» должно настораживать. Грамотный вопрос звучит иначе: где он может ошибиться, сколько такая ошибка будет стоить бизнесу и что система сделает в этом случае.

Когда задача определена, остаётся выбрать один из двух путей: готовый внешний API или модель в контуре клиента.

Быстрее и дешевле на старте: клиент выбирает провайдера и модель, а мы связываем готовый API с сайтом и бизнес-системами.

Плюсы:

• быстрый старт MVP;
• меньше вложений в инфраструктуру;
• провайдер обслуживает вычислительные мощности и обновления;
• можно сравнивать доступные модели.

Минусы и нюансы:

• расходы на токены или другие единицы тарификации;
• лимиты, задержки и возможная недоступность API;
• зависимость от правил модерации и условий платформы;
• изменение стоимости и доступности сервиса;
• вопросы передачи данных внешнему провайдеру;
• разное качество ответов у разных моделей.

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

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

Плюсы:

• данные могут оставаться внутри контура клиента;
• больше контроля над доступностью и правилами обработки;
• возможность глубокой кастомизации силами команды клиента;
• меньше зависимости от публичного API.

Минусы:

• дорогое оборудование или аренда мощностей;
• эксплуатация, безопасность и обновление моделей;
• необходимость профильных специалистов;
• ответственность клиента за качество и скорость.

Свой сервер не гарантирует автоматически лучшее качество, бесплатные запросы, высокую скорость и полную безопасность. Перенести модель в свой контур — не избавиться от проблем, а забрать их себе.

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

Самой нейросети всё равно, на чём работает сайт. Важнее, может ли существующая платформа получить нужные данные, отправить запрос в API, проверить ответ и безопасно показать его пользователю.

Простую генерацию контента или AI-консультанта можно реализовать на уже существующем сайте, например на Битриксе. Если сайт на шаблоне или конструкторе, например на Tilda, можно разместить интерфейс чата, но работу с каталогом, проверку данных и обращение к API придётся вынести во внешний сервис.

Laravel, или другой фреймворк понадобятся, если AI-функция объединяет несколько систем, обрабатывает много запросов, выполняет фоновые задачи или требует сложного разграничения прав и подробной истории действий.

Поэтому переезжать на новый сайт только ради нейросети не нужно. Стек выбирают под задачу и дальнейшее развитие всего проекта, а не под само наличие ИИ.

Много лет мы развиваем SingularityApp — мощный планировщик задач. В нём можно планировать день, управлять задачами и проектами, следить за привычками, работать с календарём, канбаном и диаграммой Ганта — и это далеко не всё.

Развитие SingularityApp, конечно, не могло обойти тему искусственного интеллекта. Но начали мы не с вопроса «куда добавить нейросеть», а с задач пользователей, которые можно упростить с её помощью. В результате, внутри приложения появилось несколько AI-сценариев — с разными возможностями и степенью самостоятельности.

Самый простой сценарий — AI-действия. Они помогают доработать конкретную задачу: подобрать для неё время, уточнить формулировку по SMART, составить описание, разбить задачу на подзадачи или подготовить чек-лист. Перед применением изменений пользователь может проверить и подтвердить результат.

Если пользователь пока не готов создавать или изменять задачи, можно перейти в режим Ask. Ассистент объясняет функции SingularityApp, помогает с планированием и позволяет провести мозговой штурм. Такой режим помогает справиться со «страхом чистого листа»: когда идея ещё не превратилась в понятную цель или задачу, её можно сначала обсудить с ассистентом, наметить план и подобрать формулировки. При этом Ask не изменяет задачи и проекты пользователя.

Режим Agent даёт больше возможностей. В отличие от AI-действий, привязанных к конкретной задаче, он может работать с разными данными внутри приложения: создавать и редактировать задачи и проекты, разбивать большие задачи на подзадачи, добавлять описания и чек-листы, искать нужные дела и анализировать продуктивность. Agent также помогает с расписанием: находит свободные промежутки для встреч и задач, замечает пересечения по времени и предлагает другие варианты. Для выполнения действий ему требуется разрешение пользователя, а внесённые изменения можно отменить.

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

Чат-бот отвечает на основании материалов из базы знаний и публичного бэклога SingularityApp. Он не ищет информацию в интернете и не использует сторонние источники. Если в базе знаний появляется новая инструкция или обновляется существующая, в течение дня эти изменения становятся доступны и чат-боту.

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

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

Для обработки запросов можно использовать модели, доступные через SingularityApp, или подключить собственного AI-провайдера. В режиме Auto приложение само подбирает модель в зависимости от задачи. При выборе другой модели могут измениться качество ответа, скорость работы и стоимость запросов.

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

Работать с данными SingularityApp можно не только через встроенный ассистент. Пользователь может подключить приложение к внешнему AI-чату, который поддерживает MCP.

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

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

Несмотря на различия между этими функциями, проектировали их по одному принципу.

Поэтому «внедрить ИИ» — слишком общая постановка. Даже в экосистеме одного продукта AI-действия, Ask, Agent, чат-бот на сайте и MCP решают разные задачи, работают с разными данными и требуют отдельного проектирования.

Перед тем как выбирать нейросеть и запрашивать оценку разработки, нужно ответить на несколько вопросов.

1. Какую проблему решаем?
Опишите её без слов «ИИ» и «нейросеть». Например: не «хотим AI-консультанта», а «покупатели не понимают различия между похожими товарами и обращаются в поддержку».

2. Точно ли здесь нужна нейросеть?
Иногда задачу быстрее и надёжнее решают фильтры, поиск, шаблон ответа, обычный алгоритм или дополнительное поле в карточке товара.

3. Какие данные понадобятся?
Определите, где хранятся характеристики, цены, остатки, заказы и правила доставки. Отдельно проверьте, кто обновляет эти сведения и насколько им можно доверять.

4. К какому готовому API подключаемся?
Нужно выбрать AI-платформу и модель, проверить стоимость, ограничения, доступность API и правила работы с данными. Также важно заранее определить, кто оплачивает сервис и отвечает за его дальнейшую настройку и доступность.

5. Что нейросети разрешено делать?
Ответить на вопрос и изменить заказ — не одно и то же. Чем серьёзнее последствия, тем больше проверок и подтверждений должно быть в системе.

6. Какие данные можно передавать?
Персональные, коммерческие и внутренние данные требуют отдельного внимания. Этот вопрос нужно решить до интеграции, а не после первого запроса реального пользователя.

7. Как будем оценивать результат?
Соберите примеры настоящих запросов и определите критерии: точность подбора, количество обращений в поддержку, скорость подготовки контента, конверсия или другой измеримый показатель.

8. Что произойдёт при ошибке?
Пользователь должен получить понятное сообщение, возможность повторить запрос или обратиться к человеку. Сайт не должен переставать выполнять основную функцию из-за недоступности AI-провайдера.

9. Как ограничим первый запуск?
Начните с одного сценария, небольшой группы пользователей и действий с невысокой ценой ошибки. После этого можно измерить результат и решить, стоит ли развивать функцию дальше.

Хороший MVP должен показать, решает ли конкретная AI-функция проблему пользователей и приносит ли бизнесу результат, который оправдывает разработку и дальнейшую поддержку.

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

Если пока понятно только то, что «в 2026 году у всех должен быть ИИ», возможно, первая полезная функция искусственного интеллекта — помочь сформулировать, зачем он вам нужен.