AI az ERP-ben: mit tud a beépített mesterséges intelligencia?

Először is: melyik Odoo-t használod?

Egy szó a hatókörről. A cikk címe ERP-t mond, a példák viszont végig az Odoo-ról szólnak. Ennek egyszerű oka van: mi elsősorban Odoo-val foglalkozunk, tehát erről tudunk olyan részletességgel írni, ami tényleg használható — a gyártói dokumentáció szó szerinti mondataiig. A mechanizmus viszont, amit bemutat, minden nagy ERP beépített AI-jára igaz: a modell nem a gyártóé, a korlát a kódban van, és a pontosságot nem méri senki helyetted. Ahol egy másik nagy szereplő adata is megvan, azt külön odaírom.

A legtöbb ismertető ezt a kérdést átugorja, pedig ez dönt el mindent. Nem az a kérdés, hogy mit tud az Odoo AI-ja, hanem hogy egyáltalán ott van-e nálad. Négy különböző válasz létezik, plusz egy ötödik.

Community: nincs beépített AI — és 2025 óta kevesebb van, mint korábban. Az ai modul nem szerepel az Odoo nyilvános, Community forráskódjában: pontosan ugyanúgy hiányzik belőle, ahogy a többi, csak Enterprise-ban elérhető modul. Az Odoo ezt sehol nem mondja ki szövegesen — a forráskód viszont egyértelmű. És van egy visszalépés is: a 18-as Community szövegszerkesztőjében még ott volt egy ChatGPT-funkció az Odoo saját kreditszolgáltatásán keresztül, a 19-esből ez kikerült. Aki Community-n van, ma nem tud gyári AI-t bekapcsolni; harmadik feles modult kell telepítenie.

Enterprise 18: nincs AI-szekció a dokumentációban. A 18-as doksiban az AI-oldalak nem léteznek; ott egyedül a Documents alatti, kreditalapú dokumentumdigitalizálás van, ami régi szolgáltatás és nem része az AI-alkalmazásnak. Ha 18-on futsz, az alábbiak nagy része nem kapcsolható be, hanem verziófrissítést jelent.

Enterprise 19: van AI, de határok között. Ez jött 2025 szeptemberében, és a teljes AI-alkalmazás ennek a kiadásnak az újdonsága. A legfontosabb mondat viszont magából a dokumentációból jön: az alapértelmezett asszisztens nem tud változtatni az adatbázison. Megnyit nézeteket, riportot mutat, de leadet nem hoz létre és adatot nem módosít — ahhoz külön témát és eszközt kell hozzárendelni. Erről szól a cikk további része.

Enterprise 20: még nincs. A 20-as verziót az Odoo a 2026-os konferenciáján mutatja be, 2026. szeptember 24. és 26. között — vagyis másfél héttel e cikk után. Hivatalos kiadási jegyzet és 20-as dokumentáció ma még nem létezik. Amit a fejlesztői ág doksija előrevetít: MCP-szerver, amelyen keresztül külső AI-agens közvetlenül módosíthatja az adatbázist; képgenerálás; a „témák" átnevezése „készségekre"; és — ez a legbeszédesebb — eltűnt belőle az a mondat, hogy az asszisztens nem tud változtatni az adatbázison. Ez fejlesztői ág, a megjelenésig változhat, és az „agentikus" szót az Odoo hivatalosan nem használja a 20-as verzióra. Aki erre tervez, várja meg a bejelentést.

A kiadási ritmus egyébként így néz ki: a legfrissebb nagy kiadás a 19.0 (2025. szeptember), amely mindhárom telepítési módon elérhető, és a támogatása a tervek szerint 2028 szeptemberéig tart. Emellett két-három havonta közbenső, „SaaS" verziók jelennek meg, de azok csak a felhős változatban élnek, és nem jogosultak kiterjesztett támogatásra.

Van, amit AI-nak hisz az olvasó, pedig nem az

A banki tranzakciók párosítása a dokumentáció szerint determinisztikus szabálylánc — pontos egyezés, majd kedvezményes egyezés, majd az összeg keresése a közleményben —, a kiegészítő szabálymodellek pedig reguláris kifejezéseken alapulnak. A duplikátumkeresés összeg, dátum és számlaszám alapján megy. Egyik sem gépi tanulás. Ez nem baj: a szabályalapú párosítás megbízhatóbb. De nem AI, és jobb tudni, hol van az egyik és hol a másik.

Mit tud pontosan — funkciónként

Az alábbi táblázat az Enterprise 19-es kiadásra vonatkozik. Community-n és 18-on ezek egyike sem érhető el.

A dokumentáció szerint egyes funkciók az alkalmazás telepítése nélkül is használhatók — az app akkor kell, ha saját API-kulcsot akarsz használni, vagy agentenként más szolgáltatót választanál.

A motorháztető alatt: nincs saját modell

A dokumentáció egyértelmű: a rendszer Geminit és OpenAI-t támogat szolgáltatóként, és mindkettőből több verziót.

Az Odoo tehát az orkesztrációt adja — a promptot, az eszközöket, a jogosultságot, a kontextust —, a modellt egy amerikai szolgáltató. Ezt érdemes pontosan érteni, mert ebből következik minden, ami a pénzről és az adatról szól.

Az architektúra, ami a cikk lényege: menedzser és munkás

A dokumentáció egy felelősségi szétválasztást ír le, és ez a legfontosabb technikai részlet az egészben.

Az AI a menedzser. Olvassa a rekordot, értelmezi a promptot, eldönti, melyik eszközt hívja és milyen argumentumokkal. És a dokumentáció szó szerint hozzáteszi: a szerveri művelet nem tartatja be az üzleti szabályokat, nem módosít közvetlenül rekordot, és nem garantálja a művelet helyességét. A szerepe a döntésre korlátozódik.

Az eszköz a munkás. Ez hagyományos, kézzel megírt szerveri művelet, amin be van kapcsolva az AI-használat. Az üzleti szabályokat kifejezetten a Python-kódban kell érvényesíteni — és ha az AI meghívja az eszközt, az feltétel nélkül lefut, hacsak maga a kód meg nem akadályozza.

És egy harmadik részlet, ami elsőre meglepő: az AI nem találja ki az argumentumokat a kódból. Amit nem deklaráltál az eszköz sémájában, azt nem adja át — akkor sem, ha a kód hivatkozik rá.

Egy mondatban: az ERP-ben az AI nem „csinál" semmit. Eldönti, melyik előre megírt gombot nyomja meg. A biztonsági korlát a gombban van, nem az AI-ban.

Ez jó hír. Ugyanez a minta érvényes minden agentre — a részleteket a tool use és a function calling bontja ki.

Mit tud az agent, és mit nem

Három építőelemből áll: témák (utasítások plusz eszközök), eszközök (a ténylegesen végrehajtható függvények) és források (PDF, weblink, dokumentum, tudásbázis-cikk, indexelve — ez gyakorlatilag egy beépített RAG).

A legfontosabb korlát szó szerint a dokumentációból: ha egy agenthez nincs téma rendelve, akkor csak információt tud adni — nem tud feladatot végrehajtani, és nem tud változtatni az adatbázison. Az alapból elérhető témák: természetes nyelvű keresés, információ-lekérés, és — csak ha az ügyfélkezelő modul telepítve van — leadkészítés.

És egy beállítás, ami könyvelési környezetben kizáró ok: agentenként választható „válaszstílus", és ennek a kreatív változatáról maga a dokumentáció írja, hogy minden alkalommal más választ ad. Az elemző beállítás az, amelyik ugyanarra a kérdésre nagy valószínűséggel ugyanazt adja — a leírás szerint akkor ajánlott, ha a pontosság fontosabb a diplomáciánál. ERP-ben ez nem stílusválasztás, hanem alapkövetelmény.

Egy harmadik út: a Community fork

Teljes nyilvánosság: ez a mi fejlesztésünk. Az eYssen az Odoo Community forkja, és a 18-as verziójában van beépített AI — olyan, ami a gyári 19-esben nincs. Az alábbiakat a saját nyilvános dokumentációjábólírom, a korlátokkal együtt, mert enélkül ez a szakasz reklám lenne.

A lényegi különbség nem a funkciólista, hanem a működési modell. Ott az asszisztens eszközhívó ciklus, nem egyszeri eszközválasztás: alapértelmezésben legfeljebb tíz egymást követő hívás, fordulónként tíz eszközhívás. Ebből következik a többi.

Autonóm ügynök saját felhasználóval. Az ügynök hozzáköthető egy felhasználói rekordhoz, és annak a jogaival fut — a doksi szavával „mint egy emberi alkalmazott" —, ehhez viszont kötelező felügyelőt megadni. A modul elutasítja, ha szuperfelhasználóhoz, portálfelhasználóhoz, rendszergazdához vagy API-kulcsot tartó felhasználóhoz kötnéd.

Ütemezett futás. Öt percenként futó ütemezett művelet indítja az esedékes ügynökfeladatokat, feladatonként állítható intervallummal. Egy „álló" feladat rekordonkénti gyerekfuttatásokra bonthatja a munkát — hívásonként legfeljebb 200 azonosítóra, tickenként legfeljebb nyolc induló tétellel.

Tartós memória. Négy memóriatípus (munka-, epizodikus, szemantikus, archív) és öt hatókör (felhasználó, vállalat, rendszer, ügynök, futás), hat óránként futó karbantartással, amely archiválja a lejárt bejegyzéseket. Ez beszélgetéseken átívelő memória, nem a session kontextusa.

Készségek. Újrafelhasználható utasításcsomagok, amelyeket az asszisztens menet közben tölt be. A gyári készlet tartalmaz egy szállítói számla playbookot, amely sosem könyvel le, piszkozatban hagyja a számlát, ellenőrző feladatot hoz létre, és külön útvonala van a NAV-ból importált duplikátumok kezelésére.

Öt szolgáltató. OpenAI, Anthropic, xAI, Google Gemini, OpenRouter és kompatibilis API-k. Saját kulcs kell hozzá, a kulcsmező csak írható.

És a biztonsági modell, ami a cikk fő tézisét igazolja. A vezérelv szó szerint: nincs sudo az üzleti adatokon — az Odoo hozzáférési listái és rekordszabályai mindig érvényesek, az AI-házirend pedig csak szűkíthet. Van egy „hard-deny padló", amit semmilyen szabállyal nem lehet kinyitni: felhasználók, jogosultságok, API-kulcsok, rendszerparaméterek, ütemezett műveletek, nézetek, szerverműveletek, fizetési tokenek, bankszámlák — és az összes AI-saját modell. Az írás alapból tiltott képesség, és háromféle írási mód van: automatikus, mindig megerősítéssel, illetve létrehozás automatikusan és módosítás megerősítéssel. A globális beállítás a feladatszintűt nem írja felül — egyetlen kapcsolóval nem lehet minden felügyelet nélküli ügynököt automatikusra állítani.

Amit a saját dokumentációja kimond, hogy nem tud. Ez a rész fontosabb, mint a funkciólista:

• a modul „kísérleti" címkével települ;
• nincs tökéletes védelem a prompt injection ellen, és az alapszabályok „csökkentik, de nem szüntetik meg a hallucinációkat";
• az üres szabálysértés-lista nem bizonyíték — a mezőszintű szerkezeti elutasítás nem hagy nyomot és nem ad figyelmeztetést;
• egy futás megszakítása nem azonnali: gyári beállításokkal nagyjából két perc, egy elakadt futás lezárása a legrosszabb esetben fél óra;
• a monitorozás auditnaplót ad — tokenfogyasztást és hívásonkénti költséget nem; költség csak napi, puha felső korlátként állítható;
• helyi, önhosztolt modell a dokumentációban nem szerepel.

Ez a két lista együtt adja ki az igazságot: nem jobb AI, hanem másik kompromisszum ugyanarra a problémára. A gyári Odoo azt választotta, hogy az alapértelmezett asszisztens nem nyúl az adathoz; a fork azt, hogy nyúlhat, de csak szűkíthető jogosultsággal, felügyelővel és naplóval. Melyik a jó, az attól függ, mennyire bízol a saját jóváhagyási folyamatodban.

A pénz: két teljesen külön modell

Ezt szinte sehol nem írják le helyesen.

(A) A dokumentumdigitalizálás kreditalapú, dokumentumonként. Egy dokumentum egy kredit:

Oldalkorlátok dokumentumonként: számla 8, költség 1, önéletrajz 8, bankkivonat 30. Túllépésnél a dokumentáció szerint az első n−1 és az utolsó oldal dolgozódik fel — egy tizenkét oldalas, sok tételsoros számlánál tehát a 8–11. oldal elveszik.

(B) Az AI-alkalmazásra az Odoo nem közöl árat. A dokumentáció annyit ír, hogy az API-kulcsok használata a szolgáltatónál további díjakkal járhat, és hogy a pontos költség a modelltől és a fióktípustól függ. Vagyis:

• felhős változatban a saját kulcs nem kötelező — ott az Odoo valamilyen formában állja vagy beszámítja (hogy pontosan hogyan, arra nem találtam nyilvános forrást);
• saját szerveren és a menedzselt tárhelyen viszont kötelező, és akkor a te szolgáltatói számlád fizeti.

Összehasonlításként egy nagy nemzetközi ERP számlakiolvasója: havi 100 tranzakció benne van, fölötte 1 000 tranzakció 300 dollár — vagyis 0,30 dollár darabonként, és a keret havi, elvész, ha nem használod fel, ezért a gyártó saját dokumentációja szerint csúcsterhelésre kell méretezni.

Kétszeres-hatszoros különbség — nem azért, mert az egyik jobb AI, hanem mert másképp csomagolják. És az általános tanulság: a nagy ERP-knél a beépített AI soha nem ingyenes és szinte soha nem korlátlan. Vagy tranzakciónként fizetsz, vagy a modellszolgáltatónál. A „benne van a licencben" a gyakorlatban azt jelenti, hogy a belépő keret benne van.

Hová megy az adat — két különböző erősségű ígéret

Ez a cikk legfontosabb része, és itt szokták összemosni a kettőt.

A számlakiolvasó OCR: a mögötte lévő szolgáltatás egy nagy keresőcég képfelismerője, bekapcsolt európai régiókorlátozással, az Odoo szerverei pedig Belgiumban és Franciaországban vannak. Adatvédelmi szempontból ez jó hír.

De: a beküldött fájlok a strukturált adataikkal együtt hat hónapig az Odoo szerverén maradnak, és a tájékoztató szerint a szolgáltatás folyamatos fejlesztésére használják őket. Utána törlik a fájlt és anonimizálják az adatot; törlés kérésre is lehetséges. Ez az a mondat, amit a legtöbb ismertető elhallgat.

Az AI-alkalmazás esetén más a helyzet. Az adat OpenAI-hoz vagy a Google-höz megy, és a tájékoztató annyit mond, hogy üzleti felhasználásra szánt feltételek mellett nem tárolják és nem tanítanak rajta. Földrajzi garancia viszont nincs a szövegben. A továbbított adat: a prompt, a beszélgetéselőzmény, a releváns rendszerkontextus, és a konfigurált forrásokból visszakeresett részletek.

Egy megnyugtató részlet ugyanitt: ahol az agent az adatbázisban tárolt információhoz fér hozzá, a hozzáférés az aktuális felhasználó jogosultságaihoz és az agent beállításához igazodik. Az agent tehát nem lát többet, mint aki használja.

Ez tehát két különböző erősségű ígéret, és nem szabad összemosni: az egyiknél kiírt EU-korlátozás van hat hónapos tárolással, a másiknál földrajzi garancia nélküli, de tárolás nélküli feldolgozás.

Saját szerveren: szabadság és felelősség egyszerre

Saját kulcsos üzemmódban nincs Odoo-kredit, nincs közvetítés, és nincs hathónapos Odoo-oldali tárolás. De az európai korlátozás sincs meg automatikusan — azt neked kell a szolgáltatónál beállítanod, adatfeldolgozói szerződéssel együtt. Erről a GDPR és az AI viszonya ad döntési sorrendet.

A korlátok — tételesen, a gyártó saját dokumentációjából

1. Az agent nem tud semmit, amihez nincs eszköze. Téma nélkül csak beszél.
2. Az AI nem tartatja be az üzleti szabályokat. Azok a kódban vannak.
3. Az AI nem talál ki argumentumot. Amit nem deklaráltál, azt nem adja át.
4. A dokumentumrendező nem vágja szét a többoldalas PDF-et — csak megjelöli, hogy kézzel kell.
5. Oldalkorlátok, lásd fent. A sok tételsoros számla pont a rossz eset.
6. A „kreatív" válaszstílus nem ismételhető.
7. Az üres AI-mezők naponta egyszer maguktól újratöltődnek egy ütemezett művelettel, ami alapból be van kapcsolva — ez rejtett tokenköltség.
8. A tulajdonságalapú AI-mező csak űrlapnézetben létezik.
9. A Studio telepítése a dokumentáció szerint befolyásolhatja az előfizetési csomagot — az AI-mezők egyik létrehozási útja ezt feltételezi.
10. Nincs publikált pontossági szám. Sem az OCR-re, sem az AI-mezőkre, sem az agentekre.

A tizedik a legfontosabb. Ha a gyártó nem ad pontosságot, a sajátodat neked kell megmérned — és pont ezért van értelme egy mérési sémának. A számlakiolvasásra levezetve ezt a dokumentumfeldolgozásról szóló recept tartalmazza, képlettel.

Amit érdemes elvinni

A beépített AI a belépés, nem a megoldás. Ami benne jó: az orkesztráció, a jogosultságkezelés és az, hogy nem kell integrációt építeni. Ami benne korlát: a modell nem a gyártóé, a szabályokat neked kell kódba írnod, a pontosságot nem méri senki helyetted — és mindenekelőtt Enterprise 19-es kiadás kell hozzá, mert Community-n és 18-on egyszerűen nincs ott.

A legfontosabb egyetlen döntés pedig nem technikai: melyik gombot engeded megnyomni az AI-nak, és mi történik, ha rosszkor nyomja meg. Az emberi jóváhagyás elhelyezéséről hova tedd a jóváhagyást című írásban van szó.

Ez a cikk 2026. szeptember 14-i állapotot tükröz. A 20-as verziót szeptember 24. és 26. között mutatják be — a cikk utána frissül.