# Внедрение ИИ в бизнес: как выбрать первый процесс и не потерять контроль
Редакция SGI24. Материал основан на практике внедрения автоматизаций и управляемых ИИ-сценариев. [О бюро](/company).
Фраза «нам нужен ИИ» пока не описывает задачу. Это всё равно что попросить «внедрить таблицу»: непонятно, для кого, с какими данными и что должно измениться после запуска.
Нормальный первый проект начинается с одного процесса. Есть входящие данные, повторяющаяся работа, понятный результат и человек, который может проверить ошибку. Тогда ИИ становится рабочим инструментом, а не демонстрацией возможностей модели.
Где ИИ приносит пользу быстрее
Для первого запуска подходят задачи, в которых сотрудники уже выполняют много однотипных действий. Например, разбирают обращения, сверяют документы, ищут отклонения, готовят краткую сводку или распределяют записи по категориям.
Хороший кандидат отвечает четырём условиям:
- процесс повторяется достаточно часто;
- результат можно проверить;
- ошибка обратима или перехватывается человеком;
- есть исходная точка для сравнения.
Если решение необратимо, связано со здоровьем, правами человека или крупной суммой, полностью автоматический первый запуск опасен. Там ИИ сначала работает как помощник и показывает рекомендацию ответственному специалисту.
Опишите работу без слова «ИИ»
До выбора модели мы рисуем обычную схему: что приходит на вход, кто принимает решение, какое действие выполняется и где сохраняется результат.
Возьмём входящее обращение. Система может определить тему, найти связанную организацию, предложить ответственного и подготовить краткую выжимку. Но правило назначения, срок реакции и финальное действие принадлежат бизнес-процессу. Модель лишь помогает пройти отдельные шаги.
Такой разбор полезен сам по себе. Иногда выясняется, что проблема решается обычной интеграцией или строгим правилом, без ИИ. Мы говорим об этом до разработки.
Измерьте исходное состояние
Нельзя доказать пользу, если до запуска ничего не измерялось. Зафиксируйте время обработки, долю возвратов на исправление, пропущенные сроки и ручные переходы между системами.
После пилота сравниваются те же показатели. Не «сотрудникам нравится», а сколько работы система действительно взяла на себя, где ошиблась и сколько времени заняла проверка.
Экономия может оказаться меньше ожидаемой. Это тоже результат. Лучше остановить неудачный пилот через месяц, чем год поддерживать дорогую автоматизацию ради отчёта о внедрении.
Данные определяют границы проекта
ИИ не должен получать весь архив организации только потому, что технически это возможно. Для каждого сценария определяется минимальный набор данных, место обработки, срок хранения и круг пользователей.
Если в материалах есть персональные, медицинские или коммерчески чувствительные сведения, до подключения внешней модели проверяется маршрут передачи. Там, где возможно, данные обезличиваются или обрабатываются внутри контролируемого контура.
Доступ к базе знаний тоже ограничивается. Сотрудник не должен получить через ответ модели документ, который закрыт для него в исходной системе.
Человек остаётся в точке ответственности
Управляемое внедрение заранее отвечает на три вопроса: кто проверяет, что происходит при сомнении и как отменить ошибочное действие.
В начале полезен режим рекомендации. Модель предлагает категорию, текст или риск, сотрудник подтверждает решение. Система сохраняет оба варианта и причину исправления. Так появляется материал для оценки качества.
Автоматическое действие включается только там, где накоплена статистика и определён безопасный откат. Даже после этого выборочные проверки остаются.
Какие сценарии бывают
ИИ можно встроить в разные участки работы:
- классифицировать обращения и документы;
- искать пропуски и противоречия;
- собирать сводку для руководителя;
- отвечать по проверенной базе знаний;
- прогнозировать нагрузку и отмечать отклонения;
- готовить черновик действия для сотрудника.
Список выглядит широко, но один проект не должен начинаться со всех пунктов. Выбирается сценарий, который ближе всего к измеримой потере.
Отраслевой пример с более жёсткими профессиональными границами: ИИ для стоматологии.
Модель не должна работать в одиночку
Кроме самой модели нужны источники данных, правила доступа, журнал действий, контроль качества и рабочий интерфейс. Иначе организация получает отдельный чат, куда сотрудники копируют информацию вручную.
Ценность появляется, когда ИИ встроен в CRM, 1С, медицинскую или образовательную систему и возвращает результат туда, где сотрудник продолжает работу. При этом критические операции проходят через подтверждение.
Как работает автоматизация бизнес-процессов
Первый этап внедрения
SGI24 начинает с короткого проекта:
- выбирает один процесс и владельца результата;
- фиксирует исходные показатели;
- определяет данные и ограничения;
- собирает прототип на реальных примерах;
- проверяет качество и стоимость;
- выдаёт решение о запуске, доработке или остановке.
Заказчик получает не обещание «ИИ повысит эффективность», а рабочий сценарий с границами и цифрами пилота.
С какого ИИ-сценария начать
Для пилота не требуется пересобирать весь бизнес. Если нужные данные доступны, модуль подключается к одному процессу. Сайт, CRM или дашборд можно дорабатывать позже.
Иногда пилот обнаруживает, что данные ненадёжны или процесс каждый сотрудник понимает по-своему. Тогда первым результатом становится порядок в источниках и регламенте. Это не провал ИИ-проекта. Это честная причина, почему автоматизацию рано масштабировать.
Границы обещания
SGI24 не гарантирует безошибочность модели и не передаёт ей ответственность руководителя, врача или другого специалиста. Мы проектируем контролируемый сценарий, измеряем качество и оставляем возможность проверить и отменить действие.
Для задач, которые могут относиться к медицинским изделиям или регулируемым решениям, отдельно проверяется правовой режим продукта.
Кто принимает ИИ-проект
Одной демонстрации недостаточно. Заказчик заранее готовит контрольный набор примеров, который не использовался при настройке. Ответственный сотрудник проверяет точность, полноту, опасные ошибки и понятность объяснений.
Для разных ошибок задаётся разная цена. Неверная тема внутреннего письма и ошибочное действие с платёжным документом нельзя складывать в один процент качества. Критический класс должен блокировать автоматизацию даже при хорошем среднем результате.
Проверяется и рабочая нагрузка. Если сотрудник тратит на контроль подсказки больше времени, чем раньше на самостоятельную работу, сценарий следует изменить или закрыть.
Что происходит после пилота
Проверка может закончиться запуском модуля в ограниченном процессе. Иногда идея оказывается полезной, но сначала приходится привести в порядок данные, справочники или права. Бывает и так, что задача не оправдывает сложность: тогда её лучше оставить человеку или решить обычным правилом.
При запуске фиксируются версия модели, параметры, источники и критерии контроля. Изменение модели считается изменением системы, потому что ответы могут стать другими. Для критичных сценариев сохраняется возможность быстро вернуться к предыдущему режиму.
Из чего складывается стоимость
Стоимость определяется не количеством запросов к модели. Основная работа состоит в разборе процесса, подготовке данных, встраивании результата в систему, настройке прав и приёмке. Поэтому обычный чат может быть недорогим, а безопасная автоматизация одного действия потребует значительно больше работы.
На первом разборе мы отделяем обязательный контур от желательных функций. Заказчик видит цену пилота отдельно от промышленного запуска и может остановиться после полученного прототипа и отчёта.