Amikor az ügynök építi a modellt: az agentikus analitika irányítása Power BI-ban és Fabricben

A Microsoft Build 2026-os analitikai bejelentéseiben a demók alatt megbújik egy részlet, amely eldönti, hogy az ügynökök által épített BI egyáltalán kézben tartható lesz-e: az Agent Skills for Power BI a Power BI Projects (PBIP) formátumon keresztül dolgozik, vagyis azon a fájlalapú formátumon, amely gond nélkül elfér verziókezelésben. Az ügynök nem a vásznon kattintgat, hanem olyan fájlokat ír, amelyeket egy ember diffként átnézhet és visszadobhat, mielőtt bármi élesbe kerülne.

Ez a részlet több figyelmet érdemel, mint maguk a címlapos képességek, már csak azért is, mert azok szélesek, és gyorsan érkeznek.

Mit jelentett be a Microsoft

Két preview-ról van szó. Az Agent Skills for Power BI-nak elég természetes nyelven leírni, mire van szükség (akár egy screenshotot is odaadhatunk neki), és az ügynök felépíti a szemantikus modellt a Fabric-adatokból, legenerálja a riportoldalakat, és iterál a vizuálokon. A 2025 novemberében kiadott Power BI Modeling MCP-re épül, amely a szemantikus réteget már lefedte; az új képesség ezt terjeszti ki teljes, riportokat is magában foglaló munkafolyamattá. Meglévő megoldásokon is működik, nem csak zöldmezősökön, a kimenetet a Microsoft szerint dizájn-best practice-ekhez igazítja, a rollout pedig a bejelentést követő héten indul.

A második preview, a Fabric Apps on Semantic Models, ennél is tovább megy: AI-ügynökök Fabric-natív webalkalmazásokat építenek és deployolnak szemantikus modellekre, a nyílt forráskódú Rayfin SDK-ra támaszkodva. A keretezés az, hogy a vállalati analitika és az operatív alkalmazások eddig külön világban éltek, és egy közös szemantikus modell mostantól mindkettőt kiszolgálhatja, alatta a Fabric adja az adatalapot, a biztonságot és a governance-t. A Microsoft által felsorolt példa-szcenáriók pénzügyes szemmel sokatmondóak: készletkezelés, pénzügyi tervezés, munkaerő-koordináció.

A modell mostantól kód, és ez dönti el, ki mondhat nemet

Amikor egy elemző Power BI Desktopban épít riportot és publikálja, a governance jellemzően utólag történik: valaki észreveszi, hogy egy szám nem stimmel, vagy egy hozzáférési felülvizsgálat talál egy gazdátlan workspace-t. A PBIP-alapú ügynök-munkafolyamat ezt megfordítja. Az ügynök minden módosítása fájl-diff, tehát kérhető hozzá pull request, futtathatók rá automatikus ellenőrzések, és ami elbukik rajtuk, az nem kerül ki.

A Syngentánál, ahol egy Fabric lakehouse-on dolgozom BI-assetekre épített CI/CD-vel, gyakorlatilag a pipeline maga a governance-réteg: a sorszintű biztonság (RLS) és az adatminőségi szabályok ezen futnak át, és a deploy is. Egy PBIP-fájlokat előállító ügynök ugyanúgy csatlakozik ehhez a pipeline-hoz, mint bármelyik másik közreműködő, ugyanazokkal a kapukkal. Egy csak UI-n keresztül dolgozó ügynököt így nem lehetne kontrollálni.

A formátum dönti el az irányíthatóságot, és a bejelentésből én ezt súlyoznám a legerősebben.

A review hangsúlya a szintaxisról a szemantikára tolódik

Az ügynök kimenete szinte definíció szerint szintaktikailag rendben lesz: a DAX leparszol, a vizuálok renderelődnek. A pénzügyi kockázati profil más: hihető, de rossz. Képzeljünk el egy kontrollert, aki azt kéri az ügynöktől, hogy „nettó elszámolási költség költséghelyenként". Ehhez az ügynöknek ténytáblát kell választania, el kell döntenie, mi legyen az elhatárolásokkal és a sztornókkal, ki kell jelölnie a devizaátváltás pontját, és értelmeznie kell, mit jelent itt a „nettó". Ezeknek a döntéseknek bármelyik kombinációja kész kinézetű chartot ad. Általában csak egyetlen kombináció egyezik a főkönyvvel. Az elszámolási költségallokációval és varianciaelemzéssel töltött évek után az első review-kérdésem egy ügynök építette modellnél az lenne, hogy egyezik-e, nem az, hogy lefut-e.

A biztató rész, hogy ez az ellenőrzés jól automatizálható: néhány kulcs-measure egyeztetése egy hitelesített forrással (főkönyv, auditált adathalmaz) merge-kapuként a legrosszabb eseteket úgy fogja meg, hogy közben senkit nem lassít.

A Fabric Apps kiszélesíti a felületet

A bejelentés szerint az alkalmazásépítés költsége és komplexitása drámaian zuhan, és nagyjából bármi legenerálható, ami leírható, teljes kontrollal a UI, az üzleti logika és a külső rendszerekkel API-n keresztüli integrációk felett. Ha ezt komolyan vesszük, a következmény kézenfekvő: a tenantban élő alkalmazások száma sokkal gyorsabban fog nőni, mint a követésükre fordítható kapacitás.

A szemantikus modellből örökölt governance valódi, és ez a legerősebb érv amellett, hogy ezek az appok a Fabricben épüljenek, ne mellette. Csakhogy ez az adatréteget fedi le. Az app-réteg generált kód: üzleti logika, amely átértelmezheti a governed számokat, és kifelé irányuló API-hívások, amelyek máshová visznek adatot. A shadow IT eddig egy makrós Excelt jelentett; ebben a modellben webalkalmazást szállít hitelesített adatokra, ami egyszerre jobb (az adat governed) és rosszabb (nagyobb a hatókör). És tizenkét hónap múlva is kell majd valaki, aki az appot gondozza, amikor az, aki annak idején bepromptolta, már rég más szerepben dolgozik.

Kontrollok, amelyeket érdemes a preview előtt felállítani

Mindez nem a preview-k ellen szól, hanem a sorrend mellett. Az alábbi kontrollok standard analytics engineering-eszközök, csak kevesebb mozgástérrel alkalmazva, mint amennyit egy emberi tempójú csapat megengedhetett magának.

Az a csapat, amelynél ezek megvannak, nyugodtan engedheti gyorsan dolgozni az ügynököt, mert a bizalmatlankodást a pipeline végzi el helyette. Amelyiknél nincsenek, az renderelt riportok nézegetésével fogja jóváhagyni az ügynök munkáját, vagyis pontosan azzal a review-módszerrel, amely már az emberek által épített riportoknál is rendre elbukik.

Mit jelent ez egy pénzügyi BI-csapatnak

A produktivitási ígéret hihető. A gyorsabb út a Fabric-adatoktól a production-ready riportig, plusz az, hogy az ügynök meglévő riportokat is fel tud javítani, pont arra a munkára céloz, amibe a pénzügyi BI-fejlesztők rengeteg időt ölnek: layout, sablonos modellezés, vizuál-iteráció. A felszabaduló órákat a definíciókba és a kontrollokba érdemes visszaforgatni, mert mostantól ezek jelentik a minőség szűk keresztmetszetét.

A teljes bejelentés, a Building in the Agentic Era with Power BI and Fabric, a Power BI updates blogon olvasható; onnan linkelve elérhető az on-demand Build-session és a Fabric Apps dokumentáció is. Érdemes elolvasni, mielőtt a preview megjelenik a tenantban: az ügynökök így is, úgy is jönnek, és a csapatok között az lesz a különbség, hogy a pipeline-ban, amelybe megérkeznek, vannak-e kapuk.