--- title: "Zanim ktoś zbuduje Wam aplikację AI, ustalcie, czyja będzie" url: "https://predictes.com/pl/blog/zanim-ktos-zbuduje-wam-aplikacje-ai-ustalcie-czyja-bedzie" description: "O tym, do kogo należy aplikacja AI, rozstrzyga pierwszy tydzień, a nie przekazanie. Co uzgodnić przed startem prac i jakie pytania ujawniają ukrytą zależność." --- # Zanim ktoś zbuduje Wam aplikację AI, ustalcie, czyja będzie 17 września 2026·3 min czytania·predictes O przekazaniu zwykle rozmawia się w ostatnim miesiącu projektu, gdy jest już za późno, żeby zmienić cokolwiek istotnego. Kod leży wtedy tam, gdzie umieścił go dostawca, wdrożenie działa na infrastrukturze skonfigurowanej przez kogoś innego, prompty są w narzędziu, którego Wasz zespół nigdy nie otworzył, a jedyni ludzie rozumiejący, dlaczego system zachowuje się tak, a nie inaczej, właśnie przechodzą do innego klienta. Nie ma w tym złej woli. Tak po prostu wychodzi, gdy własność traktuje się jako wydarzenie na końcu, a nie warunek od początku. ## Dlaczego w aplikacjach AI jest gorzej Zwykła aplikacja ma kod i dane. Aplikacja AI ma do tego prompty, konfigurację wyszukiwania, przypadki ewaluacyjne, wybory modeli, ustawienia kosztowe i nagromadzoną wiedzę o tym, które niewygodne przypadki ją psuły i dlaczego. Wiele z tego żyje poza kodem i wiele nigdy nie zostaje spisane, jeśli nikt o to nie poprosi. Ma też zależność, której zwykłe oprogramowanie rzadko ma: dostawcę modelu, którego produkty zmieniają się, są wycofywane i przeceniane w rytmie, na który nie macie wpływu. System podpięty bezpośrednio pod model jednego dostawcy ma ukrytą zależność — a jak bardzo ukrytą, okazuje się, gdy ten model się zmieni. ## Co uzgodnić przed startem prac **Kod jest w Waszych repozytoriach od pierwszego commita.** Nie trafia tam dopiero na końcu. Jeśli dostawca chce przez jakiś czas pracować we własnym repozytorium, to powód, żeby zapytać dlaczego. **Wdrożenie działa na Waszej infrastrukturze, z Waszymi sekretami.** Klucze API, poświadczenia i środowiska należą do Was. Dostawca trzymający klucze do produkcji to dostawca, od którego nie da się odejść. **Model siedzi za interfejsem.** Żeby zmiana dostawcy albo modelu była zmianą konfiguracji i ewaluacji, a nie przepisywaniem aplikacji. **Prompty, ustawienia wyszukiwania i przypadki ewaluacyjne są wersjonowane razem z kodem.** Są częścią produktu. Jeśli żyją w panelu dostawcy, odchodzą razem z nim. **Wasi inżynierowie pracują obok od początku.** Nie czytają podsumowania na końcu. Wiedza, która ma znaczenie w systemie AI, dotyczy głównie tego, dlaczego: dlaczego ten przypadek jest w zestawie ewaluacyjnym, dlaczego ten krok używa tamtego modelu. Przechodzi przez wspólną pracę, a nie przez samą dokumentację. **Zaangażowanie dostawcy maleje według spisanego harmonogramu.** Z warunkami przekazania — co, w jakim formacie i do kiedy — uzgodnionymi, póki macie siłę negocjacyjną. - Wasze repozytoriaKod tam od pierwszego dnia, a nie przeniesiony na końcu. - Wasza infrastruktura i sekretyPoświadczenia, klucze i środowiska w Waszych rękach. - Model za interfejsemZmiana dostawcy to konfiguracja i ewaluacja, a nie przepisywanie. - Prompty wersjonowane z kodemPrompty, ustawienia wyszukiwania i przypadki ewaluacyjne są częścią produktu. - Wasi inżynierowie obokWasi ludzie pracują w projekcie, a nie czytają podsumowań. - Spisany harmonogram przekazaniaCo, w jakim formacie i do kiedy — póki macie siłę negocjacyjną. Każda pozycja jest tania pierwszego dnia i droga do wynegocjowania przy przekazaniu. ## Pytania, które ujawniają zależność **„Gdybyście jutro zniknęli, czego nie moglibyśmy zrobić?”** Dobry dostawca odpowie precyzyjnie, a uczciwa odpowiedź skraca się w miarę trwania projektu. **„Czego wymagałaby zmiana modelu?”** Jeśli odpowiedź obejmuje przepisanie aplikacji, zależność jest strukturalna. **„Gdzie jest zestaw ewaluacyjny i kto może go uruchomić?”** To najbardziej wartościowy artefakt w kodzie AI. Jeśli uruchomić go może tylko dostawca, tylko dostawca może bezpiecznie zmieniać system. **„Kto ma dziś dostęp do produkcji?”** Z imienia i nazwiska. Każda osoba spoza Waszej organizacji powinna mieć powód i datę końcową. ## Ile to kosztuje Was Własność nie jest za darmo, a udawanie, że jest, kończy się przekazaniem, którego nikt nie jest w stanie odebrać. Potrzebujecie inżynierów z czasem przydzielonym do projektu — a nie pożyczonych z innej pracy na godziny, które akurat zostały — i kogoś po Waszej stronie, kto będzie odpowiadał za system, gdy dostawca się wycofa. Ta osoba powinna być znana z imienia i nazwiska, zanim podpiszecie umowę. Jeśli brakuje jednego lub drugiego, lepiej wiedzieć to przed startem i zaplanować, niż odkryć przy przekazaniu. ## Jak wygląda dobry wynik W dniu, w którym dostawca odchodzi, nic się nie zmienia. Wasz zespół wdraża, monitoruje i modyfikuje system, tak jak robi to od tygodni. Zestaw ewaluacyjny uruchamia się w Waszym CI. Model dałoby się wymienić w przyszłym kwartale bez osobnego projektu. Dostawca może wrócić przy kolejnym projekcie, ale nie dlatego, że bez niego nic nie działa. Przy [inżynierii aplikacji AI-native](https://predictes.com/pl/services/ai-native-apps-engineering) kod jest w Waszych repozytoriach od pierwszego commita, wdrożenie na Waszej infrastrukturze, sekrety są Wasze, model siedzi za interfejsem, a warunki przekazania uzgadniamy przed rozpoczęciem prac. Nasze zaangażowanie maleje według spisanego harmonogramu, bo tak ma być. - własność kodu - przekazanie - uzależnienie od dostawcy - umowy ## 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)