Budowa Aplikacji AI

Aplikacja z AI – czym jest i kiedy warto ją budować

Aplikacja z AI to zwykłe oprogramowanie (interfejs, backend, baza danych, uprawnienia), w którym model językowy wykonuje kluczowe zadanie produktu: czyta dokumenty, odpowiada na pytania, klasyfikuje, generuje albo podejmuje kroki w procesie. Budowa ma sens wtedy, gdy to zadanie jest specyficzne dla Twoich danych lub procesu i gotowe narzędzie go nie obsłuży.

Większość kodu w takiej aplikacji to nadal klasyczna inżynieria. Model jest jedną z warstw, ale najdroższą i najmniej przewidywalną: odpowiada z opóźnieniem, kosztuje przy każdym wywołaniu i czasem się myli. Dlatego tworzenie aplikacji AI różni się od zwykłego projektu głównie tym, że od pierwszego tygodnia trzeba mierzyć jakość odpowiedzi i koszt modelu, a nie tylko to, czy funkcja działa.

Budować czy kupić

Raport MIT NANDA z 2025 r., opisany przez Fortune, wskazał, że wdrożenia oparte na narzędziach kupionych od wyspecjalizowanych dostawców docierały do produkcji w około 67% przypadków, a budowane wyłącznie wewnętrznie mniej więcej w jednej trzeciej. Czytam to jako argument, żeby budować tylko tam, gdzie gotowe rozwiązanie naprawdę nie pasuje, a nie dlatego, że własny kod brzmi lepiej.

• Buduj, gdy AI jest sednem wartości produktu, który sprzedajesz, albo gdy proces i dane są na tyle nietypowe, że SaaS wymusiłby zmianę sposobu pracy.
• Buduj, gdy dane nie mogą trafić do zewnętrznego narzędzia albo potrzebujesz pełnej własności kodu.
• Kup, gdy istnieje narzędzie, które pokrywa większość potrzeb, a różnice nie są krytyczne.
• Zacznij od automatyzacji, nie aplikacji, gdy potrzebujesz połączyć istniejące systemy, a nikt nie potrzebuje nowego interfejsu.

Architektura aplikacji AI – API modeli, otwarte modele, RAG i evals

Typowa aplikacja AI ma cztery warstwy: interfejs, backend z logiką i danymi, warstwę AI (model, wyszukiwanie w dokumentach, narzędzia) oraz ewaluację i monitoring, które mówią, czy całość działa dobrze. Zaczynam od najprostszej wersji warstwy AI, która rozwiązuje zadanie, i dokładam złożoność dopiero wtedy, gdy testy pokażą, że jest potrzebna.

API modeli czy otwarte modele

API komercyjnych modeli (OpenAI, Anthropic, Google) daje najszybszy start i najmocniejsze modele, a płacisz za użycie. Otwarte modele uruchamiane na własnej infrastrukturze dają pełną kontrolę nad danymi, ale dochodzi serwer z GPU, aktualizacje i testy po każdej zmianie wersji. W większości projektów zaczynam od API z umową powierzenia, a model lokalny dokładam tylko dla kroków na najbardziej wrażliwych danych. Jak to porównać na własnych danych, opisałem w tekście jak wybrać model LLM.

RAG, czyli odpowiedzi na podstawie Twoich dokumentów

RAG (Retrieval-Augmented Generation) najpierw wyszukuje pasujące fragmenty dokumentów, a dopiero potem model formułuje odpowiedź. Jakość zależy głównie od wyszukiwania: Anthropic w publikacji o Contextual Retrieval (2024) pokazał, że kontekst dodany do fragmentów i połączenie wyszukiwania wektorowego z BM25 zmniejszyły liczbę nieudanych wyszukiwań o 49%, a z rerankingiem o 67%, bez zmiany modelu. Produkcyjny przykład to silnik wycen oparty na RAG na 70 historycznych kosztorysach w case study Konkret.

Agent tylko wtedy, gdy workflow nie wystarcza

Anthropic w tekście „Building effective agents” (2024) radzi szukać najprostszego możliwego rozwiązania i zwiększać złożoność tylko wtedy, gdy jest to potrzebne. W aplikacjach oznacza to, że stała ścieżka z jednym lub dwoma wywołaniami modelu zwykle wygrywa z agentem, który sam wybiera narzędzia: jest tańsza, szybsza i łatwiejsza do testowania.

MVP aplikacji AI – jak wyciąć zakres do jednej hipotezy

MVP aplikacji AI to najmniejsza działająca wersja produktu, która sprawdza na prawdziwych użytkownikach jedną hipotezę: że AI rozwiązuje ich problem na tyle dobrze, że będą z niego korzystać i za niego zapłacą. Wszystko, co nie służy tej hipotezie, czeka na kolejną wersję.

Ten rygor wynika z danych. CB Insights w analizie z 2026 r. przejrzał 431 startupów finansowanych przez fundusze VC, które zamknęły się od 2023 r. Słabe dopasowanie produktu do rynku pojawiło się jako przyczyna w 43% przypadków, a brak kapitału w 70%, przy czym autorzy zaznaczają, że koniec pieniędzy to zwykle ostatni objaw, a nie źródło problemu. Kod rzadko jest największym ryzykiem MVP.

Co zostaje w MVP, a co wypada

• Zostaje: jedna pętla produktu od wejścia użytkownika do wyniku AI, logowanie, baza danych, analityka zachowań i zestaw testowy do oceny odpowiedzi.
• Zostaje: pomiar kosztu modelu na aktywnego użytkownika, bo w produktach AI to on decyduje, czy model biznesowy się spina.
• Wypada: panel administracyjny z wieloma rolami, integracje „na zapas”, wiele modeli, dopracowane onboardingi i funkcje, o które nikt jeszcze nie prosił.
• Wypada: agent tam, gdzie hipotezę sprawdzi stała ścieżka z jednym wywołaniem modelu.

Szczegóły zakresu, harmonogramu i tego, co dostajesz, są na stronie MVP aplikacji AI.

Jak wygląda tworzenie aplikacji AI krok po kroku i ile trwa

MVP aplikacji AI buduję zwykle w 4–8 tygodni, a pełną aplikację dłużej, w zależności od liczby modułów, integracji i wymagań bezpieczeństwa. Pracuję w dwutygodniowych sprintach, a od pierwszego sprintu masz działającą wersję, którą można klikać.

1. Warsztat i zakres (kilka dni). Problem, użytkownik, dane, hipoteza i definicja sukcesu. Na tej podstawie powstają harmonogram, wycena i wybór stosu.
2. Zestaw testowy przed kodem. Zbieram przykładowe wejścia i oczekiwane wyniki, w tym trudne przypadki. To one później oceniają prompty i modele.
3. Fundament i pętla AI. Architektura danych, integracja z modelem przez warstwę abstrakcji i pierwsza działająca ścieżka od wejścia do wyniku.
4. Interfejs i pełny przepływ. Logowanie, baza danych, obsługa błędów i stanów ładowania, wersja na stagingu do testów.
5. Testy, zabezpieczenia i start. Testy automatyczne, ewaluacje, testy ataków na warstwę AI, monitoring i wdrożenie produkcyjne.
6. Przekazanie. Kod w Twoim repozytorium, dokumentacja, runbook i sesja z zespołem, który przejmie projekt.

Najwięcej czasu rzadko zajmuje sam kod. Opóźnienia biorą się zwykle z braku przykładowych danych na starcie, z decyzji o zakresie, które czekają tygodniami, i z integracji z systemami, do których nikt nie ma dokumentacji API. Dlatego przed startem proszę o przykładowe dane i jedną osobę po stronie klienta, która podejmuje decyzje.

Ile kosztuje aplikacja AI – budowa i koszty utrzymania

Koszt aplikacji AI to jednorazowa budowa oraz koszty bieżące: infrastruktura, opłaty za model i utrzymanie. U mnie MVP zaczyna się od 13 500 zł, backend AI od 10 500 zł, a dedykowana aplikacja webowa od 24 000 zł.

Infrastruktura (Vercel, AWS, GCP) to zwykle 210–2 100 zł miesięcznie, zależnie od ruchu. Opłaty za model zależą od liczby wywołań i długości kontekstu, więc szacuję je jako koszt na jednego aktywnego użytkownika albo na jedną operację, a nie jedną kwotą na miesiąc.

Dźwignie, które obniżają koszt modelu

• Tryb wsadowy. OpenAI podaje w dokumentacji Batch API 50% zniżki względem zwykłych wywołań, w zamian za wynik w ciągu 24 godzin. Dobre do raportów, klasyfikacji i przetwarzania nocnego.
• Cache promptów. Według dokumentacji Anthropic odczyt z cache kosztuje 10% bazowej ceny tokenów wejściowych, a przy części nowszych modeli mniej. Opłaca się przy długich, powtarzalnych instrukcjach i dokumentach.
• Dobór modelu do zadania. Mniejszy model do klasyfikacji i ekstrakcji, mocniejszy tylko do kroków, które go wymagają.
• Krótszy kontekst. Mniej zbędnej historii i lepsze wyszukiwanie w RAG to mniej tokenów przy każdym wywołaniu.

Więcej technik z przykładami opisałem w artykule optymalizacja kosztów API modeli AI.

Jak mierzyć jakość aplikacji AI – evals i metryki produktu

Jakość aplikacji AI mierzę na dwóch poziomach: ewaluacje (evals) sprawdzają odpowiedzi modelu na stałym zestawie testowym, a metryki produktu pokazują, czy użytkownicy z niej korzystają i czy koszt się spina. Bez evals każda zmiana promptu albo modelu jest zgadywaniem.

Dokumentacja Anthropic o ewaluacjach zaleca zacząć od konkretnych, mierzalnych kryteriów sukcesu, budować testy odzwierciedlające realne zadania razem z przypadkami brzegowymi i stawiać na automatyczne ocenianie: dopasowanie wyniku, sprawdzenie kodem albo ocenę przez drugi model. Lepiej mieć więcej testów ocenianych automatycznie niż kilka ocenianych ręcznie.

Co mierzę w każdej aplikacji

• Jakość odpowiedzi na zestawie testowym, uruchamianym w CI przy każdej zmianie promptu, modelu lub sposobu wyszukiwania.
• Koszt modelu na użytkownika lub operację oraz czas odpowiedzi.
• Aktywacja i powroty użytkowników, a w narzędziach wewnętrznych czas wykonania zadania w porównaniu z poprzednim procesem.
• Błędy produkcyjne: odsetek nieudanych wywołań, timeouty i przypadki, w których system przekazał sprawę człowiekowi.

Metodę ocen przez drugi model opisałem w tekście ewaluacja LLM metodą LLM-as-a-judge. Na tym wzorcu działa też AnswerLyzer, mój system, w którym osobny model ocenia odpowiedzi innych modeli według ustalonych kryteriów.

Bezpieczeństwo aplikacji AI – OWASP LLM Top 10 w praktyce

Aplikacja AI ma wszystkie ryzyka zwykłej aplikacji webowej i kilka nowych, które zebrał OWASP Top 10 for LLM Applications 2025. Na pierwszym miejscu jest prompt injection (LLM01): złośliwa instrukcja ukryta w treści, którą czyta model, może zmienić jego zachowanie.

Lista OWASP obejmuje także m.in. ujawnienie informacji wrażliwych (LLM02), niewłaściwą obsługę wyników modelu (LLM05), nadmierną sprawczość (LLM06), wyciek promptu systemowego (LLM07), słabości wektorów i embeddingów (LLM08) oraz nieograniczone zużycie zasobów (LLM10). W aplikacjach, które buduję, najwięcej pracy wymagają LLM01, LLM05, LLM06 i LLM10.

• Wynik modelu to niezaufane dane. Waliduję format i zakresy, zanim trafi do bazy, do HTML-a albo do innego systemu.
• Uprawnienia użytkownika obowiązują też w RAG. Wyszukiwanie zwraca tylko dokumenty, do których dana osoba ma dostęp.
• Najmniejsze uprawnienia dla narzędzi, z których korzysta model, i akceptacja człowieka przy działaniach nieodwracalnych.
• Limity kosztów i wywołań na użytkownika i na godzinę, żeby błąd albo nadużycie nie wygenerowały rachunku.
• Fallback na model innego dostawcy. 10 czerwca 2025 r. API OpenAI przez kilka godzin zwracało podwyższoną liczbę błędów; aplikacje oparte na jednym modelu bez planu awaryjnego przestały w tym czasie działać.

Techniki obrony przed prompt injection opisałem w artykule prompt injection i bezpieczeństwo aplikacji LLM. Jeśli aplikacja przetwarza dane osobowe, dochodzi RODO: umowa powierzenia z dostawcą modelu, minimalizacja danych w promptach i często DPIA.

Software house, freelancer czy własny zespół – jak wybrać wykonawcę

Software house wybierz przy dużym zakresie, wielu równoległych strumieniach prac i potrzebie zastępowalności ludzi. Jednego inżyniera, gdy projekt da się prowadzić jedną parą rąk, a zależy Ci na krótkiej komunikacji. Własny zespół, gdy produkt jest zwalidowany i będzie rozwijany latami.

Pytania, które warto zadać każdemu wykonawcy

• Jak będziecie mierzyć jakość odpowiedzi AI i czy dostanę zestaw testowy?
• Ile będzie kosztował model na jednego użytkownika i jak to policzyliście?
• Co się stanie, gdy dostawca modelu ma awarię albo podniesie ceny?
• Czy kod, repozytorium i konta w chmurze będą od początku na mnie?
• Jak zabezpieczacie aplikację przed prompt injection i wyciekiem danych?
• Kto przejmie projekt po starcie i co dostanę do przekazania (dokumentacja, runbook, testy)?

Pełną listę pytań i sygnałów ostrzegawczych opublikowałem w poradniku jak wybrać wykonawcę wdrożenia AI.

Najczęstsze błędy przy tworzeniu aplikacji AI

Większość nieudanych projektów AI nie upada z powodu słabego modelu, tylko z powodu niejasnej wartości, nieprzygotowanych danych i kosztów, których nikt nie policzył. Gartner (2024) prognozował, że co najmniej 30% projektów generatywnej AI zostanie porzuconych po etapie proof of concept do końca 2025 r., wskazując m.in. słabą jakość danych, niewystarczającą kontrolę ryzyka, rosnące koszty i niejasną wartość biznesową.

1. Czat AI dołożony do aplikacji bez zadania. Funkcja AI musi mieć jasno opisaną pracę, którą wykonuje, i miarę sukcesu.
2. Ocena jakości po kilku udanych przykładach. Demo na łatwych przypadkach zamiast zestawu testowego z wyjątkami.
3. Koszt modelu policzony dopiero po pierwszym rachunku. Najdroższy model do każdego zadania i brak limitów.
4. Jeden dostawca modelu bez warstwy abstrakcji. Zmiana modelu wymaga przepisywania logiki, a awaria dostawcy wyłącza produkt.
5. Pełny produkt zamiast MVP. Miesiące pracy nad funkcjami, zanim ktokolwiek sprawdził, czy użytkownicy chcą rdzenia.
6. Kod bez testów i dokumentacji. Działa u autora, ale nie da się go rozwijać ani przekazać.

Jeśli masz już prototyp, który nie wytrzymuje ruchu albo kosztów, zwykle zaczynam od programowania systemów AI: routing modeli, cache, kolejki i monitoring. Gdy produkt jest zwalidowany i potrzebuje pełnej wersji, kolejnym krokiem jest dedykowana aplikacja webowa z AI.