The debate about AI adoption is largely over. The more pressing question is how to ensure that AI governance keeps pace with AI adoption, but without slowing down time-to-value. This is true for any application, but especially for mission-critical ones. Being able to say, ‘We’d probably be able to stop the train in time,’ is not good enough. Yet the reality is that while the supporting technologies are largely in place (or getting there), the cultural attitudes and processes that support better AI governance are not.
For example, our own research of 820 IT professionals worldwide found that while 77% have confidence in AI outputs, only 39% have fully automated audit trails. If AI is to scale safely, securely, and compliantly, that gap between adoption and governance has to close. Maybe easier said than done, but better monitoring and control of AI has to become a non-negotiable priority.
Change has to start on an organizational level. In my experience, many enterprises still treat governance as something that happens outside the software delivery process. Policies are defined, audits are conducted, and compliance reviews take place after work is completed. They are already lagging behind, but with agentic AI acting autonomously, we need a change in mindset in which monitoring and control of AI are engineering capabilities built directly into the SDLC. Validation, policy enforcement, access controls, lineage tracking and compliance checks should operate alongside development activities, rather than afterwards.
AI Governance Must Move into the Delivery Pipeline
While a developer might say, “Well, we used AI, and it works”, governance asks, “How do you know”? Someone else might say, “We’ve deployed autonomous agents”, then governance asks, “And what happens when one of those agents makes a bad set of decisions?” Enterprises need to be able to understand who or what made a particular decision? What data influenced the outcome? Which policies were enforced at the time? Can we reconstruct the reasoning process if something goes wrong?
This is why traceability becomes essential. Governance depends on keeping a clear record of AI-generated code, automated actions, data usage, and decision processes. Having that visibility means teams can understand how outcomes were produced, when issues arise, how the problem occurred in the first place, and even replicate the same scenario with every element involved.
Organizations also need explainability. If traceability shows what happened, then explainability shows why it happened. Here’s an example. An AI agent identifies a performance issue, generates a code change, runs tests, updates documentation, and prepares deployment. Traceability would capture the performance alert, the generated code change, the test runs, the deployment request, and the approvals applied.
Explainability would involve why the agent decided there was a deployment issue, what evidence it used, why it selected that particular fix, and why it believed that fix was safe.
Next, we need accountability. Traceability and explainability only matter if someone is paying attention. Organizations still need people who can interpret the evidence, challenge decisions, and take responsibility for when things go wrong. This does not just mean shifting engineering focus from execution to oversight, but to having the depth of engineering experience and knowledge to precisely interpret the situation. In the age of AI, senior engineers matter more than ever.
Human Oversight Must be Able to Scale
That said, human oversight cannot risk becoming yet another burden on already overloaded engineering shoulders if they need to search across multiple systems. Furthermore, human management also needs to be scalable. Nor can governance become yet another bottleneck within an SLDC environment already riddled with barriers that slow down production.
This is why centralized access and control layers are emerging as one way to address this need, creating a single point through which AI interactions can be monitored (such as which MCPs are being used), governed, restricted (for instance, only a safe curated list of MCPs can be used), and audited. In practice, this helps organizations maintain oversight of AI activity without requiring engineers to become full-time compliance officers, nor production being de-accelerated.
Governance should also be viewed as a cross-functional responsibility, across engineering, security, operations, and compliance teams working from a common understanding of risk, accountability, and oversight. This more collaborative approach is a basic tenet of a sound DevOps practice, as is governance. This raises the point that when done well, DevOps can tangibly contribute to better governance, according to internal research: 70% of 820 IT professionals believe that mature DevOps adoption contributes to successful AI adoption. The same disciplines that underpin mature DevOps, such as automation, testing, traceability, auditability, and shared ownership, also provide the foundation for effective AI governance. So, going back to basics, reviewing and improving DevOps’ foundations is a good place to start.
While choosing the right tools makes a huge difference, DevOps was never a tooling challenge, nor is AI governance. Many governance problems stem from organizational issues rather than technical limitations. Overcome those issues, address traceability, explainability, accountability, and control, enforce governance throughout the SDLC, and then we are in better shape to start trusting the use of AI at scale. As someone who’s been involved in AI for over a quarter century as a CTO, I remain one of its biggest advocates, but it is just a tool, and a very complex one at that. So now is the time to put the control brakes in place so that we can be more confident in our ability to drive that train safely, but without slowing down the SDLC.
