Governance & accountability
Video · 5 min read
The short answer
Watch: Are there aspects of strategic leadership that should never be delegated to AI?
Watch the explanation, then explore the practical implications below.
Break a leadership decision into its different parts
A strategic decision includes several activities: gathering information, interpreting it, developing options, choosing a direction and accepting responsibility for the consequences. Delegating one activity does not require delegating them all.
This distinction helps a business use AI ambitiously without leaving authority unclear. The relevant question is what the system is being asked to do in a particular workflow, what could go wrong and how the business will recognise and contain that failure.
Capability does not establish permission
A system that produces a useful analysis has not automatically earned permission to act on it. The organisation needs to define the purpose, acceptable boundaries and people authorised to make commitments. Those choices should be visible in the workflow, rather than left to an informal expectation that someone will check.
For consequential actions, specify what approval is required before execution. Ensure the reviewer can inspect the evidence, challenge the recommendation and prevent the action. Keep access permissions aligned with the authorised task, so a drafting tool cannot make an external commitment simply because a connection is available.
A practical example: pricing a customer proposal
AI could help organise historical project results, compare scenarios and flag assumptions in a proposed price. Controlled calculations should use agreed inputs and rules, with sources available for inspection. The model’s narrative should not substitute for checking the underlying figures.
The final decision may also depend on relationship commitments, delivery capacity and commercial priorities that are not fully captured in the records. An authorised person should resolve those trade-offs under the business’s approval process. Record why an exception was accepted and the scope of that exception.
Test boundaries using work you can judge
Begin with representative historical cases or controlled trials. Compare the system’s recommendations with experienced review and known outcomes where available. Include incomplete records, conflicting instructions and unusual customer requirements.
Agreement with a past decision is not sufficient on its own: the past decision may also have been wrong. Inspect the reasoning and source evidence. Where people disagree with the system, classify the cause. Was the input missing, the instruction unclear, the analysis flawed or the judgement genuinely dependent on context?
Make accountability operational
For each delegated activity, name the business owner, the reviewer where required and the person responsible for maintenance. Define how to stop the workflow, investigate an error and communicate a correction. Keep a record proportionate to the consequences of the action.
Review permissions and decision boundaries when the workflow, data or system changes. A successful pilot in a narrow setting should not silently authorise broader use. Greater autonomy should follow evidence about the specific task and the organisation’s ability to supervise it.
How CSM would approach the work
We would agree the scope of assistance and the approval boundaries with the business owner before building. That includes what the system can prepare, what it can execute, what it must escalate and what evidence a reviewer needs.
We would test these boundaries with the people who understand the work, then agree acceptance criteria and support responsibilities. The organisation retains ownership of its priorities and commitments. Technical implementation should make that ownership easier to exercise, not obscure it behind a convincing answer.
Questions for your leadership team
What exactly are we delegating?
Separate evidence gathering, recommendation, approval and execution for one real decision.
Who has authority to make the commitment?
Name the responsible role and ensure the workflow enforces the agreed approval route.
What would make this recommendation unsafe to use?
Consider missing evidence, conflicting sources and consequences that are difficult to reverse.
Can the reviewer genuinely stop or change the action?
Check time, expertise, access to evidence and practical control.
What would justify changing the boundary?
Agree the test evidence and review needed before expanding the system’s authority.
Full video transcript
The full video transcript is included below for reference.
I’m careful about saying something can never be done, because the capabilities change and those statements can age quite quickly. There are also different parts to what we call a leadership decision. Gathering the information, developing options, challenging an assumption, deciding what to do and taking responsibility for the consequences aren’t all the same thing.
AI might be very useful in some of those parts and unreliable in others. You only find that out by testing it on work you understand well enough to judge. Pricing is a good example.
It could help you analyse past work, compare scenarios and identify where you’re making less money than you thought. That doesn’t automatically mean it understands what a particular customer relationship is worth or what promise you’re prepared to make. And even if its analysis is better than yours on part of the problem, someone still has to own the decision.
You can’t explain a damaging commitment to a customer by saying the system recommended it. So I think there’s a difference between being open to AI contributing more and being vague about responsibility. You can be quite ambitious about the first while being very clear about the second.
The lab and the people doing the work can help you discover where those boundaries should sit. Compare recommendations with actual outcomes. Look at where experienced people disagree with the system and why.
Don’t just test whether the answer sounds convincing. And don’t assume somebody else has settled this for your business. A vendor can show you what a tool does.
They can help you implement it. But the decisions about what matters, what you’re prepared to accept and who is accountable still need to be made inside the organisation. That’s a continuing job.
The boundary may move as the technology improves, but the need to decide where it belongs doesn’t disappear.
Put these questions to work in your business
Bring a real decision or workflow to a conversation with CSM. We can explore the evidence, responsibilities and practical steps needed to make AI useful for your team.