Пилот ИИ-ассистента отработал, демо понравилось руководству, сервис выкатили в продакшн – а через две недели он начал отвечать чушью, и никто этого не заметил, пока не пожаловались пользователи. Знакомая история. Промышленная эксплуатация ИИ – это не про модель, а про дежурство, метрики и регламенты. Разберём, как построить SLA для сервиса, который ведёт себя недетерминированно по своей природе.

Что ломается в ИИ-сервисах и почему обычного мониторинга мало

Классический SLA меряет доступность: сервис отвечает за 200 мс, код 200, всё зелёное. Для ИИ этого недостаточно. Эндпоинт может быть жив и быстр, но выдавать галлюцинации, деградировать после обновления внешней LLM или ломаться на новых типах запросов, которых не было в тестовой выборке.

Поэтому SLA для ИИ делим на три слоя.

  • Доступность инфраструктуры – привычные uptime, latency, error rate по API. Здесь работают стандартные практики и инструменты.
  • Качество генерации – доля ответов, прошедших автоматические проверки: фактологические гварды, проверка на отказ отвечать вне домена, формат ответа, токсичность. Меряем на потоке, а не раз в квартал.
  • Бизнес-результат – доля задач, закрытых без эскалации на человека, и доля жалоб. Это то, ради чего сервис вообще запускали.

Без второго и третьего слоя вы узнаете о проблеме от пользователя, а не от системы.

Дежурство: кто на линии и что он делает

ИИ-сервис требует своей роли on-call. Дежурный по ИИ – не тот же человек, что держит сетевую инфраструктуру. Ему нужны runbook'и под специфичные инциденты: всплеск галлюцинаций, дрейф качества после смены версии модели, утечка чувствительных данных в промпт, отказ внешнего провайдера.

Минимальный набор для дежурства:

  • Дашборд с метриками качества в реальном времени, а не только с CPU и памятью.
  • Алерты на просадку качества – например, доля ответов, отклонённых гвардами, выросла с 2% до 10%.
  • Кнопка отката на предыдущую версию модели и промптов. Версионируйте всё, включая системные инструкции.
  • Регламент эскалации – когда дежурный сам откатывает, а когда поднимает команду разработки.

Закладывайте время реакции в SLA отдельно для деградации качества. Просадка точности на 15% не роняет сервис формально, но бьёт по доверию сильнее, чем пятиминутный даунтайм.

Контур безопасности и работа в регулируемой среде

Для госсектора и КИИ ИИ-сервис – это ещё и объект регулирования. Промпты и ответы часто содержат персональные данные, а с сентября 2025 года требования к их обработке ужесточились – мы разбирали это в материалах про вступление в силу поправок к 152-ФЗ и усиление требований к субъектам КИИ. Логи ИИ-сервиса – это хранилище ПДн, и SLA должен покрывать их защиту, ретеншн и аудит доступа наравне с любой другой системой. Если ассистент работает через мобильные устройства сотрудников, добавьте контур управления мобильным доступом.

Всё это разворачивается на изолированном инфраструктурном контуре: от проектирования стенда и выстраивания дежурства до интеграции ИИ-сервиса в существующие процессы эксплуатации и регламенты on-call.

Вывод

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