Launching AI Governance With a Procurement Problem

Before Diabsolut could put AI agents to work in Delivery, it had to answer a harder question first: how much of the company’s own data should an agent be allowed to touch? This is the story of what happened when AI experimentation outran a policy nobody was enforcing — and the six months it took the Citadelis IT team and Diabsolut’s Delivery Intelligence group to turn that into a governed agentic workflow, with MuleSoft, real repository owners, and real cost visibility behind it.

Author: Alberto Navas Roch

In the beginning, there was no AI. There was only procurement.

Not glamorous, perhaps, but essential: the quiet machinery of modern enterprise civilization. Requests arrived for new cloud services, applications, professional services, and other digital creatures that promised to make life easier, faster, cheaper, and occasionally more complicated in ways nobody had budgeted for.

The ritual was familiar. Someone in the company wanted to give a vendor access to company data. We wanted to know what they planned to do with it, where they planned to store it, who could touch it, how long they would keep it, and whether their security posture was made of steel, cardboard, or optimistic PowerPoint slides.

We reviewed security certifications, breach history, past security events, contractual terms, vulnerability management practices, and the overall maturity of each provider. The mission was clear: enable the business while protecting the organization. It was not always simple, but at least the battlefield was mapped. The risks had names. The controls had owners. The approval paths, while not exactly poetic, were known.

Then AI Arrived

Not as a neatly packaged technology category, politely waiting its turn in the procurement queue, but as a tsunami. And like most tsunamis, it did not begin by asking for a meeting invite.

The first wave was curiosity. AI was the announced disruption, the thing everyone was talking about, watching, forwarding articles about, and experimenting with in the privacy of their browsers. It was exciting, strange, and a little theatrical. Many organizations were still trying to decide whether it was a passing trend, a productivity booster, or the opening scene of a much larger transformation.

At that stage, people were interested, but not yet panicked. AI was still something to observe from a safe distance, like a volcano featured in a documentary.

Then came the second wave.

This one had urgency in it.

The business began to feel the pressure. AI was no longer a futuristic topic for webinars and strategy decks. It was becoming something we needed to learn, adopt, and use quickly. The message to the staff was subtle in the way a fire alarm is subtle: move fast, or risk losing traction in the market.

As the market heated up, AI-enabled solutions appeared everywhere. Every vendor, platform, tool, and plugin seemed to have discovered artificial intelligence overnight, usually with a tagline suggesting it could transform work, accelerate decisions, automate effort, generate insights, reduce cost, and possibly make coffee if the licensing tier was high enough.

Naturally, users became curious.

And then curiosity became experimentation.

Experimentation Outran the Rules

People started trying AI tools, trial versions, browser extensions, online services, and anything else with the letters “AI” attached to it, often before asking IT or procurement for approval. The traditional process, with its controls and reviews and charming insistence on knowing where company data was going, suddenly felt to many like an old toll booth on a hyperspace highway.

For a moment, things felt out of control.

The urgency coming from the business had been interpreted by many as an open invitation to test anything that mentioned AI. Governance became optional in the minds of some users, which is a polite way of saying it was temporarily ignored by people moving very quickly and feeling very innovative.

Data could be copied into tools without a full understanding of where it would go, how it would be stored, who could access it, or whether it would be used to train external models. The old vendor risk questions still applied, but AI added a new one: could the tool learn from the data, infer from it, reproduce it, expose it, or quietly turn it into someone else’s future productivity miracle?

We had already published our first AI policy in 2024 (that was a year before, during the first wave).

It existed. It was real. It had words, structure, purpose, and presumably a file location.

But timing worked against us. In the rush to explore and adopt AI, the policy was largely forgotten, joining that noble archive of corporate documents everyone agrees are important right after something goes wrong. Experimentation moved faster than awareness, and awareness moved faster than governance.

Putting AI Governance Back in Place

At that point, IT had to put its foot down and raise an urgent flag.

The point was never to stop innovation. That would have been both unpopular and impossible, rather like trying to stop the tide with a spreadsheet. It was to put limits, structure, and accountability in place before enthusiasm outran judgment completely.

As always, procurement became a key control point for reviewing new tools and services. But AI did not fit the usual vendor mold. A standard checklist was no longer enough. AI required clearer ownership, stronger governance, and new roles capable of guiding the organization through unfamiliar territory.

That was when the company began creating specific roles and responsibilities to help regain control of AI initiatives. The focus shifted from reacting to scattered requests toward building a governance model that could support innovation safely.

AI was no longer just another technology.

It had become a business capability, a risk area, and a governance priority all at the same time. A three-headed dragon, basically, except this one came with APIs, subscription costs, and legal implications.

The question that now defined everything: how to let the business move fast with AI without letting risk, confusion, and uncontrolled experimentation move even faster.

The Delivery Team Raised the Stakes

We were still working through all of this when the Diabsolut business team came forward with a more ambitious idea: implementing an agentic workflow strategy within the Delivery department.

This was not another “let’s try this and see what happens” experiment, whispered into the void with a free trial and a corporate email address.

This was a structured business initiative with a clear objective: use AI agents to improve the way delivery teams gather intelligence, produce documentation, and accelerate internal outcomes. The vision was to create an AI-enabled environment capable of connecting with company knowledge, historical project data, delivery playbooks, and internal repositories so that agents could support teams with relevant, contextual, and reusable information.

In other words, the idea was to give delivery teams something better than scattered memory, heroic manual effort, and the ancient corporate treasure hunt known as “I think that document is somewhere in SharePoint.”

The innovation team at Diabsolut contacted our team to begin building the necessary infrastructure. The goal was to create the foundation first, then expand toward the highest capabilities required for a mature AI setup. This meant thinking not only about the AI models themselves, but also about data access, orchestration, permissions, security, cost visibility, and governance.

This was where the previous AI governance conversation stopped being theoretical.

It put on boots.

We started by exploring solutions the business was interested in, such as MuleSoft, which went through the standard procurement and security due diligence process. This step was essential. Even though the initiative was innovative and business-driven, it still had to follow the principles we had already reinforced: understand the technology, validate the vendor, assess the risk, and define the right controls before enabling broad access to internal data.

Innovation is important. So is not accidentally giving a digital agent the keys to every filing cabinet in the kingdom.

Deciding How Far Agents Could Reach

From there, the discussion moved into more complex territory. We had to explore the limits of Model Context Protocols, or MCPs, and understand how far agents should be allowed to reach into company repositories.

This raised important questions. What data should agents be able to access? Which repositories should be included? Who should approve that access? How could we ensure permissions followed role-based access control? And how could we balance the need for innovation with the responsibility to protect the organization?

At times, there was natural tension between experimentation and control. Some testing scenarios required broad access, even administrative rights, to fully explore the capabilities of the platform. At the same time, we knew that giving AI agents unnecessary access to internal repositories could create unacceptable risk.

The challenge was to avoid blocking innovation while also avoiding uncontrolled exposure. This is the delicate corporate art of saying “yes” without accidentally saying “yes to everything.”

That balance required collaboration.

We engaged SharePoint site owners, Azure DevOps owners, and other internal tool owners to define the right boundaries. Repository by repository, we worked through what could be exposed, what should remain restricted, and what level of access was appropriate for the agentic workflows.

Eventually, everyone aligned around a model that put limits in place while still allowing innovation to move forward. This was no small achievement. Anyone who has ever tried to align data owners, security requirements, business urgency, platform capabilities, and governance expectations knows this is less like a meeting and more like negotiating a treaty between technologically advanced city-states.

With that alignment, the architecture started to take shape.

Wiring It Up With Controls

MuleSoft agentic orchestration became part of the solution. Its MCP capabilities were connected to selected internal company repositories. Permissions were reviewed and aligned. AI models were connected and configured through specific Azure subscriptions, allowing us to measure spend and gain visibility across the environment.

That visibility was critical.

We did not want AI usage to become a black box: mysterious, expensive, powerful, and defended by people saying, “Don’t worry, it just works.” We needed to understand the security posture, monitor performance, and track cost from the beginning.

By structuring the environment this way, we created a setup that allowed the Delivery Intelligence team to experiment and build while giving IT the controls needed to support the initiative responsibly.

The result was more than a technical implementation. It showed how AI governance, procurement, security, and business innovation can work together. The thing we had worried about, uncontrolled AI usage, became the thing we now manage on purpose.

It took six months of intense, sometimes messy teamwork between the Citadelis IT support team and the Diabsolut Delivery Intelligence team, starting in late 2025.

By the end, we had structure where there had been uncertainty, and a governed Delivery Intelligence capability where there had been scattered curiosity and free-trial experiments.

Once the foundation is in place, the real value depends on how intelligently the organization can use it. This is the part we are working on now.