Ugrás a tartalomhoz
← Vissza a Naplóhoz

AI Readiness Audit — 30 pontos ellenőrzőlista a bevezetés előtt

Harminc konkrét pont az AI bevezetés előtt: adat-érettség, modell-választás, integráció, RBAC, költségvetés, brand, audit. 25+ zöld pontnál indulhatsz.

Az AI nem hibajavító — felerősíti azt, ami alatta van.

Ez a lista nem elméleti keret. Harminc konkrét pont, amit minden új AI bevezetés előtt érdemes végigfutni. Ha 25 vagy több pontot szépen lefedsz, érdemes elindítani a projektet. Ha kevesebbet, először az **AI Readiness retainer**-előkészítés javasolt, mielőtt a build-fázisba lépnél — különben a bevezetés féloldalas marad, és a ROI 6-12 hónappal csúszik.

A pontokat hat csomagba szervezzük: adat-érettség, modell-választás, integrációs felület, RBAC és hozzáférés, költségvetés és KPI-keret, brand és audit. Minden pontnál egy-két mondat: mit jelent, és hogyan dönts.

Adat-érettség (1-6)

  • **1. Strukturált adatforrás.** Van legalább egy konszolidált rendszer (ERP, CRM, számlázó), ahol a master-data tisztán fut, vagy még szétszórt táblákból gyűjtögetsz. Ha az utóbbi, az AI első dolga lesz, hogy a piszkos adaton hibás választ adjon — előbb tisztítani kell.
  • **2. Adat-frissesség.** Az AI-nak naprakész vagy napi szinten frissített adat kell. Ha a legfrissebb termék-leírás háromhetes Excel-export, a chat-bot félretájékoztatja a vevőt. Ütemezett szinkron (15 perc - 1 óra) az elvárás.
  • **3. Sémához kötés.** A táblákban van egyértelmű kulcs (termékID, ügyfélID, számlaszám), vagy mindenki a saját "név alapján" megoldásával dolgozik. AI-grounding kulcs nélkül halmoz hibát.
  • **4. Történeti mélység.** Van-e 12-24 hónap visszamenő adat trendekhez, szezonalitáshoz, lead-scoringhoz. 3 hónap kevés. Ha nincs, az első félévben az AI csak "jelen-pillanatra" tud építeni.
  • **5. Adatcímkézés.** A kulcs-mezőkön (termék-kategória, lead-státusz, fizetési-állapot) konzisztens címkézés fut, vagy 14 különböző értéket találunk ugyanarra. Az AI a változatosságot zajnak látja.
  • **6. PII-határ.** Egyértelmű, melyik mező személyes adat (név, e-mail, telefon, IP-cím), és melyik nem. Ezt az AI-prompt-okban tudatosan kezelni kell — GDPR-kontextusban ez nem opció, hanem alap.

Modell-választás (7-12)

  • **7. Feladat-típus tisztázva.** Klasszifikáció, generálás, ügynöki művelet vagy hang-asszisztens — mind más modell-családot kíván. Egy mondatban le kell tudni írni, hogy az AI **mit fog csinálni**, mielőtt a modellt választod.
  • **8. Latencia-cél.** Real-time hang (cél 280 ms alatti medián), interaktív chat (1-2 másodperc), batch-elemzés (10 perc) — más-más modell-réteget igényel. A cél a választást keretezi.
  • **9. Nyelv-fedettség.** Magyar nyelvű AI minőség a kis modelleknél jelentősen elmarad a nagyoktól. Ha a fő használat HU, a nagyobb modell-réteg az alap.
  • **10. Provider-stratégia.** Egy provider (lock-in kockázat) vagy modell-mix (operátori rugalmasság). A Nortinia Engine az utóbbit hajtja — OpenAI, Anthropic, Gemini, Mistral között váltogatható a tenant-szintű routing.
  • **11. Költség-cap modell-szinten.** Tudni kell, mennyit költhetsz havonta tokenre. Erre alapozva válik el, hogy a drága modellt csak premium ügyfél-folyamatra teszed, és olcsóbbat a tömeges háttér-feladatra.
  • **12. Fallback-stratégia.** Ha az elsődleges modell lassul vagy 5xx-et ad, mi a B-terv. Provider-mix nélkül nincs B-terv — egy szolgáltató kiesése az egész AI-felületet leállítja.

Integrációs felület (13-18)

  • **13. MCP-vagy-REST döntés.** A kiszolgáló rendszerek MCP-kompatibilisek lesznek, vagy hagyományos REST-tool-tracetet építünk. A Nortinia Engine MCP-elsődleges, de mindkettőt támogatja.
  • **14. Tool-katalógus listázva.** Tudod-e konkrétan, melyik 20-50 művelet kell az AI-nak. Listázás nélkül az AI nem fér hozzá a rendszerhez, csak "beszélget".
  • **15. Preview-and-confirm a mutációknál.** Minden "write" típusú tool kétlépéses: preview (mi fog történni) + felhasználói megerősítés. Enélkül az AI "saját nevében" cselekszik, ami compliance-kockázat.
  • **16. Egységes hibakezelés.** A tool-ok strukturált hibát adnak vissza (kód, üzenet, retry-stratégia), nem nyers stack-tracet. Az AI így természetes nyelvre tudja fordítani a problémát.
  • **17. Idempotencia.** A kritikus mutációs tool-ok (rendelés, refund, számla) idempotens kulccsal védve. Hálózati retry ne csináljon duplikátumot.
  • **18. Hozzáférési határ a tool-ban.** Egy tool csak a hívó felhasználó tenant-jához és szerepéhez tartozó adatot lát. Cross-tenant kérés még véletlenül sem szivároghat.

RBAC és hozzáférés (19-22)

  • **19. Szerep-katalógus tisztázva.** Tudod, ki mit csinálhat: super_admin, tenant_admin, sales, finance, logistics, support. Ha 30 ember 4 különböző szerepet vegyítve használ, az AI-szerep-térkép is zavaros lesz.
  • **20. Szerep-alapú tool-tár.** Az AI minden felhasználónak más tool-készletet villant — a sales-es nem fér a finance refund-jához. A Nortinia Engine ezt szerep-szűrővel adja, prompton kívül.
  • **21. Felhasználói súrlódás.** A drága műveleteknél (nagy összegű refund, tenant-szintű ár-változtatás) második ember megerősítése kötelező. Ez nem akadály, hanem védőháló.
  • **22. Anonim-vagy-azonosított elv.** Eldöntöd, hogy az AI csak bejelentkezett vagy anonim felhasználóknak is válaszol. A storefront chat anonim, az admin AI bejelentkezett — vegyíteni nem szabad.

Költségvetés és KPI-keret (23-27)

  • **23. Havi token-keret tenant-szinten.** Konkrét forint-szám per hó. "Annyit költünk, amennyi jön" antimintát szül.
  • **24. KPI-elsődleges célok.** Két-három mérőszám: pl. ügyfél-szolgálati átfutási idő -40%, lead-scoring pontossága +25%, hang-deflection ráta 60%. Ezek hajtják a build-prioritást.
  • **25. Hat-hónapos ROI-keret.** Mennyit takarít az AI hat hónap alatt, és mennyibe kerül. Ha a két szám távoli galaxisban van, az audit kimenete: ne indítsd.
  • **26. Build-vs-run költség-szétválasztás.** Az egyszeri bevezetés és a havi futó-költség külön sor. Ezek összemosása csúsztatja a ROI-számítást.
  • **27. Vész-leállítási küszöb.** Ha a token-keret 80%-án vagy hó közepén, mi történik. Auto-cap a modellnél, vagy emberi review — el kell dönteni.

Brand és audit (28-30)

  • **28. Brand-prompt szabályok.** Kötelező megszólítás ("te" vagy "Ön"), tiltott kifejezések, hivatkozandó értékek. A Nortinia Engine ezt tenant-szinten kezeli, nem prompt-ban smuggle-olja.
  • **29. Audit-trail minden műveletre.** Két identitás minden mutációnál: actor (felhasználó) és origin (MCP tool). Visszanézhetőség hat hónap után is. Nélküle a GDPR-megfelelőség problémás.
  • **30. GDPR-erasure érintettség.** A Nortinia oldalon van ledger-alapú PII-törlés (Article 17). Az AI-promptokban szereplő ügyfél-adat ezzel együtt törlődik. Ha nincs, az AI-adat a fő rendszer után "él" — ez nem megengedett.

Hogy döntsd el a végén

Végigfutsz a 30 ponton, mindegyiket zöld / sárga / piros értékelést adsz. Ha **25+ zöld**, indulhatsz: a Nortinia Engine + a választott modell-réteg azonnal építhető. Ha **20-24 zöld**, AI Readiness retainer-előkészítést javaslunk: 4-6 hét, a piros pontok zöldre vitele. Ha **20 alatti zöld**, először az alap-rendszer tisztázása (ERP, CRM, master-data), és csak utána AI. Az AI nem hibajavító — felerősíti azt, ami alatta van.

Az AI nem hibajavító — felerősíti azt, ami alatta van.
Norbert Kubinyi

Kiemelten érdekel egy téma?

Írj nekünk, és ha van tapasztalatunk benne, publikáljuk.