Сколько стоит внедрение ИИ в Казахстане

Коротко

ИИ можно внедрить за смешные деньги. Можно открыть no-code конструктор, подключить ChatGPT, собрать простого бота и платить примерно 10 000 ₸/мес. Для внутреннего эксперимента этого иногда достаточно.

Можно нанять человека, который соберёт похожую схему на конструкторе за 50 000 ₸. Это нормально, если задача простая: принять заявку, ответить на FAQ, отправить форму в таблицу, переслать сложный вопрос менеджеру.

Но серьёзная разработка начинается там, где бизнесу нужна предсказуемость. Агент должен работать с CRM, документами, ролями, логами, эскалацией, ограничениями доступа и нормальными ошибками. Он не должен “вроде отвечать”. Он должен выдерживать неудобные вопросы.

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

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

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

Если компания хочет запускать всё на своём железе и не отдавать данные в чужое облако, бюджет меняется. Частный контур, self-hosted модели, GPU, безопасность, мониторинг и эксплуатация быстро поднимают проект к от 50 млн ₸. Это не “та же система, только локально”. Это отдельная инфраструктурная работа.

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

За что на самом деле платит бизнес

Сметы по AI-проектам кажутся странными, потому что словом “внедрение” называют совсем разные вещи. Это может быть промпт в конструкторе, бот в Telegram, RAG по внутренним документам, агент для отдела продаж с CRM или запуск модели в частном корпоративном контуре.

Это не одна и та же работа разного размера. Это разные уровни ответственности.

Простому FAQ-боту иногда хватает формы, промпта и передачи сложного вопроса человеку. Корпоративному ассистенту нужны источники, права доступа, качество поиска, логи и способ исправлять плохие ответы. Агенту для продаж нужны статусы в воронке, правила менеджеров, аккуратная работа с обещаниями, скидками и данными клиентов.

Поэтому вопрос “сколько стоит ИИ” слишком широкий. Лучше спросить иначе: какой ответ, решение или действие система получит право делать?

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

Практические ценовые диапазоны

Это не прайс-лист. Это ориентир, который помогает не смешивать эксперимент, пилот, боевой запуск и частную инфраструктуру в одну кучу.

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

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

Что увеличивает стоимость

Модель редко является самой дорогой частью первого внедрения. Деньги уходят на то, что превращает демо в рабочую систему внутри компании.

Интеграции. CRM, ERP, WhatsApp, Telegram, почта, BI, внутренние базы, хранилища документов и HR-системы живут по разным правилам. Отдельное демо делается быстро. Система, которая читает и записывает данные в рабочие инструменты, требует больше аккуратности.

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

Права доступа. Внутренний ассистент не должен показывать всем зарплаты, юридические документы или управленческие материалы. Роли и видимость источников особенно важны, если вы строите внутренний ChatGPT для компании.

Качество поиска. Если система отвечает по документам, одних vector embeddings часто мало. Нужны гибридный поиск, reranking, метаданные, свежесть источников и правила отказа. Подробно это разобрано в статье Как работает RAG и почему векторных embedding’ов недостаточно.

Evals. Боевой системе нужен способ проверять поведение до и после изменений. Это реальные примеры, ожидаемое поведение, категории ошибок и автоматические проверки там, где они уместны. Подробнее: Зачем AI-проекту evals.

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

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

Дешёвый AI полезен, когда цена ошибки низкая

В конструкторах нет ничего плохого. Часто это самый разумный способ быстро разобраться.

Их стоит использовать для:

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

Ошибка начинается там, где демо в конструкторе принимают за доказательство готовности к боевому запуску. Демо показывает, что счастливый путь работает. В реальности появляются неполные данные, злые клиенты, двусмысленные запросы, дубли в CRM, ограничения доступа, медленные API и скриншоты вместо аккуратного текста.

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

Стоимость боевой системы начинается с ответственности

У боевой AI-системы должны быть простые ответы на несколько вопросов:

• Кто владеет процессом?
• Что AI может делать без подтверждения?
• Что всегда должен проверить человек?
• Какие источники считаются надёжными?
• Какие пользователи видят какие материалы?
• Что происходит, если ответ неуверенный?
• Как ошибки попадают в журнал и разбираются?
• Как понять, что новый промпт или новая модель лучше?

Эти вопросы сильнее влияют на архитектуру, чем название модели.

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

Здесь полезно различать уровни из статьи AI-агент, chatbot или workflow: в чём разница. Chatbot отвечает. Workflow двигает данные. Agent может рассуждать по шагам и пользоваться инструментами. Каждый следующий уровень добавляет ответственность, а значит меняет стоимость.

Где в смете находятся evals

Evals иногда воспринимают как необязательную строку. Для серьёзной системы это скорее страховка и приборная панель.

Практичный eval-набор может включать:

• 30-100 реальных запросов пользователей;
• ожидаемые свойства ответа, а не буквальное совпадение текста;
• примеры, где система обязана отказать;
• примеры, где нужно задать уточняющий вопрос;
• проверку верности источникам для RAG;
• валидацию JSON и tool calls;
• регрессии из реальных ошибок после запуска;
• сравнение стоимости и задержки разных моделей.

Это не обязано превращаться в научную лабораторию. Даже простая таблица со сценариями, ожидаемым поведением и pass/fail уже снимает магию. Команда видит, стало ли лучше, можно ли перейти на более дешёвую модель и не сломал ли новый промпт старый сценарий.

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

Расходы после запуска

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

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

Машинное использование зависит от трафика, модели, длины контекста, retrieval-стратегии и количества tools. OpenAI, Anthropic и cloud-провайдеры считают цену по токенам, запросам, service tier, data residency, batch mode и иногда отдельным инструментам. Конкретные цифры меняются, но логика стабильна: длинный контекст, дорогие модели, повторный retrieval и agent loops поднимают счёт.

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

Частный контур — это отдельный проект

Иногда компания просит “запустить AI на наших серверах”. Причина может быть в регулировании, чувствительных данных, внутренней политике или недоверии к внешним сервисам. Иногда это действительно нужно. Но работа становится другой.

Частный контур может включать:

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

Поэтому частный контур может начинаться от от 50 млн ₸. Компания покупает уже не только AI-функцию. Она покупает инфраструктуру, на которой эту функцию надо запускать и поддерживать.

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

Как подготовить нормальную оценку

Для полезной оценки нужны не громкие слова, а материал. На первый разговор лучше принести:

1. Один процесс, а не пять.
2. 30-100 реальных примеров: сообщения, заявки, документы, ответы менеджеров, ошибки.
3. Текущую стоимость процесса: часы, задержки, упущенные продажи, нагрузку поддержки.
4. Цену неправильного ответа.
5. Системы, с которыми нужно работать: CRM, мессенджеры, базы, документы, аналитика.
6. Языки: казахский, русский, английский или все сразу.
7. Границу полномочий: черновик, рекомендация, действие с подтверждением или самостоятельное действие.
8. Ограничения безопасности: можно облако, нужен ограниченный облачный контур или обязателен запуск в собственной инфраструктуре.

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

Разумная последовательность покупки

Самый спокойный путь обычно выглядит так:

1. Описать один процесс.
2. Собрать реальные примеры.
3. Сделать узкий прототип.
4. Собрать eval-набор из живых кейсов.
5. Подключить минимально полезную интеграцию.
6. Запустить на маленькую группу.
7. Разобрать логи и ошибки.
8. Расширяться только после того, как качество видно.

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

Итог

Если нужен маленький эксперимент, начинайте дёшево. Конструктора может хватить.

Если AI будет касаться клиентов, корпоративных знаний, CRM, документов или операционных решений, закладывайте боевую разработку: интеграции, доступы, evals, логи, запуск и доработки.

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

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