Ja, het is veilig om AI-gegenereerde PowerShell in productie te draaien, maar alleen met een goedkeuringspoort ervoor. Een script dat een assistent schreef is niet gevaarlijker dan een script dat een engineer op vrijdagmiddag om vier uur schreef. Wat het riskant maakt, is dat de meeste organisaties er geen regel voor hebben. Er is een wijzigingsproces voor een firewallregel en een releaseproces voor een applicatie, en dan is er een script dat in een chatvenster arriveerde en draaide met een token van een Global Administrator. De ontbrekende beheersmaatregel is geen modelinstelling. Het is een benoemde goedkeurder, een vastgelegde lijst van wat die persoon controleert, en een vastlegging van wat er draaide en waarom.

Wij zijn gecertificeerd voor ISO 27001, ISO 9001, ISO/IEC 42001 en Cyber Essentials, dus dit komt voort uit de vragen die ons in beoordelingen zijn gesteld.

De fout is de ontbrekende poort, niet het model

Het grootste deel van de discussie over AI in de operatie gaat eigenlijk over modelkwaliteit, en dat is de verkeerde discussie. Dezelfde organisatie draait al scripts van externen, van fora, en van medewerkers die in 2019 vertrokken. Herkomst was nooit de beheersmaatregel. Beoordeling wel.

Wat werkelijk verandert, is de doorvoer. Eén engineer kan nu in een middag twintig plausibele herstelplannen produceren, dus de beperking verschuift van produceren naar beoordelen, en beoordelen is het deel dat niemand heeft bemenst. Een plan dat zelfverzekerd leest en de juiste cmdlets aanhaalt, glipt langs een vermoeide beoordelaar, omdat er niets zichtbaar fout aan is. Wat ontbreekt is een begrensde scope, en afwezigheid is lastiger op te merken dan een fout.

De eerste vraag is dus niet "kunnen we de AI vertrouwen" maar "wat controleert de persoon die op goedkeuren klikt eigenlijk".

Stroomdiagram van een goedkeuringspoort voor een door AI gegenereerde operationele wijziging. Een verzoek komt binnen van een engineer of via een servicedesk-ticket. De AI-assistent stelt een plan en een script op en legt het verzoek en de versie van het hulpmiddel vast. Het concept gaat naar een beoordelingspoort waar een benoemde beoordelaar zeven dingen controleert: scope en filters, destructieve bewerkingen, ondersteuning voor een testuitvoering, idempotentie, impactbereik, de identiteit waaronder het werk draait, en het terugdraaipad. Drie uitkomsten verlaten de poort: goedgekeurd en uitgevoerd, teruggestuurd voor aanpassing, of afgewezen. Goedgekeurd werk draait onder een benoemde service-identiteit en schrijft een uitvoeringsvastlegging met wie het goedkeurde, wat er draaide, wat er wijzigde en het resultaat. Een pijl keert van die vastlegging terug naar de poort, gemarkeerd als promotiebeoordeling, omdat een workflow die herhaaldelijk slaagt een ruimere autonomiebaan verdient.

De poort is het product: alles ervoor is een concept, en alles erna is bewijs.

Drie banen van autonomie

Of AI "mag handelen" is de verkeerde vraag, want het antwoord verschilt per taak. Sorteer het werk in drie banen, en ken de baan toe aan de workflow in plaats van aan het hulpmiddel.

Alleen lezen. Loganalyse, documentatie opstellen, uitleggen wat een beleid doet. Er verandert niets aan de status, dus de faalwijze is een verkeerd antwoord in plaats van een verkeerde handeling. Alles begint hier.

Voorstellen en goedkeuren. De assistent maakt het plan en het script; een mens leest het en voert het uit. Het meeste nuttige operationele werk hoort hier thuis, en hier zit de poort. Goedkeuren moet een handeling met een vastlegging zijn. Als het proces is "de engineer kijkt ernaar en voert het uit", dan is dat de derde baan met extra stappen.

Uitvoeren binnen beleid. De assistent voert de wijziging uit binnen een vooraf geautoriseerde begrenzing: een vastgelegde set bewerkingen, een vastgelegde doelscope, een plafond voor het impactbereik en automatische stopvoorwaarden. Goede kandidaten zijn smal, repetitief, omkeerbaar en bewaakt, zoals het toepassen van een gedocumenteerde licentie-terugname op accounts die al als vertrekker zijn bevestigd.

Een workflow verdient de derde baan zodra hij in de tweede zo vaak heeft gedraaid dat het saai wordt: herhaaldelijk goedgekeurd zonder aanpassing, deterministisch, structureel begrensd in plaats van door een getypt filter, en omkeerbaar getest. Degradeer bij elke verrassing, en draag een baan nooit over aan een taak die er slechts op lijkt.

Wat een beoordelaar echt controleert

Dit is de lijst die in de meeste beleidsstukken ontbreekt. Zet hem naast de goedkeurknop en laat de beoordelaar vastleggen welke controles hij deed.

Scope en filters. Wat raakt dit, en wat bepaalt die verzameling? Een getypt filter is een belofte; een beoordeeld groepslidmaatschap is een begrenzing. Het klassieke incident is een filter dat stilzwijgend alles raakt omdat een eigenschap leeg was op meer objecten dan verwacht.

Destructieve bewerkingen. Let op remove, delete, disable, reset, en op elke schrijfactie naar een productieconfiguratie. Leesacties zijn goedkoop om fout te hebben; schrijfacties niet.

Ondersteuning voor een testuitvoering. Ondersteunt het een voorbeeldweergave, en is die voorbeeldweergave gedraaid en gelezen? In PowerShell betekent dat echte afhandeling van ShouldProcess zodat -WhatIf werkt, geen commentaarregel die beweert dat het script veilig is.

# Unbounded: matches every disabled account in the tenant, no preview, no confirmation
Get-MgUser -Filter 'accountEnabled eq false' -All | Remove-MgUser
# Bounded: a reviewed membership defines the scope, and the preview runs first
$leavers = Get-MgGroupMember -GroupId $ConfirmedLeaversGroupId -All
$leavers | ForEach-Object { Remove-MgUser -UserId $_.Id -WhatIf }

Idempotentie. Als dit tweemaal draait, doet de tweede keer dan niets of richt hij schade aan? Vraag wat een nieuwe poging na een gedeeltelijke mislukking doet, want dat is het gebruikelijke geval.

Impactbereik. Niet "is dit correct" maar "als het fout is, hoeveel mensen merken het en hoe snel". Eén licentietoewijzing en één beleid voor Conditional Access geven zeer verschillende antwoorden.

Onder welke identiteit het draait. De controle die mensen overslaan. Als het werk binnen de bevoorrechte sessie van een engineer wordt uitgevoerd, zegt elke logregel dat een mens het deed. Onbewaakt werk hoort bij een workload-identiteit die alleen de rechten heeft die de taak nodig heeft, dezelfde discipline die de huidige vragenset oplegt aan serviceaccounts in onze checklist voor directe afkeuring in Microsoft 365.

Terugdraaipad. Wat maakt dit ongedaan, en heeft iemand dat getest? Herstellen vanuit back-up is geen terugdraaipad voor een directoryobject, en wat niet ongedaan kan worden gemaakt heeft een hogere goedkeuring nodig, geen snellere.

Wat de normen zeggen, en wat ze aan u overlaten

Noch ISO 27001 noch Cyber Essentials bevat een beheersmaatregel die luidt "u mag geen AI-gegenereerde scripts draaien". Wachten op zo'n regel is een vergissing, want de verplichtingen gelden al en gebruiken het woord alleen niet.

ISO 27001:2022 vraagt om beheerste wijziging, logging waarmee u gebeurtenissen kunt reconstrueren, scheiding van bevoorrechte toegang, en vastgelegd configuratiebeheer. Een handeling die bij een assistent begint, is een wijziging en vereist dezelfde autorisatie en vastlegging als elke andere. ISO/IEC 42001 gaat verder en vraagt om een managementsysteem rond AI-gebruik: vastgelegd doel, vastgelegde rollen, risicobeoordeling en bewaking van het gedrag in de praktijk.

Cyber Essentials maakt het in hoofdzaak niet uit hoe een script is geschreven. Het schema geeft erom dat administratieve toegang gescheiden is en dat de accounts die de wijziging kunnen maken beheerst zijn. Het verband is indirect maar reëel: op het moment dat een assistent permanente rechten nodig heeft om nuttig te zijn, hebt u precies de blijvend verhoogde identiteit gecreëerd waar het schema ongelukkig mee is.

Wat ze aan u overlaten is de afweging: geen van hen zal u vertellen welke bewerkingen in de derde baan horen, en wat een beoordelaar vraagt is de redenering en de vastlegging achter dat besluit. Onze koppeling van Microsoft 365-instellingen aan Cyber Essentials en ISO 27001 behandelt het onderliggende beeld van de beheersmaatregelen.

De bewijsvastlegging die een beoordelaar accepteert

Goedkeuring die geen spoor achterlaat, heeft niet plaatsgevonden. Een werkbare vastlegging per uitgevoerde handeling bevat de aanleiding, de bedoeling van de aanvrager in zijn eigen woorden, het volledige goedgekeurde artefact in plaats van een samenvatting, het hulpmiddel en de versie die het produceerde, de benoemde beoordelaar en welke controles hij vastlegde, het besluit en het tijdstempel, de uitvoerende identiteit, de doelscope zoals die bij uitvoering werd bepaald, het resultaat inclusief gedeeltelijke mislukkingen, en elke uitgevoerde terugdraaiing.

Twee eigenschappen tellen zwaarder dan volledigheid. De vastlegging moet doorzoekbaar zijn, want een beoordelaar vraagt naar een periode en niet naar een map. En zij moet de eigen logs van het platform overleven, die eerder verlopen dan de meeste mensen aannemen.

Waar het misgaat

Gedeelde administratieve accounts. De goedkeuringsvastlegging noemt een persoon, de uitvoeringsvastlegging noemt een account, en niets verbindt de twee. Repareer eerst de accounts.

De assistent die onder de inloggegevens van een mens handelt. Handig, en het vernietigt de toewijsbaarheid. Elke log verderop toont dan een persoon die handelingen verricht die hij misschien niet aandachtig heeft gelezen.

Bewaartermijn van logs. Uw goedkeuringsvastlegging kan jaren bestaan terwijl de platformvastlegging van wat er wijzigde binnen weken verloopt. U bewijst dan dat iemand iets goedkeurde en kunt niet bewijzen wat het deed.

Gedelegeerde toegang bij leveranciers van beheerde diensten. Wanneer werk via gedelegeerde toegang in een klanttenant landt, bepaal dan welke kant de goedkeuringsvastlegging houdt en hoe de klant die krijgt, naast wat u elke maand moet rapporteren.

Goedkeuringstheater. Als de beoordelaar alles binnen seconden goedkeurt, is de poort decoratief. Meet het aanpassingspercentage, niet het goedkeuringspercentage.

Een invoeringsvolgorde met stopvoorwaarden

  1. Inventariseer wat er al gebeurt. AI-gegenereerde scripts worden al gedraaid. U hebt de eerlijke nulmeting nodig.
  2. Schrijf de checklist voor de beoordelaar. De zeven controles hierboven. Stop als u niet kunt benoemen wie beoordeelt.
  3. Draai een kwartaal lang alles in de baan voorstellen en goedkeuren. Stop als het aanpassingspercentage bijna nul is, want dan leest niemand mee.
  4. Geef onbewaakt werk een eigen identiteit. Geen permanente Global Administrator, geen gedeelde accounts, afgebakende rechten per workflow. Niets hierna werkt zonder dit.
  5. Promoveer twee of drie workflows, met vooraf ingestelde stopvoorwaarden: een plafond voor het aantal objecten, een foutdrempel, een blokkade buiten kantooruren.
  6. Beoordeel per kwartaal en degradeer zonder aarzeling.

Reken op twee kwartalen. Het trage deel is nooit de techniek; het is het eens worden over wie het besluit bezit.

Waar EtherAssist past

Om die poort heen is EtherAssist gebouwd. Het produceert het plan en het script met de operationele context van een Microsoft-omgeving erachter, houdt het werk vast bij een menselijke goedkeuringsstap, en schrijft de uitvoeringsvastlegging aan de andere kant, zodat goedkeuring en bewijs één artefact zijn in plaats van twee systemen die later moeten worden afgestemd.

Dat is wat onze route agentic operations behandelt: afgebakende uitvoering met menselijke goedkeuring en een audittrail, onderscheiden van het bredere werk rond IT-operatie en compliance. Als de aanleiding een aankomende beoordeling is, past ISO-compliance en auditgereedheid beter, en wat agentic AI betekent voor IT-teams zet het vocabulaire neer. EtherAssist kost GBP 16.00 per gebruiker per maand met een proefperiode van 14 dagen, zodat een echte workflow eerst door de poort kan.

Ontdek agentic operations om te zien hoe afgebakende uitvoering, menselijke goedkeuring en de bewijsvastlegging in één workflow samenkomen.