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

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.