AI Autonomy Gets Earned Through Defined Use Cases And Risk-Based Controls

An agentic workflow can pass every internal security review, but still fail in front of a customer. Its risk changes shape while it runs, and a review built for static systems describes only the version it saw. Enterprises are responding by moving controls earlier, into the definition of what the workflow is for. The first decision then belongs to whoever writes the use case, long before production.

Praveen Anantharaman is Vice President of IT GRC and AI Governance at MUFG Global Services, the India-based shared-services subsidiary of MUFG Bank. There, he built the enterprise AI governance framework and an automated GRC architecture covering AI risk assessments, control testing, and third-party risk management. Before joining the bank, Anantharaman co-founded an AI governance and customer experience advisory practice. He also spent six years at IBM across analytics, managed services, and transformation programs following seven years as a project manager in the Indian Navy. He holds AIGP and CISSP certifications and writes on AI governance, where his case for earned autonomy first appeared.

"AI is so good that you can scale it to a million people tomorrow, but are the customers ready to adopt it? That's the real question. It's not the technology challenge, it's the people challenge," said Anantharaman. Inside his framework, a team earns autonomy one use case at a time. He also believes strategy and context should stay with leadership, even as AI takes over execution.

• Autonomy by use case: Two teams at the same company can warrant different levels of autonomy. Anantharaman weighs how well the team in question understands its own use case, alongside the market conditions facing the product, and moves it up a five-stage maturity scale as evidence accumulates. "Autonomy is something which needs to be earned and it takes a whole team to do this, including governance," Anantharaman said.

• The order of controls: Anantharaman ranks the five controls in priority order, starting with the use case itself. A team eliminates or accepts it against the organization's risk tolerance, then designs controls into the product, with engineering and administrative controls next and resilience last. All five sit downstream of the goal an agent was given. "When we have intent-based systems, even if there is a minor mismatch in the end goal, tuning to KPI would kind of develop behaviors which is very difficult to solve later," he explained.

At MUFG Global Services, a standing governance group gives leadership a portfolio view of what's running across the organization. Review boards sit at the junctures where a project makes a consequential decision, so the choice gets peer-reviewed and signed off before the team moves on. The same body issues guidelines on third-party integrations and acceptable tech stack decisions. "We have a Center of Excellence which identifies the use cases and it brings up the risk level and acceptance," Anantharaman said.

• Minimum viable governance: Anantharaman scales governance to the phase a project is in, a standard he called "just enough governance." Too little leaves strategic exposure. The regulations take the same risk-based approach, the EU rules included, so a team can defend how much it applies. "If you overdo governance, you would not get the ROI or you will not be fast to the market, and you may lose your opportunity to shine and your opportunity to acquire customers," he noted.

• Centralized to federated: Anantharaman sees few organizations with the risk appetite to distribute authority at the start. Moving it outward takes judgment long after the direction is set, since the structures, the team processes, and the organization’s reporting lines all have to change with it. "They will start with a centralized approach which could be a little tighter control and slow moving, however slowly going towards a more federated or local decision making would make it agile," Anantharaman said.

Anantharaman estimated 60 to 70% of AI risk is with people, meaning how engaged a team is and how well it understands its own processes. His answer is to record why a decision was made, because a new model release can undo a choice that was right at the time. He wants leaders to document their own decisions before they ask their teams to. "Leadership should empower folks, and it shouldn't become another checkbox or another delay factor," he noted.

• Decision rights move: Before a use case is approved, the question is whether to build it at all. Anantharaman issues a new RACI once the risks are identified. Teams that inherit those decisions need what other teams learned, so lessons travel in short sharing sessions covering what worked and what went wrong. "The decision importance goes to people who are on the ground, making sure that it goes from business to technical," he explained.

• Prevention by design: Anantharaman noted that prevention is far cheaper than remediation. Release cycles have compressed from a two-week change to a whole product inside a week, leaving little room to react after the fact. "You need to plan for failures and inevitably there would be failures with this complexity, and you need to make sure that you don't fail strategically," he said. "You have to build in the circuit breakers and you need to ensure that blast radius is minimized."

A client who trusts a company hands over more data, and a system with more data personalizes better. Anantharaman treats governance as what makes that first share possible. He wants the same rigor applied to whether buyers will take up a product at all, and what they will pay for it. "The risk of the customer not adopting a product is also a risk which we generally tend to ignore," he noted. "We tend to only look at technical risk."

Some customers will work with a product while it's still rough. They experiment with their own data, send feedback, and stay through the failures. Anantharaman builds the early phase around them, and he wants the learning done in the market, since prior data and industry experience both miss how a customer actually behaves. "AI success will depend on building a good trust with at least the innovative 8 to 12% of the group so that you can bring a toy model pilot to a real life product," Anantharaman said.

Anantharaman still counts an agentic project with no ROI yet as a success, since a team builds the habits and processes it will need either way. He splits the inputs to any decision in two, the business context and the customer's, and he wants both in hand to make the call. "Once we identify the risk, then working backwards towards just enough governance becomes justifiable, and it becomes a strategic perspective and competitive advantage," Anantharaman concluded.