Your next AI governance problem could arrive through a software subscription you approved years ago. Your board may never have authorised an AI programme, and your business may never have employed an AI developer. Yet an assistant inside an existing application could already be helping people find confidential information, prepare customer communications or influence business decisions. How confident are you that someone understands what it can access, what it can do and where its authority should end?
You’re not alone in facing that question. Even Microsoft has had to address it in its own Microsoft 365 Copilot rollout. Its account of the governance work includes how it tackles overly broad access to information. The implication for your business is straightforward: information your employees already have permission to access can become much easier to find and use. If those permissions are too generous, introducing AI makes that weakness more consequential. You need confidence that the access you have allowed is the access you actually intend.
Buying software from a trusted supplier does not settle the questions about how your organisation will use it. The supplier provides capabilities and controls. Your business still needs to decide what information it should access, what authority it should have and who is accountable for its use. Those decisions remain yours, however familiar the supplier or established the product.
AI adoption can begin inside an existing supplier relationship
It is easy to associate AI governance with organisations developing their own models or building AI into their products. Those organisations have visible development activity, technical teams and investment decisions around which governance can be organised. If your business does none of those things, you could reasonably assume that AI governance is somebody else’s concern.
AI introduced through enterprise software is less conspicuous. A familiar application gains an assistant, a team enables a feature to save time, and someone connects it to another information source because doing so makes the answers more useful. Each step may look like an ordinary improvement to an existing service, while collectively changing what the software can access and do within your business.
This extends beyond productivity tools such as Microsoft 365. Salesforce’s publication about governing AI agents examines the implications of software moving from answering questions to taking action. These agents can carry out tasks with varying degrees of autonomy, depending on how they are configured and what authority they receive. For your leadership team, the important distinction is whether the software helps an employee make a decision or has permission to act without someone approving each step.
Consider your customer service team. An assistant that drafts a reply for an experienced employee to review may offer a useful, manageable improvement. Connecting it to customer records could make those replies more relevant, while also changing the information it can access. Authorising it to issue refunds takes the decision further: you are delegating authority over a financial transaction. You need to decide the limits of that authority, when approval is required and how mistakes will be identified and resolved.
Calling all three activities “using AI” conceals the decisions that matter. It can also allow risks to grow unnoticed: wider access creates confidentiality and privacy exposure, greater authority introduces financial and operational consequences, and mistakes reaching customers can damage trust and reputation. If your governance treats these uses as equivalent, your leadership team may never see how much the exposure has changed.
Who owns the whole process?
Your existing technology governance provides a foundation, but you need to understand whether it covers the way AI changes a business process. Supplier assessments, access controls and security reviews may each address part of the picture. Microsoft’s Copilot deployment guidance, for example, makes reviewing excessive access part of deployment readiness. That work requires someone to decide whether existing permissions are appropriate, rather than simply confirm that the software respects them.
Responsibility becomes harder to follow when it crosses organisational boundaries. Your IT team may manage the application, a department may own the process, and an external supplier may configure the service. Each can be doing its own job competently while nobody has considered the complete chain from information access to business consequence.
Your customer service manager may assume that IT has assessed an assistant because it sits inside an approved platform. IT may assume that the department has agreed how its output will be checked. The supplier may have enabled the feature exactly as requested. Unless someone brings those responsibilities together, you can end up with a working system and an unexamined business risk.
You need confidence that someone owns the complete process, including what happens when the software behaves unexpectedly or a customer challenges its output.
This is where a fractional CIO can help
An experienced fractional CIO can take responsibility for establishing how these decisions are made and leading the work needed to put them into practice. That begins with understanding your business: what you are trying to achieve, which processes matter, where sensitive information sits and how responsibility is currently shared between your people and suppliers.
We begin readiness assessments, technology strategies and fractional leadership engagements in the same way. Before recommending changes, we need to understand how your organisation actually works, what is getting in its way and what your team has the capacity to deliver. That understanding helps you distinguish between an urgent weakness, a worthwhile opportunity and something that can wait.
For AI, an application inventory is only the starting point. You need to establish which capabilities are available, which are enabled and which are being used in practice. Conversations with your business teams are essential because a use with serious consequences may sit inside an everyday workflow that has never been treated as a technology project.
A fractional CIO can use that evidence to agree priorities with your leadership team and bring business owners, IT, security, legal advisers and those responsible for data protection into the decisions that concern them. An internal drafting assistant and a system influencing employment decisions deserve different levels of scrutiny. Your resources need to follow the potential consequences, with clear ownership of the decisions and the work that follows.
The CIO leads the work across those boundaries. Your business leaders remain accountable for the processes, decisions and risks they own.
Autonomous agents make delegated authority a business decision
As agents take on more tasks without approval at each step, you need to consider what their combined permissions allow them to do. Access that appears reasonable within one application can have very different consequences when connected to another. The question is whether the agent’s effective authority matches what your business intended to delegate.
As agents take on more tasks without approval at each step, you need to consider what their combined permissions allow them to do. Access that appears reasonable within one application can have very different consequences when connected to another. The question is whether the agent’s effective authority matches what your business intended to delegate.
This is a difficult maze to unpick when ownership is spread across applications, departments and suppliers. Your CRM owner may understand the permissions within that platform, while your finance team understands payment approvals. Someone still needs to examine what happens when an agent connects the two. A technical permission can become a route to exercising business authority, and your leadership team needs to understand where that boundary lies.Your customer, however, does not care about this maze. They care about their information, the products and services you provide, and their experience of dealing with your business. They hold you responsible for what happens, however many systems, agents or suppliers are involved.
A fractional CIO can help you connect those technical permissions to business authority. Working with your internal teams and suppliers, they can establish how agents access systems, identify excessive permissions and agree limits on the actions they can take. They can also challenge whether the available controls let you trace actions, withdraw access and stop further activity when something goes wrong.
You cannot assume that every supplier provides all the controls your business needs. Where those controls are inadequate, your leadership team needs a clear decision: restrict the proposed use, retain human approval or defer deployment until the gaps are addressed. A fractional CIO can make those limitations visible and lead the discussion about what your organisation can responsibly authorise.
That gives you a basis for deciding where autonomy will create value and where the consequences exceed your ability to oversee it. You do not need to develop the agent yourself to need that leadership.
Turning governance decisions into action
An assessment can establish where the gaps are, but your organisation still needs someone to turn the findings into agreed priorities, assign the work and maintain momentum. This is where executive involvement matters. Resolving excessive access may compete with a commercial deadline; a department may want to enable a feature before another team has completed its review. Someone needs to resolve those competing priorities and bring decisions back to the leadership team when the consequences warrant it.
A fractional CIO can lead that delivery across your internal teams and suppliers, checking that agreed controls have been implemented and tested in the workflows your people actually use. The work is complete when responsibilities are understood, approval routes function and the business can demonstrate that its controls work. A policy document alone cannot provide that evidence.
Your people also need a practical way to use AI productively. They should know which tools they can use, what information they can provide and where to take a proposal or question. When the route to approval is understandable and proportionate, teams have a way to pursue useful improvements with the right support.
The same approach can cover AI capabilities you develop yourselves. Your teams then need to demonstrate how they test for inaccurate or inappropriate outputs, unintended disclosure and actions outside the intended scope. They also need to assess how changes to models, instructions or connected information affect behaviour. A shared governance approach lets your leadership team oversee a business process that combines your own development with software supplied by others.
A fractional appointment provides executive capacity to establish these arrangements and lead their implementation where your business does not yet need, or cannot yet justify, a permanent CIO. It should also leave your people able to manage routine approvals, reviews and escalation, with clear responsibility for keeping the arrangements effective.
Confidence comes from knowing who is in control
In What your AI disclosure tells your customers, we explored what an organisation’s public statements communicate about its use of AI. Those statements need operational support. You should be able to explain who owns the relevant activity, how it is controlled and what evidence supports the assurances you give.
The same principle applies inside the boardroom. Your leadership team should be able to demonstrate where AI is being used, what value it is delivering, who is accountable and how the business retains control as that use develops. Your board should be asking what evidence supports those assurances, where material risks remain and which decisions need its attention. That gives both leadership and the board a basis for judging whether AI adoption is serving the business and whether the controls remain appropriate as its use expands.
You do not need to build AI to need AI governance. You need confidence that the authority you delegate, the information you expose and the decisions you automate are understood and controlled. That confidence gives you a basis for pursuing the opportunities AI creates, knowing who is responsible and how your business will respond when something changes.
If you cannot yet answer those questions with confidence, speak to us. We can help you understand how AI is entering your business, agree what needs to change and lead the work through, so you can make your next technology decision with confidence.