A modellregiszter az új nyilvános hirdetőtábla

A modellregiszter elmondhatja a nyilvánosságnak, mi is egy rendszer, ki áll mögötte, hol használható, és mi változott. Nem tud egy rendezett bejegyzést...

A modellregiszter az új nyilvános hirdetőtábla

The page that starts by admitting it is not magic

The first thing a useful model registry does is disappoint you. It does not say that a model is safe. It does not say that an organisation is competent. It does not turn a supplier's promise into a fact, or a green label into a reason to stop asking questions. It gives you a bounded record instead: this is the thing, this is the version, this is the owner, this is the declared purpose, this is the status, and this is where the supporting evidence is kept.

That modesty is the beginning of public trust. A registry is a noticeboard, not a shrine. A noticeboard tells a neighbourhood what is being built, who is responsible for it and which notices have been replaced. It does not certify the workmanship of every building on the street. It gives people a place to start looking, and a way to notice when the notice itself has gone stale.

Open the Dutch government's Algorithm Register and the design is unusually plain. Government organisations publish information about algorithms they use in their work. The register focuses on impactful algorithms, including high-risk AI systems, and gives visitors an explanation of how those systems work. The page also makes a useful distinction that many glossy AI catalogues avoid: an algorithm is a set of rules and instructions a computer follows to calculate an answer, not a personality with a product launch.

The page is public because the work is public. A citizen does not need a private account to discover that an authority uses an algorithm, what the authority says it is for, or where to ask the next question. That does not make every technical detail public. It does make the existence of the system, its declared role and its institutional owner harder to hide behind a procurement file.

Model registries are becoming the same kind of civic object. They sit between a technical catalogue and a public record. Engineers need a stable identity and a version to integrate. Operators need a status and an owner to run. Downstream providers need capabilities, limits and conditions. Auditors need a trail back to evidence. Affected people need to know that a system exists and how to challenge what it does. One page cannot answer all of those questions, but a well-designed registry can point each reader to the right layer.

The danger is that the word registry makes a document sound more complete than it is. A phone book is a registry, but it cannot tell you whether a number still works. A shipping manifest is a registry, but it cannot tell you whether the cargo survived the voyage. A model record is a registry, but it cannot carry the entire proof of performance, fairness, security, legality and social consequence. The useful question is not whether a model is in the registry. It is what the entry establishes, what it leaves open and what a reader can inspect next.

A noticeboard is a promise of selection

An inventory tries to count everything. A catalogue tries to help you choose. A register makes a more formal promise: these entries belong to a defined scope, they have an owner, and the information is maintained under a rule. The promise is about selection before it is about software. Without a stated scope, an attractive list is only a collection of things that happened to be remembered.

That is why every registry needs a sentence that says what it includes and what it deliberately leaves out. The EU AI Act's central database is not a list of every model circulating in Europe. Article 71 establishes an EU database for specified high-risk AI systems and the systems that are registered under the routes described in Article 49. The Dutch Algorithm Register is not a list of every calculation made in a government office. It focuses on impactful algorithms, including high-risk AI systems. The boundary is part of the record, not a footnote for lawyers.

A modellregiszternek hétköznapi nyelven kell megválaszolnia ugyanezt a határkérdést. Alapmodelleket sorol fel, élesben futó AI-rendszereket, belső kísérleteket, finomhangolt leszármazottakat, értékelőcsomagokat, vagy csak a külső felhasználóknak kínált modelleket? Egy új szolgáltatási konfiguráció új bejegyzést kap, új verziót, vagy egy hozzá kapcsolt telepítési rekordot? Egy adaptív rendszer rögzített állapota ugyanannak a modellidentitásnak számít? Ha a regiszter nem dönti el ezeket a kérdéseket, minden olvasó másképp dönti el őket. Így válik egy rövid listából hosszú vita.

A kiválasztás azt is jelenti, hogy a hiány jelentéssel bír. Ha a hatókör azt mondja, hogy minden nyilvánosan hozzáférhető, magas kockázatú rendszernek szerepelnie kell, akkor a hiányzó bejegyzés kormányzási probléma. Ha a hatókör azt mondja, hogy csak a piacra helyezett modellek tartoznak bele, akkor egy belső kísérlet szándékosan hiányozhat. A nyilvánosság nem tudja értelmezni az üres keresési eredményt, ha nem tudja, hogy a két helyzet közül melyik áll fenn. A csend nem semleges, ha a nyilvántartás nem magyarázta el a szókincsét.

Van egy kis adminisztratív erény abban, ha ezt világosan kimondjuk. A regisztereknek nem kell úgy tenniük, mintha mindent tudnának. El kell mondaniuk az olvasónak, hogy mit tudnak, miért felelősek, és mi esik a kereten kívülre. A regiszter azzal szerzi meg a tekintélyét, hogy egyértelművé teszi a hatókörét, nem pedig azzal, hogy díszíti a borítót. A technológia újabb. Az adminisztratív ösztön nem az.

Mit tesz az európai szabály valójában az asztalra

Az AI-rendelet konkrét jogi formát ad a regisztráció szónak, de nem egyetlen, univerzálisat. A 49. cikk előírja, hogy a szolgáltató vagy a meghatalmazott képviselő bizonyos magas kockázatú AI-rendszereket regisztráljon, mielőtt azokat forgalomba hozza vagy üzembe helyezi. Regisztrációt ír elő akkor is, ha a szolgáltató a 6. cikk (3) bekezdésének feltételei alapján arra a következtetésre jutott, hogy a rendszer nem minősül magas kockázatúnak. A bizonyos magas kockázatú rendszereket üzembe helyező hatóságoknak és az azokkal egyenértékű közjogi szerveknek saját regisztrációs kötelezettségük van, beleértve a felhasználásuk regisztrálását is.

Ugyanez a cikk egyértelművé teszi a köz- és magánszféra közötti határt. A bűnüldözés, a migráció, a menekültügy és a határigazgatás területén használt bizonyos magas kockázatú rendszereket egy biztonságos, nem nyilvános szekcióban regisztrálják. A III. melléklet második pontjában szereplő magas kockázatú rendszereket nemzeti szinten regisztrálják. Ezek nem olyan megvalósítási részletek, amelyeket egy irányítópulton lehet elrendezni. Különböző közönségeket, különböző kockázatokat és különböző jogosultságokat írnak le a rekord megtekintésére.

A 71. cikk szerint a Bizottság a tagállamokkal együttműködve létrehozza és működteti az uniós adatbázist. A 49. cikk alapján regisztrált információknak felhasználóbarát módon hozzáférhetőnek és nyilvánosan elérhetőnek kell lenniük, könnyen navigálhatónak és géppel olvashatónak kell lenniük, a korlátozott szekciókra vonatkozó kivételekkel. Az adatbázisnak csak annyi személyes adatot szabad tartalmaznia, amennyi szükséges. Ez a nyilvános átláthatóság hasznos meghatározása: olyan rekord, amelyet az emberek megtalálhatnak és feldolgozhatnak, anélkül hogy a rekord egy második személyesadat-problémává válna.

A VIII. mellékletben válik konkrétummá a hirdetőtábla. A magas kockázatú rendszert regisztráló szolgáltató esetében a rekord tartalmazza a szolgáltató azonosító adatait és elérhetőségeit, egy egyértelmű kereskedelmi nevet vagy hivatkozást, a rendeltetési célt, a felhasznált információk és a működési logika alapvető leírását, a rendszer állapotát, a releváns tanúsítványokat, azokat a tagállamokat, ahol a rendszert forgalomba hozták vagy üzembe helyezték, a megfelelőségi nyilatkozatot, a használati utasítást és egy opcionális URL-t a további információkért. Ezek nem marketingmezők. Ezek az azonosítás és az elszámoltathatóság fogantyúi.

Egy nyilvános üzemeltető esetében az információ más. A nyilvántartás tartalmazza az üzemeltető személyazonosságát, az adatot benyújtó személyt, a szolgáltató bejegyzésének URL-címét, valamint az alapjogi hatásvizsgálat és adott esetben az adatvédelmi hatásvizsgálat összefoglalóit. A megkülönböztetés azért fontos, mert a modellszolgáltató és a hatóság nem ugyanazokat a dolgokat ismeri, és nem ugyanaz a felelősségük. Egy olyan nyilvántartás, amely egyetlen szolgáltatói kártyába olvasztja össze őket, eltünteti azt a pontot, ahol a rendszer találkozik az intézménnyel.

A jogi adatbázis ezért rétegzett jellegű. Rögzíti a rendszer azonosítóját. Rögzíti a szolgáltatót. Rögzítheti az üzemeltetőt és a felhasználást. Rögzíti az állapotot és a kapcsolódó nyilatkozatokat. Nem helyettesíti a műszaki dokumentációt, a kockázatkezelést, a minőségirányítási rendszert vagy a forgalomba hozatal utáni felügyeletet, amelyeket a rendelet másutt ír elő. Az adatbázis a felelősségre vonható tények nyilvános jegyzéke. Nem a teljes megfelelőségi dokumentáció.

Ezt a megkülönböztetést könnyű szem elől téveszteni, mert az emberek szeretik az egyetlen URL-t, amely látszólag tartalmazza a választ. A jog kevésbé érzelmes. Létrehoz egy nyilvános felületet, korlátozott felületeket és szabályozott dokumentációs útvonalakat. A nyilvános felületnek használhatónak kell lennie. A korlátozott felületnek korlátozottnak kell maradnia. A dokumentációnak hozzáférhetőnek kell maradnia az illetékes hatóság vagy a downstream szolgáltató számára, amelynek szüksége van rá. Egy komoly nyilvántartás interfész e kötelezettségek között, nem pedig kiskapu körülöttük.

A nyilvántartás akkor válik hasznossá, ha az azonosító, az állapot és a változás összekapcsolódik. A szín átmenet nélkül csak dekoráció.

Van egy másik fontos korlát is. Az AI-rendelet általános célú MI-re vonatkozó rendelkezései nem ugyanazok, mint az összes általános célú modell nyilvános katalógusa. Az 53. cikk előírja a szolgáltatóknak, hogy műszaki dokumentációt vezessenek, az információt a downstream MI-rendszerek szolgáltatói számára hozzáférhetővé tegyék, szerzői jogi politikát tartsanak fenn, és kellően részletes összefoglalót tegyenek közzé a képzési tartalomról. A Bizottság iránymutatása kifejti, hogy a műszaki dokumentáció az MI Hivatal és a nemzeti illetékes hatóságok számára készül, kérésre, míg a downstream dokumentáció segíti az integrátorokat a képességek és korlátok megértésében. Ennek az anyagnak csak egy része tartozik nyilvános hirdetőtáblára.

A rendelet azt is előírja a Bizottságnak, hogy tegye közzé és tartsa karban a rendszerszintű kockázatot hordozó általános célú MI-modellek listáját. A rendszerszintű kockázatot hordozó modellek listája értékes nyilvános jelzés, de nem ugyanaz az objektum, mint egy teljes modellnyilvántartás. Szűkebb célja van, és tiszteletben kell tartania a szellemi tulajdonhoz fűződő jogokat, a bizalmas üzleti információkat és az üzleti titkokat. Minden listát nyilvántartásnak nevezni csak addig ártalmatlan, amíg valaki nem feltételezi, hogy egy lista többet bizonyít, mint amennyit valójában bizonyít.

A modell nem egyetlen sor

Az emberek úgy beszélnek a modellről, mintha egy polcon álló üveg lenne. A név a címkén van, a verzió alatta van bélyegezve, és a tartalom változatlan marad, amíg valaki fel nem nyitja a fedelet. Ez a kép statikus artefaktum esetén működik. Megbízhatatlanná válik, amikor egy modellt adaptálnak, finomhangolnak, eszközökbe csomagolnak, több útvonalon keresztül szolgálnak ki, vagy használat közben módosítanak.

A nyilvántartásnak legalább két azonosítóra van szüksége: a modell azonosítójára és annak azonosítójára, ami ténylegesen futott. Az első azt válaszolja meg, hogy a szolgáltató melyik modellre gondol. A második azonosíthat egy rögzített állapotot, egy lezárt telepítési csomagot, egy helyi exportot vagy egy visszajátszási csomagot. Összekapcsolásuk két ellentétes hibát akadályoz meg. Egy szolgáltatás abbahagyhatja, hogy minden élő állapotnak egyetlen állandó hash-e van, és egy üzemeltető abbahagyhatja, hogy egy csomag-ellenőrzőösszeg önmagában leírja az egész modellcsaládot.

A verziószámok csak akkor hasznosak, ha a változtatás szabálya látható. Egy verzió jelenthet új tanult paramétereket, új kényszerkatalógust, a lekérdezés megváltozását, módosult biztonsági réteget vagy lényegi változást a kiszolgálási szerződésben. Ha egy szolgáltató egyetlen számot használ mindezekre, a szám udvarias módja lesz annak, hogy valami megváltozott. A nyilvántartásnak össze kell kötnie az utódot az elődjével, és meg kell mondania, hogy a szerződés melyik része mozdult el.

Az adaptív viselkedés újabb bonyodalmat jelent. Ha egy rendszer használat közben változhat, a feljegyzésnek ezt jeleznie kell. Ez nem azt jelenti, hogy a rendszer ellenőrizetlen. Hanem azt, hogy a verzió szó nem tud minden munkát elvégezni. A nyilvántartás megtarthat egy stabil modellazonosságot, időhöz kötött rögzített állapotokat kapcsolhat hozzá, és feljegyezheti azokat a feltételeket, amelyek között egy állapot létrejött. A cél nem az, hogy egy élő rendszert hamis fényképbe fagyasszunk. Hanem az, hogy minden értelmes fényképnek dátuma és kerete legyen.

Az azonosságnak társadalmi éle is van. Egy modellnév nem elegendő, ha több jogi személy terjeszt hasonló artefaktumokat, ha egy downstream szolgáltató módosítja a modellt, vagy ha egy termék saját neve mögé rejti a modellt. A nyilvántartásnak láthatóvá kell tennie a láncot: a szolgáltatót, a forgalmazót, ha az eltérő, az üzemeltetőt, ahol releváns, valamint a rendszert vagy útvonalat, amelyben a modellt használják. Egy döntés által érintett személynek nem szabad törvényszéki régészetet végeznie egy terméklogón, hogy megtudja, ki felelős érte.

A státusz ige, nem szín

A státuszmezőket gyakran jelvényként jelenítik meg, mert a jelvények szépen illeszkednek a kártyákra. A jelvény nem a státusz. A státusz egy cselekvésre és egy időpontra vonatkozó állítás. A belső tesztelés mást jelent, ha a hozzáférést a szolgáltató ellenőrzi. A megjelenés előtti állapot mást jelent, ha meghívott külsősök meghatározott feltételek mellett használhatnak egy útvonalat. A piacon, szolgálatban, felfüggesztve, visszavonva és kivonva mind más-más működési következménnyel jár.

Egy hasznos feljegyzés megmondja, mit enged a státusz, és mit nem. Ha egy rendszer csak belső használatra szól, az olvasónak nem szabad nyilvános elérhetőségre következtetnie egy dokumentációs oldalból. Ha külső béta van tervezve, a dátumot tervezettként kell megjelölni, nem pedig megjelenésként bemutatni. Ha egy rendszert kivonnak, a feljegyzésnek meg kell őriznie a korábbi azonosságot, és meg kell mondania, hogy a meglévő telepítések folytatódhatnak-e, le kell-e állniuk, vagy migrálás alatt állnak. A státusz hatálybalépési dátum nélkül egyenruhába öltöztetett pletyka.

A státusznak gazdája is kell legyen. Ki helyezhet át egy bejegyzést belsőből külsőbe? Ki függeszthet fel egy útvonalat? Ki jelentheti be, hogy egy megjelenési dátum megváltozott? Milyen bizonyíték szükséges az átmenethez? Ezek a kérdések a működési folyamathoz tartoznak, de a nyilvános bejegyzésnek olvashatóvá kell tennie az így született döntést. Az a nyilvántartás, amely mutatja az aktuális jelvényt, de elrejti a mögötte álló felhatalmazást, csak kormányzási hangulatfotó.

Szemléltető példa, nem valós bejegyzés: egy feljegyzés mondhatja azt, hogy egy modell ellenőrzött értékelés alatt áll, hogy nincs nyitott külső útvonal, hogy meghívásos tesztet javasolnak egy későbbi időpontra, és hogy a javaslat továbbra is megjelenési kapuhoz kötött. A példa nem nevez meg szervezetet, modellt vagy eseményt. Célja az, hogy megmutassa, hogyan választja el egy feljegyzés a tervet a ténytől. Ugyanez a fegyelem vonatkozik a kivonásra, egy képességre vonatkozó állításra vagy egy még ki nem adott tanúsítványra.

Ez az elkülönítés megvédi az olvasókat egy ismerős trükkötől. Egy jövőbeli szándékot elég gyakran megismételnek, és már történelemnek hangzik. A nyilvántartásoknak azoknak a helyeknek kell lenniük, ahol ez a trükk nem működik tovább. A bejegyzés mutathat tervet, de a tervnek meg kell őriznie a címkéjét. Európának már így is elég naptára van. Egy dátum nem tény pusztán azért, mert színes téglalapba helyezték.

A nyilvántartás nem a bizonyítéktár

A nyilvános bejegyzésnek elég rövidnek kell lennie az olvasáshoz, és elég erősnek ahhoz, hogy egy komoly kérdést helyes irányba tereljen. A mögötte álló bizonyítéktár ennél jóval nagyobb lehet. Az AI Act 53. cikkének dokumentációs kötelezettségei jól mutatják, miért. Az általános célú AI-modellek szolgáltatóinak műszaki dokumentációt kell készíteniük és vezetniük, amely kiterjed a fejlesztésre, a képzésre, a tesztelésre és az értékelésre. Az alsóbb szintű AI-rendszerek szolgáltatói számára hozzáférhetővé kell tenniük az információkat és a dokumentációt, hogy azok megérthessék a képességeket és a korlátokat. Kellően részletes összefoglalót kell közzétenniük a képzési tartalomról, és politikát kell fenntartaniuk az uniós szerzői jogi szabályok tekintetében.

Ezek a kötelezettségek különböző olvasókat szolgálnak. Az illetékes hatóságnak szüksége lehet a teljes műszaki nyilvántartásra. Az alsóbb szintű szolgáltatónak integrációs információkra és a korlátok ismertetésére van szüksége. A nyilvánosság számára világos leírást kell adni arról, hogy mi a modell, és hogyan határolódik a képzési tartalom összefoglalója. A nyilvántartási bejegyzés összekapcsolhatja ezeket a felületeket anélkül, hogy azt sugallná, hogy egy nyilvános oldalnak tartalmaznia kell minden biztonsági szempontból érzékeny részletet, minden súlyfájlt vagy minden személyes adatot hordozó tesztelemeket.

A linkek sem varázsütésre jelentenek bizonyítékot. Ha egy nyilvántartás egy értékelési jelentésre mutat, meg kell határoznia, hogy a jelentés melyik kiadásra vonatkozik, mit mért az értékelés, és milyen feltételek korlátozzák az eredményt. A képzési összefoglalóra mutató linknek jeleznie kell, hogy az összefoglaló az előképzésre, a finomhangolásra vagy a tartalmi kategóriák meghatározott körére vonatkozik-e. A tanúsítványra mutató linknek meg kell mutatnia, hogy ki állította ki, mit tanúsít, és mikor jár le. Ellenkező esetben az oldal nem más, mint egy polc felbontatlan borítékokkal.

Ugyanez a szabály vonatkozik a biztonsági állításokra is. Egy nyilvántartás jelezheti, hogy létezik kockázatértékelés, hogy a megfigyelési tervhez link vezet, vagy hogy a súlyos incidensek bejelentésének módja közzétételre került. Nem sugallhatja azonban, hogy egy dokumentum létezése bizonyítja az alapul szolgáló rendszer biztonságosságát. A dokumentáció az állítás ellenőrzésének módja. Nem helyettesíti az állítást.

Itt van szükség fegyelemre a nyilvános írásban. Egy modellkártya, átláthatósági oldal vagy nyilvántartási bejegyzés leírhatja a tervezett felhasználást és az ismert korlátokat. Nem használhatja a megbízható szót következtetésként, hacsak a bizonyítékok és a hatókör nem teszik védhetővé ezt a következtetést. A becsületes mondat gyakran hasznosabb: ezek azok a feltételek, amelyek között értékeltünk, ezek azok a korlátok, amelyeket megfigyeltünk, és ezek azok az esetek, amelyekre nem vállaltunk lefedettséget.

A holland nyilvántartás megmutatja egy hétköznapi nyilvános lista értékét

A holland algoritmusnyilvántartás éppen azért tanulságos, mert nem próbál futurisztikus vezérlőteremnek látszani. Lehetőséget ad a kormányzati szervezeteknek, hogy nyilvános helyen írják le a munkájuk során használt algoritmusokat. Angol nyelvű oldala figyelmeztet arra, hogy a leírásokat automatikusan fordították, és hogy a holland eredeti a mérvadó változat a leírás tekintetében. Ez a kis megjegyzés a származás tanulsága. A hozzáférés nem azonos a pontossággal, és egy lefordított felületnek nem szabad eltörölnie a forrásnyelvet.

A nyilvántartás nyilvános célját is színpadias nyelvezet nélkül fogalmazzák meg. A jelentős hatású algoritmusokra összpontosít, beleértve a nagy kockázatú AI-rendszereket is, és betekintést nyújt a látogatóknak abba, hogyan működnek. A látogató böngészhet algoritmusok, szervezetek és sablonok között. A cél nem az, hogy minden algoritmushoz pontszámot adjon. Az a cél, hogy az algoritmikus rendszerek használata elég láthatóvá váljon ahhoz, hogy az emberek, szervezetek és a média követni, megkérdőjelezni és vizsgálni tudja a kormányzati gyakorlatot.

A kapcsolódó holland Algoritmekader ezt a célt követelménnyé alakítja. Kimondja, hogy kivételek hiányában a köztestületek közzéteszik a jelentős hatású algoritmusokat és a nagy kockázatú AI-rendszereket a nyilvántartásban. Azt is kimondja, hogy a helytelen vagy hiányos közzététel megnehezítheti az érintett személyek és más érdekelt felek számára, hogy megértsék és megkérdőjelezzék az olyan technológia használatát, amely a jogaikat érintheti. Az átláthatóság tehát nem csupán udvariasság. A bejegyzés minősége befolyásolhatja a nyilvános kontroll minőségét.

Ez az útmutatás körültekintő a hatókör tekintetében. A nyilvántartást egy tágabb jogszabály- és követelményrendszer eszközeként írja le, és figyelmeztet arra, hogy a keretrendszer nem teljes, és nem feltétlenül tartalmazza az ágazatspecifikus jogszabályokat. Az a tény, hogy egy algoritmus szerepel a nyilvántartásban, nem dönt el minden jogi vagy etikai kérdést. Az a tény, hogy nem szerepel, nem bizonyítja, hogy ártalmatlan. Az olvasónak szüksége van a nyilvántartás felvételi szabályára és a környező keretrendszerre az adat értelmezéséhez.

Ez a hasznos minta a modellnyilvántartások számára. Egy nyilvános listának könnyen megtalálhatónak kell lennie, olyan embereknek kell íródnia, akik nem voltak jelen a beszerzési megbeszélésen, és kapcsolódnia kell azokhoz a nyilvántartásokhoz, amelyek részletesebb információt hordoznak. Fel kell tárnia a bizonytalanságot, nem pedig elrejtenie. Meg kell mondania, ha egy angol leírás gépi fordítás. El kell magyaráznia, hogy mely rendszerek szerepelnek benne, és melyek nem. A hiányzó vagy elavult adatot látható irányítási problémává kell tennie, nem pedig magánjellegű csalódássá.

Nem kell drámai eseményt kitalálni ahhoz, hogy lássuk, miért fontos ez. Egy állampolgár, aki egy automatizált kormányzati folyamatot próbál megérteni, már eleve gyakorlati kérdéssel szembesül: használnak-e egy rendszert, ki, milyen célból és milyen magyarázat alapján? A nyilvántartás címet ad ennek a kérdésnek. A válasz még mindig hiányos lehet. De legalább az intézmény nem tehet úgy, mintha nem lenne hová fordulni.

A nyilvános nem jelent meztelent

Az átláthatóság kontraproduktívvá válik, ha parancsként értelmezik minden közzétételére. A nyilvános nyilvántartások felfedhetnek személyes adatokat, biztonsági szempontból érzékeny információkat, üzleti titkokat és támadási útvonalakat. Hamis bizalmat is kelthetnek azzal, hogy olyan technikai részleteket tesznek közzé, amelyeket egy hétköznapi olvasó nem tud értelmezni. A nyilvános és a nem nyilvános közötti határt meg kell tervezni, dokumentálni és felül kell vizsgálni, nem pedig annak a csapatnak a belátására bízni, amelyik éppen a tartalomkezelő rendszert üzemelteti.

Az AI-törvény jogi példát ad erre. A 49. cikk (4) bekezdése bizonyos rendszereket egy biztonságos, nem nyilvános szakaszba helyez, és a hozzáférést a Bizottságra és az érintett nemzeti hatóságokra korlátozza. A 71. cikk a 49. cikk alapján nyilvántartásba vett információkat nyilvánosan hozzáférhetővé teszi, kivéve a korlátozott szakaszokat, míg a 60. cikk alapján nyilvántartásba vett információkhoz csak a piacfelügyeleti hatóságok és a Bizottság férhet hozzá, kivéve, ha a szolgáltató hozzájárul a nyilvános hozzáféréshez. A nyilvánosság tehát kivételekkel teli szabály, nem pedig egyetemes alapértelmezés.

Az 53. cikk hasonló megkülönböztetést tesz az általános célú modellek esetében. A szolgáltatóknak kérésre rendelkezésre kell bocsátaniuk a műszaki dokumentációt az AI Hivatal és az illetékes nemzeti hatóságok számára, és a továbbfelhasználó szolgáltatók számára is dokumentációt kell biztosítaniuk. A kötelezettségek kifejezetten a szellemi tulajdonjogok, a bizalmas üzleti információk és az üzleti titkok védelmének szükségességére tekintettel érvényesek. Egy nyilvántartás nem kényszerítheti a szolgáltatót olyan anyag közzétételére, amelyet a jogszabály szerint ellenőrzés alatt kell tartani. A bizalmasság nem válhat udvarias kifogássá annak elhallgatására, hogy létezik-e egy rendszer, mi a célja vagy mi az állapota, ha az a nyilvánosságot érinti.

Egy gyakorlati modellnyilvántartás rétegeket használhat. A nyilvános réteg azonosítja a modellt, a szolgáltatót, az állapotot, a tervezett célt, az általános képességeket, az ismert korlátokat, a hozzáférési útvonalakat, a kiadási feltételeket, a bizonyítékokra mutató hivatkozásokat és a változástörténetet. Egy ellenőrzött réteg részletes műszaki dokumentációt, fenyegetési modelleket, korlátozott értékelési anyagokat, incidensrészleteket és más, az arra jogosult felülvizsgálók számára szükséges információkat tartalmaz. Egy privát működési réteg titkokat, személyes adatokat és belső ellenőrzési információkat tartalmaz, amelyeket egyáltalán nem szabad nyilvánosságra hozni. A rétegek különálló nyilvántartások hivatkozásokkal, nem pedig egyetlen oldal, amelyen egy átláthatóság feliratú akkordeon található.

A jó átláthatóságnak van határa. Közzéteszi, amire az embereknek szükségük van a rendszer megértéséhez, és védi azt, amit a felhatalmazott felülvizsgálóknak ellenőrizniük kell.

A nyilvános rétegnek továbbra is konkrétnak kell lennie. Kimondhatja, hogy egy modell használat közben adaptív, anélkül, hogy felfedné a belső állapotábrázolást. Kimondhatja, hogy egy útvonal csak meghívásos, anélkül, hogy közzétenné a meghívási tokeneket. Leírhatja a kimeneti módokat és a tartalomjelölési szabályzatot anélkül, hogy felfedné az aláíró kulcsokat. Kimondhatja, hogy létezik kockázatértékelés, és meghatározhatja annak hatókörét anélkül, hogy közzétenne egy biztonsági ábrát, amely megkönnyítené a szolgáltatás megtámadását.

A szabályozott rétegnek megvan a maga őszintesége. A bizalmasnak jelölt dokumentum nem automatikusan teljes, naprakész vagy helyes. Szüksége van tulajdonosra, verzióra, hozzáférési szabályra és megőrzési szabályra. Ha egy nyilvános nyilvántartás egy szabályozott rekordra hivatkozik, a hivatkozásnak fel kell tárnia annak állapotát és felelős útvonalát akkor is, ha a tartalom korlátozott. Ellenkező esetben a nyilvánosság egy fekete lyukat lát, és arra kérik, hogy nevezze azt irányításnak.

A verziókezelés teszi hasznossá a nyilvántartást

A nyilvántartási hibák legtöbbször nem drámaiak. Apró feledékenységek. Egy új modell váltja fel a régit, de a bejegyzést a helyén szerkesztik. Egy szabályzat megváltozik, de a rendeltetésszerű használatról szóló bekezdés változatlan marad. Egy szolgáltató áthelyez egy útvonalat a belső tesztelésből egy külső bétaverzióba, de az állapotjelvény a hatálybalépés dátuma előtt megváltozik. Egy telepítést visszavonnak, de a régi bejegyzés eltűnik, magával viszi az előzményeket. A jelen rendezettnek tűnik. A múlt megválaszolhatatlanná válik.

A verziózott rekord legalább négy dátumot külön tart. A tartalomverzió azt mondja meg, melyik rekordszöveg és mezők aktuálisak. A hatálybalépés dátuma azt mondja meg, mikor érvényes az állítás. A modell- vagy csomagverzió azt mondja meg, melyik technikai objektumot írja le. Az ellenőrzés dátuma azt mondja meg, mikor ellenőrizte valaki a rekordot. Ezek a dátumok egybeeshetnek. Nem kötelező. Egyetlen dátumként kezelni őket kényelmes, és gyakran téves.

A korábbi verzióknak felfedezhetőknek kell maradniuk egy megfelelő megőrzési szabály szerint. A nyilvánosságnak nem kell minden belső szerkesztést látnia, de tudnia kell, mikor változott egy lényeges cél, állapot, útvonal, korlátozás vagy tulajdonosi nyilatkozat. A változásnapló megmondhatja, mi változott, anélkül, hogy felfedné a privát információkat. A géppel olvasható rekord hivatkozhat az előző verzióra és egy jegyzékre. Az ember által olvasható oldal hétköznapi nyelven magyarázhatja el a következményt. A két felületnek egyeznie kell.

A verziókezelés a visszavonást is értelmessé teszi. Ha egy modellt azért vonnak vissza, mert egy útvonal megszűnt, az más, mint egy visszahívás, mert súlyos hiba vagy jogi probléma intézkedést igényel. Ha egy modell meglévő privát telepítésekben marad, a nyilvános rekordnak ezt ki kell mondania. Ha egy utód csak egyes integrációkhoz kompatibilis, az áttelepítési határnak láthatónak kell lennie. Az a nyilvántartás, amely eltávolít egy nevet anélkül, hogy rögzítené az okot, arra hagyja minden downstream olvasót, hogy kitaláljon egy indokot.

A változási előzmények különösen fontosak az adaptív rendszereknél. A modellazonosság stabil maradhat, miközben a rögzített állapotok, a kényszerkészletek, a lekérési források vagy a kimeneti vezérlők változnak. A nyilvántartás kimondhatja, mely változások hoznak létre új csomagot, mely változások igényelnek új értékelést, és mely változások maradnak a kijelentett azonossági határon belül. Ez nem túlzott részletesség. Ez a különbség egy olyan rendszer között, amelyet vissza lehet játszani, és egy olyan rendszer között, amelyet csak megjegyezni lehet.

A tulajdonosok a rekord részei

A model registry entry without an owner is a weather report. It tells you what the sky looked like and leaves you with no one to call when the roof leaks. Provider and deployer roles are not the same, and neither role should be allowed to dissolve into the word platform.

The provider owns the model identity, the development record and the release decision within its scope. A deployer owns the decision to use a system under its authority, including the local purpose, safeguards, impact assessment and operating controls. A downstream provider may integrate a general-purpose model into an AI system and carry responsibilities that the model provider cannot see. A public registry should expose those relationships where the law and the risk require them.

Contact information is not administrative filler. It gives an affected person a route to ask who made a decision, which version was used or how a correction can be requested. A generic mailbox can be appropriate, but it should lead to a maintained process. The entry should also say whether the contact is for technical support, rights requests, incident reporting, procurement or public accountability. One inbox cannot be every institution at once, despite the best efforts of modern forms.

Ownership should include authority to change the record. If the named owner cannot pause a route, correct a status or publish a withdrawal, the entry is decorative. The organisation may still have a legal owner somewhere else, but the operational gap remains. A good registry makes responsibility visible before an incident forces people to draw the organisation on a whiteboard.

Designing a registry people can actually read

The first reader of a model registry is not always a regulator or an engineer. It may be a journalist, a procurement officer, a local official, a researcher, an employee asked to use the system, or a person trying to understand why an automated service touched their case. The page should answer the common question before it reaches for specialised vocabulary.

Start with the identity and the reason for the entry. Say who provides the model, which version is being described, what kind of object it is and whether it is a model, an integrated AI system or a deployment record. Say whether it is internal, available to invited users, on the market, suspended or withdrawn. The reader should not have to infer the status from a download button.

Then show the purpose and the boundary. State what the model is intended to do, which uses are outside the claim and which decisions it is not authorised to make. Explain whether the model can adapt during use, whether a captured state is required for replay, and whether a downstream route changes the conditions. A capability list without a purpose is a menu without a kitchen.

Use progressive disclosure. The top of the page should be calm and readable. Deeper sections can expose the machine record, evaluation methods, training-content summary, legal documents and release evidence. A public reader can stop after the first layer. An auditor can continue. An engineer can download a stable representation. Hiding the detail is not simplicity. It is just a slow-loading surprise.

Accessibility is part of the record's credibility. The page and machine representation should use clear labels, keyboard navigation, useful headings and text alternatives for visualisations. Dates should not be encoded only as colour. A red badge is not a status for a reader who cannot see red, and a graph that cannot be read without a mouse is not an accessible explanation. A noticeboard in the town square does not become public if the ramp ends at the first step.

Machine readability matters for a different reason. It lets researchers compare entries, lets public bodies build inventories, lets auditors detect stale records and lets a downstream tool verify that the page and the structured record refer to the same version. Machine-readable does not mean machine-only. The human page and the machine record should share identifiers, status, dates and links, with an integrity relationship that can be checked.

Registry fields are decisions

Every field tells the reader what the organisation believes is worth preserving. A provider field says who stands behind the model. A model name and version say how to distinguish it from a successor. A route field says where it can be reached. An intended-purpose field says which work the provider is prepared to describe. A limitation field says where the description stops. The schema is a governance document written in small rectangles.

Identity fields should be unambiguous and stable. They can include a provider's legal name, the model name, the version, a unique reference and links to a canonical record. If the model can be served through several products, the registry should distinguish the model identity from the integrating surface. If a product contains several models, the entry should not hide that fact behind the product name.

Status fields should include the value, the effective date, the reason or authority for the transition and any successor or predecessor. A date that is merely planned should be labelled as planned. A record that has not been verified recently should say so. The reader should be able to tell whether a model is available, proposed, paused or historic without interpreting an adjective invented by a marketing team.

Purpose and scope fields should describe the work in terms that a non-specialist can understand. They should name intended users where that matters, the kinds of inputs and outputs involved, and the decisions or actions the model may support. They should also state prohibited or unsupported uses. A model that can generate text is not thereby authorised to write an eligibility decision, and a model that can classify documents is not thereby authorised to classify people.

Capability fields need conditions. Modalities, context limits, tool access, language coverage, adaptation behaviour and output marking are meaningful only when tied to a route and a release. A capability that exists in an internal experiment but not in the external route should not be presented as one universal feature. The registry is not a wish list.

Data fields should say what the model receives, what it stores, what it learns from during use and what is used for evaluation, at the level that can be made public without exposing personal or confidential material. Training-content summaries and rights policies should be linked where required. A vague sentence such as trained on diverse data tells a reader almost nothing and asks them to supply a flattering interpretation.

Evaluation fields should identify the question, the method, the data boundary, the date, the result and the limitations. The entry does not need to reproduce every table, but it should not display a score without a denominator or a test without a purpose. A good evaluation link lets a reader see whether the evidence covers the intended use, a neighbouring use or only a laboratory condition.

Oversight fields should identify who can pause, override, review and investigate the system. If a model only recommends, say what action remains with the human. If a route can act on external systems, say which permissions and gates apply. If incident reporting has a dedicated route, publish it. Oversight is not a paragraph about keeping humans in the loop. It is a map of who can do what when the system is uncertain.

Az adat- és integritásmezőknek össze kell kötniük a nyilvános bejegyzést egy verziózott gépi rekorddal, egy kiadási csomaggal, egy nyilatkozattal, egy értékelési csomaggal vagy egy átláthatósági naplóval. A hash azt tudja igazolni, hogy egy fájl megváltozott vagy nem változott. Azt nem tudja igazolni, hogy a fájl tartalma igaz volt, ezért a nyilvántartásnak külön kell kezelnie az állítást és az integritásellenőrzést. A technikai pontosság nem helyettesíti az ítélőképességet, de megkönnyíti az ítélőképesség alkalmazását.

Végül a változásmezőknek meg kell magyarázniuk a történetet. Mi változott, mikor, miért, ki hagyta jóvá, mely útvonalakat érinti, és szükség van-e új értékelésre. A bejegyzésnek lehetővé kell tennie, hogy meg lehessen válaszolni a teremben elhangzó leghétköznapibb kérdést: mi a különbség a múlt hónapban olvasott rekordhoz képest?

Mit tud igazolni egy nyilvántartás

Egy jól karbantartott nyilvántartás igazolni tudja, hogy egy meghatározott objektumot egy megnevezett szolgáltató ír le egy adott rekordverzió alatt. Igazolni tudja a bejelentett célt, állapotot, hozzáférési útvonalat és tulajdonosi viszonyokat. Igazolni tudja, hogy mely kísérő dokumentumok és integritásrekordok tekinthetők meg az olvasó számára, és mely információk vannak szándékosan korlátozva. Igazolni tudja, hogy egy változást közzétettek, és hogy egy korábbi rekord a megadott megőrzési szabály szerint továbbra is elérhető.

Azt is igazolni tudja, hogy a szervezet milyen álláspontot képvisel. Ha egy szolgáltató azt mondja, hogy egy modell döntéstámogatásra szolgál, nem pedig automatikus elutasításra, ez a kijelentés nyilvános határvonalat jelent. Ha egy üzemeltető azt mondja, hogy elkészült egy hatásvizsgálat, a kijelentés kérdést vet fel azzal kapcsolatban, hogy hol található az összefoglaló vagy a korlátozott rekord. Ha egy szolgáltató tervezettként jelöl meg egy kiadást, a címke megakadályozza, hogy a terv történelemként jelenjen meg.

Ezek hasznos tények. Pontosabbá teszik a beszerzést, kevésbé spekulatívvá az integrációt, és könnyebben irányíthatóvá a nyilvános kérdéseket. Ugyanakkor élesebbé teszik a véleménykülönbségeket is. Az olvasó mondhatja, hogy a bejelentett cél túl tág, az állapot elavult, a korlátozás hiányzik, vagy a kísérő bizonyíték nem fedi le az állítást. A nyilvántartás akkor váltja meg az árát, ha lehetővé teszi ezt a kritikát.

Mit nem tud igazolni egy nyilvántartás

Egy nyilvántartási bejegyzés nem tudja igazolni, hogy egy modell pontos minden felhasználó számára, biztonságos minden környezetben, méltányos minden csoporttal szemben, vagy jogszerű minden telepítés esetén. Nem tudja igazolni, hogy egy hatóság a megfelelő eljárást követte pusztán azért, mert egy rendszer szerepel a listán. Nem tudja megmutatni, hogy egy emberi felülvizsgáló megértett egy kimenetet, hogy egy érintett személynek valódi jogorvoslati lehetősége volt, vagy hogy egy incidens időben észlelhető lett volna. Ezekhez a következtetésekhez a használatban lévő rendszerre, az azt használó intézményre és az általa érintett emberekre vonatkozó bizonyítékokra van szükség.

Azt sem tudja igazolni, hogy egy modell független a szállítójától, hogy egy útvonal szuverén, mert Európában üzemeltetik, vagy hogy egy nyílt licenc eltünteti a felelősséget. A tulajdonlás, a joghatóság, az ellátási lánc, az üzemeltetési ellenőrzés és a karbantartás külön kérdések. A nyilvántartás fel tudja tárni azokat a neveket és hivatkozásokat, amelyekkel ezeket fel lehet tenni. Megválaszolni nem tudja őket pusztán tipográfiával.

A nyilvántartás a negatívumot sem tudja bizonyítani. Egy hiányzó bejegyzés jelentheti azt, hogy az objektum kívül esik a hatókörön, hogy valamilyen kizárás vonatkozik rá, hogy a közzététel késik, vagy hogy valaki elmulasztotta a közzétételt. Az olvasónak egyértelmű lefedettségi nyilatkozatra és hibabejelentési útvonalra van szüksége. Egy nyilvános hirdetőtábla csak annyira megbízható, amennyire az a folyamat, amely észreveszi, ha egy hirdetmény hiányzik.

Példa jellegű rekord, nem rejtett esettanulmány

A következő egy példa jellegű rekordterv, nem pedig egy valós szervezetről, modellről vagy eseményről szóló beszámoló. Nem használ fel ügyfelet, hatóságot, telepítési dátumot vagy mért eredményt. Célja annak bemutatása, hogyan juthat el az olvasó egy nyilvános bejegyzéstől egy ellenőrzött bizonyítékútvonalhoz anélkül, hogy a két réteget összekeverné.

  • Azonosító: szolgáltatói név, modellnév, verzió és stabil gépi azonosító.
  • Állapot: ellenőrzött értékelés, hatálybalépési dátummal és megjegyzéssel, hogy külső hozzáférés nem áll nyitva.
  • Cél: dokumentumelemzési támogatás képzett munkatársak számára, az automatikus külső döntések a deklarált hatókörön kívül esnek.
  • Bemenetek és kimenetek: a reprezentált modalitások, a várható forrásanyag-típusok és azok a kimeneti típusok, amelyeket az útvonal elő tud állítani.
  • Korlátok: ismert nyelvi, domain-, frissességi, biztonsági és hozzáférési határok, mindegyik a megfelelő értékeléshez vagy szabályzathoz kapcsolva.
  • Felügyelet: az a szerepkör, amely felfüggesztheti az útvonalat, a bizonytalan eredmények felülvizsgálati folyamata és az incidens kapcsolattartója.
  • Bizonyíték: nyilvános összefoglaló, verziózott műszaki nyilvántartás az arra jogosult felülvizsgálók számára és integritás-manifesztum a közzétett fájlokhoz.
  • Változás: hivatkozás az előző nyilvántartásra, nyilatkozat arról, hogy mi változott, és az a feltétel, amely új értékelést tenne szükségessé.

A nyilvántartás egyetlen sora sem állítja, hogy a modell jó. Azt mondja meg, hogy a szolgáltató mire hajlandó vállalni a felelősséget, hol érvényes ez a vállalás, és hogyan tudja egy másik személy tesztelni vagy megkérdőjelezni. Ez elegendő egy hirdetőtáblához. Az is elegendő, hogy megakadályozza a brosúraszövegek észrevétlen beszivárgását egy jogi vagy működési döntésbe.

Miért érdemel tiszteletet a megjelenés előtti állapot

A megjelenés előtti állapot nem a nyilvános állapot gyengébb változata. Ez egy másik állapot. A belső tesztelés támogathatja a mérnöki és biztonsági munkát, miközben a hozzáférés ellenőrzött marad. A meghívásos béta kívülállóknak is megmutathatja az útvonalat, miközben megőrzi a feltételeket, a hatókört és a leállítás jogát. A nyilvános megjelenés megváltoztatja, hogy ki támaszkodhat a rendszerre, és milyen kötelezettségek hárulnak a szolgáltatóra, az integrátorokra és az üzembe helyezőkre. A nyilvántartásnak láthatóvá kell tennie ezeket az átmeneteket, ahelyett hogy egyetlen harsonaszóként kezelné a megjelenést.

A megjelenés előtti nyilvántartás még mindig hasznos lehet a nyilvánosság számára. Azonosíthatja a modellt, a szolgáltatót, a tervezett útvonalat, az állapotot, a meglévő bizonyítékokat és a még függőben lévő bizonyítékokat. Kimondhatja, hogy egy dátum tervezett, és hogy a hozzáférés még nem nyílt meg. Közzéteheti a megjelenési kaput anélkül, hogy azt állítaná, hogy a kapun már átmentek. Ez különösen jó hely arra, hogy a nyilvántartás unalmas legyen. Az unalmas állapot biztonságosabb, mint az izgalmas kétértelműség.

A Dweve-nél igyekszünk ezt a fegyelmet alkalmazni a saját nyilvános nyilvántartásunkra is. A Trust Centre-ben a modellnyilvántartás megjelenés előtti állapotúként van jelölve, és a Dweve Loom 1.0-t 2026. augusztus 1-jétől belső, csak munkatársaknak szóló megjelenés előtti tesztelésként sorolja fel. Rögzíti, hogy addig a dátumig nem történt külső megjelenés, és 2026. szeptember 1-jét tervezett uniós piaci hozzáférési dátumként sorolja fel egy meghívásos külső béta számára. A tervezett a fontos szó: a bejegyzés nem változtat tervet eseménnyé.

A nyilvános nyilvántartásunk azt is egyértelművé teszi, hogy a Loom az egyetlen ott felsorolt modell, hogy az szabadalmaztatott, nem pedig nyílt forráskódú modelllicenc alatt jelent meg, és hogy a termékeink és a külön licencelt nyílt forráskódú eszközeink nem további modellként vannak bemutatva. Ez a határ megakadályozza, hogy egy termékkatalógust modellnyilvántartásnak nézzenek. Azt is biztosítja, hogy a nyilvános vállalás elég kicsi legyen az ellenőrzéshez.

Ennyit kell itt elmondanunk a Dweve-ről. A modellnyilvántartás akkor hasznos, ha a saját megjelenési állapotunkat kevésbé hízelgővé, de pontosabbá teszi. Ugyanezt kell tennie bárki más számára is.

A nyilvános-magán határvonal tervezési döntés

A legerősebb nyilvántartás nem az, amelyik a legtöbb mezővel rendelkezik. Hanem az, amelyiknek a mezői mögött indok, felelős és határvonal áll. A nyilvános olvasóknak stabil azonosítóra, megadott célra, valós állapotra, elszámoltatható szervezetre, használható linkekre és elegendő korlátra van szükségük ahhoz, hogy megértsék az állítást. A felhatalmazott felülvizsgálóknak mélyebb bizonyítékokra, szabályozott technikai részletekre és hozzáférésre van szükségük az incidensek vagy érzékeny tesztek ellenőrzéséhez. Az üzemeltetőknek titkokra, jogosultságokra és üzemeltetési kézikönyvekre van szükségük, amelyeknek egyáltalán nem lenne szabad a hirdetőtáblán szerepelniük.

Ezeknek a rétegeknek egyet kell érteniük a határvonalon átívelő tényekről. Ha a nyilvános oldal azt mondja, hogy egy útvonal szünetel, a szabályozott nyilvántartásnak azt kell mutatnia, hogy ki szüneteltette és miért. Ha egy technikai fájl elavult, a nyilvános bejegyzésnek nem szabad továbbra is aktuálisként hivatkoznia rá. Ha egy értékelés korlátozott, a nyilvános oldalnak akkor is közölnie kell annak terjedelmét és állapotát. A határvonalnak a részletekhez való hozzáférést kell korlátoznia, nem pedig három összeegyeztethetetlen valóságváltozatot létrehoznia.

Az olvasóknak öt egyszerű kérdést kell tudniuk feltenni, és öt stabil választ kell kapniuk. Mi ez az objektum? Ki felelős érte? Mit tehet? Mi a jelenlegi állapota? Milyen bizonyítékok és jogorvoslati lehetőségek léteznek, ha az állítást megkérdőjelezik? Egy nyilvántartás, amely megválaszolja ezeket a kérdéseket, már intézményi munkát végez. Egy nyilvántartás, amely nem tudja megválaszolni őket, nem menthető meg animált jelvényekkel vagy egy tizenkét szűrős irányítópulttal.

Van egy optimista módja annak, ahogyan az európai modell- és algoritmusnyilvántartások felé mutató mozgást értelmezzük. Nem arról van szó, hogy egy adatbázis megoldja a mesterséges intelligencia irányítását. Hanem arról, hogy a közintézmények olyan helyeket építenek, ahol az állításoknak nevük, dátumuk, felelősük és határuk van. Ezek azok az apró építőelemek, amelyekből nagyobb elszámoltathatósági rendszerek épülnek.

A hirdetőtáblának túl kell élnie a változást

A modellnyilvántartás csak akkor az új nyilvános hirdetőtábla, ha a hirdetmények olvashatók maradnak az időjárás változása után is. Az oldalnak túl kell élnie egy modellfrissítést, egy beszállítóváltást, egy új telepítést, egy korrigált korlátozást, egy visszavont útvonalat és egy nehéz kérdést valakitől, aki nem volt a teremben. Ez azt jelenti, hogy meg kell őrizni az előzményeket, meg kell címkézni a terveket, hivatkozni kell a bizonyítékokra, és meg kell mondani, mit nem tud bizonyítani a nyilvántartás.

A munka kevésbé látványos, mint egy bemutatóoldal. De tartósabb is. Egy nyilvános nyilvántartás, amely megkülönbözteti a modellazonosságot a telepítési állapottól, az állapotot a szándéktól, a dokumentációt a bizonyítéktól és a nyilvános tényeket a szabályozott bizonyítékoktól, többet ad az embereknek, mint megnyugtatást. Útvonalat ad nekik a rendszeren keresztül.

A jó nyilvántartások nem kérik az olvasókat, hogy bízzanak egy színben, egy számban vagy egy híres névben. Az állítást elég szűkre szabják az ellenőrzéshez, a határvonalat pedig elég világosra a megkérdőjelezéshez. Nyomot hagynak azokhoz az emberekhez, akik válaszolni tudnak, azokhoz a nyilvántartásokhoz, amelyek ellenőrizhetők, és ahhoz a döntéshez, amely megváltoztatható. Ez egy nagyon régi polgári gondolat, amely meglehetősen modern fájlformátumba öltözött.

Tegye ki a hirdetményt a táblára. Tegye mögé a bizonyítékot. Őrizze meg a régi hirdetményt ott, ahol valaki még el tudja olvasni. Aztán hagyja, hogy a nyilvánosság döntse el, mit ér a nyilvántartás.

Források