Az AI-irányításnak van karbantartási ütemezése.

Az irányítás nem a jóváhagyás, amely egy AI-rendszer élesítése előtt történik. Hanem a mindennapi munka: figyelés, döntés, változtatás, ellenőrzés és...

Az AI-irányításnak van karbantartási ütemezése.

A politika mögött álló naptár

A legtöbb irányítási dokumentum úgy íródik, mintha az érdekes munka a rendszer használatba vétele előtt történne. Valaki meghatároz egy célt. Egy csapat kockázatot értékel. Egy vezető aláír egy sort. Egy szállító szállít egy PDF-et, amelynek fájlnevében szerepel a „végleges” szó, ami általában egy kis figyelmeztetés. Ezután a rendszer belép a hétköznapi életbe, ahol egy adatforrást lecserélnek, egy személy megtanul egy kerülőutat, egy szabályzat megváltozik, egy szolgáltató frissít egy összetevőt, vagy egy korábban szokatlan eset válik gyakorivá. A jóváhagyás a mappájában marad. A világ nem.

Ezért van szüksége a mesterséges intelligencia irányításának karbantartási ütemtervre. Nem egy ünnepélyes éves találkozóra, ahol egy dián hét zöld pont látható. Hanem a gondoskodás hétköznapi cselekedeteinek ütemtervére: annak ellenőrzése, hogy a megadott cél még mindig igaz-e, azoknak a jeleknek az olvasása, amelyek megváltoztathatják a kockázati megítélést, annak eldöntése, hogy ki módosíthatja a rendszert, annak gyakorlása, hogy mi történik, ha le kell állítani, annak rögzítése, hogy egy változtatást miért hajtottak végre, és a bizonyítékok visszavonása, amikor feltételeik lejártak. Ez kevésbé látványos, mint egy bejelentés a bevezetésről. De itt válik az elszámoltathatóság vagy valóságossá, vagy csendesen elpárolog.

A megkülönböztetés azért fontos, mert a mesterséges intelligencia rendszerek nem maradnak ott, ahová a kezdeti felmérés helyezte őket. Egy modell változatlan maradhat, miközben a bemenetei, felhasználói, felülete, telepítési útvonala, csatlakoztatott eszközei, üzleti folyamata vagy jogi környezete megváltozik. Egy modell megváltozhat, miközben a használat stabilnak tűnik. Egy rendszer technikailag elérhető maradhat, de működésileg alkalmatlanná válhat, mert azok, akik megkérdőjelezhették, másik munkahelyre kerültek, mert a felülvizsgálati sor megtelt, mert egy új, downstream felhasználás más következményt adott a kimenetének. Az az irányítás, amely a kiadás dátumát tekinti a célvonalnak, egy fényképet irányít.

Az európai szabályok már tartalmaznak egy igényesebb elképzelést. A nagy kockázatú mesterséges intelligencia rendszerek esetében az AI Act 9. cikke a kockázatkezelést folyamatos, iteratív folyamatnak nevezi, amelyet a teljes életciklus során terveznek és futtatnak, rendszeres, szisztematikus felülvizsgálattal és frissítéssel. A 72. cikk arányos, dokumentált, forgalomba hozatal utáni nyomonkövetési rendszert ír elő, amely a rendszer élettartama során aktívan és szisztematikusan gyűjti, dokumentálja és elemzi a releváns teljesítményadatokat. A lényeg nem az, hogy minden apró szoftvernek ugyanarra a gépezetre van szüksége. Hanem az, hogy a jelentős következményekkel járó technológiának működési ritmusra van szüksége, nem csupán egy kiinduló fájlra.

A hasznos kérdés ezért nem az, hogy „Van mesterséges intelligencia irányítási keretrendszerünk?”, hanem az, hogy „Mi történik jövő kedden, amikor a bizonyítékok már nem illeszkednek a szolgáltatáshoz?” Ki látja ezt meg először. Milyen információval rendelkeznek. Ki döntheti el, hogy ez egy szokásos korrekció, egy lényeges változás, egy incidens vagy a szüneteltetés oka. Hogyan őrzik meg az eredeti döntést anélkül, hogy kifogássá válna. És amikor a rendszer technikailag még működik, de az intézmény már nem érti a használatának feltételeit, ki mondhatja ki, hogy a működés már nem elég jó?

A karbantartási ütemterv nem egy általános irányítópulttal válaszol ezekre a kérdésekre. Emberekhez és pillanatokhoz rendeli őket. Minden feljegyzésnek okot ad arra, hogy újra megnézzék. A rendszer folyamatos használatát a bizonyítékok, a felhatalmazás és a körülötte zajló valódi munka közötti élő kapcsolattól teszi függővé.

Mi romlik el a bevezetés után

A szoftvernek nem kell meghibásodnia ahhoz, hogy kevésbé irányíthatóvá váljon. A leggyakoribb romlás csendesebb. Egy csapatnak jó leírása van a tervezett használatról, de a szolgáltatás oldalirányban növekszik. Egy belső tervezethez készült asszisztenst átmásolnak egy ügyfélútvonalra. Egy osztályozó, amelyet egy rögzített dokumentumkészlet rendezésére építettek, új típusú beküldést kap. Egy rendszer, amelyet eredetileg egy kis csoport vizsgált felül, egy tágabb folyamat részévé válik, ahol senki sem ismeri azt a korlátot, amely a kezdetekkor fontos volt. Ehhez a leíráshoz nem kell kitalált katasztrófa. Ez egyszerűen az, ami akkor történik, amikor egy intézmény gyorsabban változik, mint a feljegyzései.

Az elhivatottság (purpose) romlik el elsőként, mert gyakran főnévként írják le, pedig valójában egy határvonal. A „döntéstámogatás” nem megfelelő elhivatottság, ha a nyilvántartás nem mondja meg, hogy melyik döntésről van szó, kinek, milyen inputokkal, milyen felhatalmazással, és hogy a kimenetnek mit tilos kiváltania. Egy elhivatottsági nyilatkozatot újra kell vizsgálni, amikor új csapat kezdi használni a rendszert, amikor egy kimenet jelentőségteljes útvonalat kezd megnyitni vagy lezárni, amikor új populációt érint, vagy amikor az emberi átadás kevésbé válik értelmessé. A szavak változatlanok maradhatnak, miközben a gyakorlati következmény jelentősen megnő.

Az evidencia romlik el következőként. Egy értékelési eredmény egy megfigyelés meghatározott körülmények között. Sokáig hasznos lehet, de nem halhatatlan. A mért modellállapot megváltozhatott. Az adateloszlás elmozdulhatott. A rendszert használók mostanra másképp értelmezhetik a kimenetét. Egy benchmark lefedhet egy részhalmazt, amely kezdetben reprezentatív volt, de már nem az. A teszt maga még reprodukálható lehet, miközben az érv, amiért támaszkodunk rá, meggyengült. A jelentés megtartása jó nyilvántartásvezetés. Ha azonban aktuális evidenciaként kezeljük a feltételeinek ellenőrzése nélkül, az már más.

Az interfészek is romlanak. Ezt gyakran figyelmen kívül hagyják, mert egy interfészváltozás ártalmatlannak tűnhet. Egy új alapértelmezés, egy hangsúlyosabb gomb, egy rövidített magyarázat, egy hozzáadott eszközhívás vagy egy módosított eszkalációs útvonal megváltoztathatja, hogy mit tesznek valójában a felhasználók. A modell ugyanaz, ezért a csapat azt mondja, hogy nem történt modellváltozás. Ez technikailag pontos lehet, de működésileg lényegtelen. Ha az interfész kötelezővé teszi egy ajánlás érzetét, ha eltávolítja az eredmény megkérdőjelezéséhez szükséges kontextust, vagy ha lehetővé teszi, hogy egy kimenet messzebbre jusson, mint korábban, a kormányzási kérdés megváltozott, még akkor is, ha a súlyok nem.

A felhatalmazás romlik, amikor a felelősség papíron létezik, de a gyakorlatban már nem. Egy megnevezett tulajdonos távozhatott. Egy felülvizsgálati szerep megmaradhat a szervezeti ábrán, miközben az azt betöltő személynek sem ideje, sem információja nincs az ítélőképesség gyakorlására. Egy leállítási felhatalmazás hozzárendelhető egy vezető csoporthoz, amely nem tudja, hogy hozzá lett rendelve. Egy beszállítói szerződés hivatkozhat egy eszkalációs kapcsolattartóra, aki fogadhat egy értesítést, de nem tud változtatást végrehajtani. A kormányzás ekkor egy régi telefonkönyvvé válik, kissé magabiztosabb tipográfiával.

A függőségek felhalmozódással romlanak. Egy szolgáltatás hozzáadhat egy lekérési forrást, egy identitásszolgáltatót, egy megfigyelési terméket, egy következtetési útvonalat, egy várakozási sort, egy tárolási réteget vagy egy másik modellt. Minden egyes hozzáadás ésszerű lehet. Együtt azonban megváltoztatják a ténylegesen működő rendszert. A DORA ezt a pontot pénzügyi környezetben teszi meg, mivel megköveteli a szervezetektől, hogy azonosítsák, osztályozzák és dokumentálják az IKT-támogatott üzleti funkciókat, eszközöket, szerepeket, felelősségeket és függőségeket, valamint hogy a releváns dokumentációt legalább évente és jelentős változás esetén felülvizsgálják. Ez nem egy MI-szabály. Ez egy hasznos emlékeztető arra, hogy a karbantartást igénylő objektum a rendszer a működési környezetében, nem pedig a legdivatosabb nevű összetevő.

Végül az emlékezet romlik. Egy szervezet több ezer naplósort megőrizhet, és mégis elveszítheti egy döntés okát. A naplók megmondhatják, hogy egy esemény bekövetkezett. Nem mondják meg automatikusan, hogy miért állítottak be egy küszöbértéket, ki fogadta el a korlátozást, mely eseteket zárták ki egy kísérletből, vagy mit kívánt egy csapat ellenőrizni egy kiadás után. Ez az információ általában az emberekkel távozik, hacsak nem rögzítik egy tulajdonossal és felülvizsgálati ponttal rendelkező nyilvántartásban. Egy auditnyom, amely nem tudja megmagyarázni az esemény körüli ítélőképességet, hasznos, de hiányos.

Egyik sem érv az állandó gyanakvás mellett, sem amellett, hogy minden menüváltozásnál bizottsági ülést tartsanak. A mértéknek jelentősége van. Maga az AI Act is úgy írja le a forgalomba hozatal utáni nyomon követést, hogy annak arányban kell állnia a technológia jellegével és a nagy kockázatú rendszer kockázatával. A karbantartás célja nem az, hogy a hétköznapi fejlesztés lehetetlenné váljon. Hanem az, hogy a szervezet ügyesen észrevegye, melyik fejlesztés nem hétköznapi.

A jogszabály már eleve ciklusokban gondolkodik

Az európai technológiai szabályokat gyakran megfelelési kötelezettségként írják le, mintha a munka egyetlen benyújtásból állna, amit egy bélyegző követ. Ha közelebbről olvassuk, a működési logikájuk ciklikus. Azt kérik a szervezetektől, hogy azonosítsanak, nyomon kövessenek, dokumentáljanak, jelentsenek, felülvizsgáljanak, teszteljenek és fejlesszenek. A szókincs ágazatonként eltér, mert a kockázatok is eltérnek. A karbantartási ösztön feltűnően egységes.

A nagy kockázatú MI-rendszerek esetében az AI Act az életciklus-szemléletet a követelmények elejére helyezi. A 9. cikk előírja, hogy kockázatkezelési rendszert kell létrehozni, bevezetni, dokumentálni és karbantartani. Ezt a rendszert folyamatosnak és iteratívnak írja le, amelyet a teljes életciklusra terveznek és működtetnek, rendszeres, módszeres felülvizsgálattal és frissítéssel. A rendszernek azonosítania és elemeznie kell az ismert és észszerűen előrelátható kockázatokat, beleértve a rendeltetésszerű használathoz és az észszerűen előrelátható visszaélésekhez kapcsolódó kockázatokat is. Emellett fel kell használnia a forgalomba hozatal utáni nyomon követésből gyűjtött információkat is. Ez arra utasítást ad, hogy a kezdeti értékelés felülvizsgálható legyen. Nem engedi, hogy a kezdeti értékelés múzeumi darabbá váljon.

A 72. cikk pontosabban meghatározza, mi történjen azután, hogy egy nagy kockázatú rendszert üzembe helyeztek. A szolgáltatóknak a technológiával és a kockázattal arányos nyomon követési rendszert kell létrehozniuk és dokumentálniuk. Ennek aktívan és módszeresen gyűjtenie, dokumentálnia és elemeznie kell a teljesítményre vonatkozó releváns adatokat a rendszer élettartama során, hogy értékelhető legyen a vonatkozó követelményeknek való folyamatos megfelelés. Adott esetben magában foglalja a más MI-rendszerekkel való kölcsönhatás elemzését is. Ez a valós telepítéseknél azért fontos, mert a rendszer érdemi viselkedése a határfelületen alakulhat ki: egy kimenet egy másik eszközbe kerül, egy szabálymotor tetté alakít egy pontszámot, egy ember olyan felületet lát, amely megváltoztatja egy ajánlás súlyát, vagy egy downstream munkafolyamat új következményt hoz létre.

A rendelet nem kéri, hogy a nyomon követés minden szolgáltatáshasználó passzív megfigyelésévé váljon. Releváns információkat kér, és a környező jogi környezet továbbra is érvényes. A karbantartási tervnek ezért minden jel esetében a céllal kell kezdődnie. Milyen kérdésre ad választ a jel. Elég-e az összesített információ. A felülvizsgálathoz tartalomra, személyazonosságra vagy csak egy verziózott működési tényre van-e szükség. Ki férhet hozzá. Meddig őrzik meg. Hogyan lehet megkérdőjelezni. Többet gyűjteni azért, mert egy irányítópult több mezőt fogad el, nem karbantartási stratégia. Ez ambíciókkal rendelkező tárolás.

Ugyanez a fejezet kapcsolja össze a nyomon követést a súlyos incidensek kezelésével. A 73. cikk előírja, hogy az uniós piacon forgalomba hozott nagy kockázatú rendszerek szolgáltatói súlyos incidenseket jelentsenek az illetékes piacfelügyeleti hatóságoknak, miután ok-okozati összefüggést, vagy annak észszerű valószínűségét megállapították. Határidőket szab, amelyek a súlyosságtól függően változnak, beleértve két napot a meghatározott fajtájú széles körű jogsértés vagy súlyos incidens esetén. A jelentést követően vizsgálatot, kockázatértékelést és korrekciós intézkedést ír elő. A fontos működési felismerés nem a napok száma. Hanem az, hogy az incidenskezelés nem külön PR-folyamat. Része annak a bizonyítéki körnek, amelynek meg kell változtatnia a kockázatkezelést, a dokumentációt és a jövőbeli működést.

A NIS2 egyértelművé teszi a tulajdonlás kérdését a kiberbiztonságban. A 20. cikk kimondja, hogy az alapvető és fontos entitások vezető testületei jóváhagyják a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelik azok végrehajtását, és felelősségre vonhatók a jogsértésekért. A 21. cikk ezután megfelelő és arányos technikai, működési és szervezeti intézkedéseket követel meg, beleértve az incidenskezelést, az üzletmenet-folytonosságot, az ellátási lánc biztonságát, valamint a beszerzés, fejlesztés és karbantartás biztonságát. Ez messze túlmutat azokon az entitásokon, amelyekre a NIS2 vonatkozik. Az irányítás nem egy felülről lefelé küldött utasítás egy vezetői csomagból. Ha a formális hatáskörrel rendelkezők sem felülvizsgálják az intézkedéseket, sem nem értik döntéseik következményeit, a szervezet egy címet hozott létre kontroll nélkül.

A NIS2 a bejelentést is szolgáltatási kötelezettségként kezeli. A jelentős incidenseket indokolatlan késedelem nélkül be kell jelenteni, és adott esetben a szolgáltatások igénybevevőit is tájékoztatni kell, ha egy jelentős incidens valószínűleg hátrányosan érinti a szolgáltatásnyújtást. Egy incidens nemcsak akkor jelentős, ha magát a szervezetet zavarja meg, hanem akkor is, ha más személyeket érint jelentős anyagi vagy nem anyagi kárral. Ez a határvonal hasznos az AI-irányítás szempontjából. Egy csapatnak nem szabad csak arra figyelnie, hogy a rendszer rendelkezésre állási grafikonja zöld marad-e. Egy rendszer lehet elérhető, és mégis fontos működési vagy jogokkal kapcsolatos problémát okozhat.

A DORA egy másik gyakorlati mintát kínál. A pénzügyi entitásoknak azonosítaniuk és dokumentálniuk kell az ICT-támogatott üzleti funkciókat, szerepköröket, felelősségeket, információkat és ICT-eszközöket, valamint azok függőségeit. Felülvizsgálják a besorolások és a dokumentáció megfelelőségét szükség szerint és legalább évente, és kockázatértékelést végeznek az érintett funkciókat vagy eszközöket befolyásoló infrastruktúra, folyamatok vagy eljárások minden jelentős változásakor. Ez megint nem azt jelenti, hogy minden szervezet pénzügyi entitás. Ez egy példa arra, hogy egy érett szabály a leltárt, a változást és a felülvizsgálatot összekapcsolt munkaként kezeli. Egy élő rendszernek térképre van szüksége, a térképnek pedig dátumra.

A DORA változáskezelésre vonatkozó nyelvezete különösen megfontolt. Dokumentált szabályzatokat, eljárásokat és kontrollokat követel meg a szoftverek, hardverek, firmware-ek, rendszerek és biztonsági paraméterek változásaihoz. A változásokat ellenőrzött módon rögzíteni, tesztelni, értékelni, jóváhagyni, végrehajtani és ellenőrizni kell. Ez a sorrend nem azt állítja, hogy egy AI-modell mindig biztonságosan tesztelhető. Ez egy módja annak, hogy elutasítsuk azt a gondolatot, hogy egy éles környezeti frissítés önmagában indokolt. Egy változásnak oka, értékelése, jóváhagyási útvonala, végrehajtási nyilvántartása és az eredmény ellenőrzése kell, hogy legyen.

Az ISO/IEC 42001 nem jogszabály, és egy nyilvános termékoldal nem helyettesíti magát a szabványt. Mindazonáltal az ISO a szabványt egy Plan-Do-Check-Act alapú AI-irányítási rendszerként írja le, amelynek célja, hogy segítse a szervezetet az AI-val kapcsolatos kockázatok és lehetőségek kezelésében a szervezet egészében, nem pedig csupán az egyes alkalmazások vizsgálatában. A ciklus a hasznos gondolat. A Plan egy behatárolt szándékot hoz létre. A Do működésbe hozza. A Check azt kérdezi, hogy a bizonyítékok alátámasztják-e a további támaszkodást. Az Act megváltoztatja a munkarendszert. Ennek a ciklusnak az ismétlése nem öncélú bürokrácia. Ez a minimális elismerése annak, hogy a rendszerek és intézmények nem maradnak mozdulatlanok.

Egy irányítási huroknak vissza kell juttatnia a bizonyítékot egy döntéshez. Ellenkező esetben csak egy nyilvántartás az észrevett dolgokról.

A megfigyelésnek engedni kell, hogy számítson

A megfigyelést gyakran technikai tevékenységként említik, ami érthető. A rendszerek telemetriát állítanak elő. A csapatok mérőszámokat választanak. Az irányítópultok vonalakat mutatnak, amelyek emelkednek, süllyednek, és alkalmanként riasztó megbeszéléseket idéznek elő. De a nehéz rész nem a jel gyűjtése. A nehéz rész annak eldöntése, hogy a jel miben változhat.

A megfigyelési terv egy döntési kérdéssel kezdődik. Egy panasz jelezheti, hogy egy magyarázat nem világos, hogy egy bemenet hibás, hogy egy felhasználó korlátba ütközött, vagy hogy a szervezet rosszul tervezte meg a fellebbezési útvonalat. Az emberi felülbírálások számának növekedése jelezheti a modell illeszkedésének romlását, a személyzet magabiztosságának javulását, a szabályzat megváltozását, az elavult forrásadatokat, az esetek új osztályát, vagy egy olyan felületet, amely félrevezeti a felülvizsgálókat. Az elutasítások növekedése jelezheti, hogy egy biztonsági ellenőrzés működik, hogy egy függőség megbízhatatlanná vált, vagy hogy egy terméket a deklarált céltól eltérően használnak. A nyers szám nem a következtetés. Ez egy meghívás egy kapcsolat vizsgálatára.

Ezért választja el egy hasznos terv a megfigyelést az értelmezéstől. A megfigyelés azt mondja meg, hogy mit rögzítettek, melyik verzióval, útvonalon, időpontban, kontextusban és milyen megbízhatósággal. Az értelmezés azt mondja meg, hogy a szervezet szerint mit jelenthet a jel, és milyen alternatív magyarázatok maradnak fenn. A döntés azt mondja meg, hogy ki választhat válaszlépést. A rögzítés azt mondja meg, hogy mi változott és miért. Ez lassabb, mint minden riasztást a modell hibájának bizonyítékaként kezelni. Gyorsabb, mint egy rosszul megértett problémát újratanítási ciklusba küldeni, és felfedezni, hogy a tényleges hiba a szabályzatban, a forrás minőségében, a hozzáférési jogosultságokban vagy a személyzetben volt.

A mérőszámoknak is illeszkedniük kell a rendszer következményeihez. Egy modellminőségi pontszám releváns lehet, de ritkán elegendő. Ha egy kimenet egy várakozási sort érint, a csapatnak ismernie kell a késéseket, a kezeletlen kivételeket, a visszafordításokat, és azt, hogy mely esetek kerülnek manuális felülvizsgálatra. Ha egy asszisztens forrásokat ajánl, a csapatnak ismernie kell a források elérhetőségét, az idézetek javításait, a vitatott válaszokat, és azt, hogy a felhasználók a megadott körön kívüli anyagok alapján cselekszenek-e. Ha egy rendszer tartalmat szűr, a felülvizsgálathoz szükség lehet panaszmintákra, fellebbezési eredményekre, nyelvi lefedettségre és a felülbírálások okaira. A megfigyelésnek azon az úton kell haladnia, ahol a rendszer hatást fejt ki, nem pedig ott kell megállnia, ahol a modell egy tokent vagy pontszámot állított elő.

Az emberhez vezető útvonalat is meg kell figyelni. Könnyű „emberi felügyeletet” írni egy szabályzatba, és nehéz megmutatni, hogy az illető valóban tudja-e gyakorolni. Milyen gyakran bírálnak felül az emberek. Hozzáférnek-e a szükséges bemenetekhez és indokokhoz. Egy felülbírálás eléri-e az eredményt előállító folyamatot, vagy csak egy megjegyzést fűz a végéhez. Mennyi időbe telik egy eszkaláció. Vannak-e olyan esetek, amelyek soha nem jutnak el a felülvizsgálati útvonalig, mert a felület elrejti a lehetőséget. Ezek működési kérdések. Ugyanakkor irányítási kérdések is, mert a válasz meghatározza, hogy az emberi felügyelet valódi vagy pusztán dekoratív.

Nem minden jelnek kell nyilvánosnak lennie. Egyesek kereskedelmileg érzékenyek lehetnek. Egyesek biztonsági kérdéseket érinthetnek. Egyesek személyes adatokat tartalmazhatnak, és eleve nem is kellett volna gyűjteni őket. A karbantartási fegyelem az, hogy ezeket a határokat egyértelművé tegyük. Egy felülvizsgálathoz aggregált mintákra lehet szükség a teljes tartalmi archívum helyett. Szükség lehet egy rögzített állapotra az interakciók teljes naplója helyett. Szükség lehet védett hozzáférésre egy incidensvizsgáló számára, és külön nyilvános magyarázatra a módszerről. Az átláthatóság nem jelenti a nyers működési anyagok közzétételét. Azt jelenti, hogy egy ellenőrzés létezése, célja, határa és tulajdonjoga érthetővé válik.

Kicsi, de fontos különbség van a monitoringterv és a kívánságlista között. Egy terv megmondja, mely jeleket gyűjtik, hogyan védik őket, mi váltja ki a felülvizsgálatot, ki felel a felülvizsgálatért, mik a lehetséges kimenetelek, és hogyan kerül a döntés a változásnyilvántartásba. Egy kívánságlista azt mondja, hogy a szervezet figyelemmel fogja kísérni a minőséget, a biztonságot, a méltányosságot és a felhasználói elégedettséget. Az első tesztelhető. A második nagyon jól mutat egy stratégiai prezentációban, és sehol máshol.

A jó monitoring azt is láthatóvá teszi, ami nem történik meg. Ha nem érkezik jelentés, az azért van-e, mert a rendszer nem okozott problémát, mert a jelentéstételi út nem hozzáférhető, mert az emberek nem tudnak a létezéséről, vagy mert a folyamat nem őrzi meg a jelentéseket? Ha egy incidensküszöböt nem lépnek át, az azért van-e, mert a rendszer stabil, vagy mert a küszöb nem áll kapcsolatban a tényleges kárral? A jel hiánya lehet bizonyíték, de csak akkor, ha a gyűjtési útvonalat megvizsgálták. A csend nem automatikusan megnyugtató. Néha csak egy rosszul jelzett űrlap.

Az incidenskezelés az intézményi emlékezet egyik formája

Az incidensfolyamatnak az incidens előtt kell kezdődnie, mert egy szokatlan esemény első percei rossz időszakot jelentenek a felhatalmazás kitalálására. A folyamatnak módot kell adnia egy észrevétel fogadására, elegendő bizonyíték megőrzésére a megértéshez, az emberek védelmére a további kitettségtől, annak eldöntésére, hogy az esemény megfelel-e egy meghatározott küszöbnek, valamint a kommunikációra azokkal, akiknek cselekedniük kell. Szüksége van egy útvonalra vissza az irányítási rendszerbe. Enélkül a végső útvonal nélkül a szervezet kezeli az epizódot, majd csodálatra méltó hatékonysággal újrateremti annak előfeltételeit.

A DORA ezt világosan kifejezi az IKT-val kapcsolatos incidensekre. Megköveteli a pénzügyi szervezetektől, hogy incidenskezelési folyamatot határozzanak meg, hozzanak létre és hajtsanak végre az incidensek észlelésére, kezelésére és bejelentésére. Nyilvántartják az incidenseket és a jelentős kiberfenyegetéseket, és eljárásokat tartanak fenn a következetes, integrált megfigyelésre, kezelésre és nyomon követésre, hogy a kiváltó okokat azonosítsák, dokumentálják és kezeljék. A folyamatnak korai figyelmeztető mutatókat kell kialakítania, szerepeket és felelősségeket kell kijelölnie a különböző forgatókönyvekhez, valamint kommunikációs és eszkalációs megállapodásokat kell meghatároznia. Ezek konkrét pénzügyi szektorbeli követelmények. Az alapvető logikájuk széles körben hasznos: egy incidensnek jobb tudással kell hagynia a szervezetet, mint amilyennel azelőtt rendelkezett.

Az AI esetében a bizonyítékok kérdése különös figyelmet érdemel. Egy csapat azonnal módosítani akarhat egy modellt vagy szolgáltatást, amint tudomást szerez egy káros kimenetelről. Néha a sürgős elszigetelés pontosan a helyes megoldás. De egy ellenőrizetlen változtatás azt is tönkreteheti, hogy megértsük, mi történt. Az AI-törvény kimondja, hogy a súlyos incidenst vizsgáló szolgáltatónak nem szabad úgy módosítania az AI-rendszert, hogy az befolyásolhassa az okok későbbi értékelését, mielőtt tájékoztatná az illetékes hatóságokat erről a lépésről. Ez nem ad engedélyt arra, hogy az embereket kitettségben hagyjuk, miközben egy érintetlen kísérletet őrzünk. Láthatóvá teszi a kompromisszumot. Hárítsa el a kockázatot, őrizze meg a releváns állapotot, rögzítse a beavatkozást, és kerülje el, hogy a vizsgálat emlékezetből végzett rekonstrukcióvá váljon.

Egy hasznos incidensnyilvántartásnak több rétege van. Ott van a bejelentett észrevétel, amely hiányos vagy vitatott lehet. Ott van a technikai és működési környezet, beleértve a releváns verziót, útvonalat, állapotot és kapcsolódó rendszereket. Ott van a hatás és a bizonytalanság értékelése. Vannak elszigetelési lépések, beleértve azt, hogy ki tette meg őket, és mit változtattak. Ott van a vizsgálat, amelynek meg kell különböztetnie a bizonyítékot a hipotézistől. Aztán ott van a korrekciós intézkedésről szóló döntés és az a nyomon követés, amely ellenőrzi, hogy működött-e. Ha ezeket a rétegeket összekeverjük, egy korai jelentés végleges következtetésnek tűnhet, vagy egy későbbi következtetés ugyanolyan biztosnak tűnhet, mint az első riasztás.

A kommunikáció a karbantartás része, nem díszítő epilógus. Azoknak, akiket egy megszakítás vagy jelentős fenyegetés érint, gyakorlati megoldásra lehet szükségük. Az üzemeltetőknek tudniuk kell, hogy leállítsák-e a munkát, korlátokkal folytassák-e, vagy tartalék megoldást használjanak. A vezetésnek világos képre van szüksége a hatásról, a bizonytalanságról és a döntési jogkörökről. Egy szabályozó hatóság számára meghatározott jelentésre lehet szükség. A beszállítóknak esetleg egy interfészt vagy függőséget kell kivizsgálniuk. Az üzeneteknek nem kell azonosaknak lenniük, de ugyanazon a ténybeli magon kell osztozniuk. Az a szervezet, amely összeegyeztethetetlen beszámolókat ad a csapatainak, nem gondos. Ő gyártja a következő incidenst.

Nem kell drámai leállást kitalálni ennek megértéséhez. Vegyünk egy egyértelműen jelölt hipotetikus esetet: egy felülvizsgáló csapat váratlan javítások halmazát látja, miután egy új forrásformátum kerül egy egyébként ismert munkafolyamatba. Az első kérdés nem az, hogy a modell „elszabadult-e”, egy kifejezés, amelyet több másik kifejezéssel együtt a kukába lehet dobni. A kérdés az, hogy mi változott. A forrásformátum módosítja-e a bemenetet. A lekérési útvonal nem megfelelő anyagot tesz-e elérhetővé. Elmozdult-e egy szabályzatfeltétel. Az interfész miatt a felülvizsgálók kihagynak-e kontextust. Az érintett eseteket elég gyorsan javítják-e. A válasz lehet egy útvonal szüneteltetése, egy konfiguráció visszaállítása, validáció hozzáadása, útmutatás felülvizsgálata, vagy annak megállapítása, hogy a forrást soha nem lett volna szabad beengedni. A hipotetikus eset lényege nem a cselekmény. Hanem az, hogy egy felkészült folyamat megakadályozza, hogy a szervezet az első órában találgatva vergődjön át.

Egy incidens után a karbantartási ütemtervnek többre kell rákérdeznie, mint hogy a látható hiba megjavult-e. Működött-e a detektáló jelzés. A megfelelő személy kapta-e meg. Volt-e felhatalmazása. A napló megőrizte-e a releváns kontextust. Használható volt-e az eszkalációs útvonal. A nyilvános vagy ügyfél felé irányuló üzenet egyezett-e azzal, ami ismert volt. Egy döntés új monitorozási követelményt teremtett-e. Egy képzési vagy dokumentációs hiányosság súlyosbította-e az eseményt. A válaszok egy elszigetelt megszakításból a működési modell változásává alakítják az incidenst.

A változáshoz második óra kell

Minden rendszernek van egy technikai órája. A verziók épülnek, telepítésre kerülnek, visszagörgetik és lecserélik őket. Az irányításnak szüksége van egy második órára: arra az ütemtervre, amely újraértékeli, hogy a bizonyíték, a cél és a felhatalmazás még mindig megfelelő-e. Ezek az órák néha együtt járnak, néha nem. Ha ugyanannak kezeljük őket, az megbízható módja annak, hogy fontos változásokat hagyjunk figyelmen kívül.

Egy technikai változás kicsi lehet, és mégis számíthat. Egy új lekérési gyűjtemény megváltoztathatja a válaszokban használt forrásokat. Egy módosított prompt vagy szabályzati szabály megváltoztathatja azon esetek halmazát, amelyeket egy rendszer elutasít. Egy konfigurációs frissítés megváltoztathatja, hogy hová utaznak az adatok. Egy függőség új verziója megváltoztathatja a késleltetést, a naplózást vagy az elérhető biztonsági vezérlőket. A megfelelő válasz a rendszertől és annak következményétől függ. A karbantartási ütemtervnek nem szabad előre minden változást lényegesnek nyilvánítania. Lehetőséget kell biztosítania annak eldöntésére, hogy mi igényel tesztelést, új jóváhagyást, nyilvános bejelentést, kockázat-újraértékelést, új rögzített állapotot, vagy egyszerűen csak egy feljegyzést.

Fordítva, egy irányítási változás kódtelepítés nélkül is bekövetkezhet. Egy szolgáltatást új részleg használhat. Egy beszerzési szerződés új feldolgozót adhat hozzá. Egy jogi értelmezés megváltoztathatja egy munkafolyamat feltételeit. Egy útvonal átkerülhet a belső kísérletezésből a külső hozzáférésbe. Egy meglévő kimenet elkezdheti befolyásolni egy döntést lejjebb a láncban. A technikai csapat nem lát kiadást. Az érintett emberek egy nagyon más rendszert látnak. A karbantartási ütemtervnek mindkét órát észre kell vennie.

A DORA gyakorlatias osztályozási szabályt alkalmaz: minden jelentős változás esetén kockázatértékelést kell végezni a hálózati és információs rendszerek infrastruktúráján, folyamatain vagy eljárásain, amelyek a támogatott funkciókat vagy eszközöket érintik. Emellett előírja, hogy a leltárakat időszakosan, valamint minden jelentős változás alkalmával frissíteni kell. Az MI-munkában a „jelentős változás” kifejezést nem szabad magától értetődőnek tekinteni. A csapatoknak előre meg kell határozniuk a szempontjaikat. Beletartozik a rendeltetési cél megváltozása, új adatforrás, új modellállapot, új eszközengedély, új célcsoport, módosított emberi felülbírálati útvonal, megváltozott magyarázat vagy új külső függőség? A válasz változó. A válasz hiánya önmagában is kockázat.

A változásrögzítés nem a nyilvánosságnak szánt változásnapló. Ez egy érvelés, amely összeköti a kiinduló állapotot, az okot, az értékelést, a döntést, a megvalósítást és az ellenőrzést. Egyes változások esetén a nyilvános verzió rövid lehet: egy releváns szabályzat vagy felhasználókat érintő korlát megváltozott, meghatározott dátumtól hatályos, a különbségre mutató hivatkozással. A belső bizonyítékokhoz a rögzítés több részletet tartalmazhat az értékelésről, a hozzáférés-vezérlésről, az incidens kontextusáról vagy a szállítói információkról. A lényeg az, hogy mindkét réteg ugyanarra a döntésre mutasson, ne pedig külön történetekké váljon.

A verzióazonosság különösen fontos, ha egy rendszer idővel alkalmazkodik. Egy stabil terméknév nem mindig azonosítja azt az állapotot, amely egy adott kimenetet létrehozott. De ha minden átmeneti állapothoz állandó verziószámot próbálunk rendelni, az egy másfajta fikciót eredményezhet. Jobb megközelítés, ha megkülönböztetjük a tartós modell- vagy szolgáltatásazonosságot a rögzített állapottól, konfigurációtól és bizonyítéktól, amely egy meghatározott felülvizsgálathoz vagy visszajátszáshoz szükséges. A rögzítés így azt mondja meg, mit vizsgáltak meg, anélkül hogy azt sugallná, hogy minden örökre rögzítve lett.

A változás ellenőrzése az a pont, ahol sok rögzítés túlzottan optimistává válik. Egy szervezet jóváhagyta a javítást, így az incidens lezárva. De a megvalósítás nem ellenőrzés. Működött-e az új védelem valós körülmények között? Okozott-e más problémát? Működött-e a tartalék megoldás? Megkapták-e az emberi felülvizsgálók a módosított útmutatást? A releváns mérőszám a kívánt irányba mozdult-e el? A magyarázat még mindig egyezik-e a szolgáltatással? Az ellenőrzés megmutathatja, hogy egy változást vissza kell vonni, finomítani kell, vagy új korlátozással a helyén kell hagyni. Az ellenőrzésnek szabad kényelmetlennek lennie. Ez a feladatának része.

Az ütemezés rendszeres ritmust ad ennek a munkának. Egyes rögzítéseket kiváltó esemény után vizsgálnak felül. Másoknak rögzített dátumra van szükségük, mert a kiváltó eseményre való várakozás azt feltételezi, hogy a szervezet mindig felismeri a kiváltó eseményt. A rendeltetési nyilatkozat felülvizsgálatára szükség lehet a használat megváltozásakor és tervezett időközönként. Egy értékelés lejárhat egy verzió, adatútvonal vagy környezet megváltozása után. Egy incidens tervnek lehet próba dátuma, mert egy soha nem használt terv lehet tökéletesen megírt és gyakorlatilag képzeletbeli. Egy kilépési útvonalat tesztelni kell, mielőtt sürgősen szükség lenne rá. A dátum nem garantálja a gondosságot. De megkönnyíti a hanyagság észlelését.

A rögzítések az archívumban maradhatnak, miközben elveszítik azt a jogosultságukat, hogy egy aktuális döntést támasszanak alá. A felülvizsgálati dátum teszi láthatóvá ezt a különbséget.

A lejárat nem kudarc

A csapatok gyakran ellenállnak a lejárati dátumoknak, mert a lejárat vádaskodásnak hangzik. Pedig nem az. Ez a hatókörről szóló kijelentés. Egy kalibrációs eredmény érvényes lehet a tesztelt modellállapotra és bemeneti feltételekre. Egy adatvédelmi hatásvizsgálat alapos lehet az általa leírt feldolgozási útvonalra nézve. Egy beszállítói megbízhatósági igazolás jelentőséggel bírhat egy adott szolgáltatásverzióra és szerződésre. Egy képzési program megfelelő lehet azokra a munkafeladatokra, amelyeket a résztvevők az elvégzésekor végeztek. Egyik dokumentum sem válik rosszá, amikor a körülményei megváltoznak. Egyszerűen hiányossá válik egy új döntés szempontjából.

Ez az egyik oka annak, hogy az éves felülvizsgálat egyszerre hasznos és elégtelen. Az éves dátum minimális ritmust biztosít, és megakadályozza, hogy a dokumentumok határozatlan időre eltűnjenek egy megosztott meghajtón. De egy jelentős változás akár holnap is bekövetkezhet. A DORA mindkét elképzelést ötvözi: legalább évente rendszeres felülvizsgálatot, valamint minden jelentős változásnál kockázatértékelést ír elő. A két óra együtt működik: az időszakos felülvizsgálat észleli a lassú eltérést; az eseményvezérelt felülvizsgálat pedig azt a feltételt, amely már megváltoztatta a döntést.

A lejáratot állításokhoz kell kötni, nem csak dokumentumokhoz. Egy dokumentum több, eltérő élettartamú állítást is tartalmazhat. Egy architektúraábra nagyrészt pontos maradhat, miközben egy biztonsági kontroll leírása már megváltozott. Egy értékelés továbbra is alátámaszthat egy szűk képességet, miközben már nem támasztja alá egy tágabb teljesítményre vonatkozó állítást. Egy szabályzat aktuális lehet, miközben a megnevezett felelős már nem az. Amikor a csapat a teljes fájlt aktuálisnak vagy elavultnak jelöli, ezek a megkülönböztetések elvesznek. Az állítás szintű karbantartás több munkát igényel. Ugyanakkor lehetőséget ad a felülvizsgálóknak, hogy frissítsék azt, ami megváltozott, anélkül hogy átírná a történetet.

Ennek van egy emberi oldala is. Azoknak, akik egy rendszert örökölnek, tudniuk kell, mire támaszkodhatnak. Egy dokumentum, amely dátum, hatókör és felelős nélkül azt mondja, hogy „aktuális”, egy dokumentációnak álcázott bizalomproblémát ad át. Egy dokumentum, amely azt mondja, hogy „erre a célra értékelve, ezzel a rögzített állapottal, ilyen feltételek mellett, ezen a napon felülvizsgálva, a következő felülvizsgálat itt esedékes”, olyasmit ad, amit meg lehet vizsgálni és meg lehet kérdőjelezni. Nem teszi biztonságossá a rendszert kinyilatkoztatás útján. Láthatóvá teszi a meglévő tudás határát.

A lejárat a kivezetést is kevésbé drámaivá teszi. Egy rendszernek nem kell botránynak lennie ahhoz, hogy kivonják vagy lecseréljék. Egy beszállító megszüntetheti a támogatást. Egy modell már nem illeszkedhet egy új nyelvi vagy szakpolitikai környezethez. A bizonyítékterhelés meghaladhatja egy régi útvonal karbantartásának értékét. Létezhet biztonságosabb alternatíva. A szervezet dönthet úgy, hogy a feladatnak vissza kell kerülnie egy személyhez vagy egy egyszerűbb, nem mesterséges intelligencián alapuló mechanizmushoz. A karbantartási ütemtervnek tartalmaznia kell egy kilépési útvonalat, mielőtt a szolgáltatás eltávolítása nehézzé válna. A kivonás kormányzási aktus, nem pedig annak bizonyítéka, hogy a kormányzás kudarcot vallott.

Ami nem járhat le, az a történet. A szervezetnek meg kell őriznie, amit felmértek, eldöntöttek, megváltoztattak és megfigyeltek, a vonatkozó megőrzési, titoktartási és adatvédelmi szabályokra is figyelemmel. A történet megőrzése különbözik attól, hogy a régi bizonyítékot aktuálisként kezeljük. Az egyik a tanulást és az elszámoltathatóságot támogatja. A másik egy örökölt dokumentumot hamis biztosítékká változtathat. A jó archívumok emlékeznek a különbségre.

Az ütemterv a hatáskör elosztása

A leghasznosabb kormányzási eszköz talán kevésbé izgalmas, mint egy kockázati mátrix: egy naptár, mellette nevekkel. Ki vizsgálja felül a célt. Ki olvassa a monitoringjelet. Ki jelentheti ki, hogy egy küszöbérték elérésre került. Ki függesztheti fel az útvonalat. Ki hagyja jóvá a jelentős változást. Ki ellenőrzi a verifikációs bizonyítékot. Ki kommunikál a beszállítóval. Ki dönti el, hogy egy régi értékelés már nem támasztja alá a további használatot. Ha mindezekre a válasz „az AI-csapat”, akkor a szervezet nem osztotta el a hatáskört. Csupán megnevezett egy helyiséget.

Az illetékes szervnek kellő függetlenségre van szüksége ahhoz, hogy döntései valódiak legyenek, és kellő közelségre ahhoz, hogy cselekedni tudjon. Egy felügyelőbizottság vagy vezető testület viselheti a felügyelet és az erőforrások felelősségét. Egy operatív felelős értheti a tényleges munkát. Egy műszaki felelős ismerheti a rendszer korlátait. Egy biztonsági vagy adatvédelmi szakértő olyan határt azonosíthat, amelyet mások nem látnak. Egy ügyfélkapcsolati vagy közszolgálati csapat hamarabb észlelheti a kárt, mint egy irányítópult. Ezeket a szerepköröket nem kell egyetlen mindenható személybe sűríteni. Meghatározott átadási pontokra és a nézeteltérések feloldásának módjára van szükségük. A NIS2 hangsúlya a vezetői jóváhagyáson és felügyeleten itt hasznos, mert elutasítja azt a kényelmes fikciót, hogy az irányítás teljesen delegálható, miközben a felelősség a csúcson marad.

Az eszkalációs küszöböt olyan nyelven kell megfogalmazni, amely egy döntéshez illik. Az „eszkalálj, ha az anomáliapontszám meghaladja a 0,8-at” technikailag szükséges lehet, de nem mondja meg egy intézménynek, hogy mi forog kockán. Egy jobb küszöb ötvözheti a jelet és a következményt: eszkalálni kell, ha a rendszer a bejelentett felhasználási körön kívüli használatot kezd érinteni; ha egy kontrollhiba miatt egy érintett személy felülvizsgálat nélkül maradhat; ha egy lényeges forrás vagy függőség megváltozik; ha a korrekciók olyan mintázatot mutatnak, amelyet a meglévő értékelés nem fedett le; ha súlyos biztonsági, biztonságvédelmi vagy jogi aggályt jelentenek; ha egy szükséges felelős vagy tartalék már nem elérhető. A pontos küszöbértékek változhatnak. A döntés nyelvezete nem.

A karbantartásnak is költségvetésre van szüksége. Ez hétköznapi és döntő jelentőségű. A megfigyelés időt emészt fel. Egy változtatás felülvizsgálata műszaki, jogi és operatív kapacitást igényel. Egy incidensterv gyakorlása megzavarja a mindennapi munkát. Egy magyarázat, nyilvántartás vagy képzési program frissítése munka. Ha az irányításnak nincs személyzettel ellátott működési modellje, akkor vészhelyzeti adóvá válik, amelyet az fizet meg, aki először észleli a problémát. Ez a berendezkedés addig tűnik gazdaságosnak, amíg be nem következik az első nehéz esemény, amikor a szervezet rájön, hogy megspórolta a felkészülés költségét, és megvásárolta az improvizáció költségét.

Van hely az arányosságnak. Egy szűk körű belső eszköz, amelynek egyértelműen nincs következményes felhasználása, könnyebb ütemtervet igényelhet, mint egy olyan rendszer, amely a munkához, szolgáltatásokhoz, jogokhoz vagy biztonsághoz való hozzáférést érinti. De a könnyebb nem jelent hiányt. Továbbra is szükség lehet felelősre, célhatárra, változásnaplóra, alapvető incidensútvonalra és kilépési feltételre. A komplexitásnak a következményt és a bizonytalanságot kell követnie, nem pedig a projektindításkor rendelkezésre álló lelkesedés mértékét.

Egy hasznos karbantartási ütemterv egyszerű nyelven is megfogalmazható. Vizsgálja felül a célt, ha a felhasználás, a felhasználók vagy a következmények változnak. Vizsgálja felül a függőségeket, ha egy szállító, adatútvonal vagy kapcsolódó szolgáltatás változik. Vizsgálja felül az értékelési bizonyítékokat, ha a modell, a konfiguráció vagy a releváns működési feltételek változnak. Gyakorolja az incidens- és leállítási útvonalat meghatározott időközönként. Vizsgálja felül a szerepköröket, ha a szervezet változik. Tegyen közzé vagy őrizzen meg változásnaplót, ha egy döntésnek érdemi hatása van. Tesztelje a kilépési útvonalat, mielőtt a szolgáltatás attól függővé válna. Egyik sem ígéri, hogy nem történnek hibák. Azt ígéri, hogy a szervezetnek van módja észrevenni, eldönteni és tanulni belőlük, amikor megtörténnek.

Egy rövid megjegyzés tőlünk

A Dweve-nél a Trust Centre a megfigyelést külön nyilvános nyilvántartásként írja le, nem pedig ígéretként arra, hogy egy termék végleges kész állapotot ért el. Közzétett megfigyelési anyaga szerint a jelek a bejelentett gyűjtési határokhoz kötődnek, a felülvizsgálatok azonosítják a releváns modellt, útvonalat, állapotot és bizonyítékot, és az érdemi változások értékelési, kockázati, incidens- vagy kiadási felülvizsgálatot nyithatnak. A nyilvános változásnapló megkülönbözteti a jelenlegi tényeket az előkészített kontrolloktól és jövőbeli eseményektől. Ezek a bejelentett működési kialakításunk leírásai, nem pedig független biztosíték, ügyfél-eredmény vagy arra vonatkozó állítás, hogy egy nyilvános oldal minden irányítási kérdést eldönt.

Ez a határ szándékos. Úgy gondoljuk, hogy egy megfigyelési nyilvántartás akkor hasznos, ha elmondja az olvasóknak, hogy mi figyelhető meg, mi marad védett, mi válthat ki intézkedést, és hol kerül rögzítésre egy lényeges döntés. A nyilvántartás nem hozhat ítéletet a rendszert üzemeltető emberek nevében. Megkönnyítheti az ítélet ellenőrzését, amikor az megszületik.

A karbantartás az őszinte rész

A bevezetés hasznos pillanat. Okot ad arra, hogy meghatározzuk a célt, felmérjük a kockázatokat és vállalásokat tegyünk. Nem az a pillanat, amikor a technológia megszűnik megfelelni a világnak. Az irányítás ezt követően válik hitelessé, az ismétlődő munkában, amely során kiderül, hogy a régi döntés még mindig megállja-e a helyét.

Ehhez a munkához naptárra van szükség, mert a jó szándék félideje rövid, ha nincs hozzá dátum, felelős és út az intézkedéshez. Bizonyítékra van szükség, mert egy műszerfal színe nem magyarázat. Felhatalmazásra van szükség, mert a megfigyelés a változtatás joga nélkül csak megfigyelés jó arculattal. Történetre van szükség, mert a nyomon nem követhető korrekció nem javítja megbízhatóan a következő döntést. És kilépési lehetőségre van szükség, mert a működés folytatásának választásnak kell maradnia, nem örökölt ténynek.

Az érett kérdés nem az, hogy egy szervezet képes-e irányítási keretrendszert létrehozni. Sokak képesek erre. A kérdés az, hogy hónapokkal a dokumentum jóváhagyása után a szervezet még mindig meg tudja-e mondani, hogy mire való a rendszer, mi változott, milyen bizonyíték támasztja alá most, ki állíthatja le, és mi történik, ha a válasz már nem egyértelmű. Ha igen, az irányítást karbantartják. Ha nem, a szervezetnek lehet, hogy még van politikája. Csak már nincs élő politikája.

Források