The talk
The same system can draft a reply, send it, or commit the organisation to a refund. The technology does not change between those three. The permission changes, and so does the consequence. Most organisations have argued about the technology and never decided the permission.
This talk gives a room a shared way to make that decision: what a system can do, what it may do here, and who answers when it is wrong. It runs from the plain mechanics of how we arrived at agents, through what actually held up when these systems went into production in a regulated bank, to the three decisions a sponsor cannot delegate.
The working model
One
Capability
What can it do? The empirical question, answered against your own data rather than against a demo. This is the part that improves on its own, and the only one of the three a vendor can settle for you.
Two
Authority
What may it do here? Capability is general; authority is local. The same model that may draft in one process must not send in another. Somebody chooses this. It is not a property of the technology.
Three
Accountability
Who answers for the outcome? When a wrong answer has already left the building, the name on it is a human one. This is the question that never moves to the machine.
The full framework, with its failure modes →
The delegation ladder
Read→Draft→Send→Commit
Four rungs of autonomy, not a ranking of sophistication. Most failures are a system placed one rung above the authority it was actually assessed for.
The delegation ladder in full →
What the audience takes away
-
A question they can ask of any AI proposal that reaches their desk.
Three questions, in fact, and the discipline of noticing which one a confident answer has quietly skipped. A powerful model settles the first. It does not settle the other two.
-
Why quality, not capability, is the barrier.
A proof of concept shows the technology works. Production shows that quality is far harder than anyone expects, especially for retrieval, where the state of your source data quietly determines the quality of every answer.
-
The three decisions a sponsor cannot delegate.
Choose who to serve first and prove the value where the risk is lowest. Fund the foundations early, because everything built on them waits. Name what stays human before the system ships. None of the three is a technical decision.
How it runs in the room
It opens with a live vote. The room commits to a position on what it would let a system do on its own behalf, before anyone has heard an argument. It closes on the same vote, and watching the room's own answer move is the point.
As delivered: two hours, of which thirty-five minutes was unscripted questions from the floor. It also runs at 45, 60 and 90 minutes. The model stays; the depth and the number of worked examples change.
What the room wanted next
Attendees wrote afterwards asking what a follow-up session should cover. The requests clustered, and the clusters are worth knowing if you are programming this for your own audience. They are the questions a mixed business and technical room arrives with, and the ones an hour on stage does not finish.
- How you actually start. Day zero to here. Which foundations to fund first, and what waits on them.
- Governance end to end. Not the policy, the mechanics: how evaluation, assurance and sign-off work as a repeatable path, and how to make that reusable across teams instead of rebuilt per project.
- The economics. What it costs, how to put a defensible number on the value, and whether current vendor pricing is something you can plan against.
- Knowing when to trust an answer. Hallucination and confabulation, and what evidence would let you rely on an output in a real process.
- The platform underneath. The tooling and architecture choices, for the part of the room that has to build it.
Those five clusters are close to the four module programme I run with architecture and leadership teams. If your audience arrives with the same questions, that is usually the right next session rather than a second talk. See the programme →
My own account, drawn from written follow-ups after the lecture. Summarised by theme and not attributed, because the people who wrote have not been asked whether they may be quoted.
Drawn from two years of taking generative AI use cases into production in a regulated, financial-grade European environment: retrieval-augmented generation, document intelligence, summarisation, assistants, and the responsible-AI controls around them.
