Внедрение генеративного ИИ в бизнес-процессы: стратегия и практика

По материалу Николая Бажанова, руководителя отдела бизнес-процессов Sminex, опубликованному на Хабре, компания делит внедрение генеративного ИИ на три направления: массовую рутину, сложные изменения процессов и персональные инструменты для сотрудников. Практический вывод для бизнеса не в выборе очередного агента. Сначала нужно определить, какую операцию он ускоряет, кто проверяет результат и можно ли остановить внедрение без крупных потерь.

Три класса задач для ИИ

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

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

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

Что проверить перед пилотом

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

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

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

Ограничения подхода

Материал Хабра описывает практику одной компании и прямо отмечает, что универсального рецепта нет. В нём не приведены количественные результаты внедрения, метрики точности или сравнение затрат до и после автоматизации. Следовательно, это рабочая рамка для отбора задач, а не доказательство эффективности конкретных продуктов.

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