Build vs buy: postaviť AI riešenie alebo kúpiť?

Na stretnutí s výrobným riaditeľom padne otázka, ktorú vídame takmer v každej firme, čo dnes rozmýšľa o AI: „Kúpime nejaký hotový nástroj, alebo to budeme musieť stavať sami?" Otázka znie jednoducho, ale v skutočnosti spája tri rôzne rozhodnutia — o diferenciácii, o dátach a o nákladoch v čase. Kto na ňu odpovedá v prvých pätnástich minútach stretnutia, väčšinou odpovie zle.

Tento článok ponúka rámec, ktorý sme v praxi overili na desiatkach nasadení. Nejde o náboženskú vojnu medzi „buy everything" a „build everything" — obe sú extrémne, obe sú chybné. Ide o to, vedieť ktorú vrstvu každého konkrétneho riešenia kúpiť, ktorú postaviť a kde je hranica, za ktorou sa jedno alebo druhé prestáva oplácať.

Základ rámca — tri vrstvy každého AI riešenia

Každé produkčné AI riešenie možno rozdeliť do troch vrstiev:

1. 1.Model a inferencia — LLM, embedding model, serving infraštruktúra. Toto je komodita. OpenAI, Anthropic, Google, alebo open-weight modely ako Qwen 3, Mistral, Llama 4 — všetky poskytujú solídny základ, ktorý stojí stovky miliónov dolárov na vyvinutie a vy ho dostanete za zlomok ceny.
2. 2.Orchestrácia a retrieval — RAG pipeline, agentná logika, memory, nástroje, guardrails. Toto je vrstva, kde sa rozhoduje o kvalite výstupu. Je čiastočne komoditná (frameworky ako LangGraph, LlamaIndex, vektorové databázy ako Qdrant sú open-source a zrelé), ale špecifikum nasadenia — vaše dáta, vaše procesy, vaše edge-casy — si vyžaduje vlastnú prácu.
3. 3.Doménová vrstva — prompty, datasety, fine-tuning, evalvácie, UI, integrácia na systémy. Toto je miesto, kde vzniká diferenciácia. Nikto iný nemá vaše výrobné dáta, vaše SOP dokumenty ani vaše zákaznícke histórie. Túto vrstvu kúpiť nemôžete — môžete ju len postaviť.

Zjednodušene: kúpte vrstvy 1 a časť 2, stavajte vrstvu 3 a zvyšok 2. Problém nastáva, keď firma kúpi vrstvu 1 od jedného vendora, ktorý mu zabalí aj vrstvu 2 aj vrstvu 3 do proprietárnej platformy — a firma si neuvedomí, čo podpisuje.

Kedy kúpiť

Kúpa dáva zmysel, keď je use-case komoditný — to znamená, že váš problém rieši aj päťdesiat iných firiem a existuje zrelý trh riešení. Príklady:

• Zákaznícka podpora s FAQ (zendesk AI, Intercom, Freshdesk AI) — štandardná úloha, hotové integrácie, rýchly onboarding.
• Meeting summarizácia a transkripcia (Otter.ai, Fireflies, Microsoft Copilot) — žiadna diferenciačná hodnota, rýchlosť dodania je kľúčová.
• Kódový asistent pre tím (GitHub Copilot, Cursor, Codeium) — všeobecný use-case, kde individuálny fine-tuning prinesie marginálne zlepšenie za neúmerné náklady.
• HR screening prvého kola (existuje niekoľko zrelých platforiem) — komoditný problém, regulovaný trh, ready-made compliance.

Okrem komodity platí: kúpte, ak rýchlosť do produkcie je dôležitejšia ako výkon. V niektorých prípadoch je 80% riešenie dostupné zajtra lepšie ako 95% riešenie dostupné o osem mesiacov.

Posledný argument pre kúpu: ak vaša firma nemá a v blízkej budúcnosti nebude mať AI tím s potrebnými kompetenciami, údržba vlastného riešenia vás bude stáť viac ako SaaS subscription, a to na nákladoch aj na nespoľahlivosti.

Kedy stavať

Stavanie dáva zmysel v troch situáciách:

Diferenciácia cez dáta. Ak máte dáta, ktoré nikto iný nemá — výrobné záznamy zo strojov, históriu reklamácií, interné technické normy, výsledky meraní — a ak tieto dáta môžu byť zdrojom lepšieho výkonu ako u konkurencie, musíte stavať. Hotové riešenie tieto dáta neintegruje; keď ho kúpite, platíte za generickú kvalitu. Fine-tuning alebo RAG nad vlastnými dátami zmení generický model na doménového špecialistu — ale to si vyžaduje vašu prácu.

Bezpečnosť a regulatórne požiadavky. Ak operujete v odvetví, kde dáta nesmú opúšťať sieť (zdravotníctvo, energetika, obrana, finančné inštitúcie s NDA dátami), SaaS riešenia sú jednoducho mimo stolu. Tu je odpoveď on-prem LLM — lokálne nasadenie open-weight modelu s vLLM alebo Ollama, kde inferencia beží na vašom hardvéri a žiadny token neopustí sieť. Toto nie je len technická voľba — je to compliance požiadavka.

Procesná špecifika, ktoré hotový produkt nepodporí. Ak váš use-case obsahuje neštandardné kroky — napríklad integráciu na starší SCADA systém, spracovanie proprietárneho formátu dokumentácie, alebo multi-step agentný workflow, ktorý špecificky zodpovedá vašim výrobným procesom — žiadna hotová platforma to nepokryje bez rozsiahlej customizácie. A tá customizácia vás dovedie na rovnaký objem práce ako vlastné riešenie, len s cudzím kódom pod ňou.

Hybridný model — realita väčšiny produkčných nasadení

V praxi sme zriedka videli čisté build alebo čisté buy nasadenie. Typická architektúra, ktorá funguje:

• Kúpiť: LLM API (Claude Sonnet, GPT, Gemini Flash) alebo open-weight model cez vLLM na vlastnom serveri; vektorová databáza (Qdrant je de-facto štandard pre slovenský trh — EU-hosted, Apache 2.0); embedding model (open-weight BGE rodina je produkčne overená).
• Stavať: RAG pipeline so špecifickými retrieval stratégiami pre váš typ dokumentov; prompt vrstva, ktorá odráža firemné procesy a terminológiu; fine-tuning na doménovom vocabulári ak je rozdiel v kvalite merateľný; integrácia na ERP/SCADA/MES systémy; evalvácia a monitoring výkonu v produkcii.

Tento hybridný prístup vám dáva rýchlosť komerčných vrstiev (model a databáza sú hotové v deň štartu) a diferenciáciu vlastných vrstiev (doménová logika ostáva vaša). Zároveň znižuje riziko lock-inu — ak jutro vyjde lepší model, vymeníte volanie API bez prepisovania celého riešenia.

Total cost of ownership — kde sa kalkulácia mení

Najčastejšia chyba v build vs buy rozhodnutí je porovnávanie ceny SaaS predplatného s jednorazovými nákladmi na vývoj. Správna kalkulácia musí zahŕňať celkové náklady vlastníctva (TCO) za 3–5 rokov:

SaaS / buy TCO: - Mesačné predplatné (škáluje s počtom používateľov alebo s objemom dát — sledujte to) - Onboarding a integrácia (väčšinou nie je zadarmo) - Výpadky z dôvodu zmien API alebo podmienok služby (vídali sme ceníky zdvihnuté o 40–80 % pri obnove zmluvy) - Neviditeľné náklady: dáta opúšťajú firmu → privacy risk → potenciálne compliance náklady

Build TCO: - Iniciálny vývoj (typicky dominantná položka v roku 1) - Hardware ak je on-prem (GPU server — orientačne €15–60k pre produkčné nasadenie podľa požiadaviek, amortizovaný typicky za 3 roky) - Personálne náklady na údržbu a iteráciu (nie nulové — kalkulujte realisticky) - Závislosť na internom know-how (odchod kľúčového inžiniera = riziko)

Zásadný bod: SaaS sa výhodne javí v roku 1, build sa oplatí od roku 2–3. Ak je use-case dočasný (pilotný projekt, testovanie hypotézy, sezónny), kúpte. Ak je strategický a dlhodobý, build má typicky nižšie TCO a vyššiu kontrolu.

Lock-in — riziko, ktoré sa podceňuje

Vendor lock-in má v AI kontexte tri formy, ktoré sú horšie ako klasický software lock-in:

Dátový lock-in. Keď vaše firemné dáta (dokumenty, histórie, anotácie, feedback) žijú výhradne na platforme vendora, migrácia je bolestivá až nemožná. Pred kúpou vždy overte: viem exportovať 100 % svojich dát v štandardnom formáte? Ak nie, ste v lock-ine od dňa jedna.

Modelový lock-in. Ak ste vybudovali prompt logiku, fine-tuningovú sadu alebo evalvácie pre jeden konkrétny model (napr. GPT-4 class), migrácia na iný model vyžaduje repracing aj keď je nový model lepší. Riešenie: abstrakčná vrstva v orchestrácii, kde model je konfigurácia, nie hardcode.

Integračný lock-in. Niektoré platformy ponúkajú konektory na vaše systémy — ERP, CRM, SCADA. Keď sú tieto konektory proprietárne a nedokumentované, vymeníte platformu len za cenu prepisu integrácií. Vždy preferujte otvorené API a štandardné protokoly.

Dobrá správa: open-weight modely (Llama 4, Qwen 3, Mistral — väčšina pod Apache 2.0 alebo porovnateľnou komerčnou licenciou) zásadne znížili modelový lock-in za posledné dva roky. Frontier výkon je dosiahnuteľný lokálne bez viazania na konkrétneho providera.

Rozhodovacia mapa — 5 otázok pred záverom

Pred záverečným rozhodnutím si v tíme prejdite týchto päť otázok:

1. 1.Je use-case komoditný? Ak dve desiatky firiem v rovnakom odvetví riešia ten istý problém rovnako, hotové riešenie je pravdepodobne efektívnejšie.
2. 2.Sú naše dáta zdrojom diferenciácie? Ak áno, musíte stavať — hotový produkt ich nespracuje tak, aby vám dali výhodu.
3. 3.Smú dáta opúšťať sieť? Ak nie, build/on-prem je jediná možnosť.
4. 4.Máme (alebo vieme zabezpečiť) tím na stavanie a údržbu? Build bez kompetentného tímu je horší ako buy — zloženie tímu pre AI projekt je separátna téma, ktorú treba riešiť paralelne.
5. 5.Ako dlho plánujeme toto riešenie prevádzkovať? Do 12 mesiacov alebo ak je use-case neistý → kúpte. 2+ roky s jasnými výsledkami → build alebo hybrid vyjde lepšie.

Keď odpovede na tieto otázky neurčia jednoznačného víťaza, väčšinou ide o hybridný prípad — kúpiť základné vrstvy, stavať doménovú špecializáciu.

Typické chyby, ktoré vídame

Kúpa celého stacku od jedného vendora bez overenia, či je každá vrstva skutočne na úrovni best-in-class. Platformy, ktoré robia všetko, nerobia nič výborne. Čoraz viac úspešných produkčných nasadení skladá komponenty od rôznych providerov: model API z jednej strany, vektorová databáza open-source, orchestrácia vlastná.

Build bez definovaného use-casu. „Chceme AI, tak si to postavíme" je výprava bez mapy. Väčšina projektov, ktoré sme videli zlyhávať, nemala pred štartom definovaný success metric — teda ani spôsob, ako zistiť, či to, čo stavajú, má hodnotu. ROI AI projektov treba merať od prvého dňa.

Podhodnotenie nákladov na dáta. Predtým ako môžete stavať, musíte mať dáta — vyčistené, štruktúrované, dostupné vo formáte, ktorý LLM vie spracovať. Podľa Cisco AI Readiness Indexu len ~34 % firiem hodnotí svoju dátovú pripravenosť ako dostatočnú. Ak ste v zvyšných 66 %, dátový pipeline je váš prvý projekt, nie AI samotné.

Ignorovanie EU AI Act. Od augusta 2026 platia konkrétne povinnosti pre firmy nasadzujúce AI systémy v regulovaných kontextoch. Ak kupujete platformu, skontrolujte, či vendor poskytuje compliance dokumentáciu. Ak staviate, compliance dokumentácia je vaša zodpovednosť. Ignorovanie tohto aspektu dnes môže znamenať prerábanie riešenia neskôr.

Časté otázky

Má zmysel testovať hotové riešenie ako proof-of-concept a potom ho nahradiť vlastným?

Áno, ale s podmienkou: pilot musí testovať váš konkrétny use-case, nie generické demo. Ak pilot s kúpeným riešením ukáže, že use-case má hodnotu, máte dôkaz pre investíciu do vlastného buildu. Dôležité je, aby pilotná architektúra oddelila dátovú logiku od platformy — migrujete ľahšie.

Čo znamená „open-weight model" z pohľadu licencie a komerčného využitia?

Modely ako Qwen 3 alebo Mistral sú vydané pod Apache 2.0 licenciou — môžete ich použiť komerčne bez licenčných poplatkov. Llama 4 má vlastnú licenciu (bezplatné komerčné použitie pod určitým limitom mesačných aktívnych používateľov). Vždy si overte aktuálne licenčné podmienky pri konkrétnom modeli a verzii pred nasadením.

Je on-prem nasadenie reálne pre firmu bez veľkého IT tímu?

Áno, ak je use-case vymedzený. Jeden GPU server s Ollama a menším open-weight modelom (napríklad Qwen 3 8B alebo Phi-4 14B) vie nasadiť skúsený inžinier za deň. Náročnejšie je produkčné nasadenie s vysokou dostupnosťou, monitoringom a CI/CD — to si vyžaduje viac. Správnou voľbou pre firmu bez AI tímu je zvyčajne spravované on-prem riešenie s externou podporou, nie self-managed infraštruktúra.

Kedy je fine-tuning súčasťou „build" stratégie a kedy nie?

Fine-tuning dáva zmysel, keď chcete model špecializovať na váš jazykový register, terminológiu alebo formát výstupov — a keď máte dostatok kvalitných trénovacích dát (orientačne 5 000+ párových príkladov pre základný SFT). Ak nemáte dáta alebo ak problém vie riešiť dobre navrhnutý RAG pipeline, fine-tuning je predčasnou optimalizáciou. Viac o tomto rozhodnutí v článku RAG vs fine-tuning.

Čo je najčastejšia príčina, prečo build projekty prekračujú rozpočet?

Z našej praxe: podhodnotenie evalvácie a iterácie. Postaviť prvú verziu trvá predvídateľne — ale zmerať, či funguje, identifikovať kde zlyháva a opraviť to, trvá rovnako dlho znova. Projekty, ktoré s týmto počítajú od začiatku, dodajú v čase a rozpočte. Projekty, ktoré predpokladajú, že prvá verzia bude produkčná, nie.

*MP Industrial Solutions pomáha firmám prejsť build vs buy rozhodnutím s číslami v ruke — od mapovania use-casov cez TCO kalkulácie až po prvé produkčné nasadenie. Ak stojíte pred týmto rozhodnutím, radi posúdime váš konkrétny prípad spoločne.*