Egy közszolgáltatás nem ruházhatja át a döntési felelősségét
A szerződés nem döntés
Egy közintézmény vásárolhat szoftvert. Vásárolhat tárhelyet, elemzést, ajánlást, munkafolyamatot, fordítást, rangsorolást vagy jelentést. Amit nem vásárolhat meg, az az, hogy ne annak a közintézménynek kelljen eljárnia, amelyik ő. A szerződés átruházhat munkát egy szállítóra, de nem ruházza át az intézmény közcélját, jogi felhatalmazását, indokolási kötelezettségét vagy jogorvoslati kötelezettségét. Ezek a döntést követik, nem a számlát.
Ez addig nyilvánvalónak hangzik, amíg a közbeszerzési nyelv egy ítéletet szállítmánnyá nem alakít. Egy tender kockázati pontszámot kér. Egy szállító kockázati pontszámot szállít. Egy szerződés tanácsadó jellegűnek nevezi az eredményt. Egy szolgáltatás csendben megváltoztatja a sorát, a figyelmét vagy a küszöbértékét, mert a pontszám kényelmes. Mire egy embert érint a dolog, mindenki más dokumentumra mutathat. A szállító a specifikációra mutat. A közbeszerzési csapat az odaítélésre mutat. Az üzemeltető a képernyőre mutat. Az intézmény a szerződésre mutat. Az ember, akinek válaszra van szüksége, egy mutogató körrel és felelős kéz nélkül marad.
A közfeladat-ellátás mindig is járt delegálással. Egy önkormányzat megrendelhet egy ellenőrzést, egy minisztérium vásárolhat ügykezelő rendszert, egy kórház pedig beszerezhet egy időbeosztó szolgáltatást. A delegálás nem a probléma. A probléma akkor kezdődik, amikor a delegált összetevőnek megengedik, hogy döntést hordozzon a felhatalmazás, a bizonyíték és a felülvizsgálat nélkül, amelyek a döntést jogszerűvé teszik. Egy eszköz kiváló lehet egy feladatban, és mégis rossz hely lehet egy közérdekű ítélet számára. A közbeszerzésnek meg kell őriznie ezt a megkülönböztetést, mielőtt a szállító szókincse a szervezet működési modelljévé válna.
Az európai közbeszerzési hagyomány már tartalmazza a helyes ösztönt. Az ajánlatkérő hatóságoknak átláthatóan, arányosan, megkülönböztetés nélkül és a verseny mesterséges szűkítése nélkül kell eljárniuk. Ez nem csak tisztességes módja egy tender lebonyolításának. Ez egy emlékeztető arra, hogy a hatóság látható marad a vásárláson belül. A közintézmény célt választ, szükségletet határoz meg, feltételeket szab, és vállalja a következményeket. Egy okos rendszer nem tünteti el ezeket a választásokat. Csak drágább felületet ad nekik.
Az ítélet nem ugyanaz, mint a kimenet
A technikai rendszerek kimeneteket állítanak elő. A közintézmények döntéseket hoznak. A kettő egymás mellett állhat, de nem felcserélhető. Egy osztályozó kategóriát rendelhet hozzá. Egy keresőrendszer dokumentumokat tölthet le. Egy nyelvi modell levelet fogalmazhat. Egy optimalizáló útvonalat találhat a korlátok között. Egyik ige sem tartalmazza önmagában azt a jogi vagy polgári kérdést, hogy mi történjen egy emberrel.
Az ítélet akkor lép be, amikor egy intézmény eldönti, hogy egy kimenet releváns, elegendő és felhatalmazott egy adott cselekvéshez. Akkor lép be, amikor versengő érdekeket mérlegelnek, amikor kivételt vizsgálnak, amikor egy szabályt kontextusban értelmeznek, amikor egy embert meghallgatnak, amikor késedelmet fogadnak el, amikor hibát javítanak, és amikor indokot adnak. Egy modell hozzájárulhat információval ezekhez a pillanatokhoz. Nem szerez közhatalmat azzal, hogy pontos, gyors vagy magabiztosan előadott.
A megkülönböztetés azért fontos, mert a közbeszerzés gyakran képességnyelven írja le a rendszereket. A szállító észlel, értékel, rangsorol, ajánl vagy automatizál. A képességnyelv hasznos a piac megtalálásához. Nem elegendő a felelősség kijelöléséhez. A tendernek meg kell mondania, hogy melyik emberi vagy intézményi szerep alakítja a képességet cselekvéssé, mely bizonyítékot kell megvizsgálnia annak a szerepnek, mely cselekvések tilosak, és hogyan támadhatja meg az érintett személy az eredményt.
Ez az átmenet a képességből a felhatalmazásba a beszerzés első komoly aktusa. Enélkül a vevő nem szolgáltatást vásárol, hanem egy rést vásárol a saját felelősségi körének leírásában. A réseket könnyű figyelmen kívül hagyni, amíg egy projektet ünnepelnek. Meglepően szilárdakká válnak, amikor valaki megkérdezi, miért született egy döntés.
Kezdje a közérdeknél
A felelős beszerzés a közérdekből indul ki, nem pedig egy modellkategóriából. A kérdés nem az, hogy egy hatóság vásárolhat-e mesterséges intelligenciarendszert. A kérdés az, hogy melyik közfeladat igényel támogatást, milyen eredményt kell elérnie a feladatnak, kit érint, és mi számítana kudarcnak. A szűk cél lehetővé teszi a későbbi döntéseket. Egy olyan szlogen, mint a hatékonyság javítása, minden lényeges döntést későbbre halaszt, általában egy szállítói bemutatóra.
A célt a szolgáltatás nyelvén kell megfogalmazni. Egy csapatnak lehet, hogy meg kell találnia egy hiányzó információt egy fájlban, továbbítania kell a kérelmeket a megfelelő szakemberhez, le kell fordítania egy közleményt, össze kell foglalnia egy belső jelentést, vagy azonosítania kell azokat az eseteket, amelyek figyelmet igényelnek. Ezek különböző feladatok, különböző következményekkel. Egy tervezetet el lehet utasítani. Egy továbbítás késleltethet egy embert. Egy fordítás megváltoztathatja a hozzáférést. Egy rangsorolás megváltoztathatja, hogy ki kapja meg a szűkös időt. Egyetlen szó, az automatizálás, a közhatalom egész térképét rejti magában.
A célmeghatározásnak azt is ki kell mondania, hogy mit nem tehet a rendszer. Segíthet az ügyintézőnek, de nem döntheti el a jogosultságot. Javasolhat sorrendet, de nem zárhat ki senkit a szolgáltatásból. Felszínre hozhat dokumentumokat, de nem döntheti el, hogy melyik bizonyíték releváns jogilag. Előkészíthet egy közleményt, de nem küldheti el a név szerinti jóváhagyás nélkül. A negatív tér nem fogalmazási luxus. Ez az, ahogyan egy határ túléli a zsúfolt keddet.
Van egy gyakorlati ok a szigorúságra. Egy rendszer használata a kényelem révén terjed. Amint egy eszköz elérhetővé válik, a következő csapat megkérdezi, hogy kezelheti-e a szomszédos feladatot is. Az eredeti cél elég közelinek hangzik. Új mezőt adnak hozzá, új adatforrást kapcsolnak be, és egy új embercsoportot érintenek. Ha a kezdeti cél homályos volt, senki sem tudja megmondani, hogy ez apró változás-e vagy új közhatalmi aktus. A beszerzésnek olyan változási kérdést kell teremtenie, amelyre a szervezet választ tud adni, mielőtt az új használat megszokottá válna.
Az európai szabályok megnehezítik a felelősség elrejtését
A 2014/24/EU irányelv ismert közbeszerzési alapértékeket határoz meg: egyenlő bánásmód, hátrányos megkülönböztetés tilalma, átláthatóság és arányosság. Ezek az elvek nem írnak elő egy adott technológiát. Viszont megkövetelik az ajánlatkérő hatóságtól, hogy olyan eljárást alakítson ki, amely megmagyarázható és védhető. Az a követelmény, amelyet csak egy szállító tud teljesíteni valódi működési ok nélkül, kormányzási probléma, nem csupán piaci probléma. Az a követelmény, amelyet nem lehet tesztelni, egy ígéret, amely beszerzési számot visel.
Ugyanezek az elvek érvényesek, ha a megvásárolt dolog egy modell, egy ügynök vagy egy döntéstámogató szolgáltatás. A hatóságnak úgy kell leírnia a szükségletét, hogy az lehetővé tegye a tisztességes versenyt és az értelmes értékelést. Össze kell hasonlítania az ajánlatokat a szolgáltatás szempontjából lényeges kritériumok alapján, nem csak a szállító által preferált benchmark szerint. Meg kell őriznie az odaítélés mögötti bizonyítékokat, és kezelnie kell a szerződést, amikor a valóság eltér az ajánlati felhívástól. Az átláthatóság nem ér véget a nyertes ajánlat bejelentésével. Folytatódik a teljesítésen, a módosításon és a kilépésen keresztül.
Az EU mesterséges intelligenciáról szóló rendelete (AI Act) egy második réteget ad bizonyos nagy kockázatú rendszerekhez. A 14. cikk hatékony emberi felügyeletet követel meg, amely arányos a kockázattal, az autonómia szintjével és a kontextussal, és amely képes az anomáliák észlelésére, a kimenetek értelmezésére, azok figyelmen kívül hagyására vagy megfordítására, valamint a rendszer biztonságos megszakítására. A 27. cikk előírja az érintett köztestületeknek és a közszolgáltatásokat nyújtóknak, hogy a meghatározott nagy kockázatú rendszerek bevezetése előtt értékeljék az alapvető jogokra gyakorolt hatást, és a kontextus változása esetén frissítsék az értékelést. Ezek működési kötelezettségek, nem pedig díszítő szöveg egy szakpolitikai oldalhoz.
Az AI Act nem sorolja minden közbeszerzésű szoftvert ugyanabba a jogi kategóriába. Valami hasznosabbat tesz: megnehezíti a szolgáltató, az üzemeltető, a rendszer és az érintett személy közötti kapcsolat elmosását. A szolgáltatónak le kell írnia a képességeket és a korlátokat. Az üzemeltetőnek megfelelően kell használnia a rendszert, és felelősséget kell vállalnia a használatáért. A közhatóságoknak nyilvántartási és tájékoztatási kötelezettségeik vannak a meghatározott nagy kockázatú rendszerek tekintetében. A pontos jogi alkalmazás a felhasználástól és az érintett rendelkezésektől függ. Az irányítási tanulság állandó: aki a képességet megvásárolja, az birtokolja a kontextust is, amelyben a képesség működik.
A szállító kimenetének otthonra van szüksége
Minden, közösségi munkafolyamatban használt kimenetnek megnevezett gazdája kell legyen. Ez a gazda nem csupán egy adatbázistábla. Ez egy szerepkör, amelynek joga van eldönteni, hogy a kimenet megfelel-e a célnak, milyen bizonyíték támasztja alá, mi történik, ha hibás, és melyik verzió állította elő. Ha egy kimenetnek nincs gazdája, mindenki ügyének fogják tekinteni az első vita bekövetkeztéig, amikor is senki feladatává válik.
A tulajdonjogot meg kell osztani anélkül, hogy széttöredezne. A szolgáltatásgazda ismeri a közcél és az elfogadható kockázatot. Az adatgazda ismeri a forrást, a minőséget, a hozzáférést és a javítási utat. A műszaki gazda ismeri az üzembe helyezést, a biztonságot, a kapacitást és az integrációt. A modell- vagy szállítógazda ismeri az értékelést, a korlátokat és a változásokat. Az operatív felülvizsgáló ismeri a munkát, és megállíthatja az ügy továbbhaladását. Ezek a szerepkörök egy kis csapathoz is tartozhatnak. Nem helyettesíthetők az ember a folyamatban kifejezéssel.
A kimenetet felülvizsgáló személynek időre, információra és felhatalmazásra van szüksége. Ha a felület csak egy pontszámot mutat, a felülvizsgáló nem tudja megvizsgálni annak alapját. Ha a sorban állás lehetetlenné teszi a felülvizsgálatot, a felülvizsgáló nem tud érdemi felügyeletet gyakorolni. Ha egy szabályzat tanácsadó jellegűnek mondja a kimenetet, miközben a munkafolyamat alapértelmezett válaszként kezeli, akkor a felülvizsgálótól aláírást kérnek, nem pedig ítéletet. A jóváhagyás feliratú gomb nem ellenőrzési pont, ha a mögötte álló személy biztonságosan nem választhat mást.
A közbeszerzésnek ezért meg kell kérnie a szállítókat, hogy írják le az átadást. Pontosan mi kerül a rendszerbe. Mi jön ki belőle. Milyen bizonytalanság vagy korlát utazik a kimenettel. Mit láthat az üzemeltető. Mit módosíthat az üzemeltető. Mit tesz a rendszer, ha a bemenet a bejelentett hatókörén kívül esik. Hogyan jelenik meg a leállítási művelet. Mely nyilvántartások bizonyítják, hogy történt felülvizsgálat. Az a szállító, aki meg tudja válaszolni ezeket a kérdéseket, egy működő szolgáltatást ír le. Az a szállító, aki csak teljesítménypontszámmal válaszol, egy összetevőt ír le.
Az első ábra: a felelősség a láncon követi
A pontszám nem indok
A pontszámok azért vonzóak a közbeszerzésben, mert tisztának mutatják az összehasonlítást. Egy szállító beszámolhat pontosságról, válaszidőről, lefedettségről vagy a kézi munka csökkenéséről. A vevő táblázatba rendezheti az értékeket, és úgy érezheti, hogy a döntés objektívvá válik. A mérés értékes. De egy pontszám csak arra a kérdésre válaszol, amelyre tervezték. Nem válik közhatalmi intézkedés indokává pusztán azáltal, hogy tizedesjegyet kap.
Tegyük fel, hogy egy rendszer rangsorolja az eseteket a figyelem szempontjából. A rangsor hasznos lehet, de a közérdekű indok nem egyszerűen az, hogy egy szám magas volt. Az intézménynek tudnia kell, mely jogszerű cél teszi lehetővé a rangsorolást, mely adatokat vették figyelembe, mely eseteket zárnak ki, mit nem lát a rangsor, hogyan tudja a felülvizsgáló korrigálni, és hogyan tudja az érintett megtámadni az eredményt. A pontszám egyetlen jelzés a döntésen belül. Ha ez az egyetlen mondat, amelyet az intézmény fel tud mutatni, az nem az ítélőképesség bizonyítéka. Ez annak a bizonyítéka, hogy az intézmény kiszervezte a magyarázatot.
A benchmark-állításoknak is szerződésre van szükségük. Mely populáción teszteltek. Mely címkéket használtak. Mely nyelveket és szélső eseteket vontak be. Milyen alapvonalhoz hasonlítottak. Hogyan súlyozták a hibákat. Mi történt a hiányzó vagy kétértelmű bemenetekkel. Korrigált-e ember az eredményt a teszt során. Ugyanazon a verzión futtatták-e az értékelést, amelyik élesben fog működni. E részletek nélkül egy benchmark még érdekes lehet, de nem viselheti el a közbeszerzési döntés teljes súlyát.
A közbeszerzőknek olyan formában kell bizonyítékot kérniük, amilyenre a szolgáltatásnak később szüksége lesz. Egy technikai teszt megmutathatja, hogy egy modell elvégez-e egy feladatot. Egy munkafolyamat-teszt megmutathatja, hogy az emberek észlelik-e és korrigálják-e a hibákat. Egy irányítási teszt megmutathatja, hogy egy döntés rekonstruálható-e és megtámadható-e. Egy folytonossági teszt megmutathatja, hogy a hatóság tud-e működni, ha egy szállító elérhetetlenné válik. Ezek a tesztek különböző kérdésekre válaszolnak. Egyetlen szállítói pontszámba vonni őket kényelmes, és általában helytelen.
Az emberi felügyeletnek foga legyen
Az emberi felügyeletet gyakran a rendszerábra megnyugtató utolsó főneveként mutatják be. Egy ember feliratú doboz jelenik meg a modell után és a döntés előtt. Az ábra felelősnek tűnik. A valódi kérdés az, hogy az ember meg tudja-e érteni, meg tudja-e kérdőjelezni és meg tudja-e változtatni a kimenetet azokban a körülmények között, amelyek között a szolgáltatás működik.
Az AI-rendelet 14. cikke szokatlanul konkrét ebben a kérdésben. Azoknak, akiknek felügyeletet kell ellátniuk, érteniük kell a rendszer releváns képességeit és korlátait, figyelemmel kell kísérniük a működését, fel kell ismerniük az automatizálási torzítást, értelmezniük kell a kimenetet, dönteniük kell arról, hogy nem használják vagy felülbírálják, valamint biztonságos eljárás keretében közbe kell tudniuk avatkozni vagy meg kell tudniuk szakítani a folyamatot. Ezek hatáskörök. Ehhez felületre, képzésre, munkateherre, bizonyítékokra, felhatalmazásra és időre van szükség. Olyan szervezetre is szükség van, amely támogatja azt a felülvizsgálót, aki azt mondja, hogy a rendszer hatókörén kívül esik.
A felülvizsgáló nem tud felügyeletet gyakorolni olyan kimenet felett, amelyet megfosztottak a kontextustól. A kimenethez szükség van a releváns forráshivatkozásokra, a bemeneti minőségre vonatkozó figyelmeztetésekre, a verzióra és a célra. A felülvizsgálónak lehetősége kell legyen további bizonyítékot kérni, vagy az esetet megoldatlanként megjelölni. Ha a rendszer egyetlen választ úgy tálal, hogy az alternatívák költségessé válnak, akkor az automatizálási torzítást építi be a folyamatba. Ha a munkafolyamat leállításának egyetlen módja a szállító felhívása, akkor a hatóság olyan rendszert vásárolt, amelyet nem tud biztonságosan üzemeltetni.
A arányosság számít. Egy alacsony kockázatú szövegezési segédeszköznek nem kell ugyanazokkal a kontrollokkal rendelkeznie, mint egy jogosultságot, ellenőrzést vagy ellátáshoz való hozzáférést támogató rendszernek. De az arányos nem jelent szimbolikusat. Minél inkább képes a rendszer jogokat, biztonságot vagy alapvető szolgáltatásokat érinteni, annál inkább tudnia kell a hatóságnak megmutatnia, hogy a felügyelet lehetséges volt, használták, és képes volt megváltoztatni az eredményt. Egy ember, aki jelen van, de nincs hatalma, nem felügyelet. Ő egy kárpitozott felelősségkizáró nyilatkozat.
A megtámadhatóság a szolgáltatás része
Egy közhatalmi döntés nem fejeződik be akkor, amikor egy belső munkafolyamat azt mondja, hogy kész. Akkor tekinthető befejezettnek, ha az érintett személy megérti, mi történt, ki tudja javítani a releváns tényeket, és igénybe tudja venni a rendelkezésre álló felülvizsgálati vagy fellebbezési utat. A megtámadhatóság nem opcionális ügyfélélmény-funkció. Az intézmény és a nyilvánosság közötti kapcsolat része.
A Bizottság GDPR szerinti automatizált döntéshozatali biztosítékokról szóló magyarázata egyszerűen fogalmazza meg az alapvető pontot. Egy személyt nem szabad kizárólag automatizált döntésnek alávetni, amely jogi vagy hasonlóan jelentős hatással jár, kivéve a meghatározott feltételek és biztosítékok mellett. Ahol a biztosítékok érvényesülnek, az embereknek tájékoztatásra, az emberi beavatkozás lehetőségére, valamint arra van szükségük, hogy kifejezzék álláspontjukat és megtámadják a döntést. A pontos jogi út az adatkezeléstől és az alkalmazandó jogtól függ. A működési elv tágabb: az érintett személynek valódi fogódzóra van szüksége a döntéshez, nem pedig egy általános ígéretre, hogy valaki, valahol meg tudja nézni.
Ennek a fogódzónak a bizonyítékokhoz kell kapcsolódnia. Ha egy személy megtámad egy rangsorolást, a hatóságnak képesnek kell lennie visszakeresni a releváns döntési kontextust, nem csupán a jelenlegi modellverziót. Ha egy forrásrekordot később javítottak, a szervezetnek meg kell tudnia különböztetni az eredeti állapotot a javított állapottól, és meg kell mondania, mi változott. Ha egy emberi felülvizsgáló elutasított egy kimenetet, a rekordnak meg kell mutatnia, hogy a rendszer nem hozta meg a végső döntést. A megtámadhatóság rekord nélkül udvarias felkérés a kérdés megismétlésére.
A szállítók segíthetnek lehetővé tenni a megtámadhatóságot. Felfedhetik a verziózott bemeneteket, az indokokat, a forráshivatkozásokat, a felülvizsgálati állapotokat, a javítási eseményeket és az exportformátumokat. Gondoskodhatnak arról, hogy a szolgáltatás szüneteljen, ahelyett hogy csendben folytatódna, ha hiányoznak a bizonyítékok. Nem dönthetik el, hogy a közjog alapján milyen magyarázat jár, vagy milyen jogorvoslatot kell biztosítania egy közhatalmi szervnek. Ezek intézményi döntések. Egy szállító fogódzókat építhet. A hatóságnak kell eldöntenie, hogy a fogódzók hová vezetnek.
Az adathatárok közhatalmi határok
A beszerzési tárgyalások gyakran úgy kezelik az adatokat, mint egy bemenetet, amelyet a szállító kiválasztása után kell csatlakoztatni. Egy közszolgáltatásban az adathatárok egyben hatósági határok is. A forrás határozza meg, hogy a rendszer mit tudhat, mire következtethet, mit őrizhet meg, és mely embereket érintheti egy hiba. Egy szállítónak nem szabad meghatároznia ezeket a határokat azzal, hogy könnyűvé teszi a csatlakozást.
A követelményeknek meg kell nevezniük az engedélyezett forrásokat, a célt, a frissességet, a megőrzést, a hozzáférést, a helyesbítést és a törlést. Különbséget kell tenniük az elsődleges nyilvántartások és a származtatott anyagok között, mint például a beágyazások, összefoglalók, címkék, gyorsítótárak és pontszámok. Meg kell határozniuk, hogy mely adatok hagyják el a hatóságot, mely alvállalkozók kezelhetik azokat, és hogyan kerül rögzítésre a támogatási hozzáférés. Meg kell határozniuk, hogy mi történik, ha egy forrás hiányos, elavult, vitatott vagy kívül esik az eredeti célon.
Ez nem csupán adatvédelmi kérdés. A forrásfegyelem befolyásolja a döntés minőségét és jogszerűségét. Egy közintézmény rendelkezhet sok nyilvántartással, és mégis hiányozhat a jogszerű vagy megbízható alapja azok egy adott munkafolyamatban való felhasználásához. Egy modell találhat olyan összefüggést, amely technikailag hasznos, de intézményileg elfogadhatatlan. Egy lekérdezett dokumentum lehet aktuális, de nem hiteles. A közbeszerzési követelménynek lehetővé kell tennie az üzemeltető számára, hogy megkülönböztesse a rendelkezésre álló információt a megalapozott információtól.
Ugyanez a fegyelem segíti a szállítót is. A világos forráshatárok csökkentik a kísértést, hogy azt ígérjék, egy általános modell minden kérdésre választ tud adni. Reprodukálhatóvá teszik az értékeléseket. Meghatározzák, mit tegyen a szolgáltatás, ha egy bemenet kívül esik a szerződésen. Egy rendszer, amely ki tudja mondani, hogy elégtelen a bizonyíték, gyakran hasznosabb, mint az, amely mindig tud választ adni. A közbeszerzőknek jutalmazniuk kell ezt a viselkedést, nem pedig hibaként kezelniük a visszautasítást a bemutató során.
A követelményeknek le kell írniuk a hibát
A legtöbb pályázat a kívánt utat írja le: adat fogadása, feldolgozás, eredmény visszaadása, teljesítmény mérése. A közszolgáltatásoknak a nem kívánt utakra is szükségük van. Hiányzik egy nyilvántartás. Egy nyelv nem támogatott. A modell megváltozik. Egy forrás ütközik egy szabállyal. Egy szállító elérhetetlen. Egy értékelő nem ért egyet. Egy személy fellebbez. A kimenetet az eredeti céltól eltérően használják. Egy érintett helyesbítést kér. Egy incidensre hónapokkal a döntés után derül fény.
A hiba-követelményeknek tesztelhetőknek kell lenniük. A rendszernek meg kell állnia, ha egy kötelező mező hiányzik. Azonosítania kell a javaslat mögött álló verziót és forráskört. Biztonságos leállítási eljárást kell biztosítania. A nyilvántartásokat dokumentált formátumban kell exportálnia. Értesítenie kell a hatóságot a lényeges változásokról. Támogatnia kell a származtatott artefaktumok helyesbítési útját. Elegendő kontextust kell megőriznie egy engedélyezett vizsgálathoz. Nem helyettesítheti csendben egy másik modellel vagy forrásosztállyal, ha a megadott nem érhető el.
Ezek a követelmények nem arra tett kísérletek, hogy minden rossz napot előre jelezzenek. Arra szolgálnak, hogy a szolgáltatás biztonsági magatartása láthatóvá váljon. A szállító javasolhat eltérő megvalósítást, de a hatóság a megfigyelhető viselkedés alapján összehasonlíthatja a javaslatokat. A pályázat kevésbé szól a funkciók listájáról, és inkább arról, hogy a szolgáltatás képes-e felelősséget viselni nyomás alatt.
A hibanyelv a kereskedelmi párbeszédet is javítja. Egy szállító, amely nem tud biztonságos leállítást, megbízható exportot vagy verzió-értesítést kínálni, még alkalmas lehet egy alacsony kockázatú feladatra. A hatóság ezt nyíltan eldöntheti. Nem kell a szerződés aláírása után felfedeznie a korlátot. Senkinek nincs szüksége olyan pályázatra, amely technikailag izgalmas, de működés közben kísérteties.
A szerződés egy működési terv
A mesterséges intelligenciával támogatott közszolgáltatás szerződésének többet kell leírnia, mint az üzemidőt és a támogatási órákat. Le kell írnia a bizonyítékot, a változást, a hozzáférést, a felülvizsgálatot, az incidenskezelést és a kilépést. Ezek a feltételek alakítják, hogy a hatóság mit tudhat és mit tehet a szolgáltatás megkezdése után. Az architektúra részét képezik, még akkor is, ha jogi mellékletekben jelennek meg.
A változáskontroll központi jelentőségű. Az, hogy mi számít lényeges modell-, prompt-, adat-, lekérdezési vagy szabályzatváltozásnak. Mennyi előzetes értesítés szükséges. Mely értékeléseket kell újrafuttatni. Ki fogadhatja el a változást. Mi történik, ha a teljesítmény egy alcsoport vagy nyelv esetében eltolódik. Elhalaszthatja-e a hatóság a frissítést. Visszagörgetheti-e. A szállítónak szüksége lehet rugalmasságra a szolgáltatás fenntartásához, de a rugalmasság nyilvántartás nélkül nem más, mint agilitásnak álcázott kockázatáthárítás.
A hozzáférési feltételeknek többre kell kiterjedniük, mint az irányítópultokra. A hatóságnak szüksége lehet naplókra, konfigurációra, tesztelési artefaktumokra, forrásazonosítókra, támogatási nyilvántartásokra és a változások előzményeire. A hozzáférésnek arányosnak és biztonságosnak kell lennie, a személyes adatok védelmével és a titkok elkülönítésével. A cél nem az, hogy minden belső megvalósítási részletet megköveteljünk. Hanem az, hogy a hatóság ellenőrizni tudja, mit tett a szolgáltatás abban a kontextusban, amelyben használta.
Az incidensfeltételeknek megnevezett útvonalakat és a rendszer következményeihez igazodó időkereteket kell tartalmazniuk. Meg kell határozniuk, ki nyilváníthat incidenst, ki függesztheti fel a munkafolyamatot, milyen bizonyítékokat őriznek meg, hogyan veszik figyelembe az érintetteket, és hogyan ellenőrzik a helyreállítást. Az a szolgáltatás, amely csak infrastrukturális leállásokról számol be, nem azokat az incidenseket jelenti, amelyek megmagyarázásában egy közintézménynek a legnagyobb valószínűséggel segítségre van szüksége.
A szállítói elszámoltathatóság valós, de más jellegű
Tévedés azt állítani, hogy a szállítónak nincs felelőssége. A szolgáltatók rendszereket terveznek, állításokat tesznek, korlátokat határoznak meg, frissítéseket kezelnek, alvállalkozókat választanak, és a bizonyítékok egy részét ellenőrzik. A közhatóságnak számon kell kérnie rajtuk ezeket a vállalásokat. A szállító technikai és szerződéses elszámoltathatósága számít, különösen akkor, ha a hatóság nem tud minden összetevőt önállóan reprodukálni.
Ugyanilyen tévedés a szállítói elszámoltathatóságot az intézményi felelősség helyettesítőjévé tenni. A szállító nem választotta meg a közcélokat, nem határozta meg az érintett csoportot, nem döntötte el, hogy egy kimenet elegendő-e a szolgáltatáshoz, nem állapította meg a fellebbezési utat, és nem döntötte el, mely kockázatot fogadja el a nyilvánosság. Ezek a döntések a hatóságra és az azt körülvevő jogi keretre tartoznak. Az a közintézmény, amely azt mondja, hogy a modell döntött, leírja saját kudarcát abban, hogy a döntést közösségi kézben tartsa.
A hasznos kapcsolat a kifejezett kölcsönös függőség. A szolgáltató egy összetevőt vagy szolgáltatást nyújt dokumentált feltételek mellett. Az üzemeltető egy célba, folyamatba és szerepstruktúrába integrálja azt. Mindkét fél megőrzi az általa ellenőrzött rész bizonyítékait. A hatóságnak megmarad a képessége, hogy megkérdőjelezze a szolgáltatót, felfüggessze a használatot, és megmagyarázza a közösségi intézkedést. Ha a szállító kialakítása lehetetlenné teszi ezeket a képességeket, maga a beszerzési döntés válik a kockázat részévé.
A jó szerződések nem követelik meg a szállítótól, hogy minden ismeretlen felelősséget vállaljon. Feladatokat osztanak ki úgy, hogy mindkét fél teljesíteni tudja azokat. A hatóságnak jogszerű és megfelelő kontextust kell biztosítania. A szállítónak fel kell tárnia a korlátokat és a változásokat. Az üzemeltetőnek a hatókörön belül kell használnia a rendszert. A felülvizsgálónak valódi hatalommal kell rendelkeznie. A nyilvántartásoknak túl kell élniük a vitát. A szerepek pontos meghatározása kíméletesebb, mint egy olyan záradék, amely szerint a felek együttműködnek, és reméli, hogy mindenki ugyanazt a szótárt hozza magával.
A hordozhatóság ítélőképességet igénylő követelmény
A kilépést gyakran üzleti kérdésként kezelik. A közszolgáltatások esetében ez ítélőképességet igénylő kérdés is. Ha a hatóság nem tudja visszaszerezni a szolgáltatás folytatásához vagy múltjának vizsgálatához szükséges bizonyítékokat, konfigurációt, nyilvántartásokat és döntéseket, akkor nem tudja teljes mértékben birtokolni a szolgáltatáson keresztül hozott döntéseket. Egy rendszer, amely nem tud távozni, magával viszi az intézmény emlékezetének egy részét.
A hordozhatóságnak a működési állapotra is ki kell terjednie, nem csak az adatbázisban tárolt rekordokra. A hatóságnak szüksége lehet bemeneti és kimeneti rekordokra, forráshivatkozásokra, modell- és promptverziókra, szabályzati beállításokra, felülvizsgálati döntésekre, auditálási eseményekre, javítási előzményekre, megőrzési metaadatokra és az azokat magyarázó sémákra. A pontos kör a szolgáltatástól függ. Az elv az, hogy egy jövőbeli üzemeltető megértse, mi történt, anélkül hogy visszafejtené a szállító privát irányítópultját.
A kilépést még azelőtt tesztelni kell, hogy sürgőssé válna. Egy rövid próba felfedheti, hogy az export teljes-e, az azonosítók stabilak maradnak-e, a rekordok licenc nélkül olvashatók-e, a származtatott adatok egyeztethetők-e, és hogy a szolgáltatás működik-e az átállás alatt. A tesztelés azt is megmutatja, hogy a munkafolyamat mely részei soha nem voltak valóban a hatóság tulajdonában. A sikeres kilépési teszt nem bizalmatlansági szavazás a szállítóval szemben. Ez annak a bizonyítéka, hogy a közszolgáltatásnak van kikapcsolókapcsolója.
A folytonosság akkor is számít, ha a szerződés jól működik. A szállítók tulajdonost, árazást, feltételeket, infrastruktúrát vagy stratégiai irányt válthatnak. Egy közintézménynek nem szabad válsághelyzetben rájönnie, hogy az egyetlen ember, aki érti a döntési nyomvonalát, másnak dolgozik. A beszerzés az a pillanat, amikor a folytonosságot hétköznapivá lehet tenni a hősiesség helyett.
A második vizuális elem: döntési kapu, nem bélyegző
Vásárolja meg a nemet mondás képességét
A legerősebb beszerzési követelmény néha a visszautasítás. A hatóságnak nemet kell tudnia mondani egy olyan felhasználásra, amely nem igazolható, egy olyan változtatásra, amelyet nem értékeltek, egy olyan kimenetre, amely kívül esik a hatókörön, és egy olyan szállítóra, amely nem tud működőképes kilépést biztosítani. Ez nem technológiaellenesség. Ez az a minimális függetlenség, amely ahhoz kell, hogy közcélra válasszunk technológiát, ahelyett hogy a már megvásárolt technológiához igazítanánk a célt.
A nemet mondáshoz belső útvonalra van szükség. A felülvizsgálónak tudnia kell, ki dönthet arról, hogy egy ügy automatizálása kockázatos. A szolgáltatásgazdának meg kell tudnia állítani a folyamatot anélkül, hogy megvárná a jövő hónapban ülésező irányítóbizottságot. A beszerzésnek fel kell ismernie, hogy egy kevesebb funkciót kínáló ajánlat biztonságosabb lehet, mert a határai egyértelműbbek. A jogi, műszaki és üzemeltetési csapatoknak meg kell tudniuk kérdőjelezni a preferált szállítót, mielőtt a döntés társadalmilag kínossá válna.
Vendors benefit from this discipline too. A clear no gives them a defined scope in which to improve. It prevents a promising prototype from being sold as a universal answer. It makes acceptance criteria meaningful. It also stops the supplier's most enthusiastic interpretation from becoming the de facto policy. Enthusiasm is a useful fuel for exploration. It is not a substitute for a brake.
The ability to refuse is part of sovereignty at the service level. It says the authority can keep a task human, narrow the data, require more evidence, choose a different supplier or stop a deployment without losing the public purpose. That is a better definition of technological independence than the number of products in a catalogue.
Procurement should include the people who will carry the work
Buying teams need more than a technical evaluation and a legal review. The people who will operate the service should help define the task, the failure modes and the evidence they can realistically inspect. Caseworkers, inspectors, administrators, translators, clinicians, teachers or planners know where a neat output becomes a difficult case. They also know which workarounds will appear when a system does not fit.
Involvement should be specific. Ask operators to walk through representative and difficult cases. Ask them what they need to see before accepting a recommendation. Ask where an appeal begins, where a source is corrected and which deadlines make a pause dangerous. Ask what a safe refusal looks like. These are not user-research gestures. They are requirements discovery for a service that will be operated by humans rather than by the slide deck.
Affected people should be considered as well. Their perspective may reveal that a technical distinction does not make an intelligible explanation, that a correction route is too slow or that a translated notice changes the practical meaning. Public procurement cannot turn every service into a consultation, but it can test whether the proposed boundary is visible from outside the institution. A person should not have to understand the architecture to understand how to challenge an outcome.
The result is usually less elegant than a demo and more durable than one. Real work contains interruptions, exceptions, language differences, old records, accessibility needs and people who do not behave like test data. That is not a failure of public service. It is the public service. Procurement should buy for that world.
Monitoring is how ownership continues
Ownership does not end at launch. Models, source systems, policies, staff behaviour and public needs change. A system can keep returning outputs while its meaning drifts. Monitoring should therefore connect technical signals to the public action they support. Uptime and latency matter, but so do overrides, corrections, appeals, queue effects, missing evidence, subgroup outcomes, language coverage and the severity of errors.
The monitoring plan should state what happens when a signal crosses a threshold. Who investigates. Who can pause. What records are preserved. Which people may have been affected. Whether the supplier is contacted. When the authority communicates. How a remedy is verified. A dashboard that has no response rule is not governance. It is a very colourful suggestion.
Evaluation should be repeated after material changes and at intervals appropriate to the use. A model update may alter output even when the supplier says the interface is unchanged. A policy change may alter what a correct output means. A new data source may introduce a proxy or a different error pattern. A public body needs enough version history to compare states and enough authority to decide that an apparently small change requires a wider review.
A felügyelet a felülvizsgálót is védi. Ha egy személytől várják, hogy felülbírálja a rendszert, a szervezetnek nyomon kell követnie, hogy a munkateher, a felület vagy az ösztönzők ezt a gyakorlatban lehetővé teszik-e. A magas felülbírálási arány jelezhet gyenge modellt, nem egyértelmű szabályzatot vagy olyan felülvizsgálót, aki a rosszul megtervezett eszköz körül végzi a tényleges munkát. Ha minden felülbírált döntést emberi hibának tekintünk, könnyen figyelmen kívül hagyjuk a rendszer tényleges specifikációját.
Egy hipotetikus szolgáltatás teszi láthatóvá a határt
Vegyünk egy hipotetikus közszolgáltatást, amely kérelmeket fogad, és egy szállító rendszerét használja a hiányzó információk azonosítására és a felülvizsgálati út javaslására. A rendszer nem dönthet a jogosultságról. A hatóság dokumentálta a célt, az adatforrásokat és azokat az eseteket, amelyek szakértői figyelmet igényelnek. A felülvizsgáló látja a forráshivatkozásokat, a hiányzó mező magyarázatát, a rendszerverziót és egy egyértelmű lehetőséget a javaslat elutasítására. A nyilvántartás megőrzi a felülvizsgáló intézkedését és a kérelmezőnek küldött értesítést.
Ebben a példában a szállítónak érdemi feladata van. Javíthatja az adatkinyerést, feltárhatja a bizonytalanságot, támogathatja a biztonságos frissítéseket, és teljesítheti incidens- és exportkötelezettségeit. A hatóság továbbra is birtokolja a szolgáltatás célját, a jogi normát, a felülvizsgálati szerepet és a jogorvoslatot. Ha egy mező hibás, a kérelmező kijavíthatja. Ha a javaslat kívül esik a hatókörön, a felülvizsgáló elutasíthatja. Ha a rendszer meghibásodik, a hatóság felfüggesztheti az utat, és dokumentált alternatívával folytathatja. A hasznosság a határból fakad, nem abból, hogy úgy teszünk, mintha a szállító maga lenne az intézmény.
Most változtassunk meg egy feltételt. A rendszer javasolt útja alapértelmezetté válik, a felülvizsgálók csak egy színt és egy megbízhatósági jelvényt látnak, és a szállító frissítheti a modellt anélkül, hogy a szolgáltatás tulajdonosához eljutó értesítés készülne. A szerződés továbbra is tanácsadó jellegűnek nevezi a kimenetet. A munkafolyamat azonban hatósággá tette. Ezért nem menthetik meg a jogi címkék azt a működési kialakítást, amely a kimenetnek döntési hatalmat ad.
A hipotetikus példa szándékosan egyszerű. Nem tartalmaz kitalált önkormányzatot, incidenst vagy ügyfelet. Célja, hogy láthatóvá tegye azokat a választásokat, amelyeket a beszerzés során meg kell hozni. A valódi szolgáltatások bonyolultabbak lesznek. A kérdések azonban ugyanazok maradnak: ki határozza meg a felhasználást, ki látja a bizonyítékokat, ki módosíthatja az eredményt, ki rögzíti az indokot, és ki tudja orvosolni a kárt.
Mit kérdezzen egy közbeszerző
Egy gyakorlatias beszerzési csomag ezeket az elveket olyan kérdésekké alakíthatja, amelyekre az ajánlattevőknek és a belső csapatoknak válaszolniuk kell. A lista nem univerzális sablon, és minden ágazatnak saját jogi és működési részletekre lesz szüksége. Ez egy módja annak, hogy a határ kérdése korán az asztalra kerüljön.
- Mely közfeladatot támogatja, és mely intézkedések esnek kifejezetten a hatókörön kívül?
- Kit érint, mit változtathat meg egy hibás kimenet, és mennyire visszafordítható ez a változás?
- Milyen adatokat, forrásokat, verziókat és feltételezéseket használnak, és ki javíthatja azokat?
- Milyen bizonyíték jár egy kimenettel, és egy jogosult felülvizsgáló megvizsgálhatja és megkérdőjelezheti-e azt?
- Mi történik, ha a bemenet hiányzik, ellentmondásos, nem támogatott, vagy kívül esik a megadott eloszláson?
- Melyik szerepkör utasíthat el, bírálhat felül, függeszthet fel, állíthat le vagy léptethet tovább, és ez a szerepkör betöltött és felhatalmazott-e?
- Hogyan azonosítják, tesztelik, hagyják jóvá és vonják vissza a modell, a prompt, a lekérdezés, a szabályzat és az adatok változásait?
- Hogyan kap az érintett személy értesítést, helyesbítést, magyarázatot és működőképes felülvizsgálati utat?
- Mely naplók, nyilvántartások és exportok maradnak elérhetők a hatóság számára a szerződés időtartama alatt és a kilépés után?
- Mit jelent a szállító incidensként, és hogyan igazolja a hibaelhárítást?
Ezek a kérdések nem helyettesítik a közbeszerzési eljárást, a hatásvizsgálatot vagy a jogi tanácsadást. Megnehezítik, hogy minden dokumentum arra hivatkozzon, hogy a nehéz részt egy másik dokumentum kezeli. Emellett lehetővé teszik, hogy a vevő azokon a szempontokon keresztül hasonlítsa össze a szállítókat, amelyek a szolgáltatás irányíthatóságát biztosítják, nem csak azokon, amelyek egy bemutatót lenyűgözővé tesznek.
Rövid megjegyzésünk, késve és szándékosan
A Dweve-nél irányított rendszereken dolgozunk, ezért jól ismerjük a kísértést, hogy a terméket tegyük a főszereplővé. A hasznosabb fegyelem ennél szerényebb: fogalmazzuk meg a célt, kössük az engedélyezést, tartsuk meg a bizonyítékokat, tegyük ellenőrizhetővé az átadásokat, és hagyjunk utat a korrekcióra. A saját beszerzési és irányítási anyagaink is ezekből a keretekből indulnak ki, mert az elszámoltatható munkafolyamat fontosabb, mint egy eszköz meggyőző leírása. Ez egy tervezési álláspont példája, nem pedig bizonyíték arra, hogy egy termék helyettesíthet egy közintézményt.
A lényeg nem az, hogy minden közbeszerző a mi szoftverünket használja, vagy hogy egyetlen architektúra megoldja a beszerzést. Hanem az, hogy ugyanaz a teszt vonatkozik ránk is, mint bárki másra. Meg tudja-e érteni a vevő, hogy mit vásárol, mit tehet az adott eszköz, milyen bizonyítékokat hagy maga után, hogyan változik, és hogyan tud kilépni a vevő. Ha a válasz nem, a vevőnek oka van további kérdéseket feltenni, függetlenül attól, hogy a szállító mennyire európainak, nyitottnak vagy udvariasnak hangzik.
A döntés a közintézménynél marad
A közbeszerzést gyakran a pénzért kapott érték útjaként írják le. Ez igaz, de az érték nem csak alacsonyabb ár vagy gyorsabb folyamat. Egy közszolgáltatásnak arra is képesnek kell lennie, hogy indokokat adjon, hibákat javítson, kiállja az ellenőrzést, védje a jogokat, és tovább működjön, ha egy összetevő megváltozik. Egy rendszer, amely időt takarít meg, miközben ezeket a kötelezettségeket lehetetlenné teszi, nem pénzért kapott érték. Hanem egy jövőbeli vita, amelyet kedvezményesen vásároltak meg.
A szállító biztosíthat képességet, bizonyítékot, karbantartást és fejlesztési utat. A hatóságnak kell biztosítania a célt, a felhatalmazást, az ítélőképességet, a jogorvoslatot és a tulajdonlást. A szerződésnek egyértelművé kell tennie ezeket a kapcsolatokat. A munkafolyamatnak láthatóvá kell tennie őket. A nyilvántartásnak visszakereshetővé kell tennie őket. Az érintett személynek meg kell tudnia találni azt az ajtót, amelyen keresztül a korrekció beléphet.
Ezért nem ruházhatja ki egy közszolgáltatás az ítélőképességét. Az intézmény átruházhat egy feladatot, de nem ruházhatja át az eredmény közérdekű jelentését. Használhat modellt, de nem használhatja a modell magabiztosságát arra, hogy abbahagyja a gondolkodást. Vásárolhat asszisztenst, de nem vásárolhat asszisztenst, majd nevezheti az asszisztenst elszámoltatható félnek. A közhatalom nem mozdul el pusztán azért, mert egy szoftverábrán van egy nyíl.
Ezért a becsületes beszerzési kérdés nem az, hogy a szállító automatizálhatja-e ezt. Hanem az, hogy a közintézmény képes marad-e megérteni, megkérdőjelezni, szüneteltetni, javítani, magyarázni és kilépni, miközben a szállító segít. Ha a válasz igen, a technológiának van helye egy irányítható szolgáltatáson belül. Ha a válasz nem, a helyes döntés lehet a használat szűkítése, a szerződés módosítása vagy a vásárlás elutasítása. Egy közintézmény, amely képes nemet mondani, még mindig ellátja a feladatát.
Források
- A 2014/24/EU irányelv a közbeszerzésről, Európai Parlament és a Tanács, 2014. február 26.
- Az (EU) 2024/1689 rendelet, a mesterséges intelligenciáról szóló jogszabály, Európai Parlament és a Tanács, 2024. június 13., beleértve a 13., 14., 26., 27. és 49. cikket.
- Eszközök a közbeszerzők számára, Európai Bizottság, megtekintve: 2026. augusztus 5.
- A közbeszerzők szakmai fejlesztése, Európai Bizottság, 2017. október 3., megtekintve: 2026. augusztus 5.
- A magánszemélyek kérelmeinek kezelése: az automatizált döntéshozatal korlátozásai, Európai Bizottság, megtekintve: 2026. augusztus 5.
- Mesterséges intelligencia, Európai Bizottság, az oldal utolsó frissítése: 2026. június 3.