Почему ИИ-проекты не дают результата: 7 частых проблем внедрения

Первая ошибка на старте — применять большие языковые модели (LLM) там, где нужен обычный алгоритм или сначала требуется навести порядок в базовых процессах. Когда правила обработки заявок существуют только в головах опытных сотрудников, а в CRM-системе поля заполняются в свободной форме без единого стандарта, нейросеть не исправит ситуацию. Она лишь масштабирует существующую неразбериху.

Кроме того, генеративный ИИ плохо подходит для операций, где требуется стопроцентная воспроизводимость по жестким правилам. Показателен подход крупных технологических игроков. В сообщении компании «СберТех» от 23 сентября 2026 года о внедрении мультиагентной обработки клиентских обращений в Сбере (на базе Platform V Flow и GigaChat) описана четкая последовательность: сначала в компании заменили CRM и автоматизировали процессы с детерминированной логикой, и только с 2025 года добавили LLM для работы со свободным текстом. Это сообщение поставщика решения, а не независимый аудит, но сама архитектурная логика здесь универсальна.

Другая крайность — называть генеративным ИИ любые инструменты автоматизации или разрабатывать собственного LLM-агента для задачи, где давно есть готовое промышленное решение. Например, официальный каталог 1С относит распознавание первичных документов по сканам и фото к применению ИИ в бухгалтерии (каталог 1С). При этом штатный сервис «1С:Распознавание первичных документов» (1С:РПД) решает вполне конкретную прикладную задачу: поддерживает счета, накладные ТОРГ-12, акты, счета-фактуры, УПД, УКД и кассовые чеки (документация 1С:ИТС). Процесс в нем выстроен строго: загрузить скан, распознать, проверить результат силами сотрудника и создать документ в учетной базе. Пытаться заменить такой специализированный OCR-конвейер самописным ботом с генеративной моделью — значит потратить бюджет на разработку и получить менее предсказуемый результат там, где бухгалтерии нужна строгая проверка перед проведением документа.

Прежде чем выбирать модель, разделите процесс на три части:

• Маршрутизация и проверки по четким правилам — решаются обычным кодом, скриптами и штатными средствами учетных систем.
• Стандартизированное распознавание форм — закрывается профильными сервисами (например, 1С:РПД с обязательным контролем со стороны человека).
• Работа с неструктурированным текстом, резюмирование и ответы на нестандартные вопросы — реальная зона ответственности LLM.

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

Причина кроется в самой механике векторного поиска. Когда документы компании загружают в векторную базу данных — например, в Qdrant, официальная документация которого разделяет векторы, полезную нагрузку (payload), коллекции, индексы и фильтрацию (документация Qdrant), — система ищет фрагменты, математически близкие к запросу пользователя. Но наличие похожего вектора в базе не доказывает истинность итогового ответа и не означает, что найденный кусок регламента актуален именно для этой ситуации. Чтобы поиск работал точнее, векторную близость приходится сочетать с фильтрами по метаданным и классическим текстовым поиском (гибридный поиск), а сами документы — регулярно чистить от устаревших версий.

Даже при грамотной сборке промышленные системы не показывают стопроцентной автономии. Хороший ориентир из публичной практики — кейс Yandex Cloud о внедрении ИИ-помощника в компании «Инфосистемы Джет» (опубликован 13 февраля 2025 года, проверен 3 ноября 2026 года на сайте Yandex Cloud). Пилот занял полтора месяца: решение классифицирует запрос, ищет информацию по базе знаний с использованием Object Storage и OpenSearch, а часть ответов передает сотруднику для проверки. В разделе результатов пилота зафиксированы три отдельные метрики:

• до 30% обращений обрабатываются автоматически;
• точность классификации около ста типов обращений составляет 75%;
• корректность ответов LLM достигает 80%.

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

Аналогичная проблема возникает в речевой аналитике. Когда компании внедряют сервисы транскрибации и анализа звонков, руководители порой ждут от ИИ готового вердикта: кто из менеджеров виноват в потере клиента и что именно чувствовал покупатель. Однако документация профессиональных инструментов проводит четкую границу между обработкой сигнала и бизнес-выводами. Например, Yandex SpeechKit преобразует речь в текст (синхронный режим на проверенной странице рассчитан на одноканальное аудио до 30 секунд, асинхронный — на многоканальные записи до 4 часов; документация SpeechKit). Более сложный продукт Yandex SpeechSense для контактных центров добавляет к распознаванию статистику диалога, поиск ключевых слов и формирование резюме с помощью YandexGPT Pro (документация SpeechSense). Но ни выделение ключевых слов, ни автоматическая сводка разговора не являются доказательством реальных эмоций человека, виновности оператора или истинной причины отказа от покупки. Выводы о качестве работы сотрудника требуют отдельной методической проверки.

Чем уже и конкретнее сформулирована задача на старте, тем выше шанс довести ее до ума. Так, команда Сбера в своем рассказе на Habr от 26 июня 2024 года (статья на Habr) описывала создание тренажера для клиентских менеджеров, который анализирует расшифровки разговоров (полученные через SaluteSpeech) и дает рекомендации с помощью GigaChat. Примечательна именно инженерная дисциплина на этапе MVP: разработчики не пытались оценить всю работу продавца сразу, а ограничили задачу только отработкой возражений и сфокусировались на сравнении разных подходов к промптам.

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

Разберем это на конкретных проверенных тарифах российских платформ (данные проверены 2–3 ноября 2026 года):

1. Генерация текста по API. В официальном прайсе Yandex AI Studio (тарифы AI Studio, проверено 3 ноября 2026 года) в синхронном режиме цены за 1000 токенов (с НДС) составляют: для YandexGPT Lite — 0,2 ₽ на вход и 0,2 ₽ на выход; для YandexGPT Pro 5.1 — 0,8 ₽ на вход и 0,8 ₽ на выход; для Alice AI LLM Flash — 0,1 ₽ на вход и 0,2 ₽ на выход (правила для кеширования и встроенных инструментов тарифицируются отдельно). Сделаем условный расчет: допустим, ваш внутренний бот за месяц обработал объем запросов, равный 1 млн входных и 200 тыс. выходных токенов через YandexGPT Lite. Чистая стоимость генерации составит (1000 × 0,2 ₽) + (200 × 0,2 ₽) = 240 ₽. Цифра выглядит копеечной, но она не включает хранение векторного индекса, работу оркестратора, логирование и труд инженеров.
2. Нюансы контрактации у разных провайдеров. Нельзя механически переносить цены одной модели на другую или ориентироваться на старые обзоры. Например, в документации GigaChat API (тарифы для юрлиц, страница обновлена 7 октября, проверена 2 ноября 2026 года) условия разделились по категориям клиентов. Для действующих клиентов «СалютДевайсы» / «Салют для Бизнеса» по схеме синхронного pay-as-you-go за 1000 токенов с НДС действуют ставки: Lite — 0,065 ₽, Pro — 0,5 ₽, Max — 0,65 ₽ (при фактическом использовании минимальная сумма составляет 600 ₽ в месяц, при отсутствии трафика плата не взимается). А вот для новых клиентов с 1 сентября 2026 года оплата идет через платформу cloud.ru, и автоматически переносить на них прежние тарифы нельзя — условия нового подключения необходимо запрашивать отдельно.
3. Речевая аналитика против простой расшифровки. В сервисе распознавания речи Yandex SpeechKit (тарифы SpeechKit, проверено 3 ноября 2026 года) стандартное асинхронное распознавание стоит 0,1515 ₽ с НДС за 15 секунд двухканального аудио (минимум 15 секунд, далее посекундно; число каналов округляется вверх до четного; синхронный и потоковый режимы стоят 0,1626 ₽ за 15 секунд одноканального аудио с округлением фрагментов вверх до 15 секунд, отложенное асинхронное — 0,0381 ₽). Выполним условный расчет для 1000 двухканальных записей звонков по 300 секунд (5 минут) каждая: 1000 × (300 / 15) × 0,1515 ₽ = 3030 ₽. Но 3030 ₽ — это плата исключительно за превращение звука в сырой текст. Если же бизнесу нужна готовая аналитическая система с дашбордами, рабочими местами DataLens и обработкой части записей ИИ-ассистентом, то в профильном сервисе Yandex SpeechSense (тарифы SpeechSense, проверено 3 ноября 2026 года) пакетные тарифы с НДС за календарный месяц выглядят иначе: Basic (10 000 минут) — 45 000 ₽, Standard (30 000 минут) — 90 000 ₽, Advanced (100 000 минут) — 260 000 ₽. При этом даже внутри пакета обработка AI-ассистентом распространяется только на определенную долю аудиозаписей согласно условиям тарифа, а не на весь трафик безлимитно.
4. Скрытый расход в low-code оркестраторах. Многие команды собирают прототипы на платформах автоматизации n8n или Make, но путают их единицы тарификации. В n8n (тарифы n8n, проверено 2 ноября 2026 года) при годовой оплате облачный тариф Starter стоит эквивалент 20 евро в месяц за 2500 исполнений сценария (workflow executions), а Pro — 50 евро в месяц за 10 000 исполнений. В свою очередь, платформа Make (тарифы Make, проверено 2 ноября 2026 года; бесплатный план включает 1000 кредитов в месяц) считает расход в кредитах (credits), где большинство действий отдельных модулей внутри сценария списывает по одному кредиту, а некоторые ИИ-функции — больше (исключение составляют Router и ряд обработчиков ошибок). Если ваш сценарий обработки одного письма состоит из 15 шагов, в n8n это будет одно исполнение workflow, а в Make — полтора десятка кредитов. Кроме того, для российского юрлица оплата зарубежных облачных подписок несет очевидные платежные и санкционные риски, поэтому на практике компании чаще разворачивают self-hosted версию n8n (продукт распространяется по fair-code лицензии; документация n8n) на собственных серверах и отдельно оплачивают инфраструктуру.
5. Услуги интеграторов. Стоимость работы разработчиков многократно превышает расходы на API в первые месяцы. Например, в публичном прайсе подрядчика Goose AI (цены Goose AI, проверено 2 ноября 2026 года) внедрение готового агента из каталога оценивается в 150 000–300 000 рублей (включая настройку сценариев, интеграции и тестирование). Это предложение конкретного игрока, а не среднерыночный норматив, но оно показывает порядок стартовых затрат на сборку даже типового решения.

Чтобы бюджет не преподнес сюрпризов, перед стартом проекта составьте полную смету по всем уровням архитектуры:

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

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

Открытые инструменты для локального инференса — такие как популярный C/C++ проект llama.cpp (репозиторий llama.cpp, проверено 2 ноября 2026 года) — действительно позволяют запускать языковые модели без отчислений внешним API. Однако «бесплатность» кода компенсируется требованиями к видеопамяти (VRAM) и вычислительным ресурсам.

Для предварительной грубой оценки того, сколько памяти займут только сами веса модели, используют базовую формулу: число параметров × битность квантования / 8. Например, для относительно небольшой модели на 8 миллиардов параметров в 4-битном квантовании расчет весов дает: 8 млрд × 4 бита / 8 = 4 млрд байт (около 3,73 GiB). Но на практике реальная потребность в видеопамяти заметно выше: помимо самих весов в память нужно поместить KV-кеш (контекст диалога, который растет с каждым длинным документом и параллельным пользователем), служебные буферы и накладные расходы квантования. А если вы выбираете архитектуру класса MoE (Mixture of Experts), в память приходится загружать все размещаемые веса модели, а не только число параметров, активных для одного токена.

Попытка запустить более крупную корпоративную модель быстро упирается в физические пределы оборудования. Даже флагманская потребительская видеокарта NVIDIA GeForce RTX 5090 имеет официальный объем памяти 32 GB GDDR7 (спецификация NVIDIA, проверено 2 ноября 2026 года). Этого объема хватит для компактных и средних квантованных моделей с умеренным контекстом, но само по себе наличие 32 ГБ не гарантирует ни запуска тяжелых корпоративных LLM, ни приемлемой скорости генерации при одновременной работе десятка сотрудников.

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

• vGPU L40S (разделяемый виртуальный ускоритель) — от 299 ₽ в сутки;
• GPU Passthrough (выделенная карта в линейке L4 / RTX 4090 / RTX 5090 / L40S, где конкретная цена и доступность зависят от выбранной модели) — от 1150 ₽ в сутки.

Сделаем условный расчет на 30 суток при неизменной базовой посуточной ставке: минимальная конфигурация с vGPU обойдется от 8970 ₽, а сервер с выделенным GPU по нижней границе линейки — от 34 500 ₽ за 30 дней (при этом бесплатного тестового периода нет, минимальный оплачиваемый срок — 1 сутки, а объем выделенной видеопамяти, наличие карт и налоговые условия нужно проверять под конкретный заказ). Добавьте к этому зарплату MLOps-инженера, который должен настраивать окружение, следить за отказами и балансировать очередь запросов, — и выяснится, что при небольшом и среднем потоке задач защищенное российское облако по API обходится бизнесу в десятки раз дешевле собственного GPU-контура.

Юридический блок в ИИ-проектах обычно страдает от двух крайностей: либо бизнес бездумно отправляет клиентские базы в зарубежные нейросети, либо служба безопасности блокирует вообще любые облачные технологии, требуя установки закрытого сервера в офисе. Чтобы не нарушить Федеральный закон № 152-ФЗ «О персональных данных» и не парализовать проект ложными запретами, важно опираться на актуальные формулировки первоисточника (ниже нормы приведены по текстам 152-ФЗ, опубликованным на официальных ресурсах Минтруда России и Росгвардии, проверено 3 ноября 2026 года).

Вот пять практических узлов, на которых чаще всего спотыкаются компании при внедрении ИИ:

1. Локализация и трансграничная передача данных. Часть 5 статьи 18 152-ФЗ (в редакции Федерального закона № 23-ФЗ от 28.02.2025) запрещает при сборе персональных данных граждан РФ осуществлять запись, систематизацию, накопление, хранение, уточнение (обновление, изменение) и извлечение данных с использованием баз данных, находящихся за пределами территории РФ, за исключением предусмотренных законом случаев. Опасно руководствоваться устаревшими неформальными трактовками вроде «достаточно просто положить первую копию базы в России и дальше делать что угодно», но столь же неверно считать любую последующую трансграничную передачу абсолютно невозможной при любых обстоятельствах. При этом статья 12 требует подавать отдельное предварительное уведомление регулятора о намерении осуществлять трансграничную передачу персональных данных (обычное уведомление об обработке ПДн его не заменяет, и сам факт отправки уведомления не снимает возможных ограничений со стороны уполномоченного органа).
2. Оформление отношений с облачным провайдером или подрядчиком. Статья 6 допускает разные правовые основания обработки данных, а не только согласие субъекта. Однако если вы передаете обработку внешнему лицу (например, облачной платформе или интегратору), требуется корректно оформленное поручение оператора с соблюдением установленных законом требований к договору и конфиденциальности. Если же процесс опирается на согласие, помните: статья 9 требует оформлять согласие на обработку персональных данных отдельно от иных информации и документов, которые подтверждает или подписывает субъект. При этом ни одно согласие клиента не отменяет обязанностей компании по локализации и защите данных.
3. Иллюзия быстрого «обезличивания» промптов. Разработчики часто считают, что если перед отправкой текста в внешнюю LLM удалить из него фамилию клиента регулярным выражением, данные становятся обезличенными. Однако статья 3 закона определяет обезличивание как действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту. На практике, если в тексте обращения остались ИНН физлица, номер телефона, адрес доставки или уникальный узнаваемый контекст сделки, связь с конкретным человеком сохраняется.
4. Автоматический скоринг и права человека. Компании активно пытаются внедрять ИИ для фильтрации резюме кандидатов или принятия решений по клиентским претензиям. Между тем статья 16 ограничивает принятие решений, порождающих юридические последствия в отношении субъекта персональных данных или иным образом затрагивающих его права и законные интересы, на основании исключительно автоматизированной обработки (за исключением случаев, предусмотренных законом). Это не означает полного запрета на любое предварительное ранжирование анкет в HR, но требует, чтобы итоговое юридически значимое решение не принималось роботом в одиночку, а конкретный регламент был выверен с юристами.
5. Миф о том, что «локальная модель решает все проблемы с 152-ФЗ». Установка собственной LLM на сервер внутри контура компании снимает вопрос трансграничной передачи в внешний API, но сама по себе не подтверждает соблюдение закона. Статьи 18.1 и 19 требуют от оператора целого комплекса организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах (включая локальные акты, разграничение доступа, учет машинных носителей и оценку вреда). Точно так же использование российского облачного API требует изучения документации провайдера: например, в документации Yandex AI Studio (раздел документации AI Studio, проверено 2 ноября 2026 года) предусмотрены отдельные правила хранения данных и возможность управления логированием запросов, которые нужно правильно настроить и закрепить договорно.

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

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

Типичный пример — интеграция с экосистемой 1С. На рынке часто можно услышать обещания «быстро подключить любую нейросеть к вашей 1С по стандартному протоколу». В реальности универсального готового коннектора любой LLM к любой кастомизированной конфигурации не существует. Да, официальная технологическая платформа «1С:Предприятие» поддерживает произвольные HTTP-сервисы (описание платформы 1С, проверено 2 ноября 2026 года): разработчик может задать шаблоны URL, прописать обработчики HTTP-методов и управлять телом, заголовками и кодом ответа. Точно так же в индустрии развивается открытый стандарт MCP (Model Context Protocol, архитектура MCP, проверено 2 ноября 2026 года; поддержка MCP Hub также представлена в документации Yandex AI Studio) и механизмы вызова внешних функций (function calling), доступные, например, в GigaChat API.

Однако ни HTTP-сервисы в 1С, ни архитектура MCP (связывающая host, client и server через транспорт stdio или Streamable HTTP для передачи инструментов, ресурсов и промптов) не создают интеграцию сами по себе. Чтобы ИИ-агент безопасно проверил остатки на складе или создал черновик счета, программисту 1С и ИИ-инженеру нужно совместно:

• спроектировать и написать конкретные методы прикладного API на стороне 1С;
• реализовать MCP-сервер или промежуточный бэкенд;
• настроить ролевую модель и права доступа, чтобы линейный менеджер через промпт к боту не смог выгрузить закрытую финансовую отчетность всей компании;
• предусмотреть обработку ошибок и блокировок базы данных.

Схожие грабли ждут команды при выборе клиентского интерфейса. Многие привыкли ориентироваться на механику создания ботов в Telegram через BotFather и закладывают в план проекта пару часов на публикацию бота в российских корпоративных и пользовательских платформах. Но у каждой площадки свои регламенты. Например, согласно официальной инструкции платформы MAX (документация MAX, проверено 2 ноября 2026 года), создание чат-ботов требует подключения к платформе партнеров и обязательной верификации профиля организации, ИП либо самозанятого, являющихся резидентами РФ. При этом действуют строгие количественные лимиты: организации и ИП могут создать до 5 ботов, а самозанятые — до 2 (сам токен выпускается через веб-платформу или мини-приложение «MAX для бизнеса»). Если не учесть время на верификацию юрлица и лимиты на количество ботов при проектировании архитектуры, запуск клиентского сервиса сорвется по чисто организационной причине.

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

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

Чтобы этого не произошло, еще до написания первой строчки кода зафиксируйте четыре управленческих правила:

1. Назначьте владельца продукта со стороны бизнеса. Это должен быть не ИТ-специалист, а руководитель того подразделения (поддержки, продаж, юротдела, бухгалтерии), чью боль решает инструмент. Именно он формирует эталонную выборку вопросов для тестирования.
2. Заложите сценарий «человек в контуре» (Human-in-the-loop). Как мы видели на примере сервиса 1С:РПД в бухгалтерии или пилота в «Инфосистемах Джет», самые устойчивые решения не исключают человека полностью, а готовят для него проверенный черновик, берут на себя первичную маршрутизацию и экономят время на поиске фактов.
3. Разделите метрики качества модели и метрики бизнеса. Точность классификации в 75% или доля верных ответов в 80% — это технические ориентиры для инженеров. Для бизнеса критерием успеха служит сокращение среднего времени ответа (AHT), снижение нагрузки на первую линию поддержки на конкретный процент или уменьшение числа ошибок при вводе первички.
4. Обучите команду работать с ассистентом. Сотрудникам нужно прямо объяснить, что ИИ — это не замена их экспертизе и не безошибочный оракул, а быстрый стажер, чьи справки и проекты документов требуют финального взгляда специалиста.

Большинство проблем внедрения ИИ решаются не покупкой более дорогой подписки на нейросеть, а трезвым инженерным расчетом на берегу. Прежде чем выделять бюджет на масштабную разработку, выберите один узкий, хорошо оцифрованный процесс с понятной стоимостью ошибки — например, подготовку черновиков ответов для первой линии поддержки по статичным регламентам или первичную разметку входящих обращений. Рассчитайте полную стоимость владения с учетом инфраструктуры и интеграции с вашими базами, проверьте маршрут движения персональных данных по 152-ФЗ и сразу заложите в интерфейс кнопку передачи сложного случая живому сотруднику.

Нужна помощь с внедрением?

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