У внедрения ИИ есть странный момент, который редко обсуждают на старте проекта.
Пока система разрабатывается, всё понятно. Есть подрядчик, задачи, тесты, созвоны, исправления. Кто-то отвечает за результат, кто-то проверяет работу, кто-то принимает проект.
Потом автоматизацию запускают.
Она начинает сама разбирать документы, обрабатывать обращения, обновлять карточки, готовить отчёты, ставить задачи или выполнять другие операции.
Проект формально завершён.
И вот здесь появляется новый вопрос: кто теперь отвечает за то, что эта система продолжит нормально работать через три месяца, полгода и год?
Это не бюрократическая мелочь. Чем больше бизнес начинает полагаться на автоматизацию, тем опаснее ситуация, в которой система уже стала частью работы компании, а эксплуатационно принадлежит как будто никому.
Запуск — это не конец проекта, а начало эксплуатации
Автоматизация работает внутри живой среды.
Внешние сервисы меняют программные интерфейсы. Обновляются системы. Истекают токены доступа. Переименовываются поля. Меняются бизнес-правила. Появляются новые типы документов. Сотрудники начинают использовать процесс немного иначе, чем предполагалось на пилоте.
Даже если код самой автоматизации никто не трогал, окружающая среда постепенно меняется.
Поэтому сценарий, который идеально работал в январе, в июне уже может вести себя иначе.
Причём проблема не обязательно выглядит как авария.
Система может продолжать запускаться. В журнале могут быть зелёные статусы. Сервер доступен. Ошибок нет.
Но часть полезной работы уже не выполняется.
Например, интеграция перестала правильно распознавать новое поле. Или внешняя система начала возвращать данные в немного другом формате. Или модель после обновления стала чаще отправлять случаи на ручную проверку.
Технически всё живо.
Экономический эффект уже ухудшился.
Кто должен заметить, что автоматизация стала работать хуже
Это первый вопрос, который стоит решить заранее.
В плохом варианте проблему замечает конечный пользователь.
Сотрудник говорит: «Почему-то последние несколько дней заявок мало».
Руководитель обнаруживает, что часть карточек не обновилась.
Бухгалтер видит очередь документов, которая вдруг начала расти.
Клиент спрашивает, почему ему никто не ответил.
То есть мониторингом фактически становится человек, на которого автоматизация была призвана снизить нагрузку.
Гораздо лучше, когда сама система имеет измеримые признаки нормальной работы.
- Сколько объектов поступило на вход.
- Сколько успешно обработано.
- Сколько отправлено человеку.
- Каков возраст самой старой необработанной записи.
- Когда последний раз процесс действительно дал полезный результат.
- Как изменилась доля исключений.
Для разных процессов показатели будут разными. Но принцип один: нужно контролировать не только состояние программы, но и состояние бизнес-процесса.
Ошибка и деградация — не одно и то же
Есть важное различие.
Ошибка — это когда система явно не смогла выполнить действие.
Деградация — когда она продолжает работать, но хуже, чем раньше.
Например, раньше 95% документов обрабатывались автоматически, а 5% уходили человеку. Через несколько месяцев ситуация стала 70 на 30.
Технически автоматизация не сломалась.
Но сотрудники снова начали тратить много времени на ручную работу, а ожидаемая экономия исчезла.
То же самое может произойти с поддержкой. ИИ продолжает отвечать клиентам, но чаще ошибается или передаёт разговор оператору.
Или с CRM. Система по-прежнему извлекает договорённости из звонков, но стала хуже определять клиента.
Такие изменения намного сложнее обнаружить обычными уведомлениями об ошибках.
Поэтому сопровождение должно включать не только реакцию на падение системы, но и контроль её качества.
У автоматизации должен быть владелец
Любой важный рабочий процесс должен кому-то принадлежать.
Не в смысле юридического права на программу, а в смысле ответственности за результат.
- Кто принимает решение, что автоматизация работает нормально?
- Кто определяет допустимый уровень ошибок?
- Кто решает, что делать с исключениями?
- Кто согласует изменение бизнес-правил?
- Кто говорит разработчику, что новое поведение правильное?
Очень часто эти вопросы пытаются оставить на технической команде.
Но разработчик не может сам решить, допустимо ли автоматически обрабатывать 90% документов вместо 95%. Он не должен самостоятельно определять, какое бизнес-правило нужно применить в спорной ситуации.
У процесса должен быть бизнес-владелец.
А у технической части — ответственный за эксплуатацию.
Это могут быть разные люди.
Отдельный вопрос — кому вообще принадлежит система
После внедрения полезно знать ответы на очень приземлённые вопросы.
- Где находится исходный код?
- На чьём аккаунте создан сервер?
- Кому принадлежит домен?
- Где лежат резервные копии?
- На кого оформлены ключи API?
- У кого есть доступ к облачной панели?
- Кто владеет учётной записью, через которую система работает с внешним сервисом?
- Есть ли у заказчика доступ к журналам и настройкам?
Если подрядчик завтра перестанет отвечать, сможет ли другой специалист продолжить работу?
Это особенно важно для небольших автоматизаций, которые часто собираются быстро.
Сценарий может годами исправно выполнять важную работу, но технически жить на личном аккаунте разработчика.
Пока всё хорошо, никто об этом не думает.
Проблема появляется только при смене подрядчика, увольнении сотрудника или блокировке учётной записи.
Сопровождение — это не обязательно постоянная разработка
Иногда слово «поддержка» воспринимается как бесконечные доработки.
На самом деле эксплуатационное сопровождение можно разделить на несколько разных видов работы.
Первое — контроль работы.
Система запускается, результаты появляются, очередь не растёт, расходы находятся в нормальном диапазоне.
Второе — устранение неисправностей.
Что-то перестало работать из-за изменения внешнего сервиса, инфраструктуры или данных.
Третье — обновления.
Новая версия модели, библиотеки, платформы, операционной системы или интеграции.
Четвёртое — изменение самого процесса.
Компания решила, что теперь заявки нужно обрабатывать иначе или подключить новый отдел.
Вот это уже новая разработка.
Разделять эти категории полезно и заказчику, и подрядчику. Иначе любой разговор быстро превращается в спор: «Это баг или новая задача?»
Что считать гарантийным исправлением
Этот вопрос тоже лучше обсуждать заранее.
Если автоматизация изначально должна была обрабатывать определённый формат данных, но не делает этого из-за ошибки в реализации, это очевидный дефект.
Если внешний сервис через полгода полностью изменил API, это уже другая ситуация.
Если заказчик изменил бизнес-правило, это новая функциональность.
Если после обновления модели качество классификации изменилось, нужно понимать, входит ли повторная настройка в эксплуатационное сопровождение.
Нет универсального ответа.
Важно не найти «правильную» модель договора, а заранее обозначить границы ответственности.
Тогда после запуска не приходится каждый раз заново выяснять, кто должен оплачивать конкретную работу.
Внешние сервисы будут меняться
Современная ИИ-автоматизация почти никогда не существует сама по себе.
Она может зависеть от почты, CRM, хранилища файлов, облачной модели, системы уведомлений, внешнего API, базы данных и ещё нескольких компонентов.
Каждый из них живёт своей жизнью.
- Поставщик может изменить авторизацию.
- Удалить старую версию API.
- Ввести новый лимит запросов.
- Поменять тариф.
- Изменить формат ответа.
- Закрыть продукт целиком.
Поэтому зависимость от внешних систем нужно считать нормальной частью эксплуатации, а не неожиданным происшествием.
Хорошая автоматизация должна хотя бы позволять понять, какой именно внешний компонент перестал работать и что это повлияло на процесс.
Иначе любой сбой превращается в долгое расследование всей цепочки.
Модель тоже является внешней зависимостью
С ИИ появляется ещё один интересный слой.
Модель может обновиться без изменения вашего кода.
После этого ответы немного меняются.
На обычном чат-боте это может быть почти незаметно.
В автоматизации, где модель классифицирует документы, определяет следующий шаг или извлекает данные, даже небольшое изменение поведения иногда влияет на весь процесс.
Поэтому для важных сценариев полезно иметь контрольную выборку.
Набор реальных примеров с известными ожидаемыми результатами.
После смены модели или серьёзного изменения промпта эта выборка запускается снова.
Если раньше система правильно обрабатывала 96 из 100 случаев, а после обновления — 87, это нужно обнаружить до того, как изменение попадёт на весь рабочий поток.
То есть сопровождение ИИ включает ещё и регрессионную проверку поведения модели.
Расходы тоже нужно контролировать после запуска
На пилоте стоимость ИИ обычно кажется небольшой.
Десятки запросов, немного документов, несколько сотрудников.
После внедрения объём начинает расти.
Появляются новые пользователи. Система обрабатывает больше данных. Добавляются повторные попытки. Увеличивается контекст. Возникают дополнительные модели для проверки.
И через несколько месяцев счёт может выглядеть совсем иначе.
Поэтому полезно понимать не только общую стоимость API за месяц, но и стоимость бизнес-операции.
Например:
- сколько стоит обработать один документ;
- сколько стоит один клиентский диалог;
- сколько стоит один отчёт;
- сколько стоит автоматически закрытая задача.
Тогда можно увидеть, что какой-то сценарий стал непропорционально дорогим, и оптимизировать именно его.
Без такой метрики расходы на ИИ превращаются просто в очередной общий счёт за инфраструктуру.
Ежемесячный отчёт может быть очень простым
Для большинства небольших компаний не нужна сложная система аналитики.
Достаточно раз в месяц видеть несколько показателей.
- Сколько объектов пришло на вход.
- Сколько обработано автоматически.
- Сколько ушло человеку.
- Сколько завершилось ошибкой.
- Сколько было потеряно или пришлось запускать повторно.
- Какое среднее время обработки.
- Сколько стоила работа системы.
- Какие инциденты произошли.
- Какие изменения были внесены.
Такой отчёт полезен не ради бюрократии.
Он отвечает на главный вопрос: автоматизация всё ещё приносит тот эффект, ради которого её внедряли?
Если показатель постепенно ухудшается, это видно раньше, чем сотрудники начнут жаловаться.
Резервные копии нужны не только данным
Когда говорят о резервном копировании, обычно думают о базе данных.
Но у автоматизации есть и другие важные элементы.
- Исходный код.
- Конфигурация.
- Промпты.
- Настройки подключений.
- Схемы интеграций.
- Версии моделей.
- Документация.
- История изменений.
Если сервер потерян, недостаточно восстановить только таблицы с данными. Нужно восстановить весь процесс.
Особенно опасны визуальные конструкторы и облачные платформы, где сценарий существует внутри аккаунта поставщика.
Нужно заранее понимать, можно ли его экспортировать, где хранится копия и насколько быстро процесс можно поднять заново.
Надёжность автоматизации включает возможность её восстановить.
Документация нужна не для галочки
Есть распространённая проблема: систему знает только человек, который её написал.
Пока он рядом, это почти незаметно.
Через год никто уже не помнит, почему одно условие устроено именно так, откуда приходит конкретное поле и что произойдёт, если отключить старый сервис.
Хорошая документация не обязана быть огромной.
Для рабочей автоматизации достаточно ответить на несколько вопросов.
- Что запускает процесс?
- Какие внешние системы участвуют?
- Какие данные проходят между ними?
- Где хранятся состояния?
- Какие действия система выполняет автоматически?
- Где требуется человек?
- Как выглядит нормальный результат?
- Какие известны аварийные сценарии?
- Как восстановить работу?
- Как поменять ключи доступа?
Этого уже достаточно, чтобы новый специалист не начинал расследование с нуля.
Сопровождение не всегда нужно покупать у подрядчика
Здесь важно не превращать идею эксплуатации в аргумент «всем обязательно нужна ежемесячная подписка».
Не нужна.
Если процесс небольшой, некритичный и простой, заказчик вполне может поддерживать его самостоятельно.
Особенно если внутри компании есть технический специалист.
Другой вариант — периодическая проверка без постоянного сопровождения.
Третий — договор с подрядчиком только на аварийные случаи.
Четвёртый — полноценная эксплуатация с согласованным временем реакции.
Уровень сопровождения должен соответствовать цене возможного сбоя.
Если автоматизация раз в месяц помогает подготовить внутренний отчёт, час простоя никого не волнует.
Если через неё проходят клиентские заявки или финансовые операции, требования совсем другие.
SLA нужен не всем, но время реакции нужно понимать
Для критичных процессов полезно договориться, насколько быстро кто-то вообще посмотрит на проблему.
Не обязательно использовать сложные корпоративные SLA.
Можно просто заранее определить:
- критическая автоматизация — реакция в течение нескольких часов;
- обычная — в течение рабочего дня;
- некритичная — по плану.
Главное — избежать ситуации, когда бизнес предполагает, что подрядчик «следит за системой», а подрядчик считает проект завершённым несколько месяцев назад.
Это не техническая проблема.
Это проблема неверных ожиданий.
Кто должен платить за сопровождение
Ответ простой: тот, кому нужна гарантированная эксплуатация.
Но вопрос обычно не в самом факте оплаты, а в том, за что именно платят.
Плохой вариант — абстрактное «техническое сопровождение».
Хороший — конкретный перечень.
- Контроль работоспособности.
- Реакция на ошибки.
- Обновление зависимостей.
- Резервное копирование.
- Контроль расходов.
- Ежемесячный отчёт.
- Определённое количество мелких изменений.
- Поддержка инфраструктуры.
Тогда заказчик может сравнить стоимость сопровождения с ценой риска и решить, нужно ли оно вообще.
Иногда подрядчик действительно создаёт искусственную зависимость
Опасение заказчиков вполне справедливо.
Бывает, что система специально или просто по небрежности строится так, что без первоначального разработчика её почти невозможно сопровождать.
- Все аккаунты оформлены на него.
- Документации нет.
- Доступа к коду нет.
- Логика спрятана внутри облачного сервиса.
- Любое изменение требует обратиться к тому же человеку.
Это плохая архитектура отношений, даже если технически всё работает.
Нормальный проект должен допускать смену исполнителя.
Заказчику должны принадлежать данные, бизнес-логика и необходимые доступы.
Подрядчик продаёт компетенцию и ответственность за работу, а не удерживает клиента невозможностью уйти.
Что проверить ещё до внедрения
Лучше всего вопросы сопровождения обсуждать не после запуска, а до начала проекта.
- Где будет работать система?
- Кому принадлежат аккаунты?
- Где хранится код?
- Кто обновляет инфраструктуру?
- Кто контролирует ошибки?
- Кто смотрит на бизнесовые показатели?
- Кто делает резервные копии?
- Как сменить подрядчика?
- Что считается дефектом?
- Что считается новой разработкой?
- Как быстро нужно реагировать на критичную проблему?
- Что произойдёт, если используемый внешний сервис закроется?
Это не самые эффектные вопросы на первой встрече.
Зато через год они могут оказаться намного важнее выбора конкретной языковой модели.
Как я бы принимал проект автоматизации
До финальной сдачи я бы проверил не только нормальный сценарий.
Нужно убедиться, что заказчик имеет все необходимые доступы.
- Есть рабочая документация.
- Настроены резервные копии.
- Известно, где смотреть ошибки.
- Есть хотя бы минимальный контроль бизнес-результата.
- Понятно, как система ведёт себя после перезапуска.
- Можно восстановить работу на чистой инфраструктуре.
- Определён ответственный после окончания проекта.
И отдельно договориться о том, что будет происходить дальше.
- Подрядчик сопровождает систему.
- Компания забирает сопровождение на себя.
- Или стороны работают по запросу.
Любой вариант нормален.
Плохой вариант — когда никто об этом не договорился.
Самая опасная автоматизация — бесхозная
Пока система работает хорошо, кажется, что ответственный ей не нужен.
Но чем успешнее внедрение, тем больше сотрудники перестают думать о процессе.
И это естественно.
Смысл автоматизации как раз в том, чтобы не заниматься рутиной вручную.
Через несколько месяцев она превращается в часть инфраструктуры бизнеса.
А потом происходит сбой. И внезапно выясняется, что сотрудник, который заказывал проект, уже не работает в компании. Подрядчик считает договор завершённым. Пароль от одного из сервисов находится в старой переписке. Никто не знает, где хранится резервная копия. А бизнес-процесс уже зависит от этой системы каждый день.
Вот этого состояния и нужно избегать.
С чего начать
Если в компании уже есть ИИ-автоматизации, полезно провести небольшой эксплуатационный аудит.
- Выписать все важные процессы.
- Для каждого определить владельца со стороны бизнеса и ответственного за техническую часть.
- Проверить доступы, резервные копии и документацию.
- Посмотреть, какие показатели подтверждают нормальную работу.
- Понять, кто получает уведомления и кто обязан на них реагировать.
- Отдельно определить критичность каждого процесса и допустимое время простоя.
После этого обычно становится видно, где действительно нужно постоянное сопровождение, а где достаточно простого мониторинга и возможности вызвать специалиста при необходимости.
Если же автоматизация только планируется, эту схему стоит определить ещё до разработки.
Потому что внедрение ИИ заканчивается не тогда, когда система впервые успешно обработала реальную задачу.
С этого момента она только начинает жить внутри бизнеса.
