AI dokumentumfeldolgozás magyar nyelven: miért nyer a helyben futó megoldás a felhős AI-jal szemben?

A legtöbb magyar cégnél ma is ugyanúgy zajlik a papírmunka, mint tíz éve: valaki megnyitja a postafiókot, lementi a PDF-eket, kinyitja a könyvelőprogramot vagy az ERP-t, és kézzel átpötyögi a számla adatait: szállító, számlaszám, dátum, nettó, áfa, fizetési határidő. Ugyanez történik a beérkező szerződésekkel, a megrendelőkkel, a szállítólevelekkel és az űrlapokkal. A folyamat lassú, monoton, és minden egyes kézi rögzítés egy újabb lehetőség a hibára.

Az AI dokumentumfeldolgozás pontosan ezt a munkát automatizálja. De nem mindegy, hogyan. Ebben a cikkben végigvesszük, mi is az AI dokumentumfeldolgozás, milyen megoldástípusok léteznek a piacon, hol bukik el a felhőbe kiszervezett megközelítés (a Microsoft Azure Document Intelligence és a Copilot példáján), és miért hoz mérhetően jobb eredményt a magyar nyelvre optimalizált, a cég saját szerverén futó DocAI.

Mi az AI dokumentumfeldolgozás?

Az AI dokumentumfeldolgozás olyan technológia, amely mesterséges intelligencia segítségével automatikusan kiolvassa, értelmezi és strukturált adattá alakítja a dokumentumokban tárolt információt. A bemenet tipikusan egy strukturálatlan fájl — egy beszkennelt számla, egy PDF szerződés, egy e-mailhez csatolt megrendelő —, a kimenet pedig gépileg feldolgozható, mezőkre bontott adat (például JSON), amelyet a háttérrendszer közvetlenül tovább tud használni.

Fontos megérteni a három, gyakran összekevert fogalom közötti különbséget, mert ez dönti el, mire képes egy adott rendszer:

OCR (optikai karakterfelismerés). Ez a legrégebbi réteg. Az OCR annyit tud, hogy a képpontokból álló betűket géppel olvasható karakterekké alakítja. Ha a számlán szerepel az „1 250 450 Ft”, az OCR ebből szöveget csinál, de hogy ez most a végösszeg, az áfa, vagy egy tételsor ára, azt nem érti. Az OCR „lát”, de nem „ért”.

IDP (intelligens dokumentumfeldolgozás). Az IDP az OCR fölé épül. Felismeri a dokumentum típusát (számla, szerződés, megrendelő, kárbejelentő), kinyeri belőle a strukturált mezőket, validálja az adatokat, és átadja a háttérrendszernek. Ez már nemcsak látás, hanem értelmezés.

KIE (kulcsinformáció-kinyerés, Key Information Extraction). Ez az IDP legértékesebb magja: a dokumentumból pontosan azokat a mezőket nyeri ki, amelyekre a folyamatnak szüksége van, a megfelelő szerkezetben. A KIE minősége határozza meg, hogy a rendszer kimenete megbízható-e annyira, hogy emberi újragépelés nélkül beengedhető legyen a könyvelésbe vagy az ERP-be.

Ez a megkülönböztetés azért kulcsfontosságú, mert a piacon sok megoldás „AI dokumentumfeldolgozásnak” nevezi azt is, ami valójában csak egy chat-felület a dokumentumok fölött. Erre még visszatérünk.

A piaci megoldások három típusa — és ahol mind a három elhasal

Ha egy magyar KKV, könyvelőiroda vagy ügyvédi iroda ma AI dokumentumfeldolgozás után néz, három alapvető megközelítéssel találkozik. Mindháromnak megvan a maga logikája, és mindháromnak van egy strukturális gyengéje, amit érdemes tisztán látni a döntés előtt.

1. A felhős hyperscaler szolgáltatás (Microsoft Azure Document Intelligence, Copilot)

A legkézenfekvőbb út egy nagy felhőszolgáltató kész API-ja. A Microsoft kínálata itt az Azure Document Intelligence (korábbi nevén Form Recognizer), illetve a dokumentumokkal kapcsolatos kérdésekre a Microsoft 365 Copilot. Technológiailag ezek érett termékek, a probléma nem a képességükkel van, hanem az üzemeltetési modelljükkel.

Az adat elhagyja a céget. Az Azure Document Intelligence elsősorban menedzselt felhőszolgáltatás. A teljes körű, helyben futó (konténeres) telepítés csak bizonyos modellekre (Read, Layout) érhető el; az egyedi és előre betanított kinyerő modellek a betanításhoz felhős kapcsolatot igényelnek. Egy könyvelőiroda ügyfélaktái, egy ügyvédi iroda szerződésállománya vagy egészségügyi, banki, közszférás adatok esetén ez nem apró részlet: a GDPR (különösen az adatfeldolgozói szerződésekre vonatkozó 28. cikk) és az adatszuverenitási elvárások mellett az, hogy az érzékeny dokumentum egy külföldi felhőbe kerül feldolgozásra, sokszor egyenesen kizáró ok.

A költség oldalanként ketyeg. Az Azure Document Intelligence árazása oldalalapú: a Read OCR ezer oldalanként, az előre elkészített modellek (számla, nyugta, szerződés stb.) ennek többszöröséért, az egyedi kinyerés pedig még drágábban számláz. Ez azt jelenti, hogy a megoldás soha nem „a tied” — minden egyes feldolgozott oldal újabb számlatétel, a havi költség pedig a dokumentumvolumennel arányosan és kiszámíthatatlanul nő. Egy nagy iratforgalmú iroda esetében ez évek alatt komoly, ismétlődő kiadás, miközben a végén semmilyen saját eszköz nem marad a kézben.

Nincs benne magyar fókusz. A felhős OCR-szolgáltatások több száz nyelvet támogatnak, de épp ettől általánosak. Egyik sem magyar nyelvre van optimalizálva. A magyar számlák, szerződések, hivatali iratok sajátos terminológiája, ragozása, a magyar dátum- és összegformátumok kezelése egy globális, mindenre kihegyezett modellnél óhatatlanul kompromisszumos.

Nincs benne kész munkafolyamat. Az Azure Document Intelligence egy API, nem egy kész alkalmazás. Nincs beépített jóváhagyási felület, nincs „human-in-the-loop” ellenőrző UI, ezt a céges fejlesztőcsapatnak kell köré építenie (jellemzően a Power Platformból). Ehhez Azure-előfizetés, erőforrás-provisioning és kulcskezelés kell. Vagyis a „kész szolgáltatás” valójában csak a feldolgozó motor; a használható termék elkészítése külön projekt.

A Copilot pedig nem adatkinyerés. A Microsoft 365 Copilot a dokumentumokkal kapcsolatban lényegében RAG-alapú kérdés-válasz: chatben rákérdezel valamire, és kapsz egy szövegszerű választ a céges tartalmaid alapján, mindezt szintén a Microsoft felhőjében. Ez hasznos lehet a keresésre, de nem ugyanaz, mint a strukturált KIE. Egy chatválasz nem garantáltan teljes, nem determinisztikus, és nem köthető be közvetlenül, mezőről mezőre a könyvelésbe. A számlafeldolgozáshoz nem „beszélgetés” kell a dokumentummal, hanem megbízható, strukturált adat.

2. A tanácsadói/integrátori projekt

A második út, hogy egy AI-tanácsadó céggel egyedi projektben építtetjük fel a folyamatot. Ennek a megközelítésnek az ígérete a testreszabottság: workshop, KPI-definíció, néhány száz mintadokumentum begyűjtése, majd pipeline felépítése.

A gond kettős. Egyrészt ezek a projektek a háttérben szinte mindig ugyanazokra a felhős motorokra (Azure, AWS, OpenAI) támaszkodnak, vagyis öröklik az előző pont összes adatszuverenitási és költségproblémáját, csak egy tanácsadói réteggel megfejelve. Másrészt a végeredmény egy egyedi, projektszemléletű integráció: drága a felépítése, és a karbantartása is folyamatos tanácsadói függőséget jelent. A KKV-szegmensben, ahol a cél a gyors, kiszámítható megtérülés, ez ritkán a leghatékonyabb modell.

3. A SharePoint-alapú workflow + RAG-chat

A harmadik út egy nagyvállalati dokumentum-workflow platform, amely mellé AI-modult kapcsolnak. Ezek tipikusan a meglévő (gyakran SharePoint-alapú) jóváhagyási és iratkezelési folyamatra épülnek, az „AI” rétegük pedig többnyire egy felhős nagy nyelvi modellre (például OpenAI) támaszkodó RAG-chat: kereshetővé teszi a dokumentumokat, és kérdésekre válaszol.

Ez kiváló lehet egy nagyvállalat szabályzat- és szerződés-jóváhagyási láncára. De két okból sem fedi le a magyar KKV-k és irodák valódi igényét. Egyrészt nehézsúlyú, SharePoint-központú nagyvállalati platform, túl sok egy 10–50 fős könyvelő- vagy ügyvédi irodának. Másrészt, ahogy fent láttuk: a RAG-chat nem KIE. A strukturált adatkinyerés, ami a könyvelés és az ERP-betöltés alapja, ebben a modellben másodlagos. A hangsúly a keresésen és a jóváhagyási folyamaton van, nem a megbízható mezőkinyerésen. És a tényleges AI itt is felhős marad.

Miért más a DocAI? On-premise, magyar nyelvre építve

A DocAI azzal a meggyőződéssel készült, hogy a fenti három modell mindegyike ugyanazon a ponton enged: vagy az adat hagyja el a céget, vagy a magyar nyelvi minőség kompromisszumos, vagy a megoldás soha nem lesz igazán a tied. A DocAI mottója ezért: AI, ami a cégnél marad.

Az adat a cégnél marad (on-premise)

A DocAI a cég saját infrastruktúráján fut, on-premise appliance formájában, vagy szabályozott környezetben dedikált megoldásként. A dokumentum nem kerül külföldi felhőbe; a feldolgozás teljes egészében a céges határokon belül zajlik. Egy könyvelőirodának vagy ügyvédi irodának ez nemcsak megnyugtató, hanem sokszor megfelelőségi követelmény is: a GDPR adatfeldolgozói elvárásai, az ügyféltitok és az adatszuverenitás mind teljesülnek, mert az adat fizikailag sem hagyja el a szervezetet.

Magyar nyelvre optimalizált modell — és mért pontosság

A DocAI nem egy globális, „mindent tudó” felhős modellt használ, hanem magyar dokumentumokra hangolt, helyben futtatott nyelvi modellt. És ami a leglényegesebb: ezt nem ígérjük, hanem mérjük.

A DocAI saját, magyar nyelvű dokumentumokból összeállított KIE benchmark-korpuszt tart fenn, és minden modellváltást ezen a teszthalmazon, automatizált kiértékelő harnesszel validál (pontosság/recall/F1, illetve LLM-bíró és kézi ellenőrzés kombinációjával). A jelenlegi éles KIE-modell, a Qwen3.6 ezen a magyar benchmark-korpuszon F1 = 0,983 eredményt ért el, míg egy összehasonlításként mért, korszerű nyílt modell (Gemma) ugyanezen a korpuszon F1 = 0,890-en teljesített. A különbség nem marketingígéret: reprodukálható mérés magyar dokumentumokon, amelynek módszertanát és eredményeit nyilvánosan is dokumentáltuk.

Ez az a fajta bizonyíték, amit egy felhős, általános szolgáltatás nem tud felmutatni magyar nyelvre: ők globális átlagpontosságot kommunikálnak, a DocAI konkrét, magyar korpuszon mért számot.

Valódi KIE, nem chat

A DocAI a strukturált kulcsinformáció-kinyerésre (KIE) van kihegyezve, nem egy chatablakra. Felismeri a dokumentum típusát, kinyeri a meghatározott mezőket a megfelelő szerkezetben, validálja őket (van-e ilyen szállító a törzsadatban, egyezik-e a tételek összege a végösszeggel), és bizonytalanság esetén emberi ellenőrzésre irányít. A kimenet determinisztikus, mezőre bontott, strukturált adat, amely közvetlenül beköthető a könyvelésbe vagy az ERP-be, nem pedig egy szövegszerű válasz, amit utána valakinek kézzel kell visszafejtenie.

Összehasonlító táblázat: a négy megközelítés

Kinek való a DocAI?

Az AI dokumentumfeldolgozás akkor hoz a leggyorsabban mérhető eredményt, ha sok a magas volumenű, ismétlődő dokumentum, és az adat érzékeny. Ezért a DocAI elsősorban az alábbi szervezeteknek készült:

Könyvelőirodáknak, ahol naponta számlák, bankkivonatok és bizonylatok tömegét kell rögzíteni, pontosan, határidőre, miközben az ügyféladatok bizalmasak.

Ügyvédi irodáknak, ahol a szerződésportfólió kulcsadatainak (felek, határidők, összegek, kötelezettségek, kockázati pontok) kinyerése és követése komoly kézi munka, és ahol az ügyféltitok megtartása nem opció.

Szabályozott szektoroknak és KKV-knak, ahol az adat nem hagyhatja el a céges infrastruktúrát, de a back-office (számlafeldolgozás, megrendeléskezelés, iratkezelés) automatizálása óriási idő- és hibamegtakarítást hoz.

Gyakran ismételt kérdések (GYIK)

Mi az AI dokumentumfeldolgozás?
Az AI dokumentumfeldolgozás olyan technológia, amely mesterséges intelligenciával automatikusan kiolvassa és strukturált adattá alakítja a dokumentumokban (számlák, szerződések, űrlapok) tárolt információt, kiváltva a kézi adatrögzítést. A bemenet egy strukturálatlan fájl, a kimenet gépileg feldolgozható, mezőkre bontott adat.

Mi a különbség az OCR és az AI dokumentumfeldolgozás között?
Az OCR csak karaktereket ismer fel: a képből szöveget csinál, de nem érti, mi micsoda. Az AI dokumentumfeldolgozás (IDP) ennél tovább megy: felismeri a dokumentum típusát, értelmezi a szerkezetét, kinyeri a konkrét mezőket (kulcs-érték párok, táblázatok), validálja az adatokat, és strukturált kimenetet ad.

Az AI dokumentumfeldolgozáshoz a felhőbe kell küldeni az adataimat?
A felhős szolgáltatások (például a Microsoft Azure Document Intelligence) esetében jellemzően igen, a dokumentum a feldolgozáshoz a szolgáltató felhőjébe kerül. A DocAI ezzel szemben helyben (on-premise) fut, így az adat nem hagyja el a céget. Érzékeny adatoknál (könyvelés, jog, egészségügy) ez gyakran megfelelőségi követelmény is.

Mennyire pontos a DocAI magyar dokumentumokon?
A DocAI saját, magyar nyelvű KIE benchmark-korpuszán a jelenlegi éles modell (Qwen3.6) F1 = 0,983 eredményt ért el, egy összehasonlításként mért nyílt modell (Gemma) ugyanitt F1 = 0,890-en teljesített. A mérést automatizált kiértékelő harnesszel végezzük, és nyilvánosan dokumentáljuk.

A Microsoft Copilot nem elég a dokumentumfeldolgozáshoz?
A Copilot lényegében RAG-alapú kérdés-válasz a céges tartalmak fölött, a Microsoft felhőjében. Hasznos lehet keresésre és összefoglalásra, de ez nem strukturált kulcsinformáció-kinyerés (KIE): a válasza szövegszerű, nem determinisztikus, és nem köthető be megbízhatóan, mezőről mezőre a könyvelésbe vagy az ERP-be.

Miért drágább hosszú távon egy felhős AI dokumentumfeldolgozó megoldás?
A felhős szolgáltatások jellemzően oldalalapon számláznak: minden feldolgozott oldal újabb költségtétel, és a havi kiadás a dokumentumvolumennel arányosan, kiszámíthatatlanul nő. Az on-premise DocAI ezzel szemben saját eszköz, amelynek költsége kiszámítható, és nem ismétlődik minden egyes oldal után.

Alkalmas a DocAI kis cégeknek is?
Igen. A DocAI kifejezetten a magyar KKV-k, könyvelő- és ügyvédi irodák méretére és igényeire készült, nem egy nehézsúlyú nagyvállalati platform, amelyhez külön bevezetési projekt kell.

Összegzés

Az AI dokumentumfeldolgozás ma már nem kísérlet, hanem éles, napi több ezer dokumentumon működő technológia. A kérdés nem az, hogy „kell-e”, hanem az, hogy hogyan vezetjük be. A felhőbe kiszervezett megoldások, köztük a Microsoft Azure Document Intelligence és a Copilot, érett technológiát kínálnak, de három ponton rendre engednek: az adat elhagyja a céget, nincs valódi magyar nyelvi optimalizálás, és a megoldás soha nem lesz igazán a tied.

A DocAI ezt a három pontot fordítja meg: helyben fut, magyar nyelvre van hangolva és mérve, és valódi, strukturált kulcsinformáció-kinyerést ad, nem chatet. Ha a céged sok érzékeny dokumentumot kezel, és olyan AI dokumentumfeldolgozást keresel, amely a cégnél marad, beszéljünk.