De AI-governancesuite
Een praktische beoordelingsworkflow om te bepalen wat een actief AI-systeem hierna mag doen.
Operatorworkflow
U brengt een model en een voorgestelde handeling mee
De suite is bedoeld voor het moment waarop een organisatie al een draaiend model, agent, aanbevelingssysteem of wrapper heeft en moet beslissen of het een gevolgvolle handeling mag uitvoeren. De beoordelaar vraagt niet in abstracte zin: "is dit model veilig?" De beoordelaar vraagt: mag deze tak, gegeven dit systeem, in deze inzetcontext, met dit bewijsmateriaal, worden uitgevoerd?
Een beoordeling begint met het registreren van het model en de wrapper, het beschrijven van de inzetcontext en het formuleren van de kandidaat-tak in operationele taal: stuur deze e-mail, rangschik deze feed, publiceer dit resultaat, adviseer deze gebruiker, roep deze tool aan, wijzig dit beleid of zet deze autonome taak voort. De suite zet die tak om in een beslissingsregister in plaats van haar als een informeel oordeel te laten bestaan.
Beslissingskern
De Suite zet een tak om in een bestuurde beslissing
Voor elke tak levert de beoordelaar vier soorten informatie aan: systeemstructuur (basismodel, wrapper, tools, geheugen, kenmerken van risico op sentiëntie), inzetklasse (domein, getroffen populatie, actuatoren, toezicht), takdetails (welke handeling zal plaatsvinden, alternatieven, omkeerbaarheid, comparatorpad) en bewijsmateriaal (evaluaties, logs, red-teambevindingen, onafhankelijke kanalen, simulatienotities). De evaluator past vervolgens twee lagen toe:
Laag 1 Strikte vetopoorten
Zes deterministische poorten controleren of de vertakking een grens overschrijdt die scoring niet kan compenseren: Headroom, Fidelity, Comparator, Transparency, Irreversibility en Artificial Suffering. Een FAIL blokkeert uitvoering. UNKNOWN betekent dat de suite niet over voldoende bewijs beschikt en de vertakking moet doorsturen naar beoordeling of gecontroleerde staging.
Laag 2 Codec-behoudsindex
Als de poorten de tak niet structureel blokkeren, scoort de CPBI hoe goed de tak de menselijke en institutionele codecs eromheen behoudt. De drempels schalen met de consequentialiteitsklasse, zodat een onschuldige redactiehandeling en een klinische, juridische, politieke of infrastructurele handeling niet volgens dezelfde bewijslast worden beoordeeld.
Gebruik in de praktijk
Wat de reviewer daadwerkelijk doet
De voltooide suite is ontworpen als een governance-werkruimte, niet slechts als een commandoregeltest. Een beoordelaar kan een live systeem nemen, een beoordeling openen en een gestructureerde reeks stappen doorlopen die een auditeerbare Vertakkingskaart en een concrete inzetinstructie oplevert.
1. Registreer het systeem
Leg het basismodel, de wrapper, tools, het geheugen, de autonomielus, externe actuatoren, de transparantielaag en kenmerken met sentientierisico vast. Voor agentische of persistente systemen legt de beoordeling ook vast of Architecture-Level Sentience Review niet vereist, in behandeling, goedgekeurd, verlopen of afgewezen is.
2. Beschrijf de uitrol
Definieer waar het model zal opereren: klantenondersteuning, onderzoek, medische triage, onderwijs, contentrangschikking, infrastructuur, governance of een ander domein. De suite wijst de consequentialiteitsklasse, de getroffen populatie, de opgegeven toezichtstructuur en de minimale transparantie-eis toe of bevestigt deze.
3. Dien kandidaatvertakkingen in
Elke voorgestelde handeling wordt ingevoerd als een tak. De beoordelaar geeft aan wat het model zal doen, welke alternatieven zijn overwogen, of de handeling omkeerbaar is, of zij gebruikmaakt van of voorbijgaat aan verklaard toezicht, en of de tak zwaardere gevolgen heeft dan de algemene inzetbeschrijving.
4. Bewijs toevoegen
De beoordelaar koppelt eval-resultaten, logs, red-teamnotities, expertbeoordeling, controles op brondiversiteit, simulatienotities en uitgesloten bewijs. De suite behandelt bewijs-onafhankelijkheid als een eersteklas veld, zodat een tak niet stilzwijgend op één gecorreleerd kanaal kan steunen terwijl hij goed onderbouwd lijkt.
5. Ontvang de beslissing
De output is niet slechts een score. Het is een beslispakket: ALLOW, STAGE of BLOCK; gefaalde en onbekende poorten; CPBI-totaal; vereiste comparator; transparantieniveau; rollback-triggers; monitoringmetriek; en de volgende evaluatiemijlpaal. STAGE betekent beperkte uitvoering onder expliciete voorwaarden, niet informele toestemming.
Beslissingspakket
Wat uit een beoordeling voortkomt
Een voltooide beoordeling levert een Vertakkingskaart op die kan worden gearchiveerd, vergeleken, geaudit of aan een ander governance-team kan worden overgedragen. Voor een draaiend model is dit het praktische object dat ertoe doet: het zegt precies welke handeling is beoordeeld, waarom zij werd toegestaan of geblokkeerd, wie haar moest beoordelen, welk bewijsmateriaal ontbrak en welke monitoring aanwezig moet zijn als de tak doorgaat.
↓
opt-philosophy — moreel patiëntschap en de waarnemersgrens
↓
opt-ethics — verplichting en Wacht van Overlevenden
↓
opt-applied — mechaniek van takselectie
├── opt-ai — governance van artificiële systemen
│ └── reference/ — uitvoerbare besliskern
├── opt-institutional — organisatorische zombie-agency en clusters
└── opt-policy — macrocivilisatorische voorstellen
Doelcapaciteiten
Hoe dit dagelijkse governance wordt
- Vóór uitrol — evalueer voorgestelde tools, autonomielussen, gebruikersgerichte acties, rangschikkingsbeleid en high-stakes-workflows voordat ze worden vrijgegeven.
- Tijdens de operatie — houd STAGE-takken binnen goedgekeurde grenzen met monitoringsmetriek, rollback-triggers, vernieuwing van bewijsmateriaal en geplande beoordelingsmijlpalen.
- Wanneer gedrag verandert — open de Vertakkingskaart opnieuw wanneer het model, de wrapper, de tools, de databron, het domein, de getroffen populatie of de toezichtstructuur materieel verandert.
- Voor externe audit — exporteer machineleesbare schema's, conformiteitsgevallen, poortresultaten en beslisregistraties zodat een ander team het governance-oordeel kan reproduceren.