Může regulátor auditovat pohyblivý cíl?

Ano, ale ne tím, že budeme předstírat, že adaptivní systém je statický objekt. Audit potřebuje zachycený stav, ohraničené tvrzení, důkazy s podmínkami a...

Může regulátor auditovat pohyblivý cíl?

Audit smí pořídit fotografii

Pohybující se cíl neuniká kontrole. Uniká pouze tomu druhu kontroly, která položí jednu nadčasovou otázku a očekává jednu nadčasovou odpověď. Tento rozdíl je podstatný. Systémy umělé inteligence se mění několika způsoby najednou. Poskytovatel vydá novou verzi modelu. Nasaditel změní prompt nebo rozhodovací práh. Korpus pro vyhledávání získá nový dokument s pravidly. Pravidlo identity změní, kdo smí volat nástroj. Nástroj získá pole, přijde o pole, nebo začne pod stejným názvem pole vracet jiný význam. Lidský tým změní svůj postup. Svět, který dodává vstupy, se mění, aniž by se kohokoli ptal na svolení správce vydání.

Žádné z toho nedělá audit zbytečným. Činí předmět auditu přesnějším. Otázka nezní, zda organizace dokáže prokázat, že systém zůstane navždy beze změny. To by byl podivný slib i pro kalkulačku napojenou na databázi. Otázka zní, zda organizace dokáže ukázat, jaký systém byl v rozhodné době v provozu, co měl dělat, jaké důkazy toto použití podporovaly, které podmínky tyto důkazy ohraničovaly, kdo vlastnil rozhodnutí a jaká pozdější změna by měla vést k jeho přezkumu.

Audit smí pořídit fotografii. Jen nesmí fotografii nazývat krajinou. Řádný záznam identifikuje stav, který byl prověřen, a uchovává cestu od tohoto stavu k dalšímu. Pak může říci něco užitečného: toto hodnocení se týkalo tohoto modelu, těchto nastavení, této hranice dat, těchto nástrojů, této politiky, tohoto pracovního postupu a tohoto rozhodnutí o vydání. Může také říci něco méně pohodlného a o to cennějšího: závěr se automaticky nepřenesl do dalšího stavu.

To je lepší výchozí bod než známé divadlo neměnných odznaků. Odznak naznačuje, že někdo věc uzavřel. Záznam auditu by měl umožnit vidět, co bylo uzavřeno, na jakém základě, pro jaké použití a jak dlouho tento základ zůstával použitelný. Regulátor nepotřebuje zmrazenou organizaci. Regulátor potřebuje organizaci, která dovede rozlišit zmrazený záznam od živé služby, aniž by jedno nebo druhé považovala za mystický předmět.

Evropská pravidla pro umělou inteligenci už tímto směrem míří. U vysoce rizikových systémů umělé inteligence vyžaduje zákon o umělé inteligenci technickou dokumentaci před uvedením systému na trh nebo do provozu a vyžaduje její průběžnou aktualizaci. Rovněž vyžaduje automatické zaznamenávání relevantních událostí po celou dobu životnosti systému a zdokumentovaný systém monitorování po uvedení na trh, přiměřený technologii a riziku. To nejsou pokyny k pořízení jediného ceremoniálního snímku obrazovky. Jsou to pokyny k vedení stopy důkazů v průběhu změn.

Pohybujícím se cílem je obvykle systém

Je lákavé popsat systém umělé inteligence jako model a pak diskutovat o verzování, jako by nový soubor vah modelu byl celý příběh. To se hodí pro prezentace, ale pro většinu provozních otázek je to nepřesné. Model je důležitá součást. Málokdy je však úplným objektem, jehož chování ovlivňuje člověka, pracovní postup nebo právní povinnost.

Uvažme běžnou trasu pro podporu rozhodování, popsanou zde jako hypotetický příklad, nikoli jako popis skutečného nasazení. Uživatel odešle žádost. Služba vyhledá dokumenty, které smí použít. Model navrhne doporučení. Pravidlo zkontroluje, zda jsou přítomny požadované důkazy. Vyškolený recenzent může doporučení přijmout, upravit nebo odmítnout. Pracovní postup pak zaznamená akci. Pozorovaný výsledek závisí na více než jen na modelu. Závisí na verzích zdrojů, nastavení vyhledávání, oprávněních, znění rozhraní, prahách, pravidlech fronty, lidské pravomoci a hranici akcí.

Změní-li se zdrojový korpus, může model získat jiný faktický základ, aniž by se změnil jediný parametr. Změní-li se prompt, může být model požádán o jiný druh úsudku. Přestane-li obrazovka recenzenta zobrazovat nejistotu, lidský dohled popsaný v souboru rizik už nemusí být dohledem, který lidé skutečně vykonávají. Začne-li integrace automaticky uplatňovat doporučení, systém získal novou pravomoc, i když je odpověď modelu bajtově identická.

Proto rozumný záznam auditu začíná zamýšleným účelem a hranicí systému. Požadavky na technickou dokumentaci podle přílohy IV aktu o umělé inteligenci zahrnují popis zamýšleného účelu, verzí, funkcí monitorování a řízení, validace a testování, řízení rizik, změn provedených během životního cyklu a příslušných metrik výkonnosti. Nejde o to, že každý systém potřebuje katedrálu papírování. Jde o to, že recenzent nemůže posoudit tvrzení, když se předmět, na který se tvrzení vztahuje, tiše mění.

Nazývat širší objekt systémem není způsob, jak práci dodat na důležitosti. Je to způsob, jak se vyhnout kategoriální chybě. Vyhodnocení modelu může odpovědět na otázku o modelu. Audit systému musí odpovědět na otázku o systému. První může zjistit, jak se komponenta chovala za definovaných podmínek. Druhý musí ukázat, jak byl tento komponent propojen s lidmi, daty, pravidly, nástroji a důsledky. Žádné z nich nenahrazuje to druhé. Skóre modelu není popis pracovního postupu, stejně jako dobrý test pneumatik není plán trasy.

Co se auditor skutečně snaží zjistit

Audit měnícího se systému neznamená přehrávat každý okamžik jeho života v zasedací místnosti. Znamená to učinit konkrétní tvrzení ověřitelnými. Byl systém používán v rámci stanoveného účelu? Bylo rozhodnutí o vydání podloženo důkazy odpovídajícími tomuto účelu? Zachovala si organizace informace potřebné k vyšetření sporného výsledku? Vyvolaly významné změny přehodnocení? Zviditelnil monitoring rozdíl mezi neškodnou aktualizací a podstatnou změnou? Mohli odpovědní lidé pozastavit, omezit nebo opravit postup, když důkazy přestaly platit?

To jsou praktické otázky, protože každá má pozorovatelný protějšek. Zamýšlený účel patří do záznamu. Vyhodnocení má sadu testů, konfiguraci, testovanou populaci nebo vstupní hranici, metodu, výsledek a omezení. Rozhodnutí o vydání má vlastníka a podmínky. Změna má identitu, datum, důvod a posouzený dopad. Monitoring má pojmenované signály, prahové hodnoty nebo spouštěče přezkumu. Trasa pozastavení má pravomoc a postup. Detaily se liší, ale auditovatelnost pramení z přeměny abstraktních ujištění na věci, které může někdo jiný zkontrolovat.

Je zde důležitá hranice. Audit nedokazuje, že každý budoucí výstup bude správný, spravedlivý nebo neškodný. Nedokáže proměnit nejistý svět v deterministický. Může zjistit, zda organizace učinila tvrzení dostatečně úzká na to, aby je bylo možné prozkoumat, zda shromáždila důkazy schopné tato tvrzení podpořit a zda si zachovala schopnost je přehodnotit. To může znít skromně. Je to také místo, kde začíná odpovědnost.

Rozdíl mezi důkazem a jazykem ujištění je důležitý. Říci, že model byl vyhodnocen, ještě není důkazem užitečného vyhodnocení. Slovo potřebuje předmět. Vyhodnocen proti kterému úkolu, kritériím a datům? S kterým modelem a stavem systému? Za jakých provozních podmínek? Kdo zkontroloval metodu? Co bylo mimo rozsah? Co by způsobilo, že by výsledek zastaral? Bez těchto otázek je vyhodnocení pouze uklidňujícím minulým časem.

Dřívější pokyny Evropské komise pro důvěryhodnou umělou inteligenci formulovaly reprodukovatelnost jasně: experiment s umělou inteligencí by měl při opakování za stejných podmínek vykazovat stejné chování. To je užitečná definice, protože obsahuje vlastní omezení. Stejné podmínky skutečně znamenají práci. Opakovaný experiment může ukázat, zda je zaznamenané tvrzení reprodukovatelné. Nemůže ukázat, že se nezměněné chování objeví i po změně zdroje dat, zásad nebo způsobu nasazení. Reprodukovatelnost tedy není příslibem, že se svět zastaví. Je to disciplína pro přesné vyjádření toho, co se skutečně stalo.

Zachycené vyhodnocení je okamžik v čase. Audit se stává trvalým, když lze s ním porovnat následující stav.

Číslo verze je nutné, ale ne dostačující

Čísla verzí jsou užitečná, protože zabraňují tomu, aby se záznam tvářil, že názvy stačí. Přesto může označení verze vytvářet falešný pocit jistoty. Označení jako verze 4.2 může identifikovat vydání softwaru, ale nemusí nutně identifikovat skutečný stav trasy umělé inteligence. Hodnota konfigurace může ležet mimo úložiště modelu. Index pro vyhledávání může být znovu sestaven z měnících se dokumentů. Příznak funkce může zvolit jinou cestu nástroje. Modul zásad může změnit povolenou akci. Služba tedy může mít bezvadně naformátované číslo verze a přesto může být obtížně rekonstruovatelná.

Podstatná je identita odpovídající tvrzení. Pokud se tvrzení týká offline benchmarku modelu, mohou být nezbytné artefakt modelu, kód pro odvozování, nastavení parametrů, verze datové sady, definice metriky a prostředí pro spuštění. Pokud se tvrzení týká živé služby pro podporu rozhodování, může záznam navíc potřebovat výzvu nebo šablonu, konfiguraci vyhledávání, identifikátory zdrojů a jejich aktuálnost, stav oprávnění, schémata nástrojů, verzi zásad, rozhraní pro posuzovatele a pravidla pracovního postupu. Balíček auditu nemusí obsahovat každý bajt každého systému. Musí obsahovat nebo spolehlivě odkazovat na prvky, které by mohly změnit význam tvrzení.

Proto je manifest často užitečnější než archiv vysypaný na pevný disk. Manifest říká, které artefakty k sobě patří, jejich identifikátory, odkazy na integritu, vzájemné vztahy a podmínky přístupu. Umožňuje auditorovi najít příslušný balíček bez předpokladu, že každý zdroj lze zkopírovat do neomezené složky. Některé důkazy obsahují osobní údaje, citlivé bezpečnostní informace, licencovaný materiál nebo obchodní tajemství. Auditovatelnost vyžaduje řízený přístup a smysluplnou dohledatelnost, nikoli povinné veřejné zveřejnění všeho, co činí systém funkčním.

Příloha IV zaujímá podobný praktický přístup. Nezachází s technickou dokumentací jako s krátkým popisem produktu. Vyžaduje informace o systému a jeho životním cyklu, včetně změn provedených během vývoje a po uvedení na trh, funkcích monitorování a řízení, postupech a výsledcích validace a testování, opatřeních řízení rizik a popisu metrik výkonnosti. Dokument musí být dostatečně srozumitelný, aby příslušné vnitrostátní orgány a oznámené subjekty mohly posoudit shodu. Jinými slovy, informace musí být uspořádány pro kontrolu, nikoli pouze shromážděny proto, že byl k dispozici úložný systém.

Za tím vším stojí malá, ale zásadní konstrukční otázka: co by se muselo změnit, aby předchozí důkazy již nemohly podporovat současné tvrzení? Odpověď vytváří hranici verze. Pokud nový zdroj vyhledávání změní věcný základ doporučení, patří do identity. Pokud nové rozhraní recenzenta zakrývá varování, patří do identity. Pokud kosmetická úprava textu nemůže ovlivnit hodnocené chování, pravděpodobně patří do historie změn, ale ne do otisku hodnocení. Dobrá správa verzí není maximální sběr. Je to odůvodněná relevance.

Zachyťte kontrakt, nejen výstup

Výstup je důkazem něčeho, ale ne vždy je důkazem dostatečným. Snímek obrazovky může ukázat, co se na obrazovce objevilo. Často však nemůže ukázat, který model jej vytvořil, který zdroj byl načten, co vrátil nástroj, které pravidlo bylo použito, které vstupy byly vynechány nebo zda pohled skryl varování. To je jeden z důvodů, proč se snímky obrazovky hromadí ve složkách pro shodu s vážností archeologických nálezů a s podstatně menší vypovídací hodnotou.

Zachycený kontrakt je bohatší. Spojuje výsledek s podmínkami, za nichž se očekávalo, že systém bude jednat. Pro hodnocení to může zahrnovat přesnou sadu, vstupy nebo chráněný odkaz na ně, očekávaná tvrzení, konfiguraci modelu a služby, příslušné verze politik a nástrojů, prostředí spuštění tam, kde ovlivňuje výsledek, a pravidlo přijetí. Pro živé spuštění to může zahrnovat identitu požadavku, autorizovaný rozsah, záznamy o zdroji a vyhledávání, trasu modelu, volání nástrojů, kontroly, lidský zásah a výslednou změnu stavu. Cílem není zaznamenávat nekonečný deník. Je to zachovat dostatek kauzálně relevantních informací, abychom mohli později položit seriózní otázku.

Je užitečné provést jedno rozlišení. Záznam hodnocení dokládá tvrzení o definovaném testu nebo cvičení. Provozní záznam pomáhá rekonstruovat konkrétní událost nebo rozhodnutí. Záznam vydání vysvětluje, proč organizace umožnila systému vstup do definované trasy. Záznam změny vysvětluje, co bylo později pozměněno. Tyto záznamy se překrývají, ale neměly by být zaměňovány. Zacházet s produkčním protokolem jako s benchmarkem nebo s benchmarkem jako s důkazem produkčního pracovního postupu je účinný způsob, jak každému záznamu přisoudit více, než unese.

Pravidlo protokolování podle aktu o AI pro vysoce rizikové systémy je podobně vázáno na účel. Článek 12 vyžaduje automatické zaznamenávání relevantních událostí po celou dobu životnosti systému, s možnostmi protokolování přiměřenými zamýšlenému účelu. Nařízení odkazuje na sledovatelnost fungování systému, monitorování provozu a monitorování po uvedení na trh. Nevyžaduje bezohledný návyk zaznamenávání. Vyžaduje záznamy s účelem.

To slovní spojení, záznamy s úlohou, je lepším vodítkem než obecný požadavek na sledovatelnost. Identifikátor modelu může pomoci rozlišit aktualizaci. Původ vstupních dat může vysvětlit překvapivé doporučení. Verze pravidla může vysvětlit, proč byl výsledek zablokován. Přepsání rozhodnutí recenzentem může vysvětlit, proč se provozní opatření liší od návrhu modelu. Časové razítko může stanovit pořadí. Návrh respektující soukromí se stále ptá, zda je každé pole nezbytné, přiměřené, uchovávané po stanovenou dobu a chráněné před samotným systémem, který má kontrolovat.

Reprodukovatelnost má dvě poctivé podoby

Lidé často používají slovo reprodukovatelný pro řadu různých věcí. Ten zmatek je pochopitelný. Tým tím může myslet, že dokáže znovu spustit pevně dané vyhodnocení a získat stejné skóre. Výzkumník může myslet, že jiný tým dokáže spustit uvedenou metodu a prozkoumat výsledek. Provozovatel může myslet, že šetření dokáže znovu vytvořit stav použitý pro konkrétní rozhodnutí. Zákazník může myslet, že pracovní postup zajišťuje konzistentní zacházení, které se libovolně nemění od úterý do čtvrtka. Tyto cíle spolu souvisejí. Nejsou to jedna vlastnost v několika podobách.

Zaprvé existuje reprodukovatelnost zachyceného běhu. Pokud jsou artefakt, konfigurace, vstupy, relevantní stav a podmínky spuštění pevně stanoveny, mělo by opakování přinést zdokumentovaný výsledek v rámci podmínek, které systém slibuje. Některé systémy mohou pro definovanou cestu spuštění učinit silnější tvrzení o determinismu. Jiné se spoléhají na řízenou náhodnost, distribuovanou infrastrukturu nebo služby třetích stran a mohou učinit pouze užší tvrzení. Odpovědný jazyk je konkrétní. Říká, co je pevně dané, co se měří, jaká variace zůstává možná a jak se provádí srovnání.

Zadruhé existuje reprodukovatelnost vyhodnocovacího argumentu. Recenzent musí vidět, proč sada představuje dané tvrzení, zda má metrika uvedený význam, zda je přijímací práh odůvodněný a zda lze důkazy přenést do provozního kontextu. Toto nevyřeší kontrolní součet. Kontrolní součet může prokázat, že se soubor nezměnil. Nemůže prokázat, že soubor testoval správnou otázku, že populace byla vhodná nebo že skóre podporuje rozhodnutí, k němuž je přiřazeno.

Obě podoby by se měly setkat. Dokonale opakovatelný test, který měří špatnou věc, je stále špatný test. Sofistikovaný argument připojený k neopakovatelnému běhu nenechá recenzenty rozlišit nález od šťastného odpoledne. Užitečný standard není abstraktní požadavek na dokonalou reprodukovatelnost. Je to viditelná korespondence mezi tvrzením, metodou, zachycenými podmínkami, pozorovaným výsledkem a použitím, které organizace chce povolit.

Pokyny Komise týkající se povinností poskytovatelů modelů umělé inteligence pro obecné účely také udržují vyhodnocování propojené s dokumentací a rizikem. Popisují technickou dokumentaci pro orgány a samostatné informace pro navazující poskytovatele, včetně schopností, omezení a integračních informací. U modelů umělé inteligence pro obecné účely se systémovým rizikem vyžaduje článek 55 vyhodnocení pomocí standardizovaných protokolů a nejmodernějších nástrojů, včetně zdokumentovaného adversariálního testování k identifikaci a zmírnění systémových rizik. Vyhodnocení, které nedokáže říci, co bylo testováno, za jakých podmínek a s jakými omezeními, se nazváním standardizované nestane užitečnějším.

Důkazy mají podmínku vypršení platnosti

Důkazy nepozbývají platnosti proto, že se někdo rozhodl být obtížný. Pozbývají platnosti tehdy, když se podmínky, které jim umožňovaly podporovat tvrzení, změnily natolik, že toto spojení již nelze předpokládat. To je běžné uvažování. Zkouška návrhu mostu se automaticky nevztahuje na jiný materiál. Kontrola bezpečnosti potravin nepokrývá nového dodavatele silou optimismu. Hodnocení trasy AI by se nemělo automaticky vztahovat na změněný model, změněnou hranici dat, změněnou autoritu nástrojů ani změněné důsledky rozhodnutí.

Obtížná práce spočívá v rozhodování, které změny jsou podstatné. To je věc technického úsudku, analýzy rizik a řízení, nikoli jediného procenta zapsaného do politiky. Oprava, která změní barvu tlačítka, nemusí mít na hodnocení žádný vliv. Změna, která činí varování méně viditelným, může být podstatná, pokud bezpečnostní argument závisí na tom, že ho recenzent uvidí. Přeindexování zdrojového korpusu může být pro jeden úkol neškodné a pro jiný kritické. Nový koncový bod modelu může zachovat širokou schopnost, ale změnit latenci, chování při odmítání, jazykové pokrytí nebo vzorce používání nástrojů, které jsou pro trasu důležité.

Užitečná kontrola změn proto začíná otázkou dopadu, nikoli rituálem vydání. Jaké tvrzení by tato změna mohla ovlivnit? Který předpoklad narušuje? Které důkazy byly podmíněny předchozím stavem? Odpoví na otázku ohraničená kontrola, nebo trasa potřebuje nové hodnocení a rozhodnutí o vydání? Kdo může toto rozhodnutí učinit a kdo je může napadnout? Odpovědi by měly být zaznamenány, protože jinak je bude muset příští recenzent odvozovat z názvů tiketů, ústní tradice a mírné změny písma použitého na řídicím panelu vydání.

Právě zde se monitorování stává součástí důkazů, nikoli samostatným koníčkem pozorovatelnosti. Článek 72 vyžaduje, aby poskytovatelé vysoce rizikových systémů AI aktivně a systematicky shromažďovali, dokumentovali a analyzovali relevantní údaje o výkonnosti po celou dobu životnosti systému, aby mohli vyhodnocovat průběžnou shodu. Plán monitorování po uvedení na trh je součástí technické dokumentace. Monitorování tedy není pouze způsob, jak zjistit, zda je služba vytížená. Je to způsob, jak se dozvědět, zda podmínky stojící za původním tvrzením nadále platí.

Monitorování nečiní každý výsledek samovysvětlujícím. Nárůst neshody mezi recenzenty a systémem může mít mnoho příčin. Změna čerstvosti zdrojů může odrážet problém s datovým potrubím spíše než drift modelu. Vyšší míra odmítání může představovat bezpečnější politiku, přerušenou integraci nebo novou populaci požadavků. Záznam by měl zachovat dostatek kontextu pro lidské vyšetřování. Metriky jsou signály. Nejsou svědky.

Důkazy jsou platné v definovaném kontextu. Podstatná změna vytváří otázku k přezkumu, nikoli mezeru obcházející přezkum.

Podstatná změna vyžaduje cestu rozhodování

The phrase material change is often treated as if it names a self-evident property. It does not. Material to which claim, risk and user? The answer must be specific enough that people can use it when they are tired, late and keen to call a change minor. A good policy does not promise to classify every possible update in advance. It names the factors that determine whether reassessment is needed.

Those factors usually include intended purpose, affected people, authority granted to the route, data sources and their quality controls, model or system architecture, evaluation scope, decision thresholds, monitoring signals, human oversight, security controls and recovery paths. A modification that changes any of these may or may not be material. What matters is whether it can alter the evidence required for the existing claim or the risk left after controls.

The AI Act contains an explicit responsibility around substantial modification. Its exact legal application depends on the system and actors involved, so it should not be compressed into a slogan. The operational lesson is simpler and broader: an organisation should know when a change transfers or creates responsibility, when the existing documentation is no longer adequate, and when the system must be assessed again before a new use continues. It is less exciting than a feature launch. It is also less likely to produce a difficult call in which everyone agrees the system changed but nobody owns the decision.

A decision path gives a change somewhere to go. One path may permit a documented no-impact finding. Another may require a targeted regression evaluation. Another may require a broader risk review, a change to instructions for use, a revised monitoring plan or a fresh release approval. The most serious path may require the route to remain limited or paused until evidence is available. The point is not to make every edit expensive. It is to make the important edit impossible to disguise as routine housekeeping.

There is a satisfying lack of romance in this. A change record can show the previous state, the proposed state, the affected claims, the evidence reviewed, the decision, the authority and the conditions after release. That is governance in its working clothes. It will never look as thrilling as a model demonstration. It has the more useful property of helping an organisation explain itself when a demonstration has become a real service.

Evaluation should be able to fail in public, or at least in the file

Evaluation becomes performative when every result is assumed to be a release result. A mature evaluation programme must be able to conclude that evidence is incomplete, that a threshold was missed, that a known limitation prevents a proposed use, or that a claim needs narrowing. These are not embarrassing exceptions to the process. They are outputs of the process.

That is particularly important for adaptive or externally connected systems. A team may discover that a suite no longer represents a live input population. A tool contract may become too unstable to support a replay claim. A model update may improve one task but make a protected route harder to supervise. An operational signal may show that the hand-off from system to reviewer fails under ordinary workload. The right answer is not necessarily a dramatic shutdown. It may be a limit, a revised workflow, a further test, a new acceptance condition or a decision not to make the original claim.

The record must let a reviewer see that negative result. Otherwise an organisation builds a very effective machine for collecting only the evidence it likes. The quality-management requirements in Article 17 are relevant here. They cover, among other things, techniques and procedures for design, development and quality control; examination, test and validation; data management; risk management; post-market monitoring; incident reporting; and communication with authorities. A quality system is not a folder that makes failures disappear. It is a way to detect, document and address them.

The same principle governs access. An external regulator, notified body or authorised reviewer may need technical evidence that cannot be published openly. A public summary may be appropriate for other parts of the record. These are different access routes, not different facts. The public should not be offered a cheerful account while the controlled record describes a narrower and more conditional reality. Confidentiality can be legitimate. Contradiction is a governance failure.

At Dweve, our public Trust Centre makes a small, deliberately limited example of this distinction. Its evaluations page says that an evaluation identifies the model, exact suite, configuration, captured state, evidence and reviewer decision. It also says that a repeated captured contract should produce byte-identical results on supported architectures, while a live rerun can differ when external evidence or adaptive state changes. The page separates the public method from a filled-in marketing result. That is not proof of a model's quality. It is simply the right shape of a claim about evaluation records.

Live monitoring is not a substitute for a pre-release decision

Monitoring is sometimes described as the answer to uncertainty: release the system, watch the dashboard, improve continuously. There is a useful instinct in that sentence. Systems need observation after release because deployment produces information that a laboratory cannot. But monitoring cannot retroactively support a decision for which the evidence was never adequate. It cannot tell a person affected by a flawed high-consequence action that the organisation will learn from the graph next month.

Pre-release evaluation and post-release monitoring answer different questions. Evaluation asks whether the organisation has enough evidence to permit a defined use now. Monitoring asks whether the conditions behind that permission still hold and whether new risks or failures are emerging. The first establishes a starting boundary. The second watches the boundary in operation. A credible system needs both, as well as a route for data and operational learning to return to risk assessment, documentation and change control.

That loop is what turns a static assurance packet into a living record. An evaluation gives a baseline. A deployment record says which baseline was adopted. Logging and monitoring show relevant behaviour. A change may alter the baseline or reveal its limits. A review then updates the claim, its evidence, its constraints or its status. The system moves. The record moves with it, but does not rewrite its own past. An auditor can see both the current position and the path by which it arrived there.

For high-risk systems, the AI Act is explicit that post-market monitoring should gather and analyse relevant performance data throughout the lifetime and allow continuous compliance to be evaluated. It also requires deployers to monitor operation based on instructions for use, and to inform the provider and relevant authority without undue delay where they have reason to consider that use may present a risk. Those requirements do not remove the need for professional judgement. They give professional judgement records, triggers and routes.

Existuje organizační pokušení považovat monitorování za odpovědnost provozního týmu a hodnocení za odpovědnost týmu modelů. Toto rozdělení selže u první smysluplné otázky o živé trase. Tvůrce modelu může vědět, proč byl test zvolen. Operátor může vědět, že zdroje byly zastaralé. Vlastník politiky může vědět, že se změnilo rozhodovací pravidlo. Recenzent může vědět, že rozhraní vytváří automatizační zaujatost. Auditní stopa by měla spojit jejich důkazy, aniž by předstírala, že jeden člověk vidí celý systém.

Může regulátor reprodukovat rozhodnutí?

Odpověď by někdy měla být ano, ve vymezeném rozsahu. Pokud organizace tvrdí, že rozhodnutí nebo hodnocení lze přehrát, musí uvést, co přehrání znamená. Znamená to opakování volání modelu se stejným promptem? Znamená to znovupostavení celé sekvence vyhledávání a nástrojů? Znamená to rekonstrukci záznamu, který viděl recenzent? Znamená to ověření deterministického výpočtu z uchovaných vstupů? Každá možnost je užitečná. Každá má jiné technické a právní předpoklady.

Smysluplné přehrání začíná uchovanou identitou. Recenzent potřebuje vědět, která verze systému a konfigurace byly v platnosti, které vstupy a verze zdrojů byly přípustné, které politiky a oprávnění se uplatnily, které externí závislosti odpověděly a které lidské akce změnily cestu. Některé prvky může být nutné uložit přímo. Jiné lze odkazovat pomocí stabilních identifikátorů a rekonstruovat prostřednictvím řízených systémů. Co není přijatelné, je nazývat cvičení přehratelným, když závisí na živém webovém vyhledávání, přepsaném řádku databáze a zapamatovaném nastavení z notebooku inženýra.

I tehdy může přehrání reprodukovat záznam, nikoli opakovat svět. Živý zdroj může být aktualizován nebo odebrán. Služba třetí strany se může změnit. Adaptivní služba může nashromáždit nový řízený stav. Člověk může učinit jiný úsudek, když mu jsou předloženy stejné informace. To nejsou vady myšlenky přehrání. Jsou to rozdíly, které musí záznam zachovat. Přehrání může ukázat, co systém udělal na základě zachycené smlouvy. Netvrdí, že současný svět je totožný s touto smlouvou.

Proto záznamy o lidských rozhodnutích patří vedle technických záznamů, když je lidský dohled součástí argumentu o bezpečnosti nebo právech. Audit může potřebovat vědět, že osoba přezkoumala doporučení, jaké informace měla k dispozici, co zvolila a jakou pravomoc měla. Není třeba z každého recenzenta dělat cíl sledování ani uchovávat neomezený osobní materiál. Je třeba dostatek informací k prokázání, že slíbený dohled v dané události existoval.

Reprodukce je tedy žebřík, nikoli chlouba. Na jednom stupni může recenzent identifikovat vydání. Na dalším může prozkoumat důkazy. Výše může znovu vytvořit test nebo analyzovat živou rozhodovací cestu. Organizace by měla uvést, který stupeň podporuje, kde jsou limity a které části vyžadují autorizovaný přístup. Skromné, testovatelné tvrzení o přehrání je mnohem silnější než vágní ujištění, že vše je dohledatelné.

Audity potřebují záznamy, které si vzájemně odporují

Veřejný záznam o stavu organizace, interní záznam o vydání, zpráva o hodnocení, provozní protokoly a registr incidentů by neměly říkat různé věci o stejném základním stavu. Ale neměly by to být ani identické dokumenty. Každý má jiné publikum a účel. Veřejný záznam může uvádět zamýšlený účel, stav, známá omezení a cestu k dalším informacím. Technický soubor může obsahovat podrobnou architekturu, data, testy a kontroly. Provozní záznam může obsahovat sledovatelnost na úrovni událostí. Soubor změn může vysvětlit, proč byl dřívější závěr přehodnocen.

The integrity comes from correspondence. If a public page says a route is limited to recommendation, the technical and operational records should not describe automatic action. If an evaluation says it concerns a captured source set, the release record should not silently apply it to a later one. If a change record says a model update was immaterial, the impact assessment should state the affected claim and evidence. If a monitoring signal raises a review, the subsequent decision should be traceable. The documents may disagree in granularity. They must not disagree about reality.

That correspondence is useful for regulators because it reduces the need to trust one polished artefact. A reviewer can compare records. It is useful for organisations because it exposes drift between teams before an external audit does. And it is useful for affected people because the public explanation can become a real route to accountability rather than a decorative layer placed over a separate private system.

The architecture does not have to be elaborate. A small organisation may use a controlled register, versioned documents, signed exports and disciplined change reviews. A larger organisation may use structured manifests, append-only logs, policy engines and automated evidence capture. The important question is whether the method can reliably connect claim, state, evidence, decision and later change. A gigantic tooling estate that loses this relationship is simply a more expensive way to be vague.

There is a particularly European virtue in making the record inspectable without making it theatrical. Not every answer belongs on a public dashboard. Not every documented uncertainty needs a cheerful icon. But when an organisation has made a consequential claim about an adaptive system, it should be able to show a regulator where that claim lives, what state it referred to, and how the organisation would know that it had become stale.

The audit question changes the design question

Ask early whether a regulator could audit the system as it will actually operate. The answer changes design choices well before a formal audit begins. It favours stable identifiers over ambiguous labels. It favours explicit policy versions over rules embedded in prose. It favours tool contracts that can be recorded and tested. It favours source provenance and freshness markers. It favours a clear boundary between recommendation and action. It favours review screens that preserve the information a reviewer needs. It favours pause and recovery mechanisms with named authority.

It also changes procurement. A supplier's statement that a model is regularly improved is not enough when the deployment depends on a defined evaluated state. The buyer needs to know how changes are notified, what artefacts can be identified, which information is available for impact assessment, whether historical records remain interpretable, and how a route can be limited or paused. These are not exotic demands. They are the practical terms under which an organisation remains responsible for a system that contains a supplier component.

The same question changes evaluation design. A useful suite has an identity and a rationale. Its inputs or references are controlled. Its metrics and thresholds are defined before the result is read. Its exclusions are visible. Its results attach to the system state actually under discussion. Its failures have a route into a decision. Its re-run conditions are clear. An evaluation with these properties can be challenged. That is a feature, not an unfortunate side effect of being thorough.

Především tato otázka mění roli změny. Změna přestává být rozpakem, který se dokumentace snaží skrýt. Stává se událostí první kategorie v modelu důkazů systému. Některé změny si vyžádají jen málo víc než záznam. Některé spustí test. Některé znovu otevřou rozhodnutí o vydání. Disciplinovaná organizace tyto kategorie nezaměňuje a nepotřebuje budoucí incident, aby zjistila, že existovaly.

Takže ano: regulátor může auditovat pohyblivý cíl. Audit začíná odmítnutím falešné volby mezi zmrazeným modelem karty a zcela nepoznatelnou živou službou. Zachyťte stav. Uveďte tvrzení. Zachovejte podmínky. Propojte důkazy s rozhodnutím. Zaznamenejte, co se mění. Přehodnoťte, když propojení již neplatí. Cíl se může pohybovat. Stopa musí zůstat čitelná.

Zdroje