---
title: "Kto prowadzi system AI dzień po uruchomieniu?"
url: "https://predictes.com/pl/blog/kto-prowadzi-system-ai-dzien-po-uruchomieniu"
description: "Budżet projektu kończy się w dniu uruchomienia, a koszty i ryzyko dopiero wtedy się zaczynają. Jak zdecydować, kto ma prowadzić system AI i czego to wymaga od Was."
---

# Kto prowadzi system AI dzień po uruchomieniu?

6 czerwca 2026·3 min czytania·predictes

Projekty AI są budżetowane do dnia uruchomienia. Plan, zespół, kamienie milowe i odbiór — wszystko kończy się w chwili, w której system dostaje prawdziwych użytkowników. A dokładnie od tej chwili system zaczyna się zmieniać: przybywa dokumentów, pytania użytkowników przesuwają się w nowe strony, dostawca modelu wycofuje wersję, na której wszystko testowano.

Pytanie, kto to prowadzi, pada zwykle po fakcie, gdy zespół projektowy już się rozszedł. Wtedy odpowiedź jest najdroższa.

## Co właściwie trzeba prowadzić

Nie tylko serwery. Dostawca chmury utrzyma infrastrukturę lepiej i taniej niż ktokolwiek inny, ale nie powie Wam, że od dwóch tygodni odpowiedzi są gorsze.

**Jakość odpowiedzi.** Stale oceniany zestaw ewaluacyjny i ktoś, kto patrzy na wynik i reaguje na ruch, zanim zgłoszą go użytkownicy.

**Cykl życia modeli.** Dostawcy wycofują wersje i zmieniają zachowanie modeli. Każdą taką zmianę trzeba sprawdzić na Waszych przypadkach, zanim dotrze do ludzi.

**Koszt.** Rachunek za modele rośnie razem z sukcesem systemu i potrafi skoczyć po jednej niewinnej zmianie. Ktoś musi umieć przypisać go do konkretnych funkcji.

**Dane pod spodem.** Ponowne indeksowanie, odświeżanie osadzeń i egzekwowanie retencji, gdy Wasze dokumenty się zmieniają.

**Incydenty bez awarii.** System nie pada, tylko zaczyna się mylić. Ktoś musi mieć prawo zawęzić jego działanie na czas dochodzenia, bez zwoływania komitetu.

## Trzy opcje, z których jedna jest domyślna

**Własny zespół.** Najlepsza odpowiedź docelowo, jeśli macie ludzi, którzy rozumieją system i mają na niego czas zapisany w grafiku — a nie „w wolnej chwili” między projektami.

**Zewnętrzne utrzymanie.** Rozsądne, gdy zespół budujący był zewnętrzny albo poszedł dalej, a system jest zbyt ważny, żeby czekać, aż własny zespół dojrzeje. Pod warunkiem, że umowa jest zbudowana wokół przekazywania, a nie trwałej zależności.

**Nikt.** Opcja, której nikt nie wybiera świadomie i która zostaje, gdy nie wybierze się żadnej innej. System działa, bo nikt go nie wyłączył, a jego jakość jest znana dokładnie do pierwszej poważnej reklamacji.

Wysoka krytycznośćNiska krytyczność

Utrzymanie zewnętrzneZ harmonogramem przekazania, żeby zależność malała.

Własny zespółZ właścicielem jakości i czasem zapisanym w grafiku.

Lekki nadzórPodstawowe kontrole i decyzja, czy system w ogóle zostaje.

Rutyna zespołuProwadzony obok innych systemów, z tymi samymi kontrolami.

Mało kompetencjiDużo kompetencji

Oś pozioma to kompetencje Waszego zespołu; z czasem system powinien przesuwać się w prawo.

## Ile uwagi wymaga to od Was

Nawet przy zewnętrznym utrzymaniu część odpowiedzialności zostaje po Waszej stronie i nie da się jej oddać.

**Właściciel jakości po stronie biznesu.** Ktoś, kto definiuje, co jest incydentem. Błędna odpowiedź o cenie albo terminie to inny priorytet niż odpowiedź za długa, a tej różnicy nie powinien ustalać inżynier.

**Decyzja o ograniczeniu.** Wskazana osoba, która może zgodzić się na zawężenie działania systemu w ciągu godzin, a nie na najbliższym posiedzeniu.

**Jedna strona miesięcznie, przeczytana.** Co się zmieniło, co się zepsuło, ile kosztowało i co jest rekomendowane. Jeśli nikt tej strony nie czyta, utrzymanie działa w próżni, a jego ustalenia nie zmieniają żadnych decyzji.

To niewiele czasu. Ale musi mieć przypisane nazwisko.

## Co musi być w przekazaniu

Niezależnie od tego, kto przejmuje system, przekazanie powinno zawierać kilka rzeczy, które najłatwiej przygotować przed uruchomieniem, a najtrudniej odtworzyć po nim.

**Zestaw ewaluacyjny.** Prawdziwe przypadki ze znanymi dobrymi odpowiedziami. Bez niego nikt nie zmierzy, czy system się pogarsza, a monitorowanie jakości staje się deklaracją.

**Punkt wyjścia.** Obecna jakość, koszt i opóźnienia zapisane w dniu przekazania, żeby późniejsza zmiana była faktem, a nie wrażeniem.

**Runbooki i dostępy.** Co robić przy awariach, które na pewno się zdarzą, i kto ma do czego dostęp — spisane, a nie przekazane ustnie na ostatnim spotkaniu.

**Lista znanych słabości.** Przypadki, o których zespół budujący wie, że system radzi sobie z nimi źle. Rzadko powstaje bez wyraźnej prośby, a oszczędza następcom tygodnie odkrywania tego samego.

## Kiedy podjąć decyzję

Przed uruchomieniem, nie po. Najtańszy moment jest wtedy, gdy zespół budujący jeszcze jest na miejscu: przekazanie z zestawem ewaluacyjnym, runbookami i dostępami kosztuje wtedy dni. Kilka miesięcy później ktoś musi to odtworzyć z kodu i z pamięci ludzi, którzy pracują już gdzie indziej.

Dobrym testem jest jedno pytanie zadane przed odbiorem: kto dzień po uruchomieniu dostanie pierwszy alert o spadku jakości i co wolno mu zrobić? Jeśli nie ma nazwiska, decyzja o prowadzeniu systemu nie zapadła. Odłożono ją na moment, w którym będzie droższa.

Jeśli system już działa i nikt go nie prowadzi, nie jest za późno. [Utrzymanie systemów AI](https://predictes.com/pl/services/ai-managed-services) często zaczyna się od systemu, którego nie budowaliśmy, i od zbudowania zestawu ewaluacyjnego, którego wcześniej nie było — z poziomem wsparcia, który z czasem ma maleć, a nie rosnąć.

-   utrzymanie
-   przekazanie
-   odpowiedzialność

## 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)