SLA для ИИ-систем: как измерить и закрепить уровень сервиса

Зачем ИИ-системе отдельный SLA и почему типовой договор поддержки её не закрывает

Когда заказчик подключает к своим процессам внешнюю ИИ-систему — чат-бота для поддержки клиентов, модель скоринга, сервис распознавания документов или генеративную модель для маркетинга, — он покупает не «коробку», а уровень сервиса. Сервис измеряется не наличием доступа к интерфейсу, а тем, насколько стабильно и качественно система выдаёт результат в тот момент, когда он нужен бизнесу. Именно поэтому центральным документом отношений становится «соглашение об уровне сервиса» (SLA, Service Level Agreement) — приложение к договору, в котором стороны переводят расплывчатые обещания «надёжно» и «быстро» в измеримые числа: доступность в процентах, время реакции в минутах, метрики качества модели в долях правильных ответов. Без такого перевода спор о качестве превращается в спор о словах, а слова в суде стоят дёшево.

Российское право прямо не регулирует SLA как отдельный вид договора, но и не препятствует его заключению: стороны свободны определить любые не противоречащие закону условия в силу ст. 421 ГК РФ, а обязательство должно исполняться надлежащим образом в соответствии с его условиями и требованиями закона согласно ст. 309 ГК РФ. На практике SLA встраивается в договор возмездного оказания услуг, регулируемый ст. 779 ГК РФ, — заказчик платит за услугу по предоставлению доступа к ИИ-системе и её сопровождению, а исполнитель обязуется обеспечить согласованный уровень этой услуги. Если же часть работ носит характер доработки или интеграции с фиксируемым результатом, к ней дополнительно применяются правила о подряде, прежде всего ст. 702 ГК РФ, и тогда договор приобретает смешанный характер по смыслу п. 3 ст. 421 ГК РФ.

Принципиальное отличие ИИ-системы от классического программного обеспечения в том, что её поведение вероятностно. Обычный сервис либо работает по заданному алгоритму, либо нет; ИИ-модель всегда выдаёт результат с некоторой долей ошибок, и эта доля — нормальное, ожидаемое свойство, а не дефект. Поэтому SLA для ИИ-системы вынужден описывать сразу два слоя обязательств: инфраструктурный (система доступна, отвечает в срок, инциденты устраняются) и содержательный (качество ответов модели не опускается ниже согласованного порога). Смешивать их нельзя: падение точности модели на новых данных и падение сервера — это разные события с разными последствиями и разной ответственностью. Грамотный SLA с самого начала разводит эти два слоя по разным метрикам и разным разделам.

Доступность, время реакции и восстановления: как считать инфраструктурный слой

Доступность (availability) — базовая метрика любого облачного сервиса. Её записывают в процентах за расчётный период, обычно за календарный месяц: «доступность ИИ-системы составляет не менее 99,5 % времени в течение календарного месяца». За этой простой формулой прячется несколько ловушек, каждая из которых способна обнулить ценность показателя. Первая — определение «недоступности». Стороны должны заранее договориться, что считается простоем: полная неработоспособность интерфейса, превышение времени ответа модели сверх порогового, ошибки определённого класса (например, доля ответов с кодом 5xx выше согласованной). Если этого не сделать, исполнитель будет считать систему «доступной» до тех пор, пока отвечает хоть что-нибудь, а заказчик — недоступной с первой же замедленной выдачи.

Вторая ловушка — исключаемые периоды. Из расчёта доступности традиционно вычитают плановые технические работы, заранее согласованные с заказчиком, а также простои по причинам вне контроля исполнителя: сбои на стороне самого заказчика, отказ сторонних провайдеров связи, форс-мажор. Здесь важен баланс: чем шире перечень исключений, тем менее ценен показатель доступности. Я рекомендую жёстко лимитировать окно плановых работ (например, не более четырёх часов в месяц и только в согласованное ночное время) и требовать предварительного уведомления за разумный срок, иначе плановое окно превращается в лазейку. Сама обязанность исполнителя обеспечивать доступность вытекает из общего требования надлежащего исполнения по ст. 309 ГК РФ, а измеримый порог придаёт ей юридическую определённость, без которой нарушение невозможно доказать по ст. 401 ГК РФ.

Время реакции и время восстановления описывают, как быстро исполнитель отзывается на инцидент и устраняет его. Эти показатели имеет смысл дифференцировать по приоритетам инцидентов. Критический инцидент — полная остановка ИИ-системы или сбой, парализующий ключевой бизнес-процесс заказчика; высокий — существенная деградация качества или производительности; средний и низкий — частные дефекты, не блокирующие работу. Для каждого приоритета задаётся своё время реакции (исполнитель подтвердил получение заявки и приступил к диагностике) и своё целевое время восстановления. Принципиально различать «время реакции» и «время решения»: реакцию исполнитель контролирует полностью, а срок окончательного устранения сложного дефекта модели не всегда предсказуем, поэтому по критическим инцидентам разумнее фиксировать жёсткую реакцию и обязательство непрерывно работать над устранением, а целевое время решения формулировать как ориентир с правом заказчика на сервисные кредиты при его превышении.

Отдельно стоит описать порядок регистрации инцидентов: единый канал подачи заявок (сервис-деск, выделенная почта), форма заявки, момент, с которого начинает течь время реакции, и фиксацию хронологии. Без зафиксированной хронологии спор о том, уложился ли исполнитель в SLA, превращается в обмен ничем не подтверждёнными утверждениями, а бремя доказывания нарушения по общему правилу лежит на той стороне, которая на него ссылается, что в арбитражном процессе прямо закреплено в ст. 65 АПК РФ. Поэтому система тикетов с метками времени — это не ИТ-удобство, а доказательственная база.

Метрики качества модели: измеримость там, где результат вероятностен

Самая сложная часть SLA для ИИ-системы — показатели качества самой модели. Здесь нельзя ограничиться доступностью: сервер может работать идеально, а модель — выдавать мусор. Качество описывают через метрики, привычные для машинного обучения, но переведённые в договорный язык: доля правильных ответов (точность), полнота, доля ложных срабатываний, для генеративных моделей — доля ответов, прошедших модерацию или соответствующих заданным критериям. Ключевое требование к таким метрикам — воспроизводимость измерения. В договоре должно быть описано, на каком наборе данных, с какой периодичностью и кто именно проводит замер; иначе условие о качестве окажется неопределённым, а значит, практически неисполнимым, ведь надлежащее исполнение по ст. 309 ГК РФ предполагает понятный обеим сторонам критерий.

Чтобы метрика качества работала, стороны фиксируют эталонный (тестовый) набор данных и методику его обновления. Распространённая ошибка — измерять качество на тех же данных, на которых модель обучалась: показатели будут завышены и не отразят реальную работу. Поэтому эталонный набор должен быть репрезентативным и периодически обновляться под реальный профиль запросов заказчика, а ответственность за деградацию качества на принципиально новых типах данных, не охваченных согласованным профилем, должна распределяться отдельно — иначе исполнитель отвечает за то, что объективно выходит за рамки заказанной услуги. Это прямое следствие принципа, согласно которому лицо отвечает при наличии вины и в пределах принятого на себя обязательства по ст. 401 ГК РФ.

Важно различать гарантию качества и гарантию результата. Исполнитель может гарантировать, что модель в среднем выдаёт не менее определённой доли правильных ответов на согласованном наборе, но не может гарантировать правильность каждого конкретного ответа — это противоречило бы вероятностной природе технологии. Поэтому в SLA уместна формула «целевой уровень качества» с механизмом реагирования при его недостижении (доработка модели, дообучение, сервисные кредиты), а не безусловная гарантия безошибочности. Попытка записать стопроцентную гарантию точности не усилит позицию заказчика, а сделает условие заведомо нарушаемым и подтолкнёт исполнителя завышать цену под несбыточное обязательство.

Сервисные кредиты: неустойка, которую важно правильно квалифицировать

Сервисные кредиты (service credits) — основной экономический механизм SLA. При недостижении согласованных показателей исполнитель предоставляет заказчику скидку или возврат части вознаграждения, рассчитываемые по заранее заданной шкале: чем серьёзнее и длительнее нарушение, тем больше кредит. С точки зрения российского права сервисный кредит чаще всего квалифицируется как неустойка по ст. 330 ГК РФ, то есть как заранее оценённая сумма, которую должник уплачивает (или на которую уменьшается его требование) при ненадлежащем исполнении. Эта квалификация имеет серьёзные последствия, которые стороны обязаны учитывать.

Первое последствие: соглашение о неустойке должно быть совершено в письменной форме, что прямо требует ст. 331 ГК РФ; для SLA это выполняется автоматически, поскольку он является письменным приложением к договору. Второе: размер неустойки суд вправе снизить, если он явно несоразмерен последствиям нарушения, на основании ст. 333 ГК РФ и с учётом разъяснений Постановления Пленума ВС РФ от 24.03.2016 № 7; для предпринимателей снижение допускается лишь в исключительных случаях и по заявлению должника. Третье и самое важное — соотношение неустойки с убытками. По общему правилу неустойка зачётная: убытки взыскиваются в части, не покрытой ею, как предусмотрено ст. 394 ГК РФ. Если стороны хотят, чтобы сервисные кредиты были единственной компенсацией за нарушение SLA и исключали взыскание убытков сверх них, это нужно прямо записать (исключительная неустойка) — молчание толкуется в пользу зачётного характера и оставляет заказчику право довзыскать убытки.

Здесь интересы сторон расходятся, и SLA должен честно отражать достигнутый компромисс. Исполнителю выгодна исключительная неустойка с потолком: она ограничивает его риск предсказуемой суммой. Заказчику выгодна зачётная неустойка плюс право на убытки: сервисные кредиты редко покрывают реальные потери от простоя критичной системы. Практический баланс, который я обычно рекомендую, — сервисные кредиты как основной и быстрый механизм компенсации без доказывания убытков, но с сохранением права заказчика взыскать прямые убытки сверх кредитов при грубых и длящихся нарушениях, и с разумным общим лимитом ответственности. Возможность ограничить размер ответственности по соглашению сторон опирается на ст. 400 ГК РФ, но такое ограничение не действует, если нарушение допущено умышленно, — это императивно установлено п. 4 ст. 401 ГК РФ.

Отдельно стоит предусмотреть механику начисления кредитов: автоматическое уменьшение следующего платежа или возврат, заявительный порядок (заказчик предъявляет расчёт в установленный срок), потолок кредитов за период. Если оставить порядок неурегулированным, заказчик рискует «сгоранием» права на кредит, а исполнитель — бесконтрольным накоплением требований. На сумму неосновательно удержанного или несвоевременно возвращённого вознаграждения могут начисляться проценты по ст. 395 ГК РФ, поэтому сроки расчётов по кредитам лучше прописать явно.

Права на доработки и интеграции: кто становится правообладателем

В ходе эксплуатации ИИ-системы исполнитель почти всегда что-то дорабатывает под заказчика: пишет коннекторы к учётным системам, настраивает промпты, дообучает модель на данных клиента, создаёт отчётные модули. Все эти результаты — объекты интеллектуальных прав, и вопрос «кому они принадлежат» обязан быть решён в договоре, иначе он решится не в пользу заказчика. По общему правилу исключительное право на программу, созданную по договору, регулируется ст. 1296 ГК РФ: если программа разработана по заказу, исключительное право принадлежит заказчику, если договором не предусмотрено иное; но это правило о заказе на создание, и его легко перекрыть формулировкой «иное», поэтому полагаться на диспозитивную норму без явного условия рискованно.

Гораздо чаще доработки оформляют не как создание нового продукта, а как улучшение лицензируемой ИИ-системы, права на которую остаются у исполнителя. Тогда заказчик получает не исключительное право, а лицензию по ст. 1235 ГК РФ, и принципиально важно описать её объём: какие способы использования разрешены, на какой срок и территорию, можно ли передавать право по сублицензии. Если в договоре умолчать о возмездности, лицензионный договор между коммерсантами предполагается возмездным, а при отсутствии условия о размере вознаграждения может быть признан незаключённым в силу п. 5 ст. 1235 ГК РФ. Для заказчика критично, чтобы дообученная на его данных модель и созданные под него интеграции оставались доступны ему даже после прекращения отношений — это вопрос непрерывности бизнеса, и решать его нужно в разделе о последствиях расторжения, а не задним числом.

Особый сюжет — результаты дообучения модели на данных заказчика. Здесь сталкиваются два интереса: исполнитель хочет улучшать свою базовую модель и переиспользовать наработки для других клиентов, заказчик не хочет, чтобы его данные и полученные на них улучшения утекли к конкурентам. Компромисс обычно строится так: базовая модель и общие улучшения остаются за исполнителем, а специфические для заказчика веса, наборы промптов и интеграции либо передаются заказчику, либо предоставляются ему по неисключительной лицензии с запретом их использования в пользу третьих лиц. Принадлежность исключительного права и пределы его использования определяются по ст. 1229 ГК РФ, и именно её логику договор должен конкретизировать применительно к слоям ИИ-системы.

Персональные данные и поручение обработки: где SLA встречается со 152-ФЗ

Большинство ИИ-систем обрабатывает персональные данные: обращения клиентов, записи разговоров, сведения о сотрудниках, биометрию. В этой части SLA не существует в отрыве от законодательства о персональных данных. Когда исполнитель обрабатывает персональные данные по заданию заказчика, заказчик выступает оператором, а исполнитель — лицом, осуществляющим обработку по поручению оператора. Такое поручение должно быть оформлено договором или иным актом и содержать обязательный перечень условий, прямо предусмотренный ч. 5 ст. 18 152-ФЗ и ст. 6 152-ФЗ: перечень действий с данными, цели обработки, обязанность соблюдать конфиденциальность и обеспечивать безопасность, требования к защите.

Ключевой момент для распределения ответственности: перед субъектом персональных данных за действия обработчика отвечает оператор, то есть заказчик, тогда как обработчик отвечает уже перед оператором. Это значит, что заказчик заинтересован переложить на исполнителя в порядке регресса все санкции и убытки, возникшие из-за нарушения исполнителем правил обработки, — и SLA должен содержать такую регрессную оговорку с привязкой к мерам безопасности. Сами меры безопасности не отдаются на усмотрение: оператор и обработчик обязаны принимать необходимые правовые, организационные и технические меры в силу ст. 19 152-ФЗ, а перечень обязательных организационных мер закреплён в ст. 18.1 152-ФЗ.

Цена вопроса резко выросла. С 30 мая 2025 года действует Федеральный закон от 30.11.2024 № 420-ФЗ, ужесточивший административную ответственность за нарушения в области персональных данных и введший оборотные штрафы за повторную утечку; базовые санкции по ст. 13.11 КоАП РФ также повышены. Для заказчика это означает, что условие SLA об уведомлении о любом инциденте безопасности в жёсткий срок (часы, а не дни), о содействии в расследовании и о компенсации наложенных санкций перестало быть формальностью и стало одним из самых дорогих пунктов соглашения. Если ИИ-система обрабатывает данные граждан России, нельзя забывать и про требование локализации первичной обработки на территории страны, установленное ч. 5 ст. 18 152-ФЗ, — место размещения серверов исполнителя становится предметом прямого условия SLA, а не технической деталью.

Ответственность за ошибки и сбои: разводим вероятностную ошибку и нарушение обязательства

Ответственность исполнителя за работу ИИ-системы строится на разграничении двух принципиально разных событий. Сбой инфраструктуры (недоступность, превышение времени реакции, нарушение мер безопасности) — это классическое нарушение обязательства, влекущее ответственность по правилам ст. 393 ГК РФ о возмещении убытков и согласованную в SLA неустойку. Ошибка модели — выдача неверного, но «штатного» по вероятностной природе ответа — нарушением сама по себе не является, если фактический уровень качества не опустился ниже согласованного порога. Эту границу SLA обязан провести явно: иначе заказчик будет требовать ответственности за каждую отдельную ошибку, а исполнитель — отрицать ответственность за систематическую деградацию качества.

Предприниматель по общему правилу отвечает независимо от вины и освобождается только при непреодолимой силе, как установлено п. 3 ст. 401 ГК РФ. Это значит, что простая ссылка исполнителя на «непредсказуемость нейросети» от ответственности за нарушение измеримых показателей не освобождает: если он принял на себя обязательство по доступности и качеству, он отвечает за его нарушение по правилам строгой предпринимательской ответственности. Поэтому исполнители стремятся ограничить ответственность: установить потолок (как правило, привязанный к стоимости услуг за период), исключить упущенную выгоду и косвенные убытки. Такое ограничение законно в силу ст. 400 ГК РФ, но имеет жёсткий предел — оно ничтожно в части умышленного нарушения по п. 4 ст. 401 ГК РФ, и эту оговорку нельзя обойти никакой формулировкой.

Особого внимания требуют решения, которые ИИ-система принимает или предлагает автономно: скоринговые отказы, автоматическая модерация, медицинские или юридические подсказки. Чем выше цена ошибки для третьих лиц, тем важнее в договоре зафиксировать роль человека в контуре принятия решения и распределить ответственность между разработчиком, поставщиком сервиса и пользователем, который опирается на вывод модели. Если заказчик использует подсказку ИИ как окончательное решение без проверки, переложить весь риск на исполнителя не удастся: вклад самого заказчика в наступление вреда учитывается по правилам о вине кредитора, а суд уменьшает ответственность должника, если нарушению содействовали действия самого кредитора, что прямо предусмотрено ст. 404 ГК РФ.

Конфиденциальность, поддержка, обновления и возврат данных при расторжении

Заказчик передаёт исполнителю не только персональные данные, но и коммерчески ценную информацию: клиентскую базу, специфику процессов, иногда — секреты производства. Режим конфиденциальности в SLA должен охватывать всё это и переживать срок действия договора. Договорная защита опирается на режим коммерческой тайны по Федеральному закону от 29.07.2004 № 98-ФЗ и на общую возможность сторон установить обязанность не разглашать полученные сведения; нарушение влечёт ответственность в виде убытков по ст. 15 ГК РФ и согласованной неустойки. Принципиально описать, что именно является конфиденциальной информацией, как она маркируется, какие исключения действуют (общедоступные сведения, раскрытие по требованию закона) и какой срок защиты сохраняется после прекращения отношений.

Поддержка и обновления — содержательное ядро длящегося SLA. Стоит различать корректирующее сопровождение (устранение дефектов в рамках согласованных показателей), адаптивное (подстройка под изменения окружения заказчика) и развивающее (новая функциональность за отдельную плату). Обновления модели несут специфический риск: новая версия может улучшить одни метрики и ухудшить другие, поэтому в SLA полезно предусмотреть тестирование обновлений на эталонном наборе перед выкаткой в продуктив и право заказчика на откат, если обновление роняет согласованное качество. Обязанность исполнителя поддерживать согласованный уровень после обновления — это продолжение того же требования надлежащего исполнения по ст. 309 ГК РФ, а не новая услуга, и подменять поддержание качества платными апдейтами недопустимо.

Самый недооценённый раздел — последствия расторжения и возврат данных. Договор возмездного оказания услуг может быть расторгнут заказчиком в одностороннем порядке с возмещением фактических расходов исполнителя по ст. 782 ГК РФ, а порядок одностороннего отказа в целом подчиняется ст. 450.1 ГК РФ. Но техническое прекращение доступа без процедуры возврата данных способно парализовать бизнес заказчика. Поэтому SLA обязан описать «выходной» сценарий: в каком формате и в какой срок исполнитель возвращает данные заказчика и результаты их обработки, как обеспечивается переходный период для миграции на другого поставщика, в какой срок и каким способом исполнитель удаляет данные со своих систем с предоставлением подтверждения. Последствия расторжения в части уже исполненного и возврата предоставленного определяются с учётом ст. 453 ГК РФ, а обязанность обработчика прекратить обработку и уничтожить персональные данные по указанию оператора прямо вытекает из правил ст. 18.1 152-ФЗ.

Споры по SLA разумно вести через обязательный претензионный порядок: для арбитражных споров он по общему правилу обязателен в силу ч. 5 ст. 4 АПК РФ, а чёткое описание досудебной процедуры в договоре ускоряет урегулирование и фиксирует доказательства. Подсудность стороны вправе изменить договорной оговоркой по ст. 37 АПК РФ; в технологичных проектах нередко выбирают и третейское разбирательство. Главное — чтобы к моменту спора у заказчика на руках была доказательственная база: журналы инцидентов, отчёты о замерах качества, переписка по претензиям. SLA, который не порождает измеримых и фиксируемых данных, юридически пуст, каким бы красивым ни выглядел на бумаге.

Краткое заключение

SLA для ИИ-системы — это инструмент управления сервисом, а не декоративное приложение. Его ценность определяется тремя вещами: измеримостью (каждый показатель имеет число, методику замера и фиксацию), сбалансированностью ответственности (инфраструктурные сбои и вероятностные ошибки модели разведены, потолки и исключения честно отражают компромисс) и продуманностью выхода (возврат данных и переходный период защищают непрерывность бизнеса). Юридически SLA опирается на свободу договора по ст. 421 ГК РФ, правила о возмездных услугах по ст. 779 ГК РФ, механизм неустойки по ст. 330 ГК РФ и обязательные требования законодательства о персональных данных. Хорошо составленный SLA не гарантирует, что ИИ-система никогда не ошибётся, — он гарантирует, что при любом сбое стороны заранее знают, что считается нарушением, кто за него отвечает и сколько это стоит.