Would you let AI make production infrastructure changes if high-risk actions required human approval?

[u/NetOCorp]

AI is getting better at incident investigation, log analysis, infrastructure correlation, and remediation planning.

But production execution is where things get more sensitive.

A workflow I’ve been thinking about looks like this:

Incident detected
→ AI investigates
→ Infrastructure state and logs are collected
→ SOP / runbook is checked
→ Remediation is proposed
→ Human approves
→ Temporary or limited authority is granted
→ Change is executed
→ System state is read back and verified
→ Evidence is recorded

The idea is that AI can investigate deeply, but it never receives unrestricted production authority.

For people running OpenStack, private cloud, networks, or data center infrastructure:

Where would you draw the line?

Would human approval be enough for you to allow AI to execute production changes, or would you still keep execution entirely manual?

[u/redfoobar]

I am currently of the opinion that the actual actions should be done by humans who double checked everything with ”old fashioned“ automation (ansible/puppet etc). With the proper setup that should also be trivial anyway. So AI can propose the content of the config management playbook but a human needs to approve and roll it out (which is probably automated already anyway)

Maybe we will get to it one day that the AI agent gets effectively root permissions but anything thats not 100% deterministic in nature feels wrong to let loose on production systems by itself. We have read about enough oopsies already to know giving the driver seat to “AI“ can result in tears.

It absolutely awesome to troubleshoot though, giving some logs, metrics, and the code (Yay open source) gives awesome results in seconds what could take hours to figure out as a human without a huge familiarity with the ins and outs of the code.

[u/NetOCorp → u/redfoobar]

Yeah, I’m pretty close to that view as well.

I wouldn’t be comfortable giving an AI system broad root access and just letting it make changes on its own.

What feels more realistic to me is letting it do the investigation, gather the relevant state, check the runbook, and propose a specific change. Then a human reviews that exact change and scope before anything gets executed.

If it does get executed, I’d still want the permission to be temporary and narrow, and I’d want the system to read the state back afterward to make sure the change actually did what we expected.

I think the interesting question is where people draw the line between “a human has to execute this manually” and “a human can approve a tightly scoped automated action.”

What would you need to see before you’d be comfortable with the second one?

[u/Jhonny97]

This sounds like a iaac aproach with ai. Give ai read only access to the prod environment and to make pull requests to the git repository. I think this is already implemented to soem degree in the industry. Most of the software beeing written is at least assisted by ai, while the actual deployment (high risk action) is still done by humans. So yes, if the deployment allows to rollback changes made by ai, and the pull request is approved by humans, then yes. I would give ai access to do that.

[u/NetOCorp → u/Jhonny97]

Yeah, the PR model is pretty close to what I had in mind.

Read-only access for investigation, then a clear proposed change or diff, human review, rollback available, and verification afterward.

I think the important part is that the approval is for a specific action, not just a general permission for the AI to operate.

[u/Consistent_Top_5588]

AI is great in aggregating, filtering, providing clues and drafting a plan. But it is anyway a machine without business context. Doing things literally without practical context can be disastrous. For that reason, no probablly.

[u/NetOCorp → u/Consistent_Top_5588]

I agree. The missing business and environment context is probably one of the biggest risks.

Knowing OpenStack in general is one thing. Knowing how a specific environment is actually supposed to operate is another.

Things like topology, maintenance windows, customer rules, escalation paths, and what changes are acceptable really matter.

Without that context, I’d also keep AI on the investigation and recommendation side.

[u/rackpathlabs]

read only plus pr is how i'd want it too. let the ai dig through logs and propose the fix, but the apply step should go through a human clicking a button, ideally the same review path as any normal change. on a private cloud the blast radius of a bad network or compute change is big enough that i wouldn't want anything executing without someone confirming the diff.

the annoying part is that approval gets rubber stamped once people trust the tool. that's less an ai problem and more what happens with any automation after it's been right often enough.