By Naveen MR, Head of Technology for Generative AI Business Services at Happiest Minds Technologies
Enterprise AI has a production problem, and most people describe it wrong. It’s not really a technology problem. Pilots usually work, business case usually holds up, and the budget is usually there. Still, very little AI goes live with real customers on the other end. People keep blaming the technology for this. The technology isn’t the issue.
Since the problem shows up inside a tech program, everyone looks for a tech fix. That’s usually the wrong instinct. What holds the program back is almost never the model. The real issue is that no one in the organisation is clearly empowered to make the call: “Yes, switch it on.” This part of enterprise AI has changed the most, and hardly anyone writes about it. For a long time, companies got ahead based on what they could build. Now it’s about what they can approve.
Why Now: Adoption Has Outrun Oversight
The numbers here aren’t fuzzy anymore, several recent studies look at this from different sides and end up in the same place.
Companies are deploying faster than they can oversee. Around 55 percent of enterprises are actively deploying AI, yet only 26 percent say their governance frameworks are keeping pace. (Source: Smarsh & FTI Consulting, 2026 Enterprise AI Trends Study).
Leaders think they can see more than they actually can. About 90 percent of senior security leaders say they have a clear view of where AI is used in their organisation. But 59 percent also confirm or suspect shadow AI, and 70 percent report confirmed or suspected vulnerabilities from AI-generated code that’s already in production.
Proper governance is still rare. Some 60 percent of organisations use AI across multiple departments, yet just 4 percent govern it at scale.
Projects are dying because of weak controls, not weak capability. Gartner expects more than 40 percent of agentic AI projects to be canceled by the end of 2027, pointing to rising costs, unclear business value and poor risk controls.
The Distinction That Matters
Compliance and authorization sound similar. They aren’t, and most enterprises have only built compliance. Compliance is for the regulator, after the fact. It shows the system was allowed to run and keeps a record of why. Authorization is for the business, right now. It decides if the system should run at all, how much it can do without a person stepping in, and who takes the hit if it gets something wrong.
On paper, the two can look almost the same. In practice they lead to very different places. A compliance-first program keeps producing review cycles and questionnaires, and the queue just gets longer. An authorization-first program ends up with named owners, controls that fit the risk, and systems that are actually live.
That’s what has changed this year. Raw capability is no longer hard to get. Frontier models are easy to access and for most enterprise work they’re starting to look alike. What’s hard to get now is permission. Permission to use these models on anything involving money, eligibility, safety or someone’s job. And permission is exactly what risk management gives you. So, it belongs in the growth discussion. It shouldn’t be sitting off to one side.
Where AI Programs Actually Stall
The demo is rarely where things get stuck. It happens later, once people start talking about production and someone asks who’s going to sign off. Everyone knows what that signature means. The system will face customers directly. Months later an auditor, regulator or journalist might ask why a decision came out the way it did, and one person’s name will be attached to something the system did while nobody was looking.
Funding an experiment carries almost none of that weight. Approving a live deployment carries all of it. If the company hasn’t sorted out ahead of time who owns the accountability, it falls on whoever happens to be nearest. And that person does what anyone sensible would do. They ask for more testing. Then another review. Then a wider pilot.
Here’s what sits underneath all this. Enterprises don’t usually fail to deploy AI because the risk is too big. They fail because nobody owns the risk. If a company can say who answers for a system, what it’s allowed to decide without a human, and how its decisions can be pieced together later, it will put imperfect systems live and improve them in the open. If it can’t, it will keep great systems in evaluation forever and call that being careful.
What The Working Version Looks Like
A risk capability that works looks different from one that only exists in documents. You can spot six differences from the outside.
The first is triage based on consequences. Systems are sorted by the damage a wrong output could cause and how hard it would be to reverse. Which model or vendor is behind it doesn’t really come into it. Most systems turn out to be low stakes and get cleared within days. That’s what makes it possible to spend real time on the few that touch money, eligibility, safety or employment.
Second, a real person is accountable. Not a department, not a committee. When responsibility is spread across a committee, nobody holds it. Usually, the right person is the executive who owns the business process the AI is part of. And if nobody is willing to take it on, that tells you something too.
Decision rights also need to be on paper. It’s clear what the system can settle by itself, what needs approval, and what has to stop and go up the chain. This fits on roughly a page. Teams without it can spend months arguing about autonomy without getting anywhere. Reviews should happen when something changes, not simply because the calendar says so. AI systems don’t get worse once a year on schedule. What should prompt a fresh look is a specific event, such as a new data source, a newly connected app, a bigger group of users, or a move into a new jurisdiction.
Fifth, decisions can be pieced back together. Logging every call isn’t the same as being able to explain one result. The system needs to show what it looked at, which policy applied and where a person stepped in.
This has to be part of the design from day one. Bolting it on later doesn’t work well.
And finally, the off switch needs to have been tested. If a system starts producing outputs the business can’t defend, its access should be pulled straight away, without setting up a meeting first. How quickly a company can take autonomy back is an honest measure of how much it can safely hand out.
Implications For IT Services
The shift from compliance-led governance to authorization-led risk management is changing what enterprises buy and what their service providers need to deliver. Advisory work that ends with a policy document and a maturity score is losing value quickly. Clients now want the triage model actually set up. They want decision rights written in language the business understands, and a revocation path that has been built and tested, not just described in a slide.
Risk controls added after a system is built tend to cost more and still leave gaps. So, providers are moving classification, decision rights and observability into the delivery lifecycle itself, alongside architecture and testing. A lot of the ongoing work is also becoming its own type of engagement. Trigger-based reviews, drift monitoring, finding shadow AI and generating evidence never really end, and most internal teams don’t have the people for it.
The way value gets measured is shifting too. Enterprises are starting to judge providers by how much AI they’ve helped put into production safely. How many pilots they ran matters less. Time to authorization is turning into a commercial metric.
The Constraints That Remain
The shift is real, but there are still things in the way. The first is plain visibility. You can’t govern systems you can’t see, and companies almost always think they see more than they do. Review processes built for stable software will approve a system in January that’s quite different by June. And when one uniform process is used for both an internal drafting assistant and a system that adjusts financial reserves, it ends up failing at both.
Business leaders are being asked to own results from systems they didn’t commission and can’t fully explain. People who know AI governance, assurance and audit well are still hard to find. And regulators and auditors are moving toward documentation standards that most organisations couldn’t produce today if someone asked.
What AI Scale Will Demand
More autonomy is coming no matter what, systems that handle long chains of work across applications, with fewer human checkpoints, are already running inside enterprises. Autonomy doesn’t really bring in a new type of risk. It multiplies whatever governance is already in place. Where ownership is clear and controls fit the risk, output grows. Where they’re missing, exposure grows just as fast.
For leadership, the practical point is this. AI strategy and risk strategy can’t live in two separate documents anymore. How hard a company pushes AI depends on what it’s ready to answer for. A roadmap that treats governance as a side track has got the order wrong.
The competitive question has flipped without much fanfare. It’s not about what a company can build anymore. It’s about what it’s willing to approve, how quickly, and whose name goes on the approval.
The companies that build this will be able to say yes fast, to the right things, with someone’s name behind every yes. The ones that don’t will still be working out who needs to be in the meeting while a competitor is already in production.