If you've ever worked for or with enterprise companies you know that, when it comes to software, whether it's AI-powered or not, the stakes could not be higher. And that is the reason they invest heavily in making their production environments as bulletproof as possible. They will architect for high availability and disaster recovery, enforce strict service level agreements (SLAs), and build redundancy into every possible layer.But if their architecture doesn’t also account for the potential for human error, is any of it worth the effort? Time and again, we’ve seen catastrophic outages tra
![]()
Principal AI Architect - AI BU
If you've ever worked for or with enterprise companies you know that, when it comes to software, whether it's AI-powered or not, the stakes could not be higher. And that is the reason they invest heavily in making their production environments as bulletproof as possible. They will architect for high availability and disaster recovery, enforce strict service level agreements (SLAs), and build redundancy into every possible layer.
But if their architecture doesn’t also account for the potential for human error, is any of it worth the effort? Time and again, we’ve seen catastrophic outages traced back to a wrong mouse click, a badly written command, or a rushed deployment. Let’s review a few of them:
As a personal example, I once worked with a customer whose datacenter cleaning staff unplugged a production rack server to plug in a vacuum cleaner. That predictable and preventable mistake caused six hours of serious downtime (and I’m only being vague because the incident is recognizable). The solution would not be to fire the cleaner, but to install lockable power outlets, so critical equipment cannot be disconnected without a key.
The moral of these stories is: True enterprise resilience cannot ignore the human factor. It must eliminate opportunities for a single action to bypass all safeguards.
When I joined the Customer and Innovation (CAI) team within the AI Business Unit, the shared AI cluster was still managed manually by the team, and one engineer even admitted that a single slip-up had nearly wiped out the entire environment. Coming from the Cloud Services Black Belt team, I knew this was a chance to apply years of best practices to a very real risk, so I offered to build a new cluster, managed end-to-end with GitOps.
Although this AI cluster is mostly used for demos, we treat it as if it were the production infrastructure of a global bank. Although an outage wouldn’t violate external SLAs, it would stall dozens of colleagues, derail live demos and delay the team's work. By adopting the same high-availability topologies, disaster-recovery playbooks, and GitOps pipelines we recommend to our largest customers, we work towards two outcomes: our colleagues remain productive, and the guidance we give enterprises is forged in situations that mirror theirs.
Generative AI (gen AI) changes faster than people can click. And when we speak with C-level executives at customers and partners, they point to three human-error worries that keep them up at night:
Moving fast is essential, but mitigating these human-error scenarios is non-negotiable.
GitOps isn’t new, it simply means treating everything as code and managing it through the same Git workflow you already trust.
When organizations shift from after-hours command-line deployments to daytime, peer-reviewed pull requests, production incidents start to fall dramatically, not because GitOps is “faster,” but because it enforces compliance, reliability, and security.
Plenty of teams already manage much of their stack with GitOps, and for those who don’t yet, it’s a proven, low-risk upgrade.
Take the next step: bring your AI stack under GitOps governance, capture AI platform configuration, GPU quotas, and model definitions as YAML, commit them to Git, and let automation keep production safe and fast.
Adopting GitOps did more than strengthen the platform, it also changed the way we work. By putting every configuration into code, we turned unwritten tricks into clear rules that anyone can review and improve.
If this is your first encounter with GitOps and you’d like to dive deeper, grab the free GitOps Cookbook from Red Hat and O’Reilly (and I'm not plugging this just because Natale is a good friend and colleague).
If the ideas in this article resonate with you, or if someone on your team manages an OpenShift AI environment, you’ll likely want more than a high-level overview.
Good news: We’ve documented the full approach, and it’s all online:
GitOps delivers AI-era velocity without sacrificing control: every change is fast, auditable, and reversible. Use the guide and repo to give your own clusters the same speed, safety, and collaborative power.
So, back to the title question of this blog post: Do you still need GitOps in the era of gen AI?
I hope you can see that the answer is a resounding yes! AI doesn't eliminate the need for GitOps, but actually means we need it even more. We now have to manage more things, such as AI accelerators and the drivers that power them, AI models that leverage those accelerators, and many other things, such as vector databases, MCP servers, agents and probably new things each month! GitOps provides the control and automation needed to manage this complexity, so every change is fast, auditable, and reversible.
Resource
Discover how to build smarter, more efficient AI inference systems. Learn about quantization, sparsity, and advanced techniques like vLLM with Red Hat AI.
Enter keywords here to search blogs
UI_Icon-Red_Hat-Close-A-Black-RGB
The future of enterprise virtualization for your workloads on-premise or across clouds