---
title: "SLA dla systemu AI: co da się obiecać, a czego nie"
url: "https://predictes.com/pl/blog/sla-dla-systemu-ai-co-da-sie-obiecac"
description: "Klasyczne SLA mierzy dostępność, a system AI rzadko przestaje działać. Co powinno trafić do umowy na jego utrzymanie i które obietnice powinny Was zaniepokoić."
---

# SLA dla systemu AI: co da się obiecać, a czego nie

5 sierpnia 2026·3 min czytania·predictes

Dział zakupów ma sprawdzony wzór umowy serwisowej: dostępność usługi, czasy reakcji, czasy naprawy, kary za przekroczenia. Dla zwykłego oprogramowania to działa, bo awaria jest widoczna — usługa odpowiada albo nie.

System AI może mieć pełną dostępność i od trzech tygodni odpowiadać gorzej. Umowa napisana według starego wzoru będzie wtedy dotrzymana co do joty, a Waszego problemu nie będzie w niej w ogóle.

## Dlaczego klasyczny wzór nie wystarcza

**Mierzy rzecz, która rzadko się psuje.** Dostępność jest łatwą częścią. Trudna część — jakość odpowiedzi — nie ma w typowej umowie ani definicji, ani pomiaru.

**Zakłada, że błąd widać.** Czas naprawy liczy się od zgłoszenia. Gdy system myli się wiarygodnie, zgłoszenie przychodzi po tygodniach albo wcale.

**Priorytet liczy się technicznie.** Liczba dotkniętych użytkowników, liczba niedziałających komponentów. Tymczasem jedna błędna odpowiedź o cenie albo terminie może ważyć więcej niż godzina niedostępności.

Klasyczne SLA

-   –Mierzy dostępność usługi
-   –Priorytet według wpływu technicznego
-   –Pierwsza reakcja: przywrócić działanie
-   –Raport z liczbą zgłoszeń

SLA dla systemu AI

-   →Mierzy też jakość odpowiedzi
-   →Priorytet według skutku biznesowego
-   →Pierwsza reakcja: zawęzić działanie
-   →Notatka: co się zmieniło i dlaczego

## Co powinno być w umowie

**Zdefiniowany zakres monitorowania jakości.** Które przypadki są oceniane, jak często i co uruchamia alert. Bez tego zdanie „monitorujemy jakość” nie ma treści, którą dałoby się wyegzekwować.

**Priorytety opisane biznesowo.** Napisane przez Waszą stronę, a nie przez dostawcę: co jest incydentem krytycznym, a co drobną niedogodnością.

**Czasy reakcji według priorytetu i wskazany inżynier.** Ktoś, kto zna Wasze wdrożenie, a nie kolejka zgłoszeń, oraz ścieżka eskalacji na wypadek, gdy ta osoba jest niedostępna.

**Ścieżka ograniczenia.** Kto i na jakiej podstawie może zawęzić działanie systemu na czas dochodzenia — uzgodnione przed pierwszym incydentem, a nie w jego trakcie.

**Zmiany modeli testowane przed wdrożeniem.** Wycofania i nowe wersje u dostawcy modelu sprawdzane na Waszym zestawie ewaluacyjnym, zanim dotrą do użytkowników.

**Dostęp do danych.** Jak najwęższy, ograniczony w czasie, zapisywany i opisany w umowie. Zwykle wystarczą metryki, logi i próbkowany zestaw ewaluacyjny, a nie cały korpus dokumentów.

**Okna serwisowe, raport i warunki wyjścia.** Co zostaje przekazane przy zakończeniu współpracy, w jakim formacie i w jakim terminie — rozstrzygnięte, póki macie siłę negocjacyjną.

## Jak napisać priorytety

To jedyna część umowy, której dostawca nie powinien pisać za Was, i zwykle zajmuje najmniej czasu. Wystarczy kilka przykładów na każdy poziom, sformułowanych językiem skutków, a nie komponentów.

**Krytyczny.** System podaje błędne informacje, na podstawie których ktoś podejmuje decyzję finansową, prawną albo dotyczącą bezpieczeństwa — na przykład błędną cenę, termin albo warunek umowy.

**Wysoki.** System myli się w sposób, który użytkownicy zauważają i poprawiają, ale który zabiera im czas albo podważa zaufanie do wszystkich pozostałych odpowiedzi.

**Niski.** Odpowiedzi są merytorycznie poprawne, ale gorsze w formie: za długie, niekonsekwentne, mniej czytelne niż wcześniej.

Przykłady mają większe znaczenie niż definicje. Przy pierwszym incydencie nikt nie będzie interpretował abstrakcyjnego opisu poziomu — wszyscy będą porównywać sytuację z przykładem.

## Czego nikt uczciwie nie obieca

**Że model nigdy się nie pomyli.** Dostawca, który to obiecuje, opisuje coś innego niż system AI.

**Naprawy w stałym czasie dla dowolnego defektu.** Diagnoza problemu z jakością może trwać dłużej niż zawężenie działania. Uczciwie obiecać można reakcję i ograniczenie skutków, a nie termin usunięcia przyczyny.

**Stałej jakości w zmieniającym się otoczeniu.** Gdy zmieniają się Wasze dokumenty albo pytania użytkowników, umowa może obiecać wykrycie i reakcję, a nie to, że nic się nie ruszy.

Gdy w ofercie pojawia się którakolwiek z tych obietnic, warto zapytać, jak dokładnie będzie mierzona. Odpowiedź zwykle pokazuje, że nie będzie.

## Na co patrzeć w cenie

Wycena od użytkownika albo od zapytania sprawia, że opłata rośnie dlatego, że system się udał. Wycena od systemu i zakresu tego nie robi i lepiej wyrównuje interesy obu stron.

Druga rzecz to rachunek za modele. Czy koszt użycia jest w umowie, czy obok niej, i kto co miesiąc odpowiada za wyjaśnienie, dlaczego się zmienił? System, którego kosztu nikt nie umie przypisać, w końcu zostanie oceniony po fakturze, a nie po tym, co robi.

Tak układamy SLA w [utrzymaniu systemów AI](https://predictes.com/pl/services/ai-managed-services): czasy reakcji według priorytetu, wskazany inżynier, zdefiniowany zakres monitorowania jakości — i jasno zapisane, czego obiecać się nie da.

-   SLA
-   umowy
-   utrzymanie
-   zakupy

## Czytaj dalej

-   [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem)
-   [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)