How a sprawling organisational problem became six repeatable questions, a public Journey and a real-world experiment that immediately started changing the design.
I've spent a lot of this year digging into what happens between an organisation deciding it wants to use AI and actually being able to adopt it safely at scale.
If you've followed my Impact of AI series, you'll know the digging hasn't followed a straight line. AI governance led me into operating models; operating models led into ownership and decision rights; those led into capability, judgement and learning; and they eventually opened much bigger questions about how organisations develop and renew the ability to deal with things they haven't seen before.
Every time I thought I'd reached the bottom of one part of the problem, there seemed to be something else underneath it. That exploration has helped shape Empower Your World, the Frontier Capability Organisation work and much of my thinking about what AI adoption might really require. It has also created another problem: the whole thing can become enormous.
A very early version of the problem: AI adoption quickly connects governance, security, data, people, evidence, ownership, learning, judgement and much more.
Governance, security, privacy, regulation, risk, data, people, agents, controls, evidence, ownership, incidents, operating models, learning and judgement are all connected and all matter. That still doesn't help much when somebody turns up on Monday morning with an AI idea and wants to know what to do next.
At some point I realised I might be asking the wrong-sized question.
Making the problem small enough for reality to answer back
Trying to solve safe AI adoption for an entire organisation in one go is an enormous undertaking. It is easy to respond with something equally enormous: governance boards, frameworks, policies, principles, controls, standards, processes and an operating model to hold all of it together. Most organisations will need some combination of those things, but they are a difficult place to begin when the immediate problem is one real use case.
What happens if, instead of starting with the whole organisation, we change the size of the question? Take one use case. It might be somebody creating an agent over a bounded set of Microsoft 365 content, a Copilot Studio solution that starts taking actions, or something much more consequential built through Azure AI Foundry. Put one real thing in front of us and ask what needs to be true for us to make a sensible decision about that thing.
Making the problem smaller: move from the organisation-sized problem to one real use case.
The questions become much more tangible. Should this use case enter at all, and does it need formal governance or an initial self-service route? How significant is it, and what makes it materially different from another idea? If we understand the risk, what actually needs controlling, which controls already exist in the platform and which remain ours to design or own?
Putting controls in place once is not enough, so what happens as the use case, technology, data or environment changes? How would we know the controls operated? If somebody asked for evidence tomorrow, where would it come from? Eventually something will happen that nobody quite expected, so who notices and who owns the first decision?
I kept coming back to versions of those questions. Eventually the rough questions became something more formal.
The rough questions becoming repeatable: an enquiry sequence formalised into the six-stage Risk Spine.
That became the Risk Spine at the centre of Make AI Adoption Safe. The formal version now has six stages: Front Door, Risk Size, Control Floor, Living Loop, Evidence Chain and Response Net. The names matter less to me than the questions underneath them: where does this enter, how significant is it, what controls are needed and who owns them, what changes after launch, where does the evidence come from, and who acts when something surprising happens?
Making those questions explicit gives people something they can see, discuss and repeat. It does not give them all the answers, and I do not think it should.
Formalising the questions doesn't remove judgement
I have a tendency to formalise things. Sometimes that is useful. Turning a rough idea into something structured helps expose gaps, find inconsistencies and make the thinking transferable to somebody who wasn't there while I was working it out. The danger is mistaking the formal model for the answer.
So I took the Risk Spine and started writing questions all over it.
The formal Risk Spine with practical questions written back onto it. Structure supports judgement; it does not replace it.
Should Front Door be self-service or formal? What do we use to size risk, and how much do usage and scope change the judgement? When we reach controls, what is already provided by Microsoft and what do we still own? Who watches for change once something is live? If we say the use case is evidenced, where do we find the evidence? And who are we going to call when something odd happens?
Those are not flaws in the Risk Spine. They are the point. A repeatable structure gives us a consistent place to ask the questions without pretending that the circumstances surrounding two different use cases are identical.
Formalising the questions does not remove judgement. It gives us something better to exercise judgement against.
Does everything really have to go back to the governance team?
While working through this, another picture started bothering me. If AI adoption increasingly happens throughout an organisation, where do all those decisions go? The obvious model has use cases, questions and concerns converging on an AI governance team, which decides whether something can Go, needs to Pause or should Stop. That can make sense for consequential decisions, but I am less convinced it makes sense for everything.
Two ways of thinking about governance: everything converging on one team, or broader capability resolving more locally while formal authority remains available.
If thousands of people are going to encounter AI opportunities in the course of their work, telling all of them to send everything to a central team does not feel much like scaling AI adoption. It feels like scaling a queue. That is not an argument for removing governance or pretending everybody can become a security, risk, privacy, architecture or legal specialist. Some expertise should remain specialist, some decisions should remain formally owned and some things absolutely should be escalated.
The interesting possibility is what happens before escalation. Could a broader group of people recognise what they are looking at, ask sensible questions, understand where their authority ends and know when they need somebody else's expertise? Could teams describe a use case well enough that, when specialist involvement is necessary, the conversation starts somewhere better?
Perhaps scaling AI governance does not always mean scaling the AI governance team. Perhaps some of it means scaling the organisation's ability to make better decisions.
That idea increasingly sits behind J01: safe AI adoption is an organisational capability problem, not simply a policy, technology or compliance problem. Capability can become more distributed without pretending that authority and specialist expertise should be.
Same questions, different weights
A lot of what I have published recently has deliberately been technology agnostic because I wanted to understand what happens to capability and judgement as the technology underneath organisations keeps changing. That does not mean the technology does not matter. Quite the opposite.
Same Risk Spine questions, different weights: a prompt to compare how M365 Agent Builder, Copilot Studio and Foundry use cases may require different responses.
Imagine two superficially similar requests. One person wants to create a bounded Microsoft 365 Copilot agent to help a small team navigate a defined collection of information. Another team wants to build a Copilot Studio solution that connects to business systems, takes actions and operates across a much wider group of users. I can ask the same Risk Spine questions of both, but I should not expect the same answers.
Intake might be relatively lightweight for one and more formal for the other. The same risk-sizing model might produce very different judgements because agency, reach, data and governability are different. Controls may draw on different combinations of Microsoft 365, Power Platform, security, identity, data and application capabilities. Evidence may come from different places, while the operating model and support arrangements may be substantially different.
Even that comparison needs care. An Agent Builder use case is not automatically low risk because the tool is accessible, and a Copilot Studio solution is not automatically high risk because it is more extensible. The use case, technology and context have to be considered together. The thinking can still travel.
Same questions. Different use cases, technologies and answers. Transferable capability.
I am going to explore this properly in a follow-up series by taking a Microsoft 365 Copilot Agent Builder use case and a Copilot Studio use case through J01 separately, then putting them alongside each other to see what stays the same and what changes. I suspect that comparison will teach me quite a lot too.
Turning the exploration into something other people can use
There is another challenge with all of this. A sketch can be incredibly useful while I am thinking, particularly when I can stand next to it and explain what I meant. That is rather different from producing something another person can pick up without me. The exploration has to become transferable.
That is what I have been trying to do with the PUBLIC version of Make AI Adoption Safe.
The formal J01 PUBLIC Journey Map: the exploration turned into a learning experience that somebody else can navigate at their own pace.
I made a deliberate choice with PUBLIC. I did not want it to be a glossy introduction that explains just enough to make somebody register before they can understand the interesting bits. The Knowledge Layer is public.
The current pack lets somebody take a short route through the overall thinking, work through the complete Journey Guide, use the presentation material to have a conversation with colleagues, or move backwards and forwards through individual stages because one happens to be particularly relevant to a problem they are facing. It supports different depths and routes rather than requiring everybody to follow one linear path.
There is no score waiting at the end. PUBLIC is not a diagnostic of an organisation's maturity, an assurance review, a certification or an implementation plan. It stays within learning and orientation while allowing the reader to decide what, if anything, should happen next.
At PUBLIC level, I would like somebody to understand the shape of the problem, have a shared language for discussing it, make some limited practical use of the questions and, perhaps most importantly, start noticing things they had not been asking before. That is useful in its own right.
REGISTERED begins taking the personal exploration further. Beyond that, I am experimenting with how somebody might deliberately develop their own capability through SELF and what changes when a group builds and practises that capability together through WORKSHOP. Those are not simply different amounts of content; they are experiments in different ways of developing capability.
Then some actual humans got hold of it
Drawing the model was one test. Creating materials somebody else could follow was another. The much more useful test was putting the first full WORKSHOP experience in front of seven people at the South Coast User Group on 22 October.
Some of what happened worked better than I expected. Teams reconstructed each other's reasoning from the records they created, responded when a surprise was introduced, and by the end of the day all seven participants worked individually on an unseen case using the same underlying approach. The day also felt chaotic at times.
There was too much material, too many terms and models, inconsistent language and some printing mistakes. I had not left enough room to help people make sense of some of the struggle I had deliberately designed into the experience. The feedback was direct: 'a bit too paper-heavy and too many steps', 'simplify', and my favourite, 'a bit of teaching would be nice'. Fair.
I am going to write that experiment up properly because I think the things that did not work are at least as useful as the things that did. For now, the easiest way to show what happened may be to put the formal Journey beside what I wrote over it after reality started answering back.
Reality writes back: the formal PUBLIC Journey annotated with lessons from the South Coast workshop pilot.
That picture probably tells the story more honestly than a polished lessons-learned slide could. Some of the mechanism appears promising, while some of what I had built was getting in its way. The sensible response was not to defend the design but to change it.
PUBLIC, REGISTERED, SELF and WORKSHOP have all now been up-versioned with what I learned from trying this with people, and PUBLIC v2.1 is now the current public release. Putting the thinking into the world caused reality to write back, which is exactly what I wanted the Journey itself to help organisations do.
Where that leaves the experiment
So that is where Make AI Adoption Safe is today. PUBLIC v2.1 is now out there, and I am not expecting it to be the last version. I would probably be slightly worried if it was.
The free Journey is only one part of the experiment. I am also exploring what happens when somebody takes the ideas further through SELF and what happens when a group works through them together in a facilitated WORKSHOP. I have now tested that workshop once in the real world, learned a lot from it and started building those lessons back in.
If you want to understand the thinking first, explore PUBLIC. It is free, and I have deliberately made the Knowledge Layer available without registration. If you are interested in going further, I have also created a small Next Experiments form. I am much more interested in the problem you are trying to solve and what you would actually like to explore than in collecting another download number.
If SELF, WORKSHOP, partnering or another part of the experiment makes you think 'I'd like to try that', let me know. The most useful thing will be seeing what happens when these ideas meet other people's reality.
The question at the end of the PUBLIC Journey still feels like the right one to leave hanging:
If somebody asked tomorrow how your organisation knows its AI adoption is safe enough for its context, what evidence could it show?
Perhaps that is somewhere worth digging next.
Explore and participate
Explore Make AI Adoption Safe - The free public facing set of materials
J01 Make AI Adoption Safe — EmPOWER Your World
Next Experiments - Let me know if, and where, you’d like to find out more about building capability to make AI adoption safe
