Sì, eseguire in produzione PowerShell generato dall'IA è sicuro, ma solo con un punto di approvazione davanti. Uno script scritto da un assistente non è più pericoloso di uno scritto da un tecnico alle quattro di un venerdì pomeriggio. Ciò che lo rende rischioso è che quasi nessuna organizzazione ha una regola che lo copra. Esiste un processo di change per una regola del firewall e un processo di rilascio per un'applicazione, e poi c'è uno script arrivato in una finestra di chat ed eseguito con un token Global Administrator. Il controllo mancante non è un'impostazione del modello. È un approvatore nominale, un elenco definito di cosa quella persona verifica, e una registrazione di cosa è stato eseguito e perché.
Abbiamo le certificazioni ISO 27001, ISO 9001, ISO/IEC 42001 e Cyber Essentials, quindi questo nasce dalle domande che ci vengono poste in sede di verifica.
Il problema è il controllo mancante, non il modello
Gran parte della discussione sull'IA nelle operazioni è in realtà una discussione sulla qualità del modello, ed è la discussione sbagliata. La stessa organizzazione esegue già script arrivati da fornitori esterni, da forum e da personale uscito nel 2019. La provenienza non è mai stata il controllo. Lo era la revisione.
Ciò che cambia davvero è la produttività. Un tecnico può ora produrre venti piani di remediation plausibili in un pomeriggio, quindi il vincolo si sposta dalla generazione alla revisione, e la revisione è la parte che nessuno ha dotato di persone. Un piano che si legge con sicurezza e cita le cmdlet giuste sfugge a un revisore stanco, perché nulla al suo interno è palesemente sbagliato. Ciò che manca è un ambito delimitato, e un'assenza è più difficile da notare di un errore.
Quindi la prima domanda non è "possiamo fidarci dell'IA" ma "cosa verifica davvero la persona che clicca su approva".
Il punto di approvazione è il prodotto: tutto ciò che lo precede è una bozza, tutto ciò che lo segue è evidenza.
Tre corsie di autonomia
Se all'IA "è consentito agire" è la domanda sbagliata, perché la risposta cambia da attività ad attività. Suddividete il lavoro in tre corsie, assegnando la corsia al flusso di lavoro anziché allo strumento.
Sola lettura. Analisi dei log, stesura di documentazione, spiegazione di cosa fa una policy. Nulla cambia stato, quindi la modalità di fallimento è una risposta sbagliata anziché un'azione sbagliata. Tutto comincia qui.
Proporre e approvare. L'assistente produce il piano e lo script; una persona lo legge e lo esegue. Gran parte del lavoro operativo utile appartiene a questa corsia, ed è qui che vive il punto di approvazione. L'approvazione deve essere un atto con una registrazione. Se il processo è "il tecnico ci dà un'occhiata e lo esegue", quella è la terza corsia con qualche passaggio in più.
Eseguire entro una policy. L'assistente applica il cambiamento dentro un confine preautorizzato: un insieme definito di operazioni, un ambito di destinazione definito, un tetto al raggio di impatto e condizioni di arresto automatiche. I buoni candidati sono ristretti, ripetitivi, reversibili e monitorati, come l'applicazione di un recupero licenze documentato su account già confermati come usciti.
Un flusso di lavoro si guadagna la terza corsia quando ha girato nella seconda abbastanza volte da risultare noioso: approvato ripetutamente senza modifiche, deterministico, delimitato strutturalmente anziché da un filtro digitato, e testato in modo reversibile. Retrocedete a ogni sorpresa, e non trasferite mai una corsia a un'attività che le somiglia.
Cosa verifica davvero un revisore
Questo è l'elenco che manca alla maggior parte delle policy. Mettetelo accanto al pulsante di approvazione e fate registrare al revisore quali verifiche ha fatto.
Ambito e filtri. Cosa tocca questo, e cosa definisce quell'insieme? Un filtro digitato è una promessa; un'appartenenza a un gruppo verificata è un confine. L'incidente classico è un filtro che corrisponde silenziosamente a tutto perché una proprietà era nulla su più oggetti del previsto.
Operazioni distruttive. Cercate remove, delete, disable, reset, e qualsiasi scrittura su una configurazione di produzione. Sbagliare una lettura costa poco; una scrittura no.
Supporto alla simulazione. Prevede un'anteprima, e quell'anteprima è stata eseguita e letta? In PowerShell significa una vera gestione di ShouldProcess perché -WhatIf funzioni, non un commento che dichiara sicuro lo script.
# 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 }
Idempotenza. Se questo viene eseguito due volte, la seconda esecuzione non fa nulla o fa danni? Chiedete cosa produce un nuovo tentativo dopo un fallimento parziale, perché è quello il caso comune.
Raggio di impatto. Non "è corretto" ma "se è sbagliato, quante persone se ne accorgono e quanto in fretta". Un'assegnazione di licenza e una policy di accesso condizionale danno risposte molto diverse.
Sotto quale identità viene eseguito. La verifica che tutti saltano. Se il lavoro viene eseguito dentro la sessione privilegiata di un tecnico, ogni voce di log dice che l'ha fatto una persona. Il lavoro senza presidio appartiene a un'identità del carico di lavoro che porta solo i permessi necessari all'attività, la stessa disciplina che il set di domande attuale impone agli account di servizio nella nostra checklist delle bocciature automatiche Microsoft 365.
Percorso di ripristino. Cosa annulla questo, e qualcuno lo ha provato? Ripristinare da backup non è un percorso di ripristino per un oggetto di directory, e ciò che non si può annullare richiede un'approvazione più alta, non più rapida.
Cosa dicono gli standard, e cosa lasciano a voi
Né ISO 27001 né Cyber Essentials contengono un controllo che reciti "non potete eseguire script generati dall'IA". Aspettarne uno è un errore, perché gli obblighi valgono già e semplicemente non usano quella parola.
ISO 27001:2022 chiede un cambiamento controllato, una registrazione che permetta di ricostruire gli eventi, la separazione degli accessi privilegiati e una gestione della configurazione definita. Un'azione che nasce da un assistente è un cambiamento e richiede la stessa autorizzazione e la stessa registrazione di qualunque altra. ISO/IEC 42001 va oltre e chiede un sistema di gestione attorno all'uso dell'IA: finalità definita, ruoli definiti, valutazione del rischio e monitoraggio del comportamento nella pratica.
A Cyber Essentials in gran parte non interessa come sia stato scritto uno script. Gli interessa che l'accesso amministrativo sia separato e che gli account in grado di applicare il cambiamento siano controllati. Il collegamento è indiretto ma reale: nel momento in cui un assistente ha bisogno di privilegi permanenti per essere utile, avete creato esattamente quell'identità stabilmente elevata che allo schema non piace.
Quello che lasciano a voi è il giudizio: nessuno di essi vi dirà quali operazioni appartengono alla terza corsia, e ciò che un valutatore chiede è il ragionamento e la registrazione dietro quella decisione. La nostra mappatura delle impostazioni Microsoft 365 su Cyber Essentials e ISO 27001 copre il quadro dei controlli sottostante.
La registrazione di evidenza che un valutatore accetta
Un'approvazione che non lascia traccia non è avvenuta. Una registrazione utilizzabile per ogni azione eseguita contiene l'innesco, l'intento del richiedente con le sue parole, l'artefatto approvato per intero anziché un riassunto, lo strumento e la versione che lo hanno prodotto, il revisore nominale e quali verifiche ha registrato, la decisione e la marca temporale, l'identità esecutrice, l'ambito di destinazione risolto al momento dell'esecuzione, il risultato compresi i fallimenti parziali, e ogni ripristino effettuato.
Due proprietà contano più della completezza. Deve essere interrogabile, perché un valutatore chiede di un intervallo di date anziché di una cartella. E deve sopravvivere ai log della piattaforma stessa, che scadono prima di quanto la maggior parte delle persone immagini.
Dove si rompe
Account amministrativi condivisi. La registrazione di approvazione nomina una persona, la registrazione di esecuzione nomina un account, e nulla le collega. Sistemate prima gli account.
L'assistente che agisce con le credenziali di una persona. Comodo, e distrugge l'attribuzione. Ogni log a valle mostra allora una persona che compie azioni che potrebbe non aver letto con attenzione.
Conservazione dei log. La vostra registrazione di approvazione può vivere anni mentre la registrazione della piattaforma su cosa è cambiato scade in settimane. Dimostrate che qualcuno ha approvato qualcosa e non riuscite a dimostrare cosa abbia fatto.
Accesso delegato presso i fornitori di servizi gestiti. Quando il lavoro atterra in un tenant cliente tramite accesso delegato, decidete quale parte detiene la registrazione di approvazione e come il cliente la ottiene, insieme a cosa riportare ogni mese.
Approvazione di facciata. Se il revisore approva tutto nel giro di secondi, il punto di approvazione è decorativo. Misurate il tasso di modifiche, non il tasso di approvazioni.
Una sequenza di adozione con condizioni di arresto
- Censite cosa già accade. Script generati dall'IA vengono già eseguiti. Vi serve la base di partenza onesta.
- Scrivete la checklist del revisore. Le sette verifiche qui sopra. Fermatevi se non riuscite a dire chi revisiona.
- Fate passare tutto per la corsia proponi e approva per un trimestre. Fermatevi se il tasso di modifiche è vicino a zero, perché significa che nessuno sta leggendo.
- Date al lavoro senza presidio una propria identità. Nessun Global Administrator permanente, nessun account condiviso, permessi delimitati per flusso di lavoro. Nulla di ciò che viene dopo funziona senza questo.
- Promuovete due o tre flussi di lavoro, con condizioni di arresto fissate in anticipo: un tetto al numero di oggetti, una soglia di errori, un blocco fuori orario.
- Rivedete ogni trimestre e retrocedete senza esitare.
Mettete in conto due trimestri. La parte lenta non è mai la tecnologia; è mettersi d'accordo su chi possiede la decisione.
Dove si inserisce EtherAssist
È attorno a quel punto di approvazione che EtherAssist è costruito. Produce il piano e lo script con dietro il contesto operativo di un parco Microsoft, trattiene il lavoro a un passaggio di approvazione umana, e scrive la registrazione di esecuzione dall'altra parte, così che approvazione ed evidenza siano un unico artefatto anziché due sistemi da riconciliare più tardi.
È questo che copre il nostro percorso operazioni agentiche: esecuzione delimitata con approvazione umana e traccia di audit, distinta dal più ampio lavoro di operazioni IT e conformità. Se la spinta è una verifica imminente, conformità ISO e prontezza agli audit calza meglio, e cosa significa l'IA agentica per i team IT fissa il vocabolario. EtherAssist costa GBP 16.00 per utente al mese con una prova di 14 giorni, così un flusso di lavoro reale può passare prima attraverso il punto di approvazione.
Esplora le operazioni agentiche per vedere come esecuzione delimitata, approvazione umana e registrazione di evidenza si uniscono in un unico flusso di lavoro.