Visszanézhetőség és audit-trail

A Nortinia AI Asszisztens nem fekete doboz. Minden mutáció, amit a chat-en keresztül indít egy felhasználó, ugyanúgy bekerül az audit log-ba, mint a kézi UI-műveletek — és néhány extra metadat-tal, ami a chat-eredetű műveleteknek jár.

Mit rögzítünk minden mutációnál

1. Actor: ai_assistant:<userId> — a felhasználó ID-ja, aki a promptot írta. Sosem "a bot".
2. Eredeti prompt: a chat-üzenet szövege, ami a tool-hívást kiváltotta.
3. Tool name: pl. refund.initiate, user.changeRole.
4. Tool args: a tool-nak átadott paraméterek (PII maszkolva ahol kell).
5. Resulting diff: a változás előtti és utáni állapot kulcsmezői.
6. Tenant ID: melyik ügyfél-fiókban történt.
7. Timestamp: másodperc-pontos UTC.
8. Sikeresség: futott-e a tool, vagy guard-on / validation-en bukott.
9. MCP server: melyik szerver (admin-mcp, finance-mcp, stb.) szolgálta ki.
10. Conversation ID: a chat-session azonosítója, hogy a teljes párbeszéd visszakereshető legyen.

Retention

A chat-eredetű audit-events 365 napig élnek a audit_events Postgres táblában, ezután S3 archív-bucket-be költöznek (még 6 évig, GDPR + számviteli okból). A friss 365 nap online lekérdezhető az admin-felületen, az archív lekérés ügyfél-szolgálati ticket-en keresztül megy (átlagos visszaadási idő: 4 óra).

Filterelés az admin audit nézetében

Az admin /audit-events oldala négy chat-specifikus szűrőt kapott:

• "Csak chat-eredetű" — actor LIKE 'ai_assistant:%' kapcsoló
• Felhasználó — ki írta a promptot
• Tool name — melyik MCP tool futott
• Conversation — egy adott beszélgetés összes mutációja egy nézetben

Gyakori használat: "mutasd, mit csinált Anna múlt héten az asszisztenssel a finance-ben". Egy szűrő, egy lista, exportálható CSV-be.

Amit szándékosan NEM tárolunk

A modell "inner thought" tokenjeit — az LLM belső reasoning-stream-jét, amit nem küld vissza a felhasználónak. Ez az adat hatalmas mennyiségben jönne (egy átlagos prompt 2-8k extra token), zajos, és értelmezhetetlen audit-szempontból. Akkor sem segít, ha valami félrement: a végeredmény (tool-hívás argumentumokkal) és a látható válasz együtt elég a reprodukcióhoz.

Ugyanígy nem tároljuk:

• A retrieval-augmented chunk-okat (a KB-ből előhívott dokumentum-darabokat) — csak a citáció-azonosítókat (a dokumentum + page-range).
• A modell stream-jének heartbeat-eseményeit.
• A voice-session belső time-jeleit (csak a végeredmény transcript-et).

Mit lát az ügyfél

Minden tenant admin-ja az asszisztens-audit-jét magában a saját audit-nézetében látja, ugyanazon a helyen, ahol a kézi műveletek vannak. Nincs külön "AI audit" tab. Ez szándékos: az asszisztens egy interakciós csatorna a felhasználó és a rendszer között — nem külön identitás. Amit a felhasználó tett (kézzel vagy chat-en keresztül), azt egy nézetben látja.

Compliance integráció

A chat-eredetű audit log SOC 2 Type II és ISO 27001 audit-ban már 2026 márciusban bevizsgálódott. A két fő követelmény:

1. Reprodukálhatóság — egy adott mutáció okát (a felhasználói prompt) vissza tudjuk adni. ✅ az Eredeti prompt mező miatt.
2. Identitás-elválasztás — a bot nem szerepel saját identitásként. ✅ az ai_assistant:<userId> formátum miatt.

A leggyakoribb visszanézési use-case

Veszélyzónás mutációk (refund, role-change, delete) második napon utólagos sanity-check. A finance vezető lefuttat egy szűrőt: "mutasd minden chat-eredetű refundot az elmúlt 24 órában, 50k Ft felett". Lista. Ránéz. Ha valami furcsa: kattint a conversation ID-re, és látja a teljes párbeszédet, amiből a mutáció jött. Ha valami tényleg furcsa: visszavonja a refundot, és felhívja az ügyintézőt.

Ez a flow tipikusan napi 2-3 percet vesz igénybe, és felülmúlja a régi módszert (Slack-üzenetekben kérdezni "ki csinálta ezt?").

Hova fejlesztjük tovább

A következő iterációban két dolog jön: real-time audit-stream (Kafka topic-on, hogy SIEM rendszerekbe lehessen kötni), és "explain this action" gomb minden audit-bejegyzésen, ami visszaadja természetes nyelven, hogy mit csinált a tool. Ez különösen non-tech vezetőknek hasznos, akiknek a tool_args JSON nem mond semmit.