Każda agencja podaje przedział tak szeroki, że jest bezużyteczny, bo uczciwa odpowiedź zależy od rzeczy, których jeszcze nie zna. Oto więc, co kryje się za tą kwotą: na czym polegają cztery typowe rodzaje prac związanych z AI, o który z nich prosisz i co wpływa na jego koszt.

Poniższe koszty podajemy w tygodniach pracy inżyniera, a nie w pieniądzach. Stawki różnią się zależnie od rynku i wykonawcy, a strona podająca ceny w dolarach byłaby nieaktualna dla większości czytelników już w dniu lektury. Pomnóż je przez stawkę, którą faktycznie bierzesz pod uwagę. To nasze szacunki oparte na realizacji podobnych projektów, a nie badanie branżowe.

Cztery rodzaje prac związanych z AI

Niemal każde zlecenie, które otrzymujemy, należy do jednego z tych rodzajów albo łączy dwa z nich. Określenie, którego potrzebujesz, to najważniejszy krok w stronę rzetelnej wyceny — możesz go zrobić, zanim z kimkolwiek porozmawiasz.

Rodzaj Co robi Do pierwszej wersji produkcyjnej
Odpowiedzi na podstawie własnych treściPracownicy lub klienci zadają pytania, a system odpowiada na podstawie Twoich dokumentów i podaje źródła4–8 tygodni pracy inżyniera
Ekstrakcja i klasyfikacjaPrzekształca faktury, e-maile, zgłoszenia lub formularze w uporządkowane pola albo kategorie3–6 tygodni pracy inżyniera
Agent wykonujący zadaniePodejmuje działania w różnych systemach, zamiast jedynie generować tekst8–16 tygodni pracy inżyniera
Model wbudowany w Twój produktDziała na urządzeniu użytkownika lub Twoich serwerach, bez API stron trzecich10–20 tygodni pracy inżyniera

Dwa ostatnie przedziały są szersze z tego samego powodu: oba zależą od czynników niezwiązanych z AI. Możliwości agenta ograniczają interfejsy API, przez które musi działać, a model działający na urządzeniu — sprzęt, który zdecydujesz się obsługiwać.

Co faktycznie wpływa na cenę

Przykład konkretnego procesu ekstrakcji danych znajdziesz w opisie naszej usługi przewodnik po ekstrakcji danych z faktur oraz automatyzacji przetwarzania faktur na zamówienie: przyjmowanie, weryfikacja, kontrola pracowników i eksport do systemu księgowego.

Żaden z tych czynników nie dotyczy modelu. Wybór modelu to tydzień ewaluacji, a potem wpis w pliku konfiguracyjnym. Jeśli oferta przedstawia go jako główną kwestię, to sygnał, który warto wziąć pod uwagę.

  • Stan Twoich danych. To najważniejsza zmienna. Czyste, aktualne, dobrze uporządkowane dokumenty w jednym miejscu to najtańszy wariant. Cztery niespójne systemy źródłowe, zeskanowane pliki PDF i wiki, której nikt nie aktualizował od 2023 roku, to wariant najdroższy — a ta praca dotyczy danych i tak musiałbyś ją wykonać.
  • Wymagany poziom dokładności. Między „przygotowuje wersję roboczą do sprawdzenia przez człowieka” a „działa bez nadzoru” jest ogromna różnica. Drugi wariant wymaga pomiarów, obsługi błędów i bezpiecznego sposobu radzenia sobie z pomyłkami — to na to idzie budżet.
  • Liczba obsługiwanych systemów. Każda integracja oznacza osobne uwierzytelnianie, limity liczby zapytań i przypadki błędów. Dwie integracje to standard. Sześć oznacza już inny projekt.
  • Czy ktoś będzie odpowiadać za ewaluację. Jeśli nikt po Twojej stronie nie potrafi ocenić, czy odpowiedź była dobra, najpierw musimy zbudować odpowiednie zaplecze. Warto to zrobić, ale nie jest to bezpłatne.
  • Dokąd mogą trafiać dane. „Nic nie opuszcza naszej infrastruktury” to uzasadnione ograniczenie i ważne założenie projektowe. Zazwyczaj oznacza modele z otwartymi wagami, które hostujesz samodzielnie. Dają większą kontrolę kosztem części możliwości modelu, a koszt hostingu przechodzi na Ciebie.

Kosztów działania, o których się zapomina

Wycena budowy to nie budżet. Po uruchomieniu pozostają trzy koszty, a w planie zwykle uwzględnia się tylko pierwszy.

  • Korzystanie. Koszt za zapytanie, rosnący wraz z liczbą zapytań. Niski w skali pilotażu, dlatego zaskakuje przy wdrożeniu produkcyjnym. Warto oszacować go dla liczby zapytań dziesięć razy większej niż w pilotażu, zanim zdecydujesz się na architekturę.
  • Ewaluacja i monitoring. Jakość się zmienia, gdy aktualizujesz treści lub gdy dostawcy zmieniają modele. Ktoś musi to kontrolować.
  • Zmiany po stronie dostawcy. Dostawcy wycofują modele według własnego harmonogramu. Zaplanuj kilka dni pracy rocznie na migrację i unikaj projektów, które utrudniają zmianę modelu.

Ile powinien kosztować proof of concept i co powinien wykazać

Od dwóch do czterech tygodni. Jeśli trwa dłużej, to nie proof of concept, tylko projekt bez planu.

Najważniejsze jest to, czemu ma służyć. Proof of concept powinien zakończyć się decyzją, nie demonstracją — a żeby tak się stało, przed jego rozpoczęciem zapisz, jaki wynik oznacza sukces i co zrobisz, jeśli nie uda się go osiągnąć. „Powinien poprawnie sklasyfikować co najmniej 85% zgłoszeń, a jeśli mu się nie uda, przerywamy” — to proof of concept. „Sprawdźmy, co AI może dla nas zrobić” — to warsztat.

Powinien też dostarczyć coś, co przyda się później: niewielki, rzeczywisty zbiór przykładów z etykietami i prawidłowymi odpowiedziami. Taki zbiór testowy pozostanie przydatny niezależnie od tego, jaki model będzie aktualnie dostępny, i obniży koszt kolejnej decyzji.

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

  1. 1. Co mogłoby sprawić, że koszt wyniesie dwa razy więcej niż w wycenie?
  2. 2. Jak zmierzymy i liczbowo określimy, czy rozwiązanie działa, i kto to zrobi?
  3. 3. Ile będzie kosztować miesiąc działania przy dziesięciokrotnie większej liczbie zapytań niż w pilotażu?
  4. 4. Co się stanie, gdy wybrany model zostanie wycofany?
  5. 5. Dokąd trafiają nasze dane i jak długo są przechowywane?
  6. 6. Co robi system, gdy nie zna odpowiedzi?
  7. 7. Kto po zakończeniu projektu będzie właścicielem kodu, promptów i zbioru ewaluacyjnego?

Odpowiedź na szóste pytanie mówi najwięcej. System, który nie potrafi na nie odpowiedzieć, będzie z przekonaniem zmyślał — i właśnie tak projekty te tracą zaufanie osób, które miały z nich korzystać.

Kiedy nie budować

Trzy przypadki, w których odradzilibyśmy budowę — bo wczesna informacja jest tańsza dla obu stron.

  • Proces nie jest nigdzie opisany. Jeśli nikt nie potrafi opisać reguł, projekt powinien zacząć się od uporządkowania operacji, a nie od AI.
  • Zadanie pojawia się dziesięć razy w miesiącu. Automatyzacja rzadko wykonywanego zadania zwykle nie zwraca kosztów utrzymania.
  • Istniejący produkt już to robi. Jeśli Twoje dane nie są tym, co Cię wyróżnia, kup gotowe rozwiązanie. Wolimy Ci to powiedzieć, niż wystawić rachunek za jego odtworzenie.

Jak pracujemy

Jesteśmy małym zespołem inżynierów, a nie agencją: rozmawiasz bezpośrednio z osobami piszącymi kod, bez pośrednictwa opiekuna klienta, i starannie wybieramy projekty, których się podejmujemy. W obszarze AI zajmujemy się integracją LLM, wyszukiwaniem informacji w Twoich treściach, agentami i wdrażaniem modeli hostowanych przez Ciebie — a także pracami w technologiach .NET, Python, TypeScript i chmurze, które realizuje reszta studia.

Tworzymy też własne oprogramowanie dla systemu Windows, w tym asystenta tekstowego działającego w całości na modelu językowym uruchomionym na komputerze użytkownika, więc rozwiązania działające na urządzeniu i spełniające rygorystyczne wymagania dotyczące prywatności nie są dla nas teorią.

Opowiedz nam, co chcesz zbudować

Opisz problem, nie rozwiązanie: co ktoś robi dziś, jak często i ile kosztuje błąd. Odpowiemy w ciągu jednego dnia roboczego, przedstawiając zakres i wycenę albo wyjaśniając, dlaczego naszym zdaniem nie warto tego budować.

Często zadawane pytania

Ile kosztuje stworzenie chatbota AI dla mojej firmy?
W przypadku chatbota odpowiadającego na podstawie własnych dokumentów zaplanuj od czterech do ośmiu tygodni pracy inżyniera na pierwszą wersję produkcyjną. O kosztach zadecyduje przede wszystkim stan treści, a nie sztuczna inteligencja. Pomnóż ten czas przez stosowaną stawkę. Ktoś, kto podaje cenę przed zapoznaniem się z dokumentami, wycenia szablon.
Co sprawia, że jeden projekt AI kosztuje trzy razy więcej niż inny?
Zwykle decydujący jest wymagany poziom dokładności i liczba systemów, a nie model. Większość budżetu pochłania przejście od demonstracji, która zazwyczaj działa poprawnie, do rozwiązania wystarczająco niezawodnego, by działało bez nadzoru. Pieniądze idą na ewaluację, obsługę przypadków brzegowych i rozwiązania awaryjne, a nie na prompty.
Budować czy kupić?
Kup, gdy potrzebujesz powszechnej funkcji, a Twoje dane nie są tym, co Cię wyróżnia. Buduj, gdy wartość wynika z Twoich danych, Twojego procesu pracy albo ograniczenia, któremu gotowy produkt nie sprosta — najczęściej chodzi o to, że dane nie mogą opuścić Twojej infrastruktury.
Ile powinien kosztować proof of concept i co powinien wykazać?
Od dwóch do czterech tygodni, a na końcu decyzja, nie demonstracja. Zanim się zacznie, ustal, jaki wynik oznacza sukces i co zrobisz, jeśli nie uda się go osiągnąć. Proof of concept bez warunku niepowodzenia zawsze kończy się sukcesem i niczego Cię nie uczy.
Ile kosztuje utrzymanie rozwiązania po jego zbudowaniu?
Są trzy koszty, a ludzie uwzględniają w budżecie pierwszy z nich: korzystanie z modelu w przeliczeniu na zapytanie, które rośnie wraz z liczbą zapytań; monitoring i ewaluacja, które nie znikają; oraz okresowe prace, gdy dostawca wycofuje model lub go zmienia — dzieje się to według jego harmonogramu, nie Twojego.
Czy dane mogą pozostać w naszej infrastrukturze?
Tak, a to zmienia projekt, ale go nie wyklucza. Modele z otwartymi wagami mogą działać we własnym środowisku lub na urządzeniu. Trzeba liczyć się z kompromisem w zakresie możliwości modelu, a także z tym, że koszty hostingu i operacyjne przejdą na Twoją stronę.
Kiedy zobaczymy, że coś działa?
Wstępna wersja obsługująca typowe przypadki zwykle powstaje w ciągu pierwszych dwóch tygodni. Pozostały czas poświęca się na nietypowe przypadki — właśnie tam widać różnicę między demonstracją a produktem.