Evolve · Fourth stage of your AI journey
Governance programme design
Most AI governance lives in documents that nobody building an agent has ever read. This engagement works the other way round: we map the AI you actually use, turn the rules that apply to you into plain instructions for the people building, and connect each rule to a control in the cloud where your agents run.
Governance that lives in a folder does not govern anything
Most organisations that take AI governance seriously start in the same place. Someone writes an AI policy, perhaps after reading the EU AI Act or a regulator’s guidance, and it goes onto the intranet. That is a good start, and it is rarely where things go wrong. The problem is the distance between that document and the engineer who is, right now, deciding which data an agent is allowed to read.
What usually happens next is predictable:
- You are governing what you know about. The use cases on your official list are the visible part. Around them sit tools people adopted without asking, AI features switched on inside software you already own, and agents somebody built over a weekend. A policy written without that picture covers only a fraction of what actually runs.
- The rules are written for auditors, not for builders. “Appropriate human oversight” is a sound requirement and a useless instruction. An engineer cannot build to it, so every team interprets it differently, or quietly decides it is somebody else’s job.
- Governance arrives as a gate at the end. Teams that meet it for the first time on the day they want to go live find ways around it, and then you are back to the first problem.
The numbers are uncomfortable. In IBM’s 2025 research on data breaches, 13% of organisations reported a breach of an AI model or application, and 97% of those said they had no AI access controls in place. Among the organisations that had been breached, 63% either had no AI governance policy or were still developing one, and those with high levels of shadow AI saw breach costs that averaged $670,000 more than those with little or none.
Source: IBM, Cost of a Data Breach Report (2025)
Rules that run where your agents run
Governance programme design is one of our Evolve engagements. It is built for the point where AI has stopped being an experiment: several use cases are live or about to be, the rules that apply to you are becoming concrete, and “we have a policy” is no longer a satisfying answer. Like our other pre-defined engagements, you know before you start what happens, who needs to be involved and what the programme looks like at the end.
We do this our way, which means fewer documents and slides, and more operational governance. The programme we design is a single chain that you can follow in either direction: from what you use, to the rule that applies to it, to the control that enforces it, to the evidence that it is working. It comes together in three steps.
We start with what you actually use. We build a complete picture of AI usage in your organisation: the use cases everybody knows about and the ones nobody announced. Each one is recorded in your Solidbase Workspace, a private space we set up for you at the start of the engagement, with a named owner, its purpose, the data it touches and where it runs. That record is your AI portfolio, and everything else in the programme hangs from it.
Then we turn requirements into rules people can build to. Regulation and standards are written in abstract language, deliberately, so that they can apply to everyone. A builder needs something more specific. Working with your legal, compliance and risk colleagues, we take the requirements that apply to you (the EU AI Act, GDPR, DORA or your own sector’s rules, plus whichever standards you follow, such as ISO/IEC 42001) and write them as short, concrete rules: what must be true, which kinds of agent it applies to, and who is responsible for it.
Finally, we connect each rule to the place where it can be enforced. This is where most governance programmes stop, and where ours becomes useful. For each rule we decide how it will actually be met. Where the answer is a technical control, we map it to the guardrails, identity and access policies, network and data-residency settings, and logging in the cloud where your agents run. Because the rules and your portfolio live together in the Solidbase Workspace, you can look at any agent and see which rules apply to it and what enforces each one, and look at any rule and see every agent it touches.
What you end up with is not a binder. It is a working programme: an inventory of AI that you trust, a short set of rules your builders understand, a map from each rule to its control, clear owners, and a rhythm for keeping all of it current.
Three phases over six to ten weeks
Shaping (before the work starts)
A short workshop to agree the scope (the whole organisation or one business unit), which regulations and standards apply, which cloud platforms your agents run on, and who takes part. We want legal or compliance, security, your platform engineers and the people who own AI use cases in the conversation from the start, because each of them holds a piece the others lack.
We also agree who has the authority to approve the rules, so that nothing waits at the end for a decision nobody was asked to make. Your Solidbase Workspace is set up at this stage.
Phase one: Discover
We build the picture of what you actually use. People tell us what they know through short working sessions with each function and through simple forms in the Solidbase Workspace, on the clear understanding that this is not an audit and nobody gets into trouble for what they adopted.
Alongside that, we ask your IT, procurement and cloud teams for the signals they already have, such as single sign-on application lists, software and cloud spend, and cloud account inventories, because that is where tools nobody mentioned tend to show up. We do not need access to production data, and we do not scan your network.
Every use case lands in your portfolio with an owner, a purpose, the data it touches and where it runs. We also flag early anything that looks as though it may fall into a higher-risk category, so that it gets attention first.
Phase two: Translate
With your legal, compliance and risk colleagues, we identify which requirements and standards apply, and then work through them one at a time with the people who build. For each one we write a rule in plain language and keep it short: what must be true, which kinds of agent it applies to, how you will know it is being followed, and who owns it.
Each rule is then sorted into one of three kinds: enforced by a technical control, monitored, or dependent on a person. By the end of this phase you have a rulebook that an engineer can read in an afternoon, with every interpretation approved by the people who are accountable for it.
Phase three: Connect and hand over
For each rule that can be backed by a technical control, we design the control: which guardrail, which identity and access policy, which network, data or logging setting, in your cloud. We then prove it on a small number of real agents from your portfolio, working with your platform team to put the first controls in place, so that the programme has been shown to work rather than merely described.
The Solidbase Workspace links every rule to its controls and to the agents they apply to, and it holds the evidence that those controls are in place.
We close by agreeing the roles (who is responsible, accountable, consulted and informed for each part of the programme), the rhythm for keeping it current, and what triggers a review: a new agent, a change in the rules, or an incident. Your platform team can then carry the remaining controls forward, using the same pattern.
Questions we get asked
How long does it take?
Six to ten weeks, on average, from the first discovery session to the handover, plus a short shaping call beforehand. The range depends mostly on how many business units and cloud environments are in scope, and on how quickly your legal and compliance colleagues can review the rules.
Do you need access to our systems or data?
Not to production data, and we never scan your network. Discovery relies on conversations, simple forms and the information that your IT and procurement teams choose to share. To put the first controls in place, we work with your platform team inside your environment, with whatever access they are comfortable granting.
Who should take part?
A mix works best: someone from legal or compliance, someone from security, the platform engineers who run the environment your agents live in, and the people who own AI use cases. An executive sponsor who can settle disagreements between those groups is the single most useful thing to have. You do not need a dedicated governance team to start, because building the beginnings of one is part of the point.
Are you giving us legal advice?
No, we are not a law firm. We translate the requirements into rules that people can build to, and your own legal or compliance team, or your external counsel, confirms that the interpretation is right. We work with them throughout, and the rulebook is theirs as much as ours.
Can every rule really be enforced automatically?
No, and we would be wary of anyone who says otherwise. Some rules can be enforced by a technical control, some can only be monitored, and some depend on people doing something and keeping evidence. We label each rule honestly, because knowing which is which is what makes the programme credible to an auditor.
Which clouds do you work with?
AWS, GCP, and Azure, which are the platforms we have built agents on. If you run somewhere else, the usage picture and the rules carry across unchanged, while the controls themselves are specific to each platform. We will tell you early how far we can take the mapping based on a working example.
We already have an AI policy. Do we still need this?
Quite possibly, and there is a simple test. Pick one rule from your policy and ask which of your agents it applies to and what enforces it. If the answer is somebody’s memory or a spreadsheet, that is the gap this engagement closes. Your existing policy is a good starting point, and we will build on it rather than replace it.
Do we have to adopt a governance platform?
No. During the engagement you get a private Solidbase Workspace where your portfolio, your rules and the mapping between them live. It is how we work together, it is not a product we are asking you to buy, and everything in it can be exported at any time.
What happens afterwards?
That is up to you. Everything is yours and can be exported, so your own team can carry on. Governance does not stand still, though: new agents appear and the rules keep changing. If you would like our help in keeping the portfolio and the mapping current, the Solidbase Workspace can stay live as part of an ongoing arrangement.
If you have new ideas waiting, they can go through our Use Case Prioritisation exercise, and if one of them comes back as high-risk, an EU AI Act assessment goes deeper on that use case.
Ready to make governance work in practice?
If you have AI policies that nobody can tie to a specific agent, or you suspect more AI is running than anyone has recorded, that is a conversation worth having. Fill in the details and we will send you the full description of this engagement, including what deliverables you should expect from us. If that aligns with your goals, we can schedule a first call to work out the details.
