Utoljára frissítve:
AI Eszköz Kiválasztás · Spoke
AI tool stack felépítése vállalatnál — rétegek, integráció, vendor lock-in
A legtöbb vállalat nem AI stratégiával rendelkezik — hanem AI eszközök halmazával. Minden csapat bevezet egy-egy ChatGPT-t, Copilot-ot, Notionbe épített AI-t, és néhány hónap múlva senki nem tudja, mi fut, mennyibe kerül, és mi van kivel integrálva. Ez nem stack — ez szervetlen növekedés. A vállalati AI tool stack tudatos rétegrendszer, amelyet architektúra-szemlélettel kell tervezni.
A vállalati AI stack három rétege: foundation model (intelligencia), orchestration (folyamatvezérlés), application (felhasználói felület). A vendor lock-in az orchestration rétegben a legveszélyesebb. API-first tervezéssel és absztrakciós réteggel 24 óra alatt cserélhető a foundation model — lock-in nélkül.
A vállalati AI stack három rétege
A vállalati AI stack nem egyetlen eszköz — hanem három egymásra épülő réteg, amelyek együtt alkotják a működő rendszert. A leggyakoribb hiba: az application réteget (az eszközt, amit a felhasználók látnak) összekeverik magával a stackkel. A valódi stack a három réteg összessége.
A felhasználók számára látható felületek, chatbotok, dashboardok, automatizált workflow-k. Ez az a réteg, ahol az üzleti érték megjelenik és mérhető.
A prompt-láncolatok, memóriakezelés, adatlekérés (RAG), tool-hívások és integrációk vezérlése. Ez a réteg fordítja le az üzleti igényt API-hívásokká, és kapcsolja össze a foundation modellt az application réteggel.
Az LLM, amely az outputot generálja. Ez lehet managed API (OpenAI, Anthropic, Google, Azure OpenAI) vagy self-hosted modell (Llama, Mistral, Qwen). A foundation model a stack legkönnyebben cserélhető rétege — ha az orchestration réteg jól van tervezve.
A rétegek közötti interfészek mindig API-alapúak legyenek. Az application réteg ne tudjon a foundation modell részleteiről — csak az orchestration réteggel kommunikáljon. Ez a szétválasztás teszi lehetővé, hogy a foundation model váltható legyen anélkül, hogy az application réteget újra kellene írni.
Build vs. buy döntés rétegenkénti logikája
A build vs. buy döntés nem globális — rétegenkénti döntés. A foundation model réteget szinte mindig vásárolt megoldásként kezeljük (API vagy managed service). Az orchestration és az application rétegben van a valódi döntési tér.
- A use case annyira speciális, hogy nincs piaci megoldás
- Compliance: semmi nem telepíthető külső infrastruktúrára
- 50+ FTE, ahol az API-cost meghaladja az infrastruktúra-üzemeltetést
- Fine-tuning szükséges zárt, vállalati adaton
- Belső fejlesztői kapacitás rendelkezésre áll és stratégiai cél a saját IP
- Gyors bevezetés kell — a piac ma jobb megoldást kínál, mint 12 hónap fejlesztés
- Nincs belső fejlesztői kapacitás karbantartásra
- Standard use case: email automatizálás, összefoglalás, chatbot
- Kevesebb mint 50 aktív AI-felhasználó
- Kísérletezési fázis — a stack nem végleges, tesztelés zajlik
A tipikus hibás döntés: a vállalat önálló LLM infrastruktúrát épít (build), mert "biztonságosabbnak" tűnik — miközben sem a belső fejlesztői kapacitás, sem a compliance-igény nem indokolja. Az eredmény: 6-12 hónapos fejlesztési projekt, amely alatt a managed API-k előre haladnak, és a saját rendszer elavulva lép üzembe.
Vendor lock-in kockázatok és elkerülésük
A vendor lock-in nem egyszeri döntés eredménye — fokozatosan épül fel, ahogy a stack mélységi integrációkkal telik meg. Az alábbi táblázat rétegenkénti lock-in kockázatot és az ellenszert mutatja.
| Réteg | Lock-in forrása | Kockázat szint | Ellenszer |
|---|---|---|---|
| Foundation model | Proprietary API formátum, fine-tuned modell egy szállítón | Közepes | Absztrakciós réteg (LiteLLM, LangChain LLM wrapper) — a modell swappable |
| Orchestration | Natív SDK-k, szállítófüggő workflow-formátumok, zárt integráció | Magas | Nyílt standard orchestration (LangChain, n8n self-hosted) + szállítófüggetlen storage |
| Application | Beépített AI feature a meglévő platformba (pl. Notion AI, Salesforce Einstein) | Közepes | Az application réteg legyen moduláris — az AI-komponens lecserélhető legyen API-cserével |
| Adatréteg | Vektoros index egy szállítón (pl. csak Pinecone, csak Weaviate cloud) | Magas | Szállítófüggetlen embedding formátum (float32 + metadata JSON), exportálható index |
| Prompt könyvtár | Prompts zárt szállítói rendszerben tárolva (pl. csak ChatGPT Projects-ben) | Alacsony | Git-alapú prompt könyvtár (Markdown + YAML frontmatter) — szállítófüggetlen |
Ha egy szállító az AI stack mindhárom rétegét lefedi (pl. Microsoft: Azure OpenAI + Copilot Studio + Copilot 365), az rövid távon kényelmes. Hosszú távon: áremelés, funkcióleépítés esetén nincs tárgyalási pozíció. Ellenszer: minimum két rétegen legyen aktív, kész alternatíva — nem kell párhuzamosan futtatni, de ismernie kell a csapatnak.
API-first megközelítés: a legfontosabb tervezési elv
Az API-first tervezés azt jelenti, hogy minden integráció API-n keresztül épül — nem natív SDK-val, nem beépített pluginnel, nem platform-specifikus integrációval. Az API-first nem technológiai idealizmus — praktikus döntési elv, amely csökkenti a váltási cost-ot és megőrzi az architektúrális rugalmasságot.
Az API-first három konkrét szabálya
- Ne hívd a foundation model API-ját közvetlenül az application rétegből. Mindig legyen közötte egy orchestration réteg. Ha az alkalmazás közvetlenül az OpenAI API-t hívja, és az OpenAI árat emel, az egész alkalmazást át kell írni. Ha egy orchestration réteg közvetít, csak az orchestration réteg konfigurációját kell módosítani.
- Minden custom integrációhoz írj OpenAPI specifikációt. Ez biztosítja, hogy az integráció dokumentált, tesztelhető, és más eszközzel is hívható. A zárt, dokumentálatlan integráció belső lock-int teremt — nem a szállítóhoz, hanem saját fejlesztődhöz.
- A prompt könyvtárat tartsd szállítófüggetlen formátumban. Markdown fájlok, YAML frontmatter, Git verziókezelés. Ha a prompt könyvtár egy zárt rendszerben él (pl. ChatGPT Projects, Notion AI), az adatod fogva van. Ha Git-ben él, bármely eszközzel használható.
Cost governance az AI stack-ben
Az AI stack cost-struktúrája radikálisan különbözik a hagyományos szoftver-licenctől: a használatarányos API-cost (token-alapú számlázás) kiszámíthatatlan és gyorsan nőhet. A cost governance nem opcionális — a stackbe épített kell legyen, nem utólagos kontroll.
Az öt cost governance eszköz
- Token-monitoring minden API-híváson: logold a bemeneti és kimeneti token-számot, time-stamppel és workflow-azonosítóval. Ez az alapja mindennek.
- Cost-cap API-szinten: az OpenAI és Anthropic is kínál havi cost-cap beállítást — ha a határt eléri, az API-t zárja. Ez véd az elszabadult automation-loopok ellen.
- Model routing — feladathoz illő model: egyszerű összefoglaláshoz, kártya-szövegezethez GPT-4o mini vagy Claude Haiku; komplex elemzéshez, kód-generáláshoz a full model. A különbség 10–20× a token-cost-ban.
- Caching layer: ismétlődő vagy azonos promptokra (pl. rendszer-prompt + stabil kontextus) tárolt válasz, nem API-hívás. LangChain és LlamaIndex beépítve kínálja.
- Negyedéves cost audit: melyik workflow generálja a cost 80%-át? Pareto-elv alapján általában 2-3 workflow van, amely az összes token-cost döntő részét teszi ki.
Egy tipikus 20 fős KKV, amely e-mail automatizálásra, összefoglalásra és belső tudásbázis-keresésre használja az AI-t, havi 200–600 USD API-cost-ot termel. Ha nincs model routing és caching, ugyanez 1800–3500 USD is lehet. A különbség teljesen elkerülhető architektúrális döntésekkel.
Stack audit negyedévente: a négy kérdés
Az AI stack nem statikus — a szállítók API-t változtatnak, árakat emelnek, funkciókat leépítenek. A negyedéves stack audit nem opcionális karbantartás, hanem az architektúrális felelősség része. A négy kérdés, amelyet minden negyedévben meg kell válaszolni:
- Melyik workflow generálja a cost 80%-át?
- Van-e feleslegesen drága model-hívás, ahol kisebb model is megteszi?
- Caching layer hatékonysága: hány % a cache hit rate?
- Összesített TCO az elmúlt negyedévben — licensz + API + infra
- Melyik szállító kiesése állítja le a működést?
- Van-e aktív, kipróbált fallback minden kritikus komponensre?
- Deprecated API-k: milyen határidővel kell migrálni?
- Orchestration réteg: van-e szállítófüggő zárt funkcionalitás?
- Átlagos API latency az előző negyedévhez képest
- Error rate és timeout arány workflow-nként
- Token efficiency: output minőség / token-cost arány változott-e?
- Felhasználói visszajelzések és NPS az AI-eszközökre
- Szállítói áremelési tervek az elkövetkező negyedévben
- API v2 / v3 migrációs határidők
- Új modellek, amelyek cost- vagy performance-előnyt kínálnak
- Compliance változások (EU AI Act, GDPR frissítések)
Kérdések és válaszok
Mi az AI tool stack?
Az AI tool stack az a technológiai rétegrendszer, amelyen a vállalat AI-alapú folyamatai futnak. Három fő réteget különböztetünk meg: (1) foundation model réteg (GPT-4o, Claude, Gemini stb. — a nyers intelligencia), (2) orchestration réteg (LangChain, LlamaIndex, n8n, Make — a folyamat-vezérlés), (3) application réteg (a felhasználók által látott eszközök, felületek, integrációk). A stack egészét kell tervezni, nem csak az egyes eszközöket.
Hogyan épül fel rétegekre a vállalati AI stack?
Az egészséges AI stack három rétegre tagolódik. A foundation model réteg biztosítja az alap-intelligenciát — ez lehet API-hívás (OpenAI, Anthropic, Google) vagy self-hosted modell. Az orchestration réteg vezérli a folyamatokat, kezeli a memóriát, a láncolatokat és az integrációkat. Az application réteg az üzleti felhasználók számára látható felület: chatbot, dashboard, automatizált workflow. A rétegek közötti interfészek API-alapúak legyenek — ez biztosítja a cserélhetőséget.
Hogyan kerüld el a vendor lock-int?
A vendor lock-in elkerülésének három alappillére: (1) API-first tervezés — minden integrációt API-n keresztül építs, ne natív SDK-val, mert az API váltható, az SDK nem; (2) absztrakciós réteg — ne az egyes modellek API-ját hívd közvetlenül az application rétegből, hanem egy köztes orchestration réteget (LangChain, LlamaIndex); (3) contract-based storage — az adatot és a prompt-könyvtárat szállítófüggetlen formátumban tárold (JSON, YAML, Git). Ha ezeket betartod, a foundation model 24 óra alatt cserélhető.
Mi a build vs. buy döntés logikája AI stack esetén?
A build vs. buy döntés az orchestration és az application rétegre vonatkozik — a foundation model réteget szinte mindig buy. Orchestration rétegben: ha meglévő no-code/low-code tool (n8n, Make) lefedi az igényeket, ne fejlessz — a build cost tipikusan 5-10× drágább az első évben. Application rétegben: build akkor indokolt, ha a use case annyira speciális, hogy nincs piaci megoldás, vagy ha compliance-ból adódóan semmi nem telepíthető külső rendszerre. Minden más esetben vásárolj és konfigurálj.
Mi a platform konvergencia veszélye?
A platform konvergencia azt jelenti, hogy egy szállító igyekszik az AI stack mindhárom rétegét lefedni — model, orchestration és application szinten egyaránt (pl. Microsoft: Azure OpenAI + Copilot Studio + Copilot 365). Ez kényelmes, de veszélyes: ha az egész stack egyetlen szállítón fut, az áremelés, a funkcióleépítés vagy a szállítóváltás szinte lehetetlen. Ellenszer: minimum két rétegen legyen versenytársi alternatíva megtartva.
Hogyan kezeljük a cost governance-t az AI stack-ben?
A cost governance öt eszköze: (1) token-monitoring minden API-híváson — logold a bemeneti és kimeneti tokeneket; (2) cost-cap beállítás API-szinten (OpenAI, Anthropic mindkettőhöz nyújt eszközt); (3) model-routing — kisebb modellek (GPT-4o mini, Claude Haiku) egyszerű feladatokhoz, nagyobb modellek csak komplex, magas-értékű feladatokhoz; (4) caching layer — ismétlődő promptokra cached response, nem API-hívás; (5) negyedéves cost audit — melyik workflow generálja a cost 80%-át?
Mikor érdemes self-hosted modellt használni a stackben?
Self-hosted modell (Llama, Mistral, Qwen stb.) három esetben indokolt: (1) compliance — az adatok nem hagyhatják el a vállalat infrastruktúráját (egészségügy, pénzügy, honvédelem); (2) skála — ha havonta több millió API-hívás kell, a saját infrastruktúra olcsóbb, mint az API-cost; (3) fine-tuning — ha a modellt zárt, vállalati adaton kell tréningezni. Minden más esetben a managed API rugalmasabb, olcsóbb és kevesebb karbantartást igényel.
Mi az interoperabilitás és miért kritikus?
Az interoperabilitás azt jelenti, hogy az AI stack különböző rétegei és eszközei kommunikálni tudnak egymással szabványos protokollokon keresztül. A legfontosabb szabványok: REST API, OpenAPI spec, webhook, OAuth 2.0 hitelesítés. Ha egy eszköz csak zárt, natív integrációkat kínál és nem nyújt nyílt API-t, az automatikusan vendor lock-in kockázatot jelent. Az interoperabilitás az API-first tervezés eredménye — nem véletlenszerű.
Hogyan auditáljuk a AI stack-et negyedévente?
A negyedéves stack audit négy kérdés köré épül: (1) Cost: melyik réteg generálja a cost aránytalanul nagy részét? Van-e optimalizálási lehetőség? (2) Dependency: van-e single-point-of-failure a stackben — egy szállító, amelynek kiesése leállítja a működést? (3) Performance: a használati metrikák (latency, error rate, token efficiency) romlottak-e az előző negyedévhez képest? (4) Roadmap: a szállítók tervezett változásai (áremelés, API-deprecation) érintenek-e kritikus komponenst?
Mi az AI stack és az adat-stratégia kapcsolata?
Az AI stack hatékonysága nagyrészt az adatstratégián múlik. A foundation model minősége adott — a differenciáló tényező az, hogy milyen kontextust, tudásbázist és vállalati adatot csatol hozzá az orchestration réteg. A RAG (Retrieval-Augmented Generation) architektúra a leggyakoribb megoldás: a vállalati tudásbázis vektorizálva, a releváns részek a promptba kerülnek. Az adatminőség, az indexelési stratégia és a retrieval pontossága döntően befolyásolja az AI output minőségét.
AI Stack Audit — architektúra-szemlelű értékelés
Ha az AI stack-ed organikusan nőtt és most átláthatóságot, cost-kontrollt és lock-in mentes architektúrát szeretnél: az AI Stack Audit egy napos, struktúrált átvizsgálás — rétegenkénti értékelés, dependency térkép és konkrét optimalizálási javaslatok.
AI Stack Audit kérése →AI Eszköz Kiválasztás — témák
