Пока AI используется как отдельный инструмент сотрудника, к нему редко предъявляют требования, похожие на требования к корпоративным системам. Если чат временно недоступен или ответ приходится получить ещё раз, это обычно воспринимается как небольшая техническая неприятность.
Но после интеграции AI в рабочий процесс ситуация меняется. Система начинает участвовать в обработке заявок, подготовке документов, анализе данных, коммуникации с клиентами или принятии внутренних решений. Если она перестаёт работать, проблема возникает уже не у отдельного сотрудника, а у всего процесса.
На этом этапе возникает необходимость договориться о простых, но конкретных правилах: насколько быстро система должна отвечать, сколько времени допустима недоступность, кто реагирует на сбой и что происходит, если AI не может выполнить задачу.
Именно для этого AI-системе нужен SLA — набор требований к качеству и доступности сервиса.
Почему обычного «AI должен работать» недостаточно
На старте проекта требования часто формулируются слишком общо. Система должна быть доступной, отвечать быстро и выдавать приемлемый результат. Пока пользователей мало, этого может хватать.
После перехода в рабочую эксплуатацию появляются конкретные ситуации. Ответ может занимать несколько минут вместо привычных секунд, внешний сервис может временно не отвечать, интеграция с CRM может перестать передавать данные, а очередь задач — постепенно увеличиваться.
Без заранее определённых критериев непонятно, где заканчивается нормальная работа системы и начинается проблема.
SLA переводит ожидания в измеримые параметры
Вместо формулировки «система должна быстро отвечать» появляется конкретное требование к времени обработки.
Вместо «не должно быть длительных сбоев» фиксируется допустимый уровень доступности. А вместо «если что-то сломалось, нужно починить» появляется понятный порядок реакции.
Это особенно важно, когда AI становится частью критичного процесса и от его работы зависят другие сотрудники или клиенты.
Какие параметры имеет смысл фиксировать
SLA для AI не обязательно должен быть большим техническим документом на десятки страниц. На практике достаточно определить несколько параметров, которые действительно влияют на работу бизнеса.
Например:
- допустимое время ответа;
- доступность системы;
- максимальное время реакции на инцидент;
- максимальное время восстановления;
- допустимая очередь необработанных задач;
- правила обработки ошибок;
- условия перехода на резервный сценарий;
- ответственные за технические и бизнес-проблемы.
Набор параметров зависит от конкретного процесса. Для внутреннего помощника и для системы, которая обрабатывает клиентские обращения, требования будут совершенно разными.
Скорость ответа — не единственный показатель
Компании иногда концентрируются только на задержке ответа AI.
Для рабочего процесса это может быть недостаточно.
Предположим, система отвечает за пять секунд, но затем результат ещё десять минут ждёт проверки сотрудника. Формально AI работает быстро, однако для бизнеса скорость всего процесса от этого не становится выше.
Поэтому SLA лучше привязывать к реальной операции, а не только к техническому показателю модели.
AI должен укладываться в ритм процесса
Если заявка клиента должна быть обработана в течение пятнадцати минут, нет смысла проектировать AI с расчётом только на среднее время ответа.
Нужно учитывать весь путь: поступление данных, обработку, генерацию результата, дополнительные проверки, передачу в следующую систему и возможное участие сотрудника.
AI-сервис должен соответствовать требованиям процесса, а не существовать отдельно от него.
Что происходит, когда SLA отсутствует
Без заранее определённых правил проблемы начинают решаться ситуативно.
Если система стала работать медленнее, команда спорит, насколько это критично. Если выросла очередь, непонятно, кто должен вмешаться. Если AI недоступен несколько часов, сотрудники продолжают ждать или возвращаются к ручной работе.
Каждый такой случай требует отдельного решения.
Со временем это превращается в скрытую операционную нагрузку. Команда тратит время не только на работу с AI, но и на постоянное выяснение того, что считать нормой.
SLA помогает определить приоритет проблемы
Не каждый сбой одинаково опасен.
Если AI-помощник для подготовки внутренних текстов недоступен двадцать минут, сотрудники, скорее всего, смогут продолжить работу другим способом.
Если система автоматически распределяет входящие обращения клиентов, такая же пауза может привести к накоплению очереди и задержкам в обслуживании.
Поэтому SLA должен учитывать критичность конкретного процесса.
Для разных AI-систем нужны разные требования
Внутри одной компании может работать несколько десятков AI-инструментов, и устанавливать для всех одинаковые параметры бессмысленно.
Одной системе достаточно работать в рабочее время. Другой нужна круглосуточная доступность. Для третьей критично не столько время ответа, сколько гарантированная обработка всех поступивших задач.
Чем сильнее AI влияет на операционную деятельность, тем конкретнее должны быть требования к его работе.
Кто отвечает за выполнение SLA
Ещё одна распространённая проблема — отсутствие владельца.
Компания может договориться, что AI должен быть доступен 99% времени, но при этом никто не отвечает за мониторинг. В результате показатель существует только на бумаге.
Нужно заранее определить:
- кто следит за доступностью;
- кто получает уведомление об инциденте;
- кто принимает решение о переходе на ручной процесс;
- кто отвечает за восстановление интеграций;
- кто оценивает последствия сбоя для бизнеса.
Ответственность должна быть распределена не только между техническими специалистами. Если AI влияет на бизнес-процесс, его владелец тоже должен участвовать в контроле.
SLA нужен не только для внешнего подрядчика
Сам термин часто связывают с договором между компанией и поставщиком IT-услуг.
Для AI полезно применять этот подход и внутри организации.
Даже если система разработана собственной командой, остаются зависимости от моделей, API, баз данных, корпоративных систем и инфраструктуры.
Внутренний SLA позволяет зафиксировать ожидания между командами и не превращать каждый инцидент в ручные переговоры.
Что делать с внешними AI-сервисами
Многие AI-системы зависят от внешних поставщиков.
Модель может работать через API, данные могут храниться в облачной системе, а отдельные функции — выполняться сторонним сервисом. Компания при этом не контролирует все элементы цепочки.
Поэтому при проектировании SLA нужно учитывать не только собственные показатели, но и внешние зависимости.
Если критичный процесс полностью зависит от сервиса, который может временно стать недоступным, одного внутреннего обещания «мы восстановим работу быстро» недостаточно.
Резервный сценарий должен быть частью договорённостей
Если внешний AI-сервис недоступен, процесс должен иметь понятный следующий шаг.
Это может быть ручная обработка, использование другой модели, отложенная постановка задачи в очередь или временное ограничение функциональности.
Главное, чтобы сотрудники не узнавали о таком сценарии впервые в момент сбоя.
SLA не должен превращаться в бюрократию
Есть риск и обратного характера: компания создаёт слишком сложные регламенты вокруг небольшого AI-инструмента.
Для внутреннего помощника, которым пользуются несколько человек, не нужны требования уровня банковской транзакционной системы.
SLA должен соответствовать цене простоя и последствиям ошибки. Чем критичнее процесс, тем строже требования. Для второстепенных инструментов правила могут быть гораздо проще.
Так компания не тратит ресурсы на контроль там, где сбой практически ни на что не влияет.
Какие показатели стоит отслеживать после запуска
Одного зафиксированного SLA недостаточно. Нужно периодически сравнивать требования с фактической работой системы.
Полезно отслеживать:
- среднее и максимальное время ответа;
- количество сбоев;
- продолжительность недоступности;
- число задач, ушедших в резервный сценарий;
- размер очереди;
- количество инцидентов;
- время реакции команды;
- время полного восстановления.
Такая статистика показывает, соответствует ли AI заявленным требованиям или система уже работает на пределе своих возможностей.
Когда SLA приходится пересматривать
Требования к AI могут меняться вместе с самим процессом.
Если число пользователей увеличилось в несколько раз, прежняя инфраструктура может перестать справляться. Если AI подключили к новому этапу работы, выросла и цена его простоя. Если система стала обрабатывать клиентские обращения вместо внутренних запросов, прежний уровень доступности уже может оказаться недостаточным.
Поэтому SLA не стоит воспринимать как документ, который подписали один раз и больше к нему не возвращаются.
Его нужно пересматривать при существенном изменении нагрузки, архитектуры или роли AI в бизнесе.
SLA помогает заранее увидеть слабые места
Сам процесс определения требований часто оказывается полезнее самого документа.
Когда команда пытается ответить на вопрос «что произойдёт, если система не работает два часа?», быстро обнаруживаются зависимости, которые раньше никто не учитывал.
Выясняется, что без AI останавливается следующий этап, что никто не знает, как обрабатывать накопившуюся очередь, или что резервный сценарий существует только на словах.
SLA заставляет проектировать эксплуатацию до того, как возникнет реальная авария.
Вывод
AI становится бизнес-сервисом не в момент покупки подписки и не после красивой демонстрации. Это происходит тогда, когда от его работы начинают зависеть реальные операции компании.
На этом этапе недостаточно знать, что система умеет делать. Нужно понимать, как именно она должна работать в штатном режиме, что считается нарушением и кто отвечает за восстановление.
SLA помогает перевести эти ожидания из устных договорённостей в понятные правила. Причём требования должны быть соразмерны роли AI: критичный процесс требует одного уровня контроля, вспомогательный инструмент — другого.
При внедрении AI в бизнес стоит заранее определить не только функциональность системы, но и условия её эксплуатации. Это позволяет избежать ситуации, когда технически работающий AI становится слабым звеном всего процесса.