Budoucnost Change Enablement může být governance výjimek, ne každé změny CIO MAG

Na pravidelném CAB je 84 ticketů. Prvních šedesát popisuje malé deploymenty stejného typu. Každý už má konkrétní commit, schválený pull request, průchod testů, security scan, policy výsledek, identitu artefaktu a automatický canary. Přesto se na poradě znovu čte název služby, termín a věta „rollback připraven“.

Mezi nimi leží jedna změna, která zavádí novou třídu osobních údajů, mění privilegované oprávnění a obsahuje databázový krok, jehož návrat nebyl ověřen. Dostane přibližně stejnou dobu jako běžná konfigurace. Formálně prošly všechny změny stejnou governance. Prakticky se lidská pozornost rozptýlila mezi případy, které už technický systém uměl rozhodnout, a výjimku, která skutečné rozhodnutí potřebovala.

To není argument pro zrušení Change Enablement. Je to argument pro změnu jeho jednotky práce. Centrální funkce nemusí autorizovat každý jednotlivý deployment, jestliže předem schválila cestu, která přesně určuje povolené typy změn, povinné důkazy, rizikové hranice a podmínky zastavení. Její nejcennější práce pak začíná tam, kde standardní cesta selže, neplatí nebo narazí na trade-off, který automatizace nesmí přijmout sama.

Manažerské shrnutí

01Standardní cesta může být předem autorizovaná Verzování, nezávislé review, testy, policy, řízený rollout a provozní důkaz mohou společně autorizovat opakovatelnou třídu změn.

02Lidské schválení patří k nejistotě Výjimka, nová třída rizika, nevratnost, chybějící důkaz nebo obchodní trade-off vyžadují konkrétního vlastníka rozhodnutí.

03Change funkce musí řídit guardrails Její produkt tvoří risk model, evidence contract, pravidla výjimek, kontrola účinnosti a převod opakovaných odchylek do lepší standardní cesty.

Change Enablement nezmizí. Změní se jednotka governance

PeopleCert popisuje účel Change Enablement jako maximalizaci úspěšných změn prostřednictvím přesného posouzení rizika, autorizace změn a řízení harmonogramu. Tato odpovědnost zůstává. Nemusí však být naplněna tím, že stejná skupina lidí ručně schválí každý deployment.

PeopleCert zároveň v textu o propojení DevOps a ITIL uvádí, že změny mají být autorizovány lidmi co nejblíže práci nebo pomocí automatizovaných kontrol. DORA jde ještě dál: externí schvalování přes CAB nebo seniorního manažera spojila s horší výkonností dodávky a nenašla důkaz, že formálnější externí review souvisí s nižším change fail rate. Doporučuje peer review, automatické testy, průběžnou integraci a observability; CAB ponechává koordinaci, zlepšování procesu a významné obchodní trade-offy.

Jednotka governance	Tradiční těžiště	Možné nové těžiště
Jednotlivý deployment	Ticket, schůzka a ruční souhlas před každým provedením.	Předem schválená třída změny a technicky vynucený evidence contract.
Riziko	Obecný štítek low / medium / high vyplněný žadatelem.	Strojové i lidské triggery odvozené z dat, oprávnění, vratnosti, blast radiusu a kritičnosti.
Autorizace	Kliknutí osoby, která často nezná konkrétní technologii.	Nezávislé review a automatické kontroly přesného artefaktu; člověk rozhoduje pouze nesplněnou hranici.
Audit	Ručně opsaný popis změny a seznam schvalovatelů.	Propojený řetězec commitu, review, testů, policy rozhodnutí, identity artefaktu, deploy logu a runtime výsledku.
Centrální change funkce	Fronta jednotlivých žádostí.	Vlastník risk modelu, guardrails, výjimek, vzorkování a continual improvement.

AUTORSKÝ MODEL

„Governance výjimek“ zde není oficiální název jedné ITIL nebo NIST metodiky. Je to autorský provozní model: standardní cestu autorizovat předem prostřednictvím schválených kontrol a lidskou rozhodovací kapacitu soustředit na odchylky, nová rizika a vědomé přijetí reziduálního rizika.

Standardní cesta musí vyrábět důkaz, ne pouze zelený stav

DORA chápe continuous delivery jako schopnost uvolňovat změny rychle, bezpečně a udržitelně a spojuje ji s test automation, deployment automation, pervasive security, verzováním a observability. [4–8] Samotný zelený pipeline badge ale není důkaz. Důkaz vzniká teprve tehdy, když lze zpětně zjistit, která kontrola běžela nad kterým artefaktem, s jakými vstupy, podle které verze politiky a s jakým výsledkem v produkci.

Vrstva	Minimální důkaz	Co prokazuje	Co neprokazuje
1. Záměr	Vlastník, důvod, akceptační podmínka a vazba na změnový artefakt.	Proč má změna vzniknout a kdo vlastní výsledek.	Že navržený technický rozsah skutečně odpovídá záměru.
2. Přesný artefakt	Verzovaný commit, diff a neměnný identifikátor verze.	Co se navrhuje změnit a jak se návrh vyvíjel.	Že právě tento commit byl sestaven a nasazen.
3. Nezávislé review	Reviewer odlišný od autora, komentáře a finální schválení.	Segregaci povinností a odborné posouzení návrhu.	Že reviewer měl správný kontext nebo review nebylo pouze formální.
4. Testy	Výsledek funkčních, integračních, performance a regresních kontrol.	Že definované scénáře prošly nad konkrétní verzí.	Že testy pokrývají neznámé failure modes nebo nejsou flaky.
5. Security a policy	Scan, pravidlo, verze policy, input a rozhodnutí allow / deny.	Že známé požadavky byly vyhodnoceny konzistentně.	Že policy je správná, aktuální a pokrývá nový typ rizika.
6. Provenance	Identita buildu, builderu, vstupů, podpis a vazba na artefakt.	Kde, kdy a jak byl artefakt vytvořen.	Že artefakt plní obchodní účel nebo je provozně bezpečný.
7. Progressive delivery	Kroky rolloutů, omezený blast radius, prahy a auto-abort.	Že dopad byl ověřován postupně na reálném provozu.	Že zvolené metriky zachytí každý významný regresní efekt.
8. Observability	SLI/SLO, logy, metriky, traces a post-deploy ověření.	Co se po změně skutečně stalo a zda se chování odchýlilo.	Že nepozorovaný nebo pomalý dopad neexistuje.
9. Obnova	Ověřený rollback/roll-forward, vlastník a rozhodovací trigger.	Jak firma omezí dopad po zjištění problému.	Že všechny datové a externí účinky jsou fakticky vratné.

KONTROLNÍ PRAVIDLO

Pipeline může předautorizovat změnu pouze tehdy, když zelený výsledek znamená, že známé kontroly skutečně proběhly nad přesně identifikovaným artefaktem. „Vše prošlo“ bez dohledatelné verze, vstupů a výsledku je barva rozhraní, nikoli auditní důkaz.

Předautorizace není absence autorizace

NIST SP 800-53 u configuration change control požaduje určit kontrolované typy změn, posoudit dopad, změny schválit nebo zamítnout, implementovat je, uchovat záznamy a průběžně kontrolovat provedení. Katalog zároveň obsahuje rozšíření pro automatizovanou dokumentaci, zákaz změn, testování, implementaci a reakci. Z toho neplyne, že každá autorizace musí být ruční. Plyne požadavek, aby organizace předem určila, kdo a jak smí změnu povolit a jak bude toto rozhodnutí doloženo.

Branch protection a required status checks mohou například zabránit merge bez schváleného review a požadovaných kontrol. Deployment environments mohou přidat oddělené ochrany pro citlivé prostředí. OPA umožňuje vyjádřit rozhodovací pravidla jako kód a decision logs uchovat vstup, použitou policy a výsledek. SLSA provenance váže artefakt k jeho buildu a zdrojům. [14–18] Každý z těchto mechanismů řeší jen část autorizace; společně však mohou vytvořit přesnější důkaz než pozdější ruční přepis do ticketu.

Otázka	Ruční model po jednotlivých změnách	Předautorizovaný model
Kdo autorizuje?	Konkrétní schvalovatel v ticketu nebo na CAB.	Předem určený vlastník change class; konkrétní instanci autorizuje kombinace nezávislého review a kontrol.
Co je autorizováno?	Textový popis, který se může lišit od skutečného diffu.	Přesný commit, artefakt, prostředí a definovaný rozsah změny.
Podle čeho?	Zkušenost schvalovatele a obecná risk klasifikace.	Verzovaný risk model, policy, testy, evidence contract a jasné exception triggery.
Kde je záznam?	Komentář, stav ticketu a zápis z porady.	Vývojová platforma, policy decision log, provenance, deploy log a provozní telemetrie.
Kdy vstoupí člověk?	Před každým deploymentem bez ohledu na typ změny.	Když důkaz chybí, kontrola selže, změna překročí hranici nebo je potřeba přijmout reziduální riziko.

ROZHODOVACÍ PRAVIDLO

Centrální change autorita neschvaluje „automatizaci obecně“. Schvaluje konkrétní verzi standardní cesty: povolené změnové třídy, povinné důkazy, vlastníky kontrol, prahy rizika, bypass pravidla, retenci záznamů a podmínky, za nichž automatická autorizace okamžitě přestává platit.

Výjimka začíná tam, kde důkazní řetězec přestává platit

Výjimkou není každý neúspěšný test. Jestli povinná kontrola změnu zastaví, standardní cesta zafungovala správně. Výjimka vzniká ve chvíli, kdy někdo žádá pokračovat navzdory chybějící, nesplněné nebo neaplikovatelné kontrole, případně když risk model nedokáže situaci spolehlivě zařadit.

Exception trigger	Proč standardní důkaz nestačí	Potřebné lidské rozhodnutí
Bypass nebo failed control	Žadatel chce obejít review, test, scan, policy nebo ochranu prostředí.	Kdo vlastní porušený kontrolní cíl a jaké kompenzační opatření přijímá.
Out-of-band změna	Zásah vzniká v konzoli, na serveru nebo mimo verzovanou cestu.	Zda je nouzový zásah oprávněný, jak se zachytí a jak se stav vrátí pod správu.
Nová třída dat nebo privilegia	Stávající policy nezná nový účel, datový tok, oprávnění nebo trust boundary.	Privacy, security a business vlastník musí určit nový standard nebo jednorázovou hranici.
Obtížná vratnost	Datová migrace, externí účinek nebo fyzická změna nemusí mít skutečný rollback.	Zda lze přijmout point of no return, jaký je stop trigger a obnova.
Vysoký blast radius	Lokálně správná změna může ovlivnit mnoho služeb, zemí nebo zákazníků.	Rozsah rolloutů, koordinace, krizový mandát a vlastník podnikové expozice.
Chybějící provozní signál	Canary běží, ale metriky neumějí rychle rozlišit úspěch a regresi.	Zda rollout odložit, omezit, monitorovat ručně nebo přijmout dočasné riziko.
First-of-kind změna	Nová architektura, dodavatel nebo failure mode nemá ověřenou historii.	Kdo schvaluje experiment, omezení rozsahu a podmínky návratu do standardu.
Emergency	Časové riziko incidentu převyšuje běžnou dobu ověření.	Které kontroly lze zkrátit, které nikoli a kdo přebírá krizové riziko.
Konflikt mezi cíli	Rychlost, dostupnost, regulace a obchodní dopad vedou k různým odpovědím.	Vědomý trade-off na úrovni člověka s odpovídajícím mandátem.
Opakovaná dočasná výjimka	Odchylka už není jednorázová; standardní cesta neodpovídá skutečné práci.	Zda změnit guardrail, odstranit příčinu nebo výjimku ukončit.

HRANIČNÍ PODMÍNKA

Manuální schválení má mít pojmenovatelný důvod. Pokud schvalovatel neumí říct, která nejistota, porušená kontrola nebo podniková expozice vyžaduje jeho úsudek, pravděpodobně pouze opakuje rozhodnutí, které už technický systém provedl.

Governance výjimek potřebuje vlastní životní cyklus

NIST CSF 2.0 výslovně uvádí, že změny a výjimky mají být řízené, posouzené z hlediska rizika, zaznamenané a sledované. Implementační příklady doporučují dokumentovat riziko výjimky, plán reakce, kompenzační kontroly a pravidelně přezkoumávat dříve přijaté riziko. Výjimka proto nemá být volný komentář „schváleno na 30 dní“. Potřebuje vlastní kontrakt.

Pole výjimkové karty	Minimální obsah
Porušená nebo neaplikovatelná kontrola	Přesné pravidlo, test, review, policy nebo provozní podmínka, kterou změna nesplňuje.
Rozsah	Konkrétní služba, artefakt, prostředí, data, uživatelé a časové okno; nikoli obecná formulace.
Obchodní důvod	Proč je pokračování nyní hodnotnější než odklad nebo návrat k bezpečné variantě.
Vlastník rizika	Jedna role s pravomocí přijmout důsledky; ne pouze technický realizátor.
Reziduální riziko	Co může selhat i po zavedení všech dostupných opatření a jaký bude dopad.
Kompenzační kontroly	Dočasné omezení rozsahu, zvýšený monitoring, další review, feature flag, manuální dohled nebo zákaz určité operace.
Stop trigger	Měřitelná podmínka, při níž se změna zastaví, vrátí nebo přejde do incidentního režimu.
Expirace	Datum a událost ukončení; po expiraci nesmí výjimka mlčky pokračovat.
Nápravný plán	Vlastník, termín a backlog položka, která odstraní potřebu výjimky nebo upraví standard.
Historie opakování	Kolikrát, kde a z jakého důvodu byla stejná odchylka už použita.
Rozhodnutí a důkaz	Kdo rozhodl, na základě kterých podkladů, jaký artefakt byl nasazen a co ukázal provoz.

Novým produktem change funkce jsou guardrails a risk model

Centrální change tým se v tomto modelu nemění v administrátora výjimkového formuláře. Stává se vlastníkem kontrolního systému. Potřebuje technické, provozní, bezpečnostní i obchodní kompetence a musí umět rozhodovat o tom, které riziko lze převést do automatického pravidla a které zůstane vědomým lidským trade-offem.

Dnešní těžiště	Budoucí těžiště	Hmatatelný výstup
Čtení a schvalování ticketů	Taxonomie změn a risk model.	Povolené třídy, risk faktory, váhy, prahy a explicitní exception triggery.
Kontrola každého deploymentu	Certifikace standardních cest.	Schválený evidence contract pro konkrétní technologii, prostředí a kritičnost.
CAB kalendář	Koordinace skutečných závislostí.	Pravidla pro cross-domain, regulatorní, zákaznické a časově kolizní změny.
Compliance checklist	Účinnost kontrol.	Test pokrytí, false positives, false negatives, bypass události a pravidelná recertifikace policy.
Emergency bypass	Rychlá standardní cesta pro incident.	Předem určený krizový mandát, neměnné minimální kontroly a automatický post-change review.
Příprava auditu	Průběžný důkaz a vzorkování.	Retence, integrita, vazba artefaktů a nezávislé testy, že záznam odpovídá skutečnosti.
Schvalování výjimek	Řízení jejich životního cyklu.	Vlastník rizika, kompenzační kontrola, expirace, opakování a převod do improvement backlogu.

DORA tuto změnu popisuje jako posun CAB od gatekeepera k procesnímu architektovi a informačnímu uzlu. V praxi jde ještě o krok dál: centrální funkce musí řídit guardrails jako produkt. Každé pravidlo má uživatele, vlastníka, verzi, testy, provozní telemetrii, náklady na falešné blokace a známé mezery.

Guardrails se mohou pokazit stejně jako kód

Automatizace nepřenáší odpovědnost z člověka na nástroj. Přenáší opakované rozhodnutí do jiného artefaktu. Test může být mělký nebo flaky, review se může změnit v rubber stamp, policy může zastarat, provenance může přesně doložit špatný build a canary může sledovat metriku, která nevidí skutečný dopad. [18–22]

Zdání kontroly	Skutečné riziko	Co má ověřovat centrální funkce
„Všechny testy prošly.“	Testy nepokrývají relevantní scénář nebo začaly běžně selhávat bez významu.	Mutation/coverage signály, flaky rate, defect escape a pravidelné odstranění nehodnotných testů.
„PR má dvě approval.“	Revieweři neměli doménový kontext nebo schválili příliš velký diff bez skutečného čtení.	Velikost změn, čas review, vlastnictví kódu, kvalitu komentářů a opakované post-review opravy.
„Policy dovolila změnu.“	Policy je chybná, zastaralá, neaktivní nebo ji lze obejít jinou cestou.	Verzi, testy policy, rollout pravidel, decision logs, bypass role a pokrytí skutečných deploymentů.
„Artefakt má provenance.“	Provenance dokládá původ, nikoli funkční, bezpečnostní nebo obchodní správnost.	Důvěryhodnost builderu, podpis, vazbu na schválený commit a další kontrolní vrstvy.
„Canary byl zelený.“	Vzorek byl malý, signál pomalý, prah špatný nebo dopad vznikl až po delším čase.	Kvalitu SLI, čas detekce, dry-run analýzy, velikost blast radiusu a pozdní regresní efekty.
„Observability nic neukázala.“	Systém neměří správnou věc nebo nemá korelaci mezi změnou a dopadem.	Coverage telemetrie, change markers, SLO, data quality a pravidelné ověřování detekčních scénářů.
„Pipeline je zdroj pravdy.“	Útočník nebo privilegovaný uživatel ovládne samotný control plane.	Oprávnění, izolaci runnerů, secrets, podpisy, provenance a detekci změn v pipeline konfiguraci.

OCHRANA PŘED CHYBOU

Governance se nemá přesunout z deploymentů do guardrails a poté guardrails přestat kontrolovat. Čím více změn systém autorizuje automaticky, tím vyšší musí být nároky na vlastnictví, testování, monitoring a nezávislou recertifikaci samotného kontrolního řetězce.

Modelový příběh: 480 změn, 11 skutečných výjimek

Následující příklad je složený z opakujících se situací z praxe. Finanční firma týdně prováděla přibližně 480 produkčních změn. Všechny předcházely přes CAB. Fórum kontrolovalo termín, vlastníka a vyplněný rollback, ale na jednu změnu připadalo méně než devadesát sekund. Vývojové týmy zároveň už používaly protected branches, peer review, automatické testy, security scanning, policy-as-code a canary deployment.

Firma nejprve měsíc nic nerušila. U stovky změn porovnala ruční schválení s technickým důkazem a zjistila, že většina zásahů patří do několika opakovatelných tříd. Pro každou vytvořila evidence contract a přesné triggery: nová třída dat, privilegium, změna sdíleného rozhraní, nevratná migrace, vysoký blast radius, chybějící SLO signál nebo bypass kontroly.

Po přechodu procházely standardní změny bez čekání na CAB, ale se stejnou nebo vyšší mírou technického důkazu. V prvním týdnu vzniklo jedenáct výjimek. Jedna změna privilegovaného přístupu byla zamítnuta, protože neměla vlastníka rizika. Dvě databázové migrace dostaly omezené okno, další review a explicitní point of no return. Tři opakované odchylky ukázaly, že platforma neumí bezpečný expand–contract postup, a změnily se v prioritní položku platformního backlogu.

CAB nezmizel. Přestal však číst stovky běžných ticketů a jednou týdně se věnoval novým risk patternům, opakovaným výjimkám, cross-team kolizím, kvalitě guardrails a business trade-offům. Výsledek nebyl „méně kontroly“. Výsledek byl více času na rozhodnutí, která technický systém skutečně neuměl udělat.

Co má vedení IT měřit

Podíl změn bez manuálního schválení není sám o sobě cílem. Lze jej zvýšit tím, že se rizikové změny chybně označí jako standardní. vedení IT proto musí párovat flow metriky s kvalitou kontrol, životním cyklem výjimek a skutečnými provozními výsledky. DORA doporučuje sledovat podíl manuálně schvalovaných změn podle rizikové třídy a dobu čekání na externí schválení.

Metrika	Co odhaluje	Varovný signál
Pokrytí standardní cestou podle risk class	Které typy změn mají skutečně použitelný evidence contract.	Vysoké procento vzniká pouze přeznačením rizika nebo vynecháním kontrol.
Čekání na manuální rozhodnutí	Cenu výjimek a externích approval bodů.	Výjimka čeká déle než samotná technická realizace a nemá rozhodovací SLA.
Exception rate podle triggeru	Kde standardní cesta nejčastěji přestává platit.	Kategorie „other“ roste a zakrývá nejasný risk model.
Podíl opakovaných výjimek	Dluh guardrails, platformy nebo produktu.	Stejná odchylka se schvaluje znovu bez nápravné položky.
Výjimky po expiraci	Zda je dočasné riziko skutečně dočasné.	Systém výjimku mlčky obnovuje nebo po termínu nekontroluje.
Exception-to-standard conversion	Schopnost převést učení z výjimek do lepší standardní cesty.	Výjimkový backlog roste, ale policy a platforma se nemění.
False positive / false negative guardrails	Kvalitu automatických rozhodnutí.	Týmy často obcházejí blokace nebo audit nachází rizika, která pipeline propustila.
Manuální a privilegované bypassy	Skutečnou možnost obejít předautorizovaný model.	Bypass je běžný, sdílený, bez důvodu nebo bez následného review.
Progressive abort a rollback rate	Kolik problémů zachytí runtime kontrola před plným dopadem.	Rollouty se nikdy nezastaví, přestože change fail rate není nulový.
Audit sample mismatch	Zda evidence chain odpovídá skutečně nasazenému stavu.	Schválený commit, artefakt, deploy log a runtime se nedají spolehlivě propojit.
Intervention yield	Kolik výjimek lidské review změnilo, omezilo nebo zamítlo.	Schvalovatelé téměř vždy kliknou ano bez úpravy podmínek.
Change fail rate a recovery	Zda nový model skutečně drží stabilitu a obnovu.	Lead time klesá, ale roste neplánovaná práce, dopad nebo doba obnovy.

Šedesátidenní přechod od approval queue ke governance výjimek

Přechod nemá začít zrušením CAB ani nákupem dalšího workflow. Nejdříve je potřeba zjistit, které kontroly už technická cesta spolehlivě provádí, které existují pouze na papíře a které podnikové riziko zatím žádný guardrail neumí vyjádřit.

Období	Hlavní krok	Hmatatelný výstup
0 až 10 dní	Vzít nejméně sto nedávných změn a rozdělit jejich lead time na technickou práci, čekání, ruční approval a rework; ověřit skutečné artefakty.	Mapa reálné změnové cesty, kontrol, bypassů a míst, kde ticket neodpovídá nasazené změně.
11 až 20 dní	Pro dvě až tři technologie definovat standardní change classes a evidence contract od commitu po runtime ověření.	Přesný seznam povinných důkazů, vlastníků, retence a podmínek automatické autorizace.
21 až 35 dní	Navrhnout risk model, exception triggery, výjimkovou kartu, pravomoci, SLA a expirace.	Jedna rozhodovací logika, která rozlišuje běžnou změnu, zvýšené review a skutečnou výjimku.
36 až 45 dní	Spustit shadow mode: starý proces běží, ale každá změna dostane zároveň novou klasifikaci a vysvětlení.	Důkaz, kde nový model chybně propouští nebo zbytečně blokuje změny; upravené guardrails.
46 až 60 dní	U vybraných nízko- a středně rizikových tříd odstranit ruční gate, zavést náhodné auditní vzorkování a týdenní review výjimek.	První provozní data o čekání, výjimkách, intervention yield, stabilitě a kvalitě evidence chain.
Od 60. dne	Každou opakovanou výjimku převést do rozhodnutí: odstranit příčinu, změnit guardrail, změnit architekturu, nebo riziko výslovně přijmout.	Improvement backlog řízený frekvencí, expozicí a cenou výjimek; ne pouze hlasitostí jednotlivých týmů.

Budoucnost není bez governance. Je přesněji umístěná

Manuální approval může být důležitý kontrolní mechanismus. Je však drahý, pomalý a omezený lidskou pozorností. Když jej firma použije na každou změnu, nezíská automaticky více bezpečnosti. Často pouze rozdělí stejnou pozornost mezi případy s radikálně odlišnou mírou nejistoty.

Standardní cesta musí být proto silnější než formulář. Musí spojit přesný artefakt, nezávislé review, testy, security, policy, provenance, řízený rollout, observability a obnovu do jednoho dohledatelného rozhodovacího řetězce. Teprve potom lze rozumně tvrdit, že konkrétní deployment byl autorizován technickým mechanismem, nikoli pouze proveden bez schválení.

Centrální change funkce se v takovém systému neposouvá na okraj. Přesouvá se blíže ke skutečnému riziku: navrhuje hranice autonomie, kontroluje kvalitu guardrails, spravuje risk model, hlídá bypassy, rozhoduje výjimky a z opakovaných odchylek vytváří změnu standardní cesty.

ZÁVĚREČNÁ TEZE

Budoucnost Change Enablement není governance bez lidí. Je to governance, která předem schvaluje pravidla, důkazní řetězec a hranice autonomie; a lidskou pozornost šetří pro okamžiky, kdy standardní cesta selže, neplatí nebo vyžaduje vědomé přijetí rizika. Cílem není nula manuálních schválení. Cílem je, aby každé manuální schválení odpovídalo skutečné výjimce.