Senki nem írta ki a nyitvatartást: AI-ügynökök és az adatpiacterek

Másodpercenként valamivel több mint egy kérés. Minden másodpercben, éjjel is, hétvégén is, ünnepnapon is. Így néz ki napi nagyjából 100 000 kérés, ha mind ugyanattól a klienstől jön. Ezt találtuk egy reggel annak az adatszolgáltatásnak a naplóiban, amelynek az üzemeltetésében egy ügyfelünknek segítünk.

Az első gondolatom az volt, hogy letiltom. Rossz gondolat volt, de ettől még megvolt.

A kliens egy AI-ügynök volt. Dokumentált végpontot használt, olyan adatot kért, amely azért létezik, hogy használják, és semmilyen szabályt nem szegett meg. Minden egyes kérése jogos volt. A viselkedése egészében viszont abszurd. Pár napomba telt, mire elfogadtam, hogy az abszurd rész a miénk.

Minden kérés helyes, a viselkedés mégis rossz

A doktorim alatt automatikus programjavítással foglalkoztam, vagyis azzal, hogyan javítson ki egy gép hibákat a kódban. A szakterületnek van egy szava arra a javításra, amely minden teszten átmegy, mégis rossz: plauzibilis. A plauzibilis javítások miatt nem lehet egy javítást pusztán a tesztek alapján megítélni. A tesztek azt rögzítik, amire a szerzőjük gondolt. Semmi mást.

Az ügynök ugyanez a probléma volt, csak kifordítva. Minden kérése átment az interfészünk összes ellenőrzésén. Csakhogy az interfészben nagyon kevés ellenőrzés volt, mert azt rögzítette, amit mi egy fogyasztótól elvártunk. Mi pedig addig mindig csak emberekre számítottunk.

Nézzük, mivel dolgozhatott az ügynök. Lekérhette az aktuális értékeket. Arra nem volt jó módja, hogy megkérdezze, mi változott a legutóbbi látogatása óta. Semmi nem mondta meg egyértelműen, mikor frissülnek az adatok, és azt sem, melyik érték végleges és melyik mozdulhat még. Úgyhogy azt tette, ami egy gondos, de óra nélküli fogyasztónak maradt. Kérdezett tovább.

Számoljunk egy gondolatkísérlettel. Tegyük fel, hogy a mögöttes adat naponta tízszer változik. Akkor a 100 000 válaszból 99 990 pontosan ugyanaz volt, mint az előző. Az ügynök valójában nem az adatainkat olvasta. A hallgatásunkat olvasta az időről, újra és újra, nagyjából egy hertzen.

Az unalom volt a kéréskorlátunk

A kellemetlen rész az, hogy mi, emberek is pontosan ezt csináljuk. Aki frissítette már a felvételi eredmények oldalát, egy járat státuszát vagy egy banki utalást, ismeri a mozdulatot. Mi is pollingolunk. Csak az ötödik frissítés után megunjuk, főzünk egy kávét, és egy óra múlva nézünk vissza.

A web jó része harminc évig csendben erre épített. Az unalom korlátozta a kérések számát. Az alvásnak köszönhettük az éjszakai karbantartási ablakokat. A gyorsítótárazás azért működött, mert az emberek többnyire ugyanazt a néhány népszerű oldalt nézik. Amit egyetlen API sem válaszolt meg, azt elintézte, hogy valaki egyszer elolvasta a dokumentációt, vagy felhívta azt, akié az adat. Ezt senki nem tervezte így. Ingyen járt az emberi fogyasztókkal, és mi úgy építettünk rá, hogy soha nem írtuk le.

Az ügynökök mindezt egyszerre veszik el. Nem unatkoznak, nem alszanak, és mindenre egyformán kíváncsiak. A Wikimedia Foundation ezt drágán tanulta meg. 2025 áprilisáig a multimédia-letöltések sávszélessége 50%-kal nőtt 2024 eleje óta, és a legdrágább forgalmuk legalább 65%-át botok adták, miközben az oldalmegtekintéseknek csak nagyjából 35%-át. A botok nem ragadnak le a népszerű oldalaknál, így elkerülik a gyorsítótárat, és a központi adatközpontot terhelik. A Cloudflare 2025-ös összesítője szerint az AI-asszisztensek által, egy felhasználó nevében végzett crawling egyetlen év alatt több mint tizenötszörösére nőtt. A mi ügynökünk pontosan ebbe a kategóriába tartozott.

Amikor aztán elolvastam a BARC 2026 júniusi Spotlight-jelentését (A Data Marketplace Is What Your Agents Need), egy régi szám maradt meg bennem. Egy 2024-es BARC-felmérésben a válaszadók 73%-a mondta, hogy a releváns adatot nehéz megtalálni. Ez emberi probléma volt már jóval az ügynökök előtt. Az elemzők elvesztegetett délutánokkal és telefonhívásokkal fizettek érte, és soha senki nem küldött róla számlát. Nem az ügynökök csinálták a rendetlenséget. Ők az első fogyasztók, akiknek a zavarodottsága megjelenik a számlán.

Egy megjegyzés, mert számít: a jelentést az Entropy Data szponzorálta, egy cég, amely adatpiactereket árul. Ettől még nem téves. Csak kétszer olvastam el, és lent néhány ponton vitatkozom is vele.

Nyitott ajtós raktár

Minden vajdasági városban van piac. Újra és újra ehhez térek vissza, mert ez a legjobb kép arra, ami hiányzott.

A mi szolgáltatásunk, mint a legtöbb adatszolgáltatás, úgy működik, mint egy raktár, amelynek nyitva hagyták az ajtaját. Bárki bemehet, elviheti, amit akar, és távozhat. Reggel a gazda lábnyomokat lát, és találgathatja, ki járt ott, mit vitt el és miért.

A piac másképp működik, és nem az áru miatt. Minden stand mögött áll valaki, akit holnap is megtalálsz. Az árun ott az ár és a származás. Van mérleg, és a mérleget valaki az önkormányzattól ellenőrzi. Vannak szabályok, amelyek minden standra vonatkoznak, a higiéniától addig, hogy hol hagyhatod a talicskát. És van nyitvatartás, kiírva a kapura.

Hajnali háromkor senki nem zörget a kapun, hogy megjött-e már a paradicsom. Nem azért, mert a piaci vásárlók különösen udvariasak. Hanem mert ki van írva, mikor nyitnak.

Fordítsuk le a piacot adatra, és szinte pontról pontra megkapjuk, amit a data mesh közösség adatterméknek, a gyártók pedig adatpiactérnek hívnak: minden adatkészletnek megnevezett gazdája van, leírás arról, mit jelent és mennyire jó, ígéret a frissességről, mindenkire érvényes szabályok, és valami, ami minden tranzakciót ezekhez mér.

Ez megváltoztatta, hogyan nézek a történetbeli szolgáltatásra. Már nem forgalmi problémával küzdő API-nak látom. Inkább olyan piacnak, amely sosem rakta ki a standjait. Az áru megvan, az árusok megvannak, a vevők pedig láthatóan megérkeztek. Ami hiányzik, az a tábla a kapun, a címkék és a felügyelő. Ez jóval kisebb lépés, mint amilyennek az „építsünk adatpiacteret” hangzik, és gyanítom, hogy sok nyilvános adatszolgáltatás áll ugyanitt anélkül, hogy tudna róla.

Húsz év dokumentáció senkinek

Az adatos világ a címkét adatszerződésnek (data contract) hívja. A gyakorlatban ez egy YAML-fájl, manapság többnyire az Open Data Contract Standard (ODCS) szerint, amelyet a Linux Foundation alatt működő Bitol projekt gondoz. Leírja, mi az adatkészlet, kié, mennyire friss, milyen minőségi ellenőrzéseken kell átmennie, és mire szabad használni. Egy egyszerűsített részlet elég lett volna a hetünk nagy részének megmentéséhez:

# egyszerűsített, ODCS-stílusú részlet
id: daily-aggregates
status: active
description:
  purpose: Végleges aggregált értékek, munkanaponként egyszer frissülnek.
  limitations: A 10:00 CET előtti értékek ideiglenesek.
slaProperties:
  - property: frequency
    value: 1
    unit: d
  - property: timeOfAvailability
    value: "10:00 CET"

Egy ügynöknek, amely azt olvassa, hogy „naponta egyszer, tízkor, a korábbi értékek ideiglenesek”, semmi oka százezerszer kérdezni. Egyszer kérdez, tíz után. Egy mondatnyi metaadat a legolcsóbb kéréskorlát, amit ismerek.

És itt jön az a rész, amiről keveset hallok. Húsz évig a legtöbben olyan dokumentációt írtunk, amelyet senki nem olvasott el. Az emberek átfutották, tippeltek, aztán írtak annak az egy kollégának, aki tudta a választ. Ő volt az igazi dokumentáció. Most viszont a dokumentációnknak van egy olvasója, aki minden szavát elolvassa, szó szerint veszi, és senkinek nem tud e-mailt írni.

Ez ajándék, de fenyegetés is. A hiányzó frissességi mező miatt pollingolt az ügynökünk. Drága volt, de minden válasz, amit felhasznált, friss volt. A hibás frissességi mező rosszabb. Ha a szerződésben tíz óra áll, az adat viszont fél tizenkettőkor érkezik, akkor egy jól nevelt ügynök tízkor egyszer rákérdez, megkapja a tegnapi számokat, és teljes magabiztossággal dolgozik velük másnapig. A hiányzó metaadat pénzbe kerül. A hibás csendben az igazságba kerül a fogyasztóinak.

A szerződést tehát kódként kell tesztelni, a pipeline-ban, minden alkalommal, amikor az adat mozdul. Nyílt eszközök, például a Data Contract CLI, pontosan ezt csinálják. Egy teszteletlen szerződés sémával ellátott hazugság.

A cél állítás, nem tény

A témáról szóló írások többsége, a BARC-jelentés is, jogos dolgot mond a hozzáférésről. Nem lehet belépőkártya, amit egyszer megkapsz és örökre megtartasz. A jóváhagyások felhalmozódnak, az adat olyan felhasználásokba csúszik át, amelyeket senki nem hagyott jóvá, és ügynököknél ez az elcsúszás gyors és láthatatlan. A szokásos válasz a célhoz kötött hozzáférés: minden kérés megmondja, mire kell neki az adat, és ezt a célt a szerződéshez mérik. Az Entropy Data MCP-szervere például cél megadása nélkül le sem futtat egy lekérdezést.

Az iránnyal egyetértek. Magában a bejelentésben nem hiszek.

Ezt a filmet már láttuk. A sütibannereknek a tájékozott beleegyezést kellett volna rögzíteniük, és egy kattintás lett belőlük, amit mindenki olvasás nélkül megnyom. A bejelentett céllal ugyanez lesz. Egy éven belül az ügynökök megtanulják, melyik szó melyik ajtót nyitja, és minden kérésben az fog állni: „kutatás”. Az a célmező, amely csak a helyesírást ellenőrzi, színház.

Amit egy ügynök mond, az állítás. Amit csinál, az bizonyíték. Az az ügynök, amely „havi riportot” jelent be, és másodpercenként kérdez, nem havi riportot készít. Valamit figyel, és nagyon is lehet, hogy egy üzleti terméket táplál vele. Az az ellenőrzés ér valamit, amely a bejelentett célt összeveti a megfigyelt mintázattal, és a kettő közötti különbségre reagál.

Mi idáig sem jutottunk el. Tudtuk, honnan jönnek a kérések és milyen gyakran. Azt nem tudtuk, ki áll mögöttük, mit épít, és hogy nem váltana-e szívesen valami olcsóbbra, ha bárki szólni tudott volna neki. Csak a tompa eszköz maradt, a kéréskorlátozás. Működik, de egy talán értékes fogyasztót támadóként kezel, és a következő ügynököt semmire nem tanítja meg.

A bizalom nem elég. A piachoz ár kell

A BARC-nak van egy mondata, amit szeretek: a bizalom az a piaci mechanizmus, amely sok kudarcba fulladt piactér-bevezetésből hiányzik. Igaz, de csak a fele. Az elmúlt évtized belső adatpiacterei közül sok tisztességes metaadattal is elhalt. Semmi nem került semmibe a fogyasztónak, és semmi nem hozott semmit a gazdának. Az ár nélküli piac csak egy katalógus szebb kirakattal.

Az ügynökök visszahozzák az árakat, akár tervezte ezt valaki, akár nem. A napi 100 000 kérés mindegyike került valamibe: számítási kapacitásba, sávszélességbe, naplókba, az ügyeletes figyelmébe. Mindezt az adatot kiszolgáló oldal nyelte le. A nyílt weben az egyensúlytalanság látványos: a Cloudflare mérése szerint 2025-ben az Anthropic crawlerei minden visszaküldött látogatásra 25 000 és 100 000 közötti kérést indítottak. 2025 júliusában a Cloudflare elindította a pay per crawl szolgáltatást, amely a HTTP 402-es, Payment Required státuszkódra épül. Ez a kód 1997 óta „későbbi használatra fenntartott” volt. Majdnem harminc év és néhány milliárd crawler-kérés kellett ahhoz, hogy valakinek szüksége legyen rá. Európában 2025 szeptembere óta alkalmazandó az uniós adatrendelet (Data Act), amely a vállalatok közötti adatmegosztást szerződéses feltételekhez köti, és ahol a megosztás kötelező, észszerű ellentételezést is lehetővé tesz.

Ez felvet egy kérdést, amire nincs tiszta válaszom. Sok nyilvános adatnak ingyenesnek kell maradnia, és ezt hangosan képviselném is. De minden kérésért fizet valaki. Ha egy közpénzből működő szolgáltatás egy olyan ügynököt szolgál ki, amely üzleti terméket épít, akkor az adófizető támogatja valakinek az ügynökét, másodpercenként egy kéréssel. Lehet, hogy ez rendben van. Lehet, hogy pont erre való a nyílt adat. De ez legyen döntés, ne olyasmi, amit senki nem vett észre.

Ostrom piacteret épített volna

Ilyenkor általában Garrett Hardin közlegelőjét szokás felhozni, a közös javak tragédiáját. Közös legelő, minden gazda észszerűen kihajt még egy tehenet, a legelő tönkremegy. Egy ügynök, amely másodpercenként kérdez, még belefér. Ezer ilyen ügynök már leállás, és közben mindegyik észszerűen viselkedik.

Elinor Ostrom nagyrészt azért kapta meg 2009-ben a közgazdasági Nobel-díjat, mert megmutatta, hogy Hardin befejezése nem elkerülhetetlen. Valódi közös javakat vizsgált a svájci alpesi legelőktől a spanyol és fülöp-szigeteki öntözőrendszerekig, olyan közösségeket talált, amelyek évszázadokig életben tartották a közös erőforrásaikat, és összegyűjtötte, mi bennük a közös. Ha ma olvassuk a tervezési elveit, úgy hangzanak, mint egy követelményspecifikáció. Egyértelmű határok: a fogyasztóknak neve van. A helyi viszonyokhoz illő szabályok: adattermékenként egy szerződés, nem egyetlen szabály mindenre. Megfigyelés, amire valaki tényleg rá is néz. Fokozatos szankciók azonnali tiltás helyett. Olcsó konfliktuskezelés, ami a gyakorlatban egy gazdát jelent, aki válaszol. És egymásba ágyazott szintek: szervezeti szabályok, bennük a domainek szerződései.

Ezt meggyőzőbbnek tartom bármelyik gyártói architektúraábránál, főleg azért, mert nem a szoftverről szól. A piactér nem a platform. Az a szabályrendszer, amely mellett egy közös erőforrás túléli a nagy terhelést, a platform pedig csak segít betartatni.

A csatlakozó nem szabályzat

Pár szó a Model Context Protocolról, mert ügynökökről és adatról ma minden beszélgetés ide fut ki. Az MCP-vel nevetségesen könnyű egy ügynöknek olyan eszközt adni, amely közvetlenül egy adatbázissal beszél. Ha így csináljuk, az megint a nyitott raktárajtó, csak szebb felirattal. Ha jól csináljuk, az MCP a piac kapuja. Simon Harrer az Entropy Datától úgy írja le a piacteret, mint egy réteget, amelyen minden ügynökhívás áthalad, a lekérdezés is, így a szerződést és a szabályokat menet közben ellenőrzik. A protokoll mindkét esetben ugyanaz. A különbség az, hogy az irányítás mögötte él, vagy egy promptban.

És pár szó a saját szakmám ellen. Legyünk óvatosak mindenkivel, aki szerint az első lépés egy platform, beleértve a gyártókat, és beleértve minket is. Abból, amire a mi incidensünknek szüksége volt, a legtöbb elfér egy YAML-fájlban, három HTTP-fejlécben és egy beszélgetésben arról, mi kié.

Mit tegyünk hétfőtől?

• Számoljuk meg a gépeket. Derítsük ki, a forgalom mekkora része automatizált, és melyik tíz kliens adja a nagyját. Minket meglepett. A legtöbb csapatot meglepi.
• Írjuk ki a nyitvatartást. Mondjuk meg, mikor frissül az adat és mikor válik véglegessé. Adjunk változásfolyamot vagy napi pillanatképet, és támogassuk az ETag és If-Modified-Since fejléceket, hogy a „nem változott semmi” egy 304-be és szinte semmi másba ne kerüljön.
• Írjunk egy szerződést, és teszteljük. Vegyük a legtöbbet kért adatkészletet, írjuk le ODCS-ben, és futtassuk az ellenőrzéseit a pipeline-ban. A teszteletlen szerződés rosszabb, mint a semmi.
• Adjunk nevet a nagy fogyasztóknak. Egy ingyenes kulcs elég. Kérdezzünk rá a célra, aztán vessük össze azzal, amit a kulcs valójában csinál.
• A tiltás helyett létra. Ha valaki túl gyakran kérdez, válaszoljunk 429-cel, Retry-After-rel és egy linkkel a bulk fájlra. Előbb sávok, aztán tiltás.
• Döntsük el, ki fizet. Mielőtt a felhőszámla dönti el helyettünk.

Az ügynök egyetlen szabályt sem szegett meg. Csak sosem unta meg, és így megtalált minden helyet, ahol tervezés helyett az unalomra hagyatkoztunk. A piacon hajnali háromkor senki nem zörget a kapun. Ki van rá festve a nyitvatartás.

Források

• Florian Bigelmaier, BARC: BARC Spotlight: A Data Marketplace Is What Your Agents Need, 2026. június, szponzor: Entropy Data
• Jochen Christ: From Data Catalog to Data Marketplace
• Simon Harrer: A Data Marketplace is What Your Agent Needs, DATA Festival 2026
• Entropy Data: MCP: Connect AI Clients with Business Data
• Bitol: Open Data Contract Standard; Data Contract CLI
• Wikimedia Foundation: How crawlers impact the operations of the Wikimedia projects, 2025. április
• Cloudflare: Radar 2025 Year in Review; Introducing pay per crawl
• Európai Bizottság: Data Act
• Elinor Ostrom: Governing the Commons, Cambridge University Press, 1990

A MALI Labs szoftver- és AI-mérnöki cég a vajdasági Adán. Abban segítünk a csapatoknak, hogy az adataik használhatók legyenek AI-ügynökök számára, anélkül hogy elveszítenék felettük az irányítást: adatszerződések, irányított MCP-interfészek, ügynökökre felkészített API-k. Ha a szolgáltatásuk mostanában több gépet lát, mint embert, beszéljünk. Az első proof of concept, egy hét a saját adataikon, ingyenes.