Ügynök által épített Power BI riportok: mit delegáljunk és mit védjünk

Egy riportoldal négy KPI-kártyával, néhány slicerrel és egy részletező táblával jó egyórányi kattintgatás a Power BI Desktopban, és ebből az órából szinte semmi nem igényel szakmai ítéletet. A Microsoft legújabb preview-ja pontosan ezt az órát adja át egy ügynöknek. A Power BI authoring plugin a Skills for Fabricben jelent meg (ez a Microsoft Fabric first-party agent skill katalógusa, a GitHub Copilot CLI-hez optimalizálva), és azt teszi lehetővé, hogy az AI-ügynök természetes nyelvű briefből írjon riportdefiníciót: séma-helyes PBIR fájlokat generál, újratölti a Power BI Desktopot, képernyőképet készít az elkészült oldalakról, és addig iterál, amíg az eredmény meg nem felel a kérésnek.

Egy pénzügyi BI-csapat számára nem az az érdekes kérdés, hogy működnek-e a demók. Hanem az, hogy hol húzódik a határ az átadható és a megtartandó munka között. A preview elég széles ahhoz, hogy a határ mindkét oldalát lefedje, és ezért érdemes alaposan végigolvasni, mielőtt éles workspace közelébe kerülne.

Mit tud valójában a preview

A bejelentés három képességcsoportot mutat be. Az ügynök tud riportot építeni nulláról: a példaprompt egyetlen bekezdésben ír le két oldalt (KPI-kártyák megnevezett metrikákra, slicerek, részletező tábla, egységes branding mindkét oldalon), és az ügynök felépíti őket. Tud meglévő riportot átalakítani referenciakép és logó alapján, hozzáigazítva az oldalak stílusát. És tud elavult riportot modernizálni: ilyenkor egy kísérő skill, a powerbi-report-design először strukturált design-összefoglalót készít (best practice elvek az adott riporthoz), és ezt kapja meg az implementáció. Ugyanez a plugin-család kapcsolódik a Modeling MCP serverhez és a szemantikus modellt építő skillhez is, így az ügynök elvben a teljes láncot végig tudja vinni a modelltől a riportig.

Két mechanizmus többet nyom a latban, mint a demók. Az ügynök PBIR-t ír, vagyis a PBIP projektek fájl-alapú riportdefiníciós formátumát, nem a vásznon kattintgat. A Desktop bridge pedig újra tudja tölteni a már megnyitott Power BI Desktop-példányt, és képernyőképet készít a friss oldalakról, tehát az ügynök látja a saját outputját és korrigál, ahelyett hogy találgatna, jól jelent-e meg egy vizuál.

A riportnak rétegei vannak, és az ügynök csak az egyiket ellenőrzi

A screenshot-ciklus valódi előrelépés a prezentációs rétegben, mert az ügynök végre azt látja, amit a felhasználó látna. Csakhogy amit ellenőriz, az a megjelenítés, nem az igazság. Képzeljünk el egy hipotetikus variancia-hidat, amelyben az egyik measure előjele fordítva áll: gyönyörűen renderelődik, minden vizuális ellenőrzésen átmegy, és mindenkit félrevezet, aki ránéz. Hogy a havi zárás számai egyeznek-e a főkönyvvel, az a szemantikus modellben és a mögötte lévő adatban dől el, és ezt semmilyen képernyőkép nem tudja megmondani.

Egy riport tökéletesnek tűnhet úgy is, hogy téved.

Mit érdemes delegálni

A layout-építés a kézenfekvő jelölt. Oldalak felhúzása írott spec alapján, vizuálok igazítása, brand-téma alkalmazása referenciaképből, navigáció hozzáadása: pontosan ezt mutatják a demók, az egész látható a vásznon, és egy hiba legfeljebb kínos, nem veszélyes.

A modernizálás a második jelölt, és valószínűleg az értékesebb. Egy tipikus pénzügyi csapat évekkel ezelőtt épült riportok tucatjait tartja életben: válaszolnak a kérdésekre, de látszik rajtuk a koruk, és redesign-sprintre soha nem lesz büdzsé. Egy ügynök, amelyik előbb átnézhető design-összefoglalót ad, majd implementálja azt, átírja ennek a backlognak a költség-haszon mérlegét.

A Morgan Stanley-nél épített globális költségdashboardom 50+ felhasználót szolgált ki, mögötte havi 600+ számla (PDF és Excel) automatizált feldolgozásával és varianciaelemzésével. Az érték a variancialogikában és az adatfeldolgozásban volt; az oldalak layoutja egyszerűen az ára volt annak, hogy ez az érték célba érjen. Visszanézve ez az a fajta munka, amit egy ilyen eszköznek adtam volna oda.

Mit kell védeni

Első a szemantikus modell. Ugyanez az ökoszisztéma a Modeling MCP serveren keresztül modellt is tud építeni, és egy pénzügyi csapatnak itt kell lelassítania, mert a modellben születnek a számok. A generált measure ugyanazt a bánásmódot érdemli, mint a generált kód: ember olvassa végig minden sorát a merge előtt, vagy nem merge-öl. Az alapvető pénzügyi logikánál (allokációk, FX, variancia-definíciók) védhető döntés, hogy a szerzőség emberi marad, és csak a dokumentálást delegáljuk.

A row-level security más okból kerül a védett listára: ha hibázik, némán teszi. Egy elromlott RLS-ű riport ugyanúgy néz ki és ugyanúgy működik, miközben olyan sorokat mutat valakinek, amiket sosem lett volna szabad látnia. Hozzáférési szabályt ne írjon olyan eszköz, amelynek az egyetlen visszajelzése egy képernyőkép.

A publikálás a harmadik kapu. A preview hatóköre a tervezéstől a Fabricbe publikálásig terjed, és éppen ezért az utolsó lépésnek emberi jóváhagyás mögött a helye, ahogy egy deployment pipeline is sign-offra várakoztatja a production release-t.

Egy működőképes felosztás

Ebben semmi egzotikus nincs. Ugyanaz a review-fegyelem, amit a pénzügy máshol is alkalmaz, csak egy új eszközre irányítva.

A fájl teszi governance-képessé az egészet

A védett felosztást az a részlet teszi működtethetővé, hogy az ügynök outputja fájl. A PBIP projektben élő PBIR definíció szöveg, tehát működik rajta a branch, a diff és a pull request. A Syngentánál végzett munkám része a BI-assetek CI/CD-je, és ez az a keret, amibe ez a preview beleillik: az ügynök által írt riportdefiníció branchben ülhet és review-n mehet át, mielőtt bármelyik workspace meglátná, ugyanúgy, mint az ember által írt.

A kezdéshez két parancs kell egy támogatott AI-kliensben:

# a first-party skill-katalógus regisztrálása, pl. GitHub Copilot CLI-ben
/plugin marketplace add microsoft/skills-for-fabric
# a Power BI authoring plugin telepítése
/plugin install powerbi-authoring@fabric-collection

A teljes bemutató a példapromptokkal és az előtte-utána demókkal az AI-Powered Power BI reporting: From design to deployment with agent skills bejegyzésben olvasható a Power BI updates blogon. Preview-ról van szó, és a Microsoft saját közlése szerint gyors ütemben javítanak rajta, úgyhogy a fenti részletek még mozogni fognak.

Az első értelmes pilot

Képzeljünk el egy controllert, aki egy tucat öregedő vezetői riportot gondoz egy stabil, már átnézett szemantikus modell felett. Adjuk oda az ügynöknek az egyiket, másolaton, modernizálási brieffel. Hadd rendezze át a layoutot és a navigációt, aztán diffeljük a PBIR outputot az eredetihez képest, és nézzük át a változásokat úgy, ahogy egy kolléga pull requestjét néznénk át. A modell és az RLS érintetlen marad, a publikálás pedig kézi. A legrosszabb kimenet egy elutasított branch és egy elveszett óra; a legjobb egy felfrissült riportállomány és egy kalibrált érzék arról, hol ér véget az eszköz ítélőképessége, és hol kezdődik a miénk.