Governance & beleid is waar je bepaalt hoe jouw organisatie AI-operaties bestuurt — hoeveel de AI zelfstandig mag doen, wanneer een mens moet tekenen, wie geïnformeerd wordt en hoe lang gegevens bewaard blijven. Het vervangt de oude laag-niveau "Agentgedrag"-schakelaars door acht secties in gewone taal.
Open het via Instellingen → Governance. Het is een beheerderssurface (de rol Beheerder, plus platformbeheerders), beperkt tot je eigen tenant. Elke wijziging werkt live — er is geen aparte publicatiestap — en de standaarden laten het huidige gedrag exact ongewijzigd, dus er verandert niets totdat jij iets wijzigt.
1. AI-autonomie
De belangrijkste instelling. Kies een modus die bepaalt hoeveel de AI zonder jou doet:
| Modus | Wat het doet |
|---|---|
| Conservatief | Maximaal toezicht. Elk plan vereist goedkeuring, de AI pauzeert bij elke goedkeuringspoort, en revisie-/herhaalpogingen blijven kort. |
| Gebalanceerd (standaard) | Goedkeuring bij riskant of kritiek werk; de AI gaat door bij routinewerk. Dit komt overeen met het standaardgedrag van het platform. |
| Agressief | Maximale doorvoer. Geen planpoort, de AI bouwt door langs poorten, en het goedkeuren van een gemarkeerde wijziging accepteert die zoals ze is. |
| Aangepast | Stel de onderliggende controles handmatig in. Bij Aangepast verschijnt een Geavanceerd-paneel met de losse schakelaars (auto-revisielimiet, herhalingslimiet, pauzeren-bij-poort, afwijzen-breekt-af, releasestap, revisie-hervatten, en wat "goedkeuren" met een gemarkeerde patch doet). |
De plangoedkeuringspoort zelf wordt aangestuurd door de sectie Goedkeuringsbeleid hieronder, zodat de twee nooit met elkaar in tegenspraak zijn.
2. Goedkeuringsbeleid
- Wanneer is menselijke goedkeuring vereist? — de basispoort voordat AI-werk live gaat: Nooit, Alleen riskante wijzigingen, Productie-impact, Beveiligingsgevoelig, Externe integraties, Databasewijzigingen of Altijd.
- Als niemand op tijd reageert — een standaard time-out (in minuten;
0= onbeperkt wachten) en wat er gebeurt als die verstrijkt: pauzeren, escaleren, automatisch afwijzen of een reserve-goedkeurder informeren. - Goedkeuringsroutering & fasen — optionele regels die de basis verfijnen. Een regel matcht op risiconiveau (en, naarmate het platform groeit, werkruimte/integratie), kiest de kanalen waarop de goedkeuring wordt afgeleverd, en kan fasen koppelen (bijvoorbeeld CTO → QA → Release Manager) elk met een eigen time-out.
Zonder routeringsregels geldt de basis voor alles.
Plangoedkeuring vóór de uitvoering
Waar een poort dat vereist, stelt de AI een gestructureerd, geversioneerd uitvoeringsplan op en wacht op akkoord voordat er werk gedaan wordt — aanpak, betrokken systemen, risico, validatie en terugrolplan, allemaal in gewone taal. De goedkeurder kan Goedkeuren, Wijzigingen vragen (de AI maakt dan een nieuwe versie met de feedback erin) of Afwijzen. Een nieuwe versie maakt een eerdere goedkeuring ongeldig, zodat een plan nooit verandert ná het akkoord. Of deze poort opent, volgt de autonomiemodus en de basis hierboven (Conservatief vereist het bij elk plan; Agressief schakelt het uit). Voor de operator-kant hiervan, zie Goedkeuringen.
Goedkeuren vanuit e-mail
Managers kunnen goedkeuren of afwijzen zonder in te loggen. Zo schakel je het in:
- Configureer uitgaande e-mail onder de platforminstellingen E-mail (SMTP) (
SMTP_HOST,SMTP_FROMen inloggegevens). - Voeg een goedkeurings- (of meldings-)*routeringsregel toe met het kanaal E-mail*** ingeschakeld.
Wanneer er dan een poort opent, ontvangen bevoegde goedkeurders een e-mail met het issue, het risico, een verificatiesamenvatting en een aanbeveling, met de knoppen Goedkeuren / Wijzigingen vragen / Details openen. Elke knop is een eenmalige, verlopende beveiligde link; bij het klikken opent een korte bevestigingspagina en wordt de beslissing in FixControl vastgelegd — via hetzelfde beslispad als het Goedkeuringscentrum in de app.
3. Meldingsbeleid
Bepaal wie wat te horen krijgt, via welk kanaal, wanneer er aandacht nodig is. Elke regel koppelt een trigger (goedkeuring vereist, patch mislukt, sandbox mislukt, missie voltooid, herhalingen uitgeput, riskante patch gedetecteerd, klantantwoord in afwachting) aan een rol en een kanaal. Dit is aanvullend — je managers krijgen nog steeds de standaard in-app meldingen; deze regels voegen de gewenste routering toe (bijvoorbeeld "QA bij sandbox-fouten").
4. Risicobeleid
Classificeer welke soorten wijzigingen gevoelig zijn en welke controles ze in werking stellen. Stel per categorie — authenticatie, facturatie, databaseschema, beveiligingsgevoelige bestanden, externe API-integraties, deployment/release, infrastructuur — een risiconiveau in (laag → kritiek) en of het goedkeuring, verificatie of escalatie vereist.
5. Verificatiebeleid
Wat bewezen moet worden voordat een wijziging live mag:
- Verificatiestrengheid — Soepel (verifieer de werkmap, auto-reviseer bij een mislukte sandboxrun), Standaard (de standaard) of Streng (verifieer een schone kloon vastgezet op de commit van de run, geen auto-revisie).
- Schakelaars om een geslaagde sandbox te vereisen, de testsuite te laten voltooien, QA-goedkeuring te vereisen en productie-impact zonder QA te blokkeren.
6. Klantcommunicatie
Bepaalt of en hoe de AI met klanten mag communiceren. Dit is een opt-in plafond bovenop je per-mailbox auto-antwoordinstellingen — zet Dit communicatiebeleid afdwingen aan om het te activeren. Indien afgedwongen kan het automatisch verzenden alleen beperken, nooit het beleid van een mailbox versoepelen:
- AI-antwoordgedrag — nooit automatisch verzenden, alleen concept, verzend bij hoge zekerheid, of verzend laag-risico.
- Zekerheidsdrempels — op/boven de auto-verzend-drempel mag de AI verzenden; tussen goedkeuring en auto-verzend keurt een mens goed; onder goedkeuring escaleert het.
- Toegestane kanalen — waar de AI mag communiceren (portaal, e-mail, Slack, API).
- Beperkte onderwerpen — onderwerpen die de AI nooit automatisch mag afhandelen (facturatie, juridisch, beveiliging, terugbetalingen, storingen, of je eigen). De AI mag deze nog wel als concept opstellen voor een mens; alleen niet automatisch verzenden.
Zie ook de gebruikersgids over auto-antwoorden.
7. Escalatiebeleid
Wat er gebeurt wanneer werk stilvalt. Stel per trigger — herhalingen uitgeput, goedkeuring verlopen, inactiviteit, SLA-overschrijding, vastgelopen missie — een vertraging en een actie in (een reserve informeren, opnieuw toewijzen, automatisch afwijzen, of piket oproepen) en een doelrol.
8. Audit & bewaartermijnen
Hoe lang gegevens bewaard blijven, in dagen (0 = onbeperkt bewaren): agent-traces, goedkeuringen, auditgebeurtenissen, runtime-logs en klantcommunicatie. Een geplande sweep dwingt deze termijnen af en past ook goedkeurings-time-outs/escalatie toe. Alleen categorieën met een niet-nul termijn worden ooit opgeschoond.
Veiligheidsmodel. Alles hier is aanvullend en opt-in: een tenant die deze pagina nooit aanraakt, gedraagt zich precies zoals voorheen. Wijzigingen werken direct, en de preset "Gebalanceerd" is identiek aan de platformstandaarden.