Kupić czy budować AI? Decyzja strategiczna, nie techniczna

# Kupić czy budować AI? Decyzja strategiczna, nie techniczna

Decyzja build vs buy w AI bywa przedstawiana jako spór architektów: platforma własna kontra gotowy produkt dostawcy. To błąd. W praktyce jest to decyzja o modelu przewagi konkurencyjnej, tempie realizacji i profilu ryzyka na kolejne trzy lata. Technologia jest środkiem, a nie punktem wyjścia.

Wielu liderów wchodzi w ten wybór z intuicją opartą na kosztach licencji albo preferencjach CTO. Tymczasem realny koszt i realne ryzyko ujawniają się dopiero po starcie: w integracji, jakości danych, odpowiedzialności za błędy modelu, ograniczeniach umownych oraz zdolności organizacji do utrzymania rozwiązania. Dlatego pytanie nie brzmi: "co jest tańsze dziś?", ale "co szybciej i trwalej dowozi wartość bez blokowania firmy jutro?".

Dlaczego klasyczne build vs buy nie działa dla AI

W tradycyjnych systemach IT można było założyć względnie stabilne wymagania. W AI wymagania zmieniają się wraz z użyciem, jakością danych i dojrzewaniem organizacji. To oznacza, że decyzja build vs buy nie jest jednorazowa. Jest decyzją warstwową: co kupić teraz, co budować później i co celowo zostawić jako komponent wymienialny.

Druga różnica dotyczy odpowiedzialności. Przy klasycznym SaaS łatwiej oddzielić odpowiedzialność dostawcy od odpowiedzialności klienta. W AI granice są rozmyte: wynik modelu, konfiguracja promptów, dane wejściowe i proces weryfikacji współtworzą końcowe ryzyko. Kupienie narzędzia nie przenosi odpowiedzialności za decyzję biznesową.

Trzecia różnica to ekonomika skali. W AI część kosztów jest zmienna (użycie, tokeny, inferencja), a część ukryta (monitoring jakości, red teaming, review człowieka, korekty procesu). Organizacja może wystartować tanio i szybko, a po kwartale odkryć, że koszt operacyjny przewyższa zakładany efekt.

Trzy złe pytania, które prowadzą do złej decyzji

Pierwsze złe pytanie: "Który model jest najlepszy?". Zarząd nie kupuje modelu, tylko wynik biznesowy. Nawet najlepszy model bez integracji w workflow nie tworzy wartości.

Drugie złe pytanie: "Czy vendor gwarantuje zgodność?". Vendor może dać narzędzia zgodności, ale nie zastąpi wewnętrznej odpowiedzialności za dane, decyzje i wyjątki.

Trzecie złe pytanie: "Czy zespół data science to zbuduje?". Kompetencja techniczna jest konieczna, ale niewystarczająca. Potrzebna jest też zdolność operacyjna: właściciel procesu, rytm monitoringu, governance i budżet na utrzymanie.

Lepsza rama decyzyjna: model 6D

Aby uniknąć decyzji intuicyjnej, warto użyć prostego modelu 6D.

Differentiation (przewaga): Czy dany komponent jest źródłem przewagi trudnej do skopiowania? Jeśli tak, rośnie sens budowania lub silnej personalizacji.

Dependency (zależność): Jak duże ryzyko vendor lock-in tworzy decyzja? Czy możemy wymienić komponent bez zatrzymania procesu?

Data (dane): Czy wartość zależy od naszych unikalnych danych i pętli uczenia? Im większa zależność od danych firmowych, tym większy sens budowy warstwy własnej.

Duty (odpowiedzialność): Gdzie leży odpowiedzialność regulacyjna i reputacyjna? Obszary wysokiego ryzyka wymagają większej kontroli nad decyzją i śladem audytowym.

Delivery (tempo): Jak szybko potrzebujemy efektu? Kupno często wygrywa na starcie, ale nie zawsze w długim horyzoncie.

Durability (trwałość ekonomiki): Czy model kosztowy utrzyma się przy skali? Jeśli ekonomika pogarsza się wraz ze wzrostem użycia, decyzja startowa wymaga korekty.

Model 6D nie daje automatycznej odpowiedzi. Daje wspólny język dla zarządu, technologii, finansów i ryzyka.

Kiedy kupować, kiedy budować, kiedy mieszać

Kupować warto wtedy, gdy potrzeba szybkiego wdrożenia jest wysoka, obszar nie tworzy trwałej przewagi, a ryzyko można kontrolować przez standardowe mechanizmy governance. Typowe przykłady to wsparcie produktywności ogólnej, podsumowania, klasyfikacje niskiego ryzyka i funkcje pomocnicze.

Budować warto wtedy, gdy AI staje się rdzeniem procesu biznesowego, przewaga zależy od danych własnych i workflow, a firma chce kontrolować jakość, koszty i roadmapę w horyzoncie wieloletnim. To częste w obszarach pricingu, decyzji operacyjnych, rekomendacji osadzonych głęboko w procesie oraz krytycznych mechanizmach obsługi klienta.

Najczęściej jednak wygrywa model mieszany: kupujemy fundament i czas wejścia, budujemy warstwę różnicującą oraz integracyjną. Praktycznie oznacza to: vendor dla ogólnych komponentów, własna orkiestracja, własne guardraile, własne metryki jakości i własne osadzenie w procesie.

Co zarząd powinien wymagać przed decyzją

Po pierwsze, pełnego obrazu TCO na 12-24 miesiące, a nie tylko ceny licencji. TCO musi obejmować integrację, utrzymanie, monitoring, review człowieka, kontrolę ryzyka i koszt zmian.

Po drugie, scenariusza wyjścia z zależności od vendora. Jeśli organizacja nie umie opisać kosztu i czasu migracji, prawdopodobnie nie kontroluje swojej pozycji negocjacyjnej.

Po trzecie, jawnego przypisania odpowiedzialności za błędy modelu i decyzje biznesowe. W AI "to zrobił vendor" nie jest strategią obrony.

Po czwarte, planu rozwoju kompetencji wewnętrznych. Nawet przy dominującym modelu buy firma potrzebuje capability do wyboru, kontroli i poprawy systemu.

Po piąte, metryk wartości i metryk ryzyka raportowanych w jednym rytmie. Osobne raportowanie "wartości" i "zgodności" zwykle ukrywa realną ekonomię decyzji.

Realistyczny scenariusz decyzji boardowej

Firma z sektora usług B2B rozważa wdrożenie AI do przygotowania ofert i odpowiedzi dla kluczowych klientów. Zespół zakupowy promuje szybkie kupno kompletnej platformy. Zespół technologiczny proponuje budowę własnej warstwy na modelach bazowych. CFO naciska na krótkoterminowy efekt.

Po zastosowaniu modelu 6D zarząd widzi, że przewaga firmy nie leży w samym modelu językowym, tylko w danych relacyjnych i sposobie prowadzenia procesu sprzedaży. Jednocześnie czas wdrożenia ma znaczenie, bo konkurencja już skraca cykl odpowiedzi.

Decyzja końcowa: model mieszany. Firma kupuje komponenty bazowe i gotowe funkcje niskiego ryzyka, ale buduje własną warstwę workflow, monitoring jakości, repozytorium wiedzy domenowej i mechanizm eskalacji. Dodatkowo kontrakt zawiera klauzule przenoszalności i audytowalności.

Po sześciu miesiącach efekt nie wynika z "lepszego modelu", ale z lepszej integracji procesu i dyscypliny operacyjnej. To kluczowa lekcja: decyzja sourcingowa jest decyzją o modelu operacyjnym, nie o samym narzędziu.

Najczęstsze pułapki i jak ich uniknąć

Pułapka pierwsza: decyzja prowadzona przez demo, nie przez kryteria. Antidotum: wspólny arkusz 6D i porównanie scenariuszy na tych samych założeniach.

Pułapka druga: niedoszacowanie kosztów operacyjnych po starcie. Antidotum: obowiązkowy kosztorys utrzymania i jakości, aktualizowany po każdym kwartale.

Pułapka trzecia: brak strategii kompetencji. Antidotum: równoległy plan rozwoju ownerów procesu, architektury i governance.

Pułapka czwarta: lock-in umowny ukryty w szczegółach technicznych. Antidotum: standard minimalnych wymagań kontraktowych dla AI vendora.

Pułapka piąta: mylenie szybkości wdrożenia z szybkością tworzenia wartości. Antidotum: metryki efektu biznesowego ustawione od dnia pierwszego.

Executive Takeaway

Co się zmieniło? Decyzja build vs buy w AI przestała być wyborem narzędzia i stała się wyborem modelu przewagi, odpowiedzialności oraz kosztu skali. Dlaczego to ważne? Firmy, które kupują szybko bez architektury decyzji, zwykle płacą później przez lock-in, ukryte koszty operacyjne i utratę kontroli nad ryzykiem. Co liderzy powinni zrobić? Wprowadzić boardowy standard oceny 6D, porównywać scenariusze kupić-zbudować-mieszać na wspólnym TCO i wymagać planu wyjścia oraz odpowiedzialności przed podpisaniem kontraktu.