Разработка ИИ для бизнеса редко означает обучение собственной большой модели с нуля. Чаще проект состоит из выбора подходящей модели, подключения корпоративных данных, бизнес-правил, интеграций, интерфейса, прав доступа, тестирования и мониторинга. Собственная разработка оправдана тогда, когда готовый сервис не закрывает ваш workflow, требования к данным, качеству или интеграциям
Сначала решите: покупать, расширять или разрабатывать
| Подход | Когда подходит | Пример |
|---|---|---|
| Buy | Задача типовая, готовый продукт закрывает 80-90% процесса | Корпоративный AI-помощник для черновиков и анализа |
| Extend | Готовой платформе не хватает ваших данных, workflow или действий | Ассистент с корпоративной базой знаний и CRM |
| Build | Процесс уникален, нужна своя логика, сложные интеграции, права или высокая нагрузка | Сквозной AI-контур обработки документов и принятия решений |
Microsoft Learn в программе для архитекторов AI-бизнес-решений отдельно включает оценку «создавать, покупать или расширять» как часть проектирования AI-систем, а не как решение, которое принимают после начала разработки (Microsoft Learn)
Какие ИИ-решения обычно разрабатывают для бизнеса
| Тип | Что делает | Когда кастом имеет смысл |
|---|---|---|
| AI-ассистент | Работает с контекстом сотрудника и помогает выполнять задачи | Нужны свои данные, роли, шаблоны и интеграции |
| RAG / поиск по знаниям | Отвечает по внутренним документам с источниками | Сложные права, большой корпус, высокие требования к точности |
| Классификация и извлечение | Разбирает письма, документы, звонки, заявки | Свой набор классов, полей, проверок и downstream-действий |
| AI-агент | Планирует и выполняет несколько действий через инструменты | Нужны конкретные полномочия, оркестрация и контроль |
| ML / predictive | Прогнозирует или оценивает на структурированных данных | Есть достаточная история данных и стабильная бизнес-цель |
Что должно быть в требованиях до оценки проекта
Если подрядчику дают задачу «сделайте ИИ для отдела», оценка почти неизбежно будет либо фантазией, либо большим запасом на неизвестность. До запроса сметы полезно свериться с планом внедрения ИИ в бизнес и зафиксировать, что именно меняется в процессе. До сметы полезно зафиксировать восемь блоков
- Бизнес-результат - что должно стать быстрее, дешевле, точнее или масштабируемее
- Вход - письма, PDF, звонки, CRM, таблицы, изображения, события
- Выход - текст, поля, решение, действие в системе, задача человеку
- Системы - CRM, 1С, ERP, база знаний, почта, внутренние API
- Качество - как измеряется правильность и какие ошибки критичны
- Права - что система может читать и что ей разрешено менять
- Нагрузка - количество кейсов, требования к скорости и доступности
- Приёмка - набор реальных тестов, после которых решение можно выпускать
Архитектура AI-решения простыми словами
| Слой | Что в нём происходит | Типовая ошибка |
|---|---|---|
| Источники | Собираются документы, события и бизнес-данные | Модель получает устаревший или лишний контекст |
| Подготовка | Данные нормализуются, разбиваются и проверяются | Всё отправляют в модель «как есть» |
| Модель | Классифицирует, извлекает, рассуждает или генерирует | Одной моделью пытаются решить все задачи |
| Правила | Проверяют ограничения и бизнес-условия | Критичные правила оставляют на усмотрение модели |
| Интеграции | Результат читается и записывается в рабочие системы | AI живёт отдельной вкладкой |
| Контроль | Логи, оценки, мониторинг, лимиты и human review | После запуска никто не видит деградацию качества |
Семь этапов разработки ИИ-системы
- Разобрать бизнес-процесс и границы проекта
- Собрать реальные примеры и определить критерии качества
- Сделать технический spike на главной неопределённости
- Спроектировать данные, права, интеграции и human-in-the-loop
- Собрать пилот и прогнать тестовый набор
- Встроить в рабочий контур с логами, лимитами и fallback
- Наблюдать фактическое использование и обновлять решение по данным
OpenAI в Enterprise AI 2025 отмечает, что компании всё глубже интегрируют модели в повторяемые, многошаговые workflow, а рост API-использования отражает переход от экспериментов к системным продуктам и внутренним инструментам (OpenAI)
Что сильнее всего влияет на стоимость разработки
| Фактор | Почему увеличивает проект |
|---|---|
| Количество интеграций | Каждая система добавляет авторизацию, форматы, ошибки и тестирование |
| Сложность прав | Нужно гарантировать, что разные пользователи видят только разрешённые данные |
| Цена ошибки | Чем критичнее решение, тем больше тестов, правил и human control |
| Качество исходных данных | Грязные данные превращают AI-проект в data-проект |
| Нагрузка и SLA | Рабочий контур требует устойчивости, мониторинга и сценариев отказа |
| On-premise / закрытый контур | Появляется инфраструктура, эксплуатация и дополнительные ограничения |
| Нестандартная модель | Fine-tuning или собственный ML требуют датасета, оценки и поддержки версии |
Поэтому сравнивать предложения только по цене «разработки бота» бесполезно. Для бюджета полезнее отдельно посмотреть, из чего складывается стоимость внедрения ИИ. В одном проекте бот показывает ответы из готового API, в другом должен соблюдать права доступа, работать с 1С, проверять документы и оставлять аудируемый след каждого действия
Как выбрать подрядчика на разработку ИИ
| Вопрос подрядчику | Что вы хотите услышать |
|---|---|
| Как вы поймёте, что проект успешен? | Конкретная бизнес-метрика + технические критерии |
| Как будет тестироваться качество? | Набор реальных кейсов, критичные ошибки, регулярная оценка |
| Что произойдёт при сбое модели? | Fallback, очередь, ручной режим, алерты |
| Где будут храниться данные? | Понятная схема потоков, сроков хранения и доступа |
| Кто владеет кодом и конфигурацией? | Это прямо зафиксировано в договоре и документации |
| Как меняется модель без поломки процесса? | Версионирование, тесты и контролируемый rollout |
Когда собственная разработка не оправдана
- Готовый сервис уже закрывает задачу и подходит по политике данных
- Процесс редкий и экономический эффект маленький
- Нет владельца процесса и критериев правильного результата
- Данные настолько нестабильны, что сначала нужно починить источник
- Компания не готова поддерживать ещё одну рабочую систему
В таких случаях зрелое решение - не «делать AI любой ценой», а выбрать более простой способ. Иногда лучшая разработка ИИ - это интеграция готовой функции в один нужный шаг
Нужно понять, требуется ли вам собственная разработка ИИ?
Опишите задачу и системы, в которых она живёт. Мы разберём, достаточно ли готового сервиса или интеграции, где действительно нужна кастомная разработка и какие требования стоит зафиксировать до оценки бюджета
Частые вопросы
Нужно ли обучать собственную модель для разработки ИИ?
В большинстве бизнес-задач нет. Часто достаточно готовой модели с вашими данными, инструментами, правилами и интеграциями. Собственное обучение нужно, когда оно даёт измеримое преимущество
Можно ли интегрировать ИИ с 1С, CRM и внутренними системами?
Да, если системы имеют API, события или другой безопасный способ обмена данными. При отсутствии API возможны промежуточные интеграции, но их надёжность нужно оценивать отдельно
Можно ли развернуть ИИ в закрытом контуре?
Да, но требования к моделям, инфраструктуре, обновлениям и эксплуатации становятся строже. Решение о размещении лучше принимать после классификации данных и требований к риску
От чего зависит срок разработки ИИ-системы?
От количества интеграций, качества данных, требований к точности, правам, нагрузке, интерфейсу и цене ошибки. Сам прототип модели обычно не самая длинная часть проекта: основное время занимает рабочее внедрение
Что должно остаться у заказчика после разработки?
Документация архитектуры и интеграций, критерии качества, инструкции по эксплуатации, схема данных и прав, порядок обновления, а также договорённости о владении кодом и конфигурацией
Как выбрать между готовым AI-сервисом и своей разработкой?
Сначала сравните требования к данным, интеграциям, контролю, цене ошибки и уникальности workflow. Если готовый сервис закрывает требования без критичных компромиссов, разработка с нуля обычно не нужна.
