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

Оксана Иванова

20 октября 2026 г.

11 мин.

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

«Хотим внедрить искусственный интеллект в отдел продаж». За этой просьбой обычно скрываются разные задачи: менеджеры переносят заявки из писем в CRM, руководитель собирает прогноз, а скидки согласуют в мессенджере. У каждой операции свои источники данных, риски и критерии качества. И не везде нужна нейросеть.

Начинать с выбора модели — всё равно что заказывать оборудование, не измерив производственную линию. Оно может быть превосходным, но для какой задачи? Мы начинаем с потерь, ограничений и измеримых результатов.

Каждый критерий оцените от 0 до 2 баллов: 0 — условие не выполнено или доказательств нет; 1 — готовность частичная; 2 — ее подтверждают документы и проверка на реальном процессе. Максимум — 30 баллов. Проверяйте оценки по данным, а не словам.

Участвуют владелец процесса, ИТ, ответственные за данные, ИБ и пользователи. Шкала прикладная, не нормативная.

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

Например, компания хочет автоматизировать заявки. Но артикулы в письмах устарели, в 1С и CRM различаются контрагенты, а скидки согласуют устно. Запускать агента поверх таких противоречий рано. Сначала нужны источники данных и правила принятия решений.

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

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

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

3. Известны исходные показатели. Измерены объем обращений, время обработки, частота ошибок и задержек. Проверка: отчеты из CRM, 1С или хронометраж. Без исходных цифр доказать экономический эффект невозможно.

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

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

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

7. Проверены интерфейсы систем. ИТ-команда знает, какие API и способы обмена доступны, что можно читать и записывать. Проверка: тестовый вызов с ограниченными правами. «К 1С есть доступ» — недостаточное подтверждение.

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

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

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

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

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

13. Собрана рабочая группа. Назначены представители бизнеса, ИТ, данных, ИБ и будущих пользователей. Проверка: список ролей и выделенное время. Без экспертов некому подтвердить правильность тестовых результатов.

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

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

0–10 баллов: описываем процесс, назначаем владельцев, готовим данные. Пилот с записью в рабочие системы пока рано запускать.

11–20 баллов: возможен ограниченный эксперимент, например распознавание обезличенных документов без автоматической записи в 1С. Одновременно устраняем выявленные ограничения.

21–30 баллов: есть основания проектировать контролируемый пилот с измеримыми метриками. Но даже максимальная оценка не отменяет обязательных проверок безопасности.

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

Рассмотрим условную оптовую компанию. Менеджеры получают заявки по почте, проверяют товары в 1С и создают сделки в CRM. Первичная оценка — 19 из 30 баллов: процесс понятен, письма сохраняются, у CRM есть API. Но артикулы различаются между отделами, правила скидок не закреплены, а передачу вложений во внешнюю модель ИБ не согласовала.

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

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

Неделя 1 — диагностика. Интервью с продажами, ИТ и ИБ, сбор характерных заявок, измерение текущих показателей. Итог: паспорт процесса, риски и базовые метрики.

Недели 2–3 — данные и правила. Сопоставление справочников, выборка с проверенными ответами, требования к правам. Итог: готовые данные и критерии приемки.

Недели 4–5 — прототип. Разбор писем, поиск товаров, подготовка черновика без проведения документов, журналирование. Итог: рабочий сценарий в тестовом контуре.

Неделя 6 — испытания. Проверка дублей, неверных артикулов, недоступного API, попыток изменить цену через текст заявки. Итог: измеренное качество и перечень ошибок.

Недели 7–8 — ограниченный запуск. Небольшая группа менеджеров, сравнение с исходными показателями, оценка расходов. Итог: решение масштабировать, доработать или остановить проект.

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

Допустим, отдел обрабатывает 2 000 заявок в месяц, затрачивая семь минут на каждую: около 233 часов. Если пилот сократит время до четырех минут, расчетное высвобождение составит 100 часов. Это не автоматическая экономия фонда оплаты труда: сотрудники могут направить время на дополнительные продажи и проверку сложных заказов.

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

В Mad Brains ориентир стоимости аудита применения ИИ в бизнес-процессах — 120–250 тыс. ₽ для согласованного объема. Быстрая диагностика отдельного направления возможна примерно за неделю; полноценное обследование нескольких подразделений требует больше времени. Пилот оцениваем отдельно.

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

Такой отчет помогает решить, куда инвестировать и что исправить. Иногда выгоднее отложить ИИ и сначала наладить данные.

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

Оксана Иванова

20 октября 2026 г.

11 мин.