Autor: DataTip · Opublikowano
W skrócie: Przedsiębiorstwa powinny kupować dojrzałe, standardowe funkcje AI, a budować te warstwy, które zależą od danych własnych, procesów, ładu (governance) i wiedzy operacyjnej. Model łączony często daje największą kontrolę: korzystanie z komercyjnych modeli bazowych lub modeli open-weight przy zachowaniu własności routingu, wyszukiwania (retrieval), agentów, ewaluacji i aplikacji. Te wybory warto porównywać w horyzoncie od trzech do pięciu lat, uwzględniając koszty użycia, utrzymania, bezpieczeństwa i zmiany dostawcy.
- Dostęp do modeli bazowych i własność firmowego AI to odrębne decyzje; zakup modelu nie oznacza outsourcingu warstwy, która wyróżnia firmę.
- Dojrzałe funkcje, takie jak transkrypcja, przetwarzanie dokumentów, narzędzia produktywności i podstawowa obsługa klienta, warto kupować, gdy nie dają istotnego wyróżnienia.
- Budować warto tam, gdzie o wydajności decydują dane własne, własność intelektualna, specjalistyczna wiedza lub unikalne procesy.
- Pięcioletni koszt operacyjny należy oceniać w zakresie infrastruktury, inferencji, potoków danych, bezpieczeństwa, ewaluacji, utrzymania, licencji i zależności od dostawcy.
- Routing i architektura wielomodelowa zmniejszają ryzyko uzależnienia każdej aplikacji od jednego dostawcy.
Demo AI z pierwszego roku może sprawić, że kosztowna decyzja wygląda na prostą. Dla CIO, CTO czy dyrektora finansowego prawdziwe pytanie brzmi: co przedsiębiorstwo powinno mieć na własność, co pozyskiwać z zewnątrz i jak te wybory sprawdzą się w horyzoncie od trzech do pięciu lat.
Przedsiębiorstwa powinny kupować dojrzałe, standardowe funkcje AI, a budować te warstwy, które zależą od danych własnych, procesów, ładu (governance) i wiedzy operacyjnej. Model łączony często daje największą kontrolę: korzystanie z komercyjnych modeli bazowych lub modeli open-weight przy zachowaniu własności routingu, wyszukiwania (retrieval), agentów, ewaluacji i aplikacji. Te wybory warto porównywać w horyzoncie od trzech do pięciu lat, uwzględniając koszty użycia, utrzymania, bezpieczeństwa i zmiany dostawcy.
Najmocniejszą odpowiedzią często będzie połączenie: kupić standardową inteligencję, a następnie zbudować dane, procesy, ład i aplikacje, które wyróżniają firmę.
Czy przedsiębiorstwo powinno budować, kupować, czy łączyć funkcje AI?
Przedsiębiorstwa powinny zasadniczo kupować dojrzałe funkcje, które nie dają istotnego wyróżnienia, budować warstwy zależne od danych lub procesów własnych oraz łączyć modele komercyjne lub open-weight z technologią kontrolowaną wewnętrznie. Wybór nie jest zero-jedynkowy, ponieważ dostęp do modeli bazowych i własność firmowego AI to odrębne decyzje.
Przydatna decyzja o pozyskaniu AI w przedsiębiorstwie dzieli daną funkcję na warstwy:
- Inteligencja bazowa: dostęp do GPT, Claude, Gemini lub modeli open-weight.
- Dane firmowe i wyszukiwanie: informacje, które nadają systemowi kontekst biznesowy.
- Agenci i procesy: sposób, w jaki funkcja wykonuje pracę w organizacji.
- Orkiestracja i routing: sposób przydzielania żądań do modeli lub usług.
- Ewaluacja, ład i wdrożenie: sposób utrzymania jakości, kontroli ryzyka i kontroli operacyjnej. Pytanie nie brzmi po prostu, czy zespół potrafi zbudować daną funkcję. Chodzi o to, czy warstwa tworzy wystarczającą wartość strategiczną, by uzasadnić ponoszenie bieżących kosztów jej posiadania.
Kiedy zakup AI ma więcej sensu niż jego budowa?
Zakup jest zazwyczaj lepszym wyborem, gdy funkcja jest dojrzała, powszechnie dostępna i raczej nie zapewni istotnej przewagi konkurencyjnej. Do tego wzorca pasują asystenci programowania, transkrypcja spotkań, przetwarzanie dokumentów, narzędzia produktywności i podstawowe aplikacje obsługi klienta.
Zakup nie jest automatycznie tańszy. Kupione funkcje mogą oznaczać subskrypcje, opłaty za API, zużycie tokenów, licencje korporacyjne, prace integracyjne i zależność od roadmapy dostawcy. Mimo to mogą być lepszym wyborem, gdy w przeciwnym razie wewnętrzne zespoły musiałyby utrzymywać funkcję, która nie jest kluczowa dla przewagi firmy.
Budowa staje się atrakcyjniejsza, gdy wydajność zależy od danych własnych, własności intelektualnej, specjalistycznej wiedzy operacyjnej lub unikalnych procesów biznesowych. Nie musi też oznaczać trenowania modelu bazowego od zera. Przedsiębiorstwo może kupić dostęp do modeli komercyjnych lub open-weight, a jednocześnie rozwijać własne systemy wyszukiwania, potoki danych, agentów, orkiestrację, systemy ewaluacji i aplikacje.
Ta otaczająca warstwa może być bliżej źródła przewagi konkurencyjnej niż sam model.
Jak przykłady przedsiębiorstw pokazują wartość łączenia funkcji AI?
AT&T informuje o mniej więcej pięciokrotnym zwrocie z inwestycji w AI w ciągu roku oraz o oszczędnościach rzędu 80–90 procent w niektórych zastosowaniach dzięki modelom otwartym. To wyniki raportowane przez firmę, a nie typowe rezultaty, których powinno oczekiwać każde przedsiębiorstwo. Szersza lekcja dotyczy architektury: AT&T nie musi rozwijać każdego modelu, ponieważ jest właścicielem warstwy kontrolującej wybór modeli, dane firmowe i wdrożenia.
Goldman Sachs pokazuje inną wersję podejścia „buduj i kupuj”. Bank zatrudnia na całym świecie ponad 12 000 inżynierów, co stanowi mniej więcej jedną czwartą jego pracowników, i ma dzięki temu duże możliwości dostosowania AI do procesów finansowych i inżynieryjnych. Integruje technologie komercyjne, w tym Anthropic Claude i Devin od Cognition, zamiast próbować budować każdy model wewnętrznie.
Setki agentów AI pracowały ramię w ramię z zespołem inżynieryjnym Goldmana. Devin miał według doniesień zapewnić trzy- do czterokrotnie wyższą produktywność niż wcześniejsze narzędzia AI dla programistów w niektórych zadaniach inżynierii agentowej. CIO Goldmana, Marco Argenti, przekonuje też, że firmy nie powinny automatycznie odrzucać modeli open-weight, jeśli dostępne są odpowiednie zabezpieczenia cybernetyczne.
Model Goldmana łączy zewnętrzne narzędzia z wewnętrzną inżynierią, integracją, ładem i wiedzą finansową. Taka elastyczność musi być wspierana przez stale utrzymywane kompetencje wewnętrzne; zakup narzędzia nie eliminuje pracy potrzebnej, by było ono użyteczne i kontrolowane.
Które warstwy firmowego AI warto budować?
EY to wyraźny przykład budowania wokół modelu, a nie budowania samego modelu. We współpracy z firmą 8090, specjalizującą się w rozwoju oprogramowania opartym na AI, EY stworzył EY.ai PDLC – oparty na AI cykl rozwoju produktu, łączący architekturę, automatyczne testy, ład i nadzór człowieka.
Według analizy TechTarget dotyczącej strategii „budować czy kupować” w AI w przedsiębiorstwach tego rodzaju podejścia mogą skrócić procesy wytwarzania oprogramowania, które tradycyjnie trwały miesiące, do dni lub tygodni. Nie chodzi o to, że każde przedsiębiorstwo powinno oczekiwać tego samego wyniku. Chodzi o to, że EY zdecydował się mieć na własność sposób projektowania, testowania, nadzorowania i dostarczania aplikacji z AI, zamiast rozwijać przełomowy model bazowy.
Athena Intelligence pokazuje drugą stronę tej samej strategii. Wykorzystuje Claude od Anthropic w procesach pracy z wiedzą w przedsiębiorstwach, a swoje zasoby rozwojowe koncentruje na agentach, procesach i doświadczeniu użytkownika. Według studium przypadku klienta opublikowanego przez Anthropic takie podejście pozwala wdrożyć firmowe procesy AI produkcyjnie w ciągu czterech do ośmiu tygodni, w porównaniu z branżowym punktem odniesienia wynoszącym od sześciu do dwunastu miesięcy.
Ten harmonogram pochodzi ze studium przypadku, a nie z niezależnie zweryfikowanego benchmarku. Mimo to ilustruje logikę pozyskiwania: kupić inteligencję bazową i skoncentrować wewnętrzny wysiłek na warstwie specyficznej dla biznesu.
Kiedy firma powinna kupić wyspecjalizowaną aplikację AI?
Wyspecjalizowane aplikacje mogą być lepszym wyborem, gdy dany proces nie zapewnia wystarczającego wyróżnienia, by uzasadnić wewnętrzny rozwój i utrzymanie. Agenci AI firmy HyperVerge dla kredytowania sektora MŚP automatyzują analizę finansową, wielojęzyczne rozmowy wideo i badanie due diligence kredytowe.
W pilotażach z udziałem 10 średniej wielkości kredytodawców przeglądy finansowe miały skrócić się z dwóch–trzech godzin do około pięciu minut. Przygotowanie memorandum oceny kredytowej skróciło się z około czterech godzin do niecałych 10 minut, a dokumentacja rozmów osobistych – z 45–60 minut do pięciu minut. Trzech kredytodawców wdrożyło agenta do rozmów wideo produkcyjnie.
To raportowane wyniki pilotaży, a nie uniwersalne benchmarki. Bank mógłby opracować podobną technologię wewnętrznie, ale zakup wyspecjalizowanego systemu i zintegrowanie z nim własnych polityk kredytowych może mieć więcej sensu, gdy zautomatyzowana ocena kredytowa sama w sobie nie jest istotnym wyróżnikiem.
Co powinno obejmować porównanie całkowitego kosztu AI w horyzoncie pięciu lat?
Całkowity koszt posiadania AI wykracza daleko poza subskrypcję w pierwszym roku czy porównanie opłat dla dostawcy z pensjami inżynierów. Budowa może wymagać inżynierów AI, GPU, infrastruktury chmurowej, potoków danych, inferencji, bezpieczeństwa, ewaluacji i utrzymania modeli. Zakup przenosi wiele z tych kosztów na subskrypcje, użycie API, zużycie tokenów, licencje, integrację i koszty zarządzania dostawcami.
WYGENEROWANE PRZEZ AIKoszty mogą gwałtownie się zmienić, gdy system osiągnie skalę produkcyjną. Architektura pozwalająca przedsiębiorstwu zmieniać modele może nabrać znaczenia finansowego, gdy zmienią się ekonomika użycia lub możliwości modeli. I odwrotnie: ścisłe powiązanie setek aplikacji z jednym dostawcą może generować wysokie koszty zmiany, jeśli zmienią się możliwości, ceny tokenów lub warunki umowne.
Dlatego najlepiej obronionym zasobem rozwijanym wewnętrznie może nie być model AI. Może nim być warstwa routingu, danych własnych, projektowania procesów, ewaluacji, ładu i wdrożeń wokół modelu. Skala prognozowanych wydatków na infrastrukturę AI wyjaśnia też, dlaczego odtwarzanie infrastruktury klasy frontier pozostaje nierealistyczne dla większości przedsiębiorstw.
Praktyczna decyzja jest więc konkretna: kupować standardowe funkcje, budować tam, gdzie wiedza i procesy własne dają wyróżnienie, i łączyć oba podejścia tam, gdzie liczy się kontrola nad danymi, architekturą i ekonomiką użycia. Demo dowodzi, że funkcja działa. Perspektywa trzech do pięciu lat pokazuje, kto musi ją utrzymywać, jak łatwo można ją zmienić i czy przedsiębiorstwo buduje zasób, nad którym ma kontrolę.
Najważniejsze wnioski
- Dostęp do modeli bazowych i własność firmowego AI to odrębne decyzje; zakup modelu nie oznacza outsourcingu warstwy, która wyróżnia firmę.
- Dojrzałe funkcje, takie jak transkrypcja, przetwarzanie dokumentów, narzędzia produktywności i podstawowa obsługa klienta, warto kupować, gdy nie dają istotnego wyróżnienia.
- Budować warto tam, gdzie o wydajności decydują dane własne, własność intelektualna, specjalistyczna wiedza lub unikalne procesy.
- Pięcioletni koszt operacyjny należy oceniać w zakresie infrastruktury, inferencji, potoków danych, bezpieczeństwa, ewaluacji, utrzymania, licencji i zależności od dostawcy.
- Routing i architektura wielomodelowa zmniejszają ryzyko uzależnienia każdej aplikacji od jednego dostawcy.
Praktyczne wskazówki
- Uzasadnienie biznesowe dla modelu bazowego warto oddzielić od uzasadnienia dla wyszukiwania, agentów, procesów, ładu i kontroli wdrożeń.
- Przed wykorzystaniem raportowanego wyniku w decyzji inwestycyjnej należy odnotować, czy pochodzi on z oświadczenia firmy, studium przypadku klienta, czy z niezależnego benchmarku.
- Warto zamodelować koszt zmiany dostawcy, w tym integracje aplikacji i ponowne szkolenie zespołów operacyjnych, zamiast zakładać, że zmiana dostawcy przebiegnie bez tarć.
- Standardowe funkcje należy oceniać oddzielnie od warstw wyróżniających przedsiębiorstwo; nie powinny opierać się na tym samym założeniu „budować czy kupować”.
Decyzja o własności – jawnie i świadomie
Warto przypisać każdą funkcję AI do jednej z warstw: inteligencja bazowa, dane firmowe, procesy, orkiestracja i ład. Następnie należy porównać koszty operacyjne i konsekwencje dla kontroli wynikające z posiadania lub pozyskiwania każdej warstwy w horyzoncie od trzech do pięciu lat.
WYGENEROWANE PRZEZ AI
