Amikor a kormányzás futásidő-problémává válik
A szabályzat, amely lemaradt a kérésről
A kormányzási megbeszélés alapos volt. A kockázatokat felsorolták. A felhasználási esetet besorolták. Az adatforrásokat jóváhagyták. A jogalapot rögzítették. A nagy hatású eseteknél emberi felügyeletet írtak elő. A jegyzőkönyv elég tiszta volt ahhoz, hogy egy megfelelőségi tisztviselő rövid időre elhiggye, hogy létezik civilizáció. Aztán a rendszer élesben elindult, és az első kínos kérés kedden 09:14-kor megérkezett.
A kérés nem törődött azzal, hogy a bizottság havonta ülésezik. Magában hordozott egy felhasználói szerepkört, egy ügyfélaktát, egy szabályzatverziót, egy modellútvonalat, egy eszközengedélyt, egy adattárolási helyre vonatkozó kérdést, egy költségkeretet és egy lehetséges külső hatást. A munkafolyamatnak másodpercek alatt kellett eldöntenie, hogy lekérjen, létrehozzon, továbbítson, megtagadjon, naplózzon, értesítsen vagy cselekedjen. A kormányzás már nem a rendszer mögötti dokumentum volt. Futásidejű problémává vált a rendszeren belül.
Itt érzik meg sok AI-programnál, hogy kicsúszik a talaj a lábuk alól. A kormányzási kialakítás nem feltétlenül volt hibás. A vezetőség nem volt ostoba. A szabályzat nyelvezete akár jó is lehetett. A probléma az, hogy az AI-rendszerek mozgás közben működnek. Friss környezetet húznak be, eszközöket hívnak, szolgáltatási határokat lépnek át, adatokat használnak fel újra, új artefaktumokat hoznak létre, és arra hívják az embereket, hogy támaszkodjanak az eredményekre. Az a szabályzat, amely nem tud belépni ebbe a mozgásba, referenciaművé válik. Hasznos lehet. De nem elégséges.
A futásidejű kormányzás azt jelenti, hogy a rendszer a munka közben képes kiértékelni a kormányzási feltételeket. Ki kérdez. Milyen célból. Mely adatok használhatók. Melyik modell engedélyezett. Melyik eszköz cselekedhet. Melyik joghatóság érvényes. Melyik költségkeret elfogadható. Mely esetek igényelnek emberi felülvizsgálatot. Melyik nyilvántartást kell vezetni. Melyik út áll rendelkezésre a kifogáshoz. Ezek nemcsak beszerzési kérdések vagy éves felülvizsgálati kérdések. Ezek a kérési útvonal kérdései.
A dokumentumok továbbra is számítanak
Divatos kísértés kigúnyolni a kormányzási dokumentumokat. Szabályzatok, nyilvántartások, hatásvizsgálatok, kockázati keretek, beszállítói értékelések, modellkártyák, DPIÁ-k, beszerzési feljegyzések, adatmegőrzési ütemtervek. Ezek valóban válhatnak díszes elemekké. Egyes dokumentumokat azoknak a kísérteties eleganciájával írnak, akik tudják, hogy senki sem olvassa el az ötödik oldalnál tovább. De a válasz nem az, hogy megvessük a dokumentumokat. A válasz az, hogy hagyjuk abba a színlelést, hogy ezek a kormányzás végső formáját jelentik.
A dokumentumok leírják a szándékot, a felelősséget, a hatókört, a kockázatot és az értelmezést. Intézményi emlékezetet teremtenek. Lehetővé teszik, hogy az emberek az üzembe helyezés előtt vitatkozzanak, ne a kár bekövetkezte után. Közös felületet adnak az auditálóknak, a vásárlóknak, a mérnököknek, a jogászoknak és a vezetőknek. Ez értékes. A futásidőben történő irányítás ettől függ. Egy rendszer nem tud kiértékelni egy olyan szabályzatot, amelyet senki nem írt meg. Nem tud érvényt szerezni egy olyan célnak, amelyet senki nem határozott meg. Nem tud megőrizni bizonyítékokat egy olyan ütemezés szerint, amely nem létezik.
A probléma akkor kezdődik, amikor egy dokumentumot úgy kezelnek, mintha futna. Egy szabályzat azt mondja, hogy a nagy kockázatú kimenetek felülvizsgálatot igényelnek, de a munkafolyamatban nincs állapot a kötelező felülvizsgálathoz. Egy kockázatértékelés azt mondja, hogy egy modell nem használhat érzékeny forrást, de a lekérdezésben nincs forrás-hatókör-védelem. Egy beszerzési feljegyzés azt mondja, hogy a szállítónak támogatnia kell az auditálást, de az integráció csak összesített naplókat tárol. Egy megőrzési ütemezés azt mondja, hogy a nyilvántartások lejárnak, de a generált artefaktumok leszármazási adatok nélkül vándorolnak a downstream rendszerekbe. A dokumentum megtette a magáét. A futásidő nem kapta meg az értesítést, ami nem metafora, ha az értesítést szó szerint e-mailben küldték el.
A jó irányításnak ezért van egy fordítási lépése. Az írott szabályzat futásidőbeli feltételekké válik: kapukká, szerepekké, küszöbértékekké, sémákká, naplókká, riasztásokká, fellebbezési útvonalakká, megőrzési szabályokká és kiadási ellenőrzésekké. Nem minden mondat válik kóddá. Néhány ítélet emberi marad. De a rendszernek tudnia kell, mely részek működési jellegűek. Ellenkező esetben az irányítás egy ceremoniális tetővé válik egy falak nélküli épület fölött.
A kérés útvonalán derül ki, hogy a vállalások megállják-e a helyüket
A mesterséges intelligencia irányításáról gyakran a rendszerek szintjén beszélnek. Jóvá van hagyva ez a rendszer. Megbízható ez a modell. Elfogadható ez a felhasználási eset. Ezek a kérdések számítanak, de az élő kockázat a kérések szintjén jelenik meg. Ugyanaz a rendszer alacsony kockázatú lehet az egyik felhasználó számára, és magas kockázatú egy másik számára. Ugyanaz a modell elfogadható lehet vázlatkészítésre, és elfogadhatatlan autonóm műveletekre. Ugyanazok az adatok megengedettek lehetnek támogatáshoz, és tiltottak marketinghez. Ugyanaz a válasz ártalmatlan lehet belsőleg, és következményekkel járhat, ha kifelé küldik.
A futásidőben történő irányítás észreveszi ezeket a különbségeket, mert a kontextust értékeli. Egy képzett alkalmazott kérése szűk célból nem ugyanaz, mint egy külső felhasználó kérése széles körű eszközhozzáféréssel. Egy lekérdezés nyilvános dokumentációból nem ugyanaz, mint egy érzékeny ügyiratból történő lekérés. Egy vázlatüzenet nem ugyanaz, mint egy elküldött üzenet. Egy ajánlás, amelyet az ember figyelmen kívül hagyhat, nem ugyanaz, mint egy döntés, amely frissít egy nyilvántartást. A kérés útvonalán válnak ezek a megkülönböztetések valósággá.
Ez nem azt jelenti, hogy minden kéréshez jogi szeminárium kell. Azt jelenti, hogy a rendszernek elegendő kontextust kell hordoznia a helyes útválasztáshoz. Személyazonosság, cél, adatosztály, hatásosztály, modelljóváhagyás, eszközhatókör, joghatóság, visszafordíthatóság, emberi szerep és bizonyítékigény. Sok ellenőrzés egyszerű, ha egyszer megnevezték. A nehéz rész nem mindig a számítás. A nehéz rész az, hogy elismerjük, hogy a kontextus számít, és nem simítjuk el a kényelem kedvéért.
A kényelem az, ahol a futásidőben történő irányítás általában elvész. Egy fejlesztő parancsikont ad hozzá, mert a felülvizsgálati sor lassú. Egy termékcsapat újra felhasznál egy adatforrást, mert a mezőnevek egyeznek. Egy vezető jóváhagy egy ideiglenes kivételt, mert közel a megjelenés. Egy prompt új utasítást kap, mert a szabályzati kapu még nem áll készen. Minden lépés érthető lehet. Együtt egy olyan rendszert építenek, ahol az irányítás szellemében létezik, de az útvonalon kudarcot vall. A szellem rossz futásidőbeli függőség.
A szabályzati kapuk nem szabályzati tulajdonosok
A runtime gate can enforce a condition, but it does not own the meaning of the condition. This distinction matters. A policy owner decides which cases require review, which sources are allowed, which retention period applies, and which harms matter. A gate applies those decisions at speed. If the organisation confuses the two, engineering ends up quietly becoming policy, or policy ends up pretending that implementation detail is someone else's weather.
The healthy pattern is a contract between policy and runtime. Policy owners define rules, thresholds, exceptions, and review obligations. Engineers implement gates, tests, records, and failure modes. Operators monitor whether gates are firing as expected. Reviewers feed back where rules create absurd outcomes. Governance bodies review the evidence and change the policy when reality has been impolite. This is governance as a loop, not as a framed PDF.
Policy gates also need versioning. A request handled under last month's rule should not be judged later as if today's rule had existed. A pending case may cross a policy release. A model may produce drafts under one threshold and actions under another. If the system records only current policy state, audits become time travel with bad signage. The record must say which rule version applied to which transition.
There is a modest discipline here that saves a lot of drama. Treat policy like a live dependency. Give it identifiers. Give it owners. Test it. Stage it. Roll it back. Observe it. Record its decisions. This does not make policy mechanical. It makes the mechanical part honest enough for people to govern the rest.
Locality turns governance into routing
Data locality used to be discussed as a storage issue. Where is the database. Which region. Which supplier. Which backup. In AI systems locality becomes more active. Retrieval may pull data from one region, a model may run in another, a tool may call a third-party service, and a human reviewer may sit under a different legal regime. The question is no longer only where data rests. It is where work crosses boundaries.
Runtime governance must therefore route according to locality. Some data can leave a device only as an aggregate. Some records can be processed in one jurisdiction but not another. Some suppliers may be approved for low sensitivity and blocked for higher classes. Some model routes may be allowed for public text but not for personal files. Some logs may stay local even when the model call is remote. These choices cannot be solved only at procurement time. The live request carries the answer.
Locality is not just law. It is performance, resilience, security, cost, and institutional control. A local model may be slower but more acceptable for sensitive work. A remote service may be cheaper but unsuitable for certain records. A regional index may reduce latency but create version divergence. A supplier may support encryption but not the export format needed for audit. Runtime governance does not magically solve these tradeoffs. It makes them explicit before the system sends work across a boundary.
The alternative is hidden routing. The workflow calls whatever endpoint is convenient. The endpoint calls another service. Logs move elsewhere. Derived data appears in analytics. Six months later someone asks where a case went. The answer requires a diagram, two engineers, and a surprising amount of optimism. This is not governance. It is cartography after the expedition.
A költségvetés kormányzás, nem pénzügyi apróság
Az AI-költségvetésekről gyakran csak a számlák megérkezése után esik szó, ami nagyjából ugyanolyan későn van, mint amikor a ló már előfizetett egy prémium tokencsomagra, és csak utána zárják be az istállóajtót. A költség futásidejű kormányzási kérdés, mert a nem kezelt költség megváltoztatja a viselkedést. A csapatok kikapcsolják a nyomkövetést. Lerövidítik az értékelést. Elkerülik az emberi felülvizsgálatot. Csökkentik a forrásminőséget. Túl agresszívan kötegelnek. Hagyják, hogy az ügynökhurkok céltalanul bolyongjanak. A költségproblémából könyveléssel megtűzdelt kontrollprobléma lesz.
A futásidejű rendszernek az útvonal részeként kell ismernie a költségvetést. Hány modellhívást tehet ez a kérés. Mely eszközök engedélyezettek. Mennyi kontextus indokolt. Hány újrapróbálkozás. Mikor kell az ügynöknek megállnia. Mikor elfogadható az olcsóbb útvonal. Mikor érdemel egy nagy hatású eset drágább bizonyítékot. A költség nem csak egy felső korlát. Ez egy módja annak, hogy kifejezzük a prioritást és megakadályozzuk a szabályozatlan viselkedést.
A költségvetési védők a biztonsági kockázatot is csökkentik. Egy hurok, amely pénzt éget, megismételhet műveleteket, sokszorosíthat üzeneteket, zárolhat rekordokat, vagy leterhelhet egy szállítót. Egy lekérési folyamat, amely túl sok adatot húz le, növelheti az adatvédelmi kitettséget. Egy összegző feladat, amely minden dokumentumot feldolgoz, származtatott rekordokat hozhat létre új kötelezettségekkel. A lépéskorlátok, kvóták, megszakítás és a hasznos eredményenkénti költségmutatók kormányzási kontrollok. Kevésbé nemesek, mint az értéknyilatkozatok, de nagyobb valószínűséggel állítják meg a gépet a megfelelő pillanatban.
Ez nem azt jelenti, hogy a legolcsóbb útvonal a felelős útvonal. Néha az erősebb bizonyíték többe kerül. Néha a helyi feldolgozás többe kerül, és mégis az a helyes. Néha az emberi felülvizsgálat azért drága, mert ez a lényeg. A futásidejű kormányzásnak láthatóvá kell tennie ezeket a választásokat. A cél nem az olcsó AI. A cél az olyan AI, amelynek költsége, bizonyítéka és kockázata érthető, amíg a munka folyik.
A meghibásodási módok ismerős szagot árasztanak
A futásidejű kormányzási hibák ritkán érkeznek táblával a nyakukban. Ismerős szaguk van. Politikai sodródás. Árnyékeszközök. Túllépés. Hiányzó fellebbezés. Költségvetési hurkok. Elavult hozzájárulás. Ezek nem egzotikus AI-szörnyek. Ezek hétköznapi szervezeti kudarcok, amelyeket a szoftver felgyorsít. Ez szinte rosszabb, mert a hétköznapi kudarcokat könnyű megbocsátani, amíg infrastruktúrává nem válnak.
Policy drift akkor következik be, amikor az írott szabály megváltozik, de a futásidejű útvonal nem, vagy a futásidejű útvonal változik meg, az írott szabály viszont nem. Shadow eszközök akkor jelennek meg, amikor a csapatok nem hivatalos integrációkkal kerülik meg a lassú ellenőrzéseket. A túlterjeszkedés akkor jelenik meg, amikor egy támogatásra jóváhagyott rendszer csendben elkezdi befolyásolni a végrehajtást, az árazást vagy a hozzáférést. A hiányzó fellebbezés akkor jelenik meg, amikor a felhasználók kaphatnak egy MI által formált eredményt, de nem tudják azt olyan módon megtámadni, amely eljut a nyilvántartásba. A költségvetési hurkok akkor jelennek meg, amikor az ügynökök vagy a kötegelt feladatok tovább költenek, miután a hasznos munka véget ért. Az elavult hozzájárulás akkor jelenik meg, amikor a régi engedélyeket frissként kezelik, mert senki sem tette a hozzájárulást a kérés útvonalának részévé.
A hasznos válasz nem a pánik. Hanem a mérhetőség. Nevezze meg a hibamódot. Adjon hozzá egy védelmet ott, ahol megelőzhető. Adjon hozzá egy riasztást ott, ahol észlelhető. Adjon hozzá egy felelőst ott, ahol javítható. Adjon hozzá egy nyilvántartást ott, ahol auditálni kell. Egyes hibák szabályzatmódosítást igényelnek. Egyesek felületmódosítást. Egyesek adatszerződéseket. Egyesek beszerzési fegyelmet. A futásidejű irányítás azért hasznos, mert a szervezetnek helyet ad a javítás rögzítésére.
Emellett kellemetlen igazságokat is feltár. Egy kapu megmutathatja, hogy egy népszerű használati esetből hiányzik a jogalap. Egy hozzájárulás-ellenőrzés megmutathatja, hogy az adatcsatorna nem olyan rendezett, mint a prezentáció. Egy költségkeret megmutathatja, hogy az üzleti terv csak akkor működik, ha az értékelés alulfinanszírozott. Egy fellebbezési nyilvántartás megmutathatja, hogy nem egy modell, hanem egy szabályzat hoz létre igazságtalan eredményeket. A jó irányítási bizonyíték udvariatlan. Ez az egyik legjobb tulajdonsága.
Az emberi irányításnak a körben kell maradnia
A futásidejű irányítás nem terv az emberek eltávolítására az irányításból. Éppen ellenkezőleg. Jobb beavatkozási pontokat ad az embereknek. Egy igazgatótanács nem tud minden kérést értékelni. Egy szabályzatgazda nem tud minden eszközhívást jóváhagyni. Egy jogász nem tud minden lekérdezési döntésben benne ülni. Egy lektor nem tud minden alacsony kockázatú tervezetet átvizsgálni. A rendszernek kezelnie kell a hétköznapi ellenőrzéseket. Az embereknek kell birtokolniuk a szabályokat, a kivételeket, a vitatott eseteket, az értelmezést és a javítást.
A kulcs az eszkalációs tervezés. Mikor kell a rendszernek megállnia és kérdeznie. Mikor kell megtagadnia kérdezés nélkül. Mikor kell engedélyeznie és rögzítenie. Mikor kell mintát vennie későbbi felülvizsgálatra. Mikor kell az ismétlődő alacsony kockázatú jeleknek magas kockázatú mintává válniuk. Mikor kell egy felhasználói panasz egy lezárt állapotot újranyitnia. Ezek irányítási döntések. Nem szabad őket elrejteni a promptokban, a sorban állási alapértelmezésekben vagy az ügyeletes hősies megítélésében.
Runtime-evidence javítja az emberi irányítást, mert a bizottságoknak valami jobbat ad az anekdotáknál. Az irányító csoport látja, milyen gyakran blokkoltak a kapuk, hol csoportosultak a kivételek, mely fellebbezések jártak sikerrel, mely beszállítók okoztak súrlódást, mely szabályzatok lassították a munkát, és mely modellútvonalak okoztak incidenseket. Aztán az ülés az evidencia köré szerveződik. Lehet, hogy még mindig hosszú. Nem ígérhetünk csodákat. De legalább van esélye annak, hogy hasznos legyen.
Az emberekre azért is szükség van, mert a szabályzat néha ütközik a valósággal. Egy szabály lehet jogilag helyes és működésében kegyetlen. Egy adatforrás lehet engedélyezett, és mégis társadalmilag kockázatos. Egy modell teljesíthet jól összességében, és mégis elbukhat egy sérülékeny élszituációban. Egy költségkeret takaríthat meg pénzt, és okozhat igazságtalan késedelmet. A runtime-rendszerek felszínre hozhatják ezeket az ütközéseket. Az embereknek kell eldönteniük, mit jelentenek.
A runtime-irányítás megváltoztatja a beszerzést
Runtime-irányítási támogatás nélkül mesterséges intelligenciát vásárolni annyi, mint jövőbeli bizonytalanságot vásárolni. Egy beszállítónak lehetnek kiváló modelljei, kellemes demói, tanúsítványai és magabiztos prezentációi. A gyakorlati kérdések kevésbé fényesek. Képes-e a rendszer kérésenként feltárni a szabályzati döntéseket. Lehet-e rögzíteni a modell- és promptverziókat. Érvényesíthető-e dinamikusan az adatok lokalitása. Korlátozhatók-e és rögzíthetők-e az eszközhívások. Szétválaszthatók-e a naplók cél szerint. Exportálható-e az evidencia használható formátumban. Távozhat-e egy intézmény a saját rekordjaival. Visszajátszható-e egy eset, ha a beszállító megváltoztatta a platformját.
Ezek a kérdések nem ellenségesek a beszállítókkal szemben. Felnőttek. Az a beszállító, amely támogatja a runtime-irányítást, segít a vevőnek felelősen működni. Az a beszállító, amely nem tudja támogatni, még hasznos lehet alacsony kockázatú feladatokra, de a vevőnek ismernie kell a határt. A legrosszabb kimenet az, ha úgy teszünk, mintha egy általános képesség alkalmas lenne jelentős következményekkel járó munkára, pusztán azért, mert a demó nem tartalmazott irányítási problémát. A demók ritkán tartalmaznak. Ezért férnek el nassolnivalókkal teli termekben.
A beszerzésnek a hibákról is kérdeznie kell. Mi történik, ha egy szabályzati kapu nem érhető el. A rendszer biztonságos leállást alkalmaz, nyitva hagyja a kaput, vagy felülvizsgálatra irányít. Mi történik, ha egy modellt kivonnak. Mi történik, ha egy régió elérhetetlenné válik. Mi történik, ha audit-exportot kérnek. Mi történik, ha egy felhasználó törlést kér. Mi történik, ha a naplók érzékeny adatokat tartalmaznak. A válasz az irányításra gyakran a hibaüzemmódban rejlik.
A runtime-irányítás nem követeli meg, hogy minden beszállító felfedje minden belső módszerét. Azt követeli meg, hogy a szolgáltatási határ elszámoltatható legyen. A vevőnek elég kontrollra és evidenciára van szüksége ahhoz, hogy teljesítse a saját kötelezettségeit. Ha egy feketedoboz-összetevő biztonságosan ülhet egy irányított határ mögött, rendben. Ha maga a határ feketedoboz, a vevő nemcsak a képességet, hanem a munkáért való felelősség egy részét is kiszervezte.
Az irányítás mint működési hurok
Az érett minta egy működési hurok. Érzékeld, mi történik. Értékeld a kontextust. Kapuzd a műveletet. Cselekedj a korlátokon belül. Tekintsd át az eredményeket. Frissítsd a szabályokat, adatokat, modelleket és interfészeket. Ez a hurok különböző sebességgel fut. Egyes ellenőrzések kérésenként történnek. Egyesek naponta. Egyesek kiadás után. Egyesek negyedévente. Egyesek incidensek után. A fontos rész az, hogy a hurkok kapcsolódjanak. Egy panasz eljusson az értékeléshez. Egy fellebbezés eljusson a szabályzathoz. Egy szabályzatváltozás eljusson a kapukhoz. Egy modellfrissítés eljusson a tesztekhez. Egy beszállítói incidens eljusson az útválasztáshoz.
Így válik az irányítás kevésbé színpadiasá. Megszűnik a rendszer körüli ceremóniák halmaza lenni, és a rendszer működésének tulajdonságává válik. A szervezetnek lehetnek bizottságai, nyilvántartásai, szabályzatai és jelentései. Kell is legyenek. De ezek az artefaktumok mostantól élő evidenciához kapcsolódnak. Az irányítási ülés megkérdezheti, mit tett a rendszer, nem csak azt, minek mondja magát a rendszer.
Az üzemeltetési hurok a kormányzást is alkalmazkodóbbá teszi. Az AI-rendszerek változnak. A törvények változnak. Az adatok változnak. A felhasználói viselkedés változik. A modellek változnak. A szállítói feltételek változnak. Egy statikus jóváhagyás mindezt nem tudja lefedni. A futásidőben működő kormányzás nem úgy oldja meg a bizonytalanságot, hogy befagyasztja a világot. Lehetőséget ad a szervezetnek arra, hogy észleljen, döntsön és frissítsen anélkül, hogy elveszítené az elszámoltathatóságot a korábbi döntésekért.
A huroknak memóriával kell rendelkeznie. Különben az alkalmazkodás csendes átírásba fordul. Amikor egy szabály megváltozik, a régi eseteknek továbbra is szükségük van a régi kontextusukra. Amikor egy modellútvonalat kivonnak, a korábbi döntéseknek továbbra is magyarázatra van szükségük. Amikor egy forrást eltávolítanak, a származtatott kimeneteknek továbbra is szükségük van az adatvonalra. A futásidőben működő kormányzásnak támogatnia kell a változást anélkül, hogy eltörölné a korábbi okokat. Ez egy unalmas mondat, nagy következményekkel.
A tanulság
A kormányzás futásidőben megoldandó problémává válik, amikor az AI-rendszerek gyorsabban, szélesebb körben és kontextusfüggőbben mozognak, mint amennyit a vezetői szintű dokumentumok önállóan kezelni tudnak. A válasz nem az, hogy feladjuk a kormányzási dokumentumokat, vagy kóddal helyettesítjük az emberi ítélőképességet. A válasz az, hogy összekapcsoljuk a dokumentumokat, szerepköröket, szabályzatokat, kapukat, rekordokat és felülvizsgálati hurkokat, hogy a kormányzás működhessen, amíg a munka folyik.
A futásidőben működő kormányzás ellenőrzi az identitást, a célt, az adatokat, a lokalitást, a modellútvonalat, az eszközök jogosultságát, a költségvetést, az emberi felülvizsgálatot, a bizonyítékokat, a fellebbezést és a megőrzést az élő folyamatban. Az élő függőségekként kezeli a szabályzatokat. Tudatosan irányít át jogi és működési határokon. Rögzíti, hogy melyik szabályt alkalmazták. Megnevezi a meghibásodási módokat, mielőtt szokássá válnának. Bizonyítékot ad az embereknek anekdoták helyett.
Ez kevésbé romantikus, de hasznosabb szemlélet a kormányzásról. A komoly kérdés nem az, hogy a szervezet rendelkezik-e AI-kormányzási keretrendszerrel. A komoly kérdés az, hogy mi történik kedden 09:14-kor, amikor egy valódi kérés azt kéri a rendszertől, hogy lépjen. Ha a válasz ellenőrzött, korlátozott, rögzített és felülvizsgálható, a kormányzás működik. Ha a válasz az, hogy a szabályzat egy mappában van, a kormányzás még mindig az ügyfélfogadási időre vár.