Before the Technology Becomes the Answer

It rarely sounds like a reckless request.

It may come from the chief executive, the board or a trusted provider. Employees may already be experimenting. However it arrives, the expectation is familiar:

“We need AI.”

The problem is usually less clear.

The person who inherits it is expected to create movement from very little clarity. Sometimes experimentation has already begun, so delay carries consequences as well as caution.

This book is for that person.

You may lead a business function, a technology team or an entire organisation. In a smaller company, you may hold several of those responsibilities at once. You have enough authority to organise the next decision, but you cannot create certainty that the evidence does not support.

The purpose of this book is to help you sequence the work. It begins with the demand, examines the problem beneath it, and follows the resulting decisions through experiment, design, production and eventual retirement. AI is one possible outcome of that journey. A repaired process, a better source of information or a decision to wait may be more valuable.

The first decision is smaller than an AI strategy

Maya’s board did not need a complete AI strategy by Friday. It needed an honest response to a demand that had already created pressure and exposure.

Her one-page note could not tell the company where every use of AI belonged. It could establish what had happened, who needed to act and what should be contained while the organisation learned more.

For a new consequential use outside existing permission, the first useful decision is often:

Does this demand deserve diagnosis, and what must be bounded while that diagnosis occurs?

For those consequential demands, there are three first decisions: decline; contain and clarify; or authorise a bounded diagnosis. Routine use within existing approval does not enter this gate. Wider lifecycle decisions follow when an experiment or production use is proposed.

A request may be declined when it has no credible outcome, owner or organisational reason to continue. It may return to its sponsor with better questions.

The answer may be yes, with prerequisites. The underlying work may be real while the data, process or ownership is unfit for an AI intervention.

An experiment may follow diagnosis. It should answer a specific question under conditions that protect people and information, with agreed limits and a clear decision at the end. The full experiment contract comes later in the book.

Later, the organisation may decide to enable a feature, configure an existing product, buy a service or build a capability. Each route still requires a clear purpose and evidence proportionate to what the system may influence or do.

Production brings a different set of decisions. The organisation has to determine whether the capability should continue, change, lose authority or be retired. Approval is never the last decision.

FIG-I.4

Follow the decisions through the lifecycle

1. The Demand Arrives

Intake

2. The Work Beneath the Request

Diagnosis

3. The Demonstration

Understand the technology

4. Choosing the Route

Choose the route

5. The Bounded Experiment

Experiment

6. What Could Go Wrong

Risk and protection

7. Going Live

Adoption

8. Watching It Work

Monitoring

9. When the Assumptions Break

Recovery and learning

10. The Whole Cost

Whole cost

11. Earning Authority Again

Renew or retire

12. The Answer for Tom

Strategy

Most AI use does not need the full method

At this company, most everyday use covered by the existing approval sits in the first row below. That is the working boundary of this example, not a claim about how AI is used in every organisation. A new tool, purpose, information category or permission requires the boundary to be checked again.

Consider a finance analyst summarising her own internal meeting notes with an approved office feature. These particular notes contain no personal or customer information. The feature is approved for this information, she checks the summary, and it stays inside the company. Daniel records the use in the provisional register. She does not need a Demand Note or an independent challenger for each summary.

The service-credit assistant is different: its sources disagree and its output could shape customer answers. It needs a bounded experiment. The later claims system is different again because its decisions would affect customer money. The evidence and authority must match that consequence.

FIG-I.1

Match the process to the proposed use

Use and decision	Requirements and stopping conditions
Routine use | proceed within permission	Approved summarising feature; analyst’s own non-personal internal notes; checked output. Record the use, not every summary. Stop if information or audience exceeds approval.
Bounded experiment | obtain a new decision	Service-credit retrieval. Diagnose source conflicts; agree limits, challenge and an end decision. No customer contact or record changes before approval.
Consequential system | withhold live authority until justified	Small claims decisions affect customer money. Test material assumptions; establish challenge and correction; name a pause owner. The board decides the proposed authority.

Proceed under existing authority when the actual use remains inside its approved purpose, information, audience and checking requirements.

Obtain a new decision when the purpose, information or authority changes, or the existing permission is unclear.

Stop the affected use when its boundary is crossed or a required protection is absent. For the analyst’s example, that includes personal or customer information entering this narrowly approved use, or output leaving unchecked. It is not a universal ban on every authorised use of such information.

The rest of the book concentrates on the middle and bottom rows. Routine permission should be easy to use; consequential decisions need the fuller method.

Authority changes the question

AI conversations often begin with capability. Can the model summarise this document? Can it answer a customer? Can it rank these cases? Can an agent complete the task without help?

Capability does not settle permission.

This book uses five authority modes: Inform, Assist, Recommend, Determine and Act. The figure below shows the practical distinction.

The word determine distinguishes an automated output that takes effect as a decision from a recommendation that a person considers. Terminology varies across organisations and jurisdictions; accountability does not. Named people still have to approve the purpose, establish the limits and provide a route for correction or challenge.

These modes are not a universal risk ranking. A determination affecting employment or access to an essential service may carry greater consequence than a tightly bounded, reversible action. Assess the combination of data access, audience, reach, autonomy, consequence and reversibility. One system may occupy several modes.

Additional authority requires evidence that matches the decision. The evidence falls into four broad families: the reality of the problem and comparison with simpler options; technical and operational performance in the intended workflow; human consequences, review and correction; and organisational fitness, including privacy, security, permissibility, cost, support and recovery. A high accuracy result in a test set cannot establish all four.

FIG-I.2

Five authority modes

Inform

Can people see the source and its limits?

Assist

Can a person verify the work in the time available?

Recommend

How much weight will people give it?

Determine

Who is accountable, and how can an error be challenged?

Act

What can it reach, and can it be stopped or reversed?

Assess separately

Consequence • reach • data • reversibility • people affected. These modes are not a ladder of risk.

A model sits inside operating arrangements

The service assistant proposed in Maya’s meeting would not operate alone.

It would depend on source material that somebody had to approve and maintain. Employees would need to know when to trust an answer and when to check it. Customers would need a way to correct an error. Managers would need to understand whether the assistant reduced repeat contact or simply made first replies faster. Someone would have to respond when a provider changed the service.

A capable model can depend on poor operating arrangements.

The operating arrangements around an AI capability include the work, people, information, permissions, controls, suppliers and support that allow it to function. They also include the less visible parts: who can pause it, who pays for exceptions, which records are preserved and what happens when the original owner leaves.

These responsibilities exist in a small organisation too. One person may hold several roles, but the roles still need to be named. Where consequences are material, the person seeking approval should not be the only person challenging the evidence. The challenger should sit outside the expected benefit or delivery target and have enough knowledge to test the claim. Legal, safety or rights-sensitive uses may still require specialist advice.

FIG-I.3

Look around the model

Model

One component within the work.

Work and people

Purpose, workload, skills and affected people.

Information and permissions

Current sources, access and allowed actions.

Controls and suppliers

Checks, provider changes and dependencies.

Support and pause

Correction, recovery, an available owner and a usable stop procedure.

You can begin without buying another platform. Use documents, spreadsheets and shared systems your organisation already approves, with appropriate access, retention, confidentiality and backup arrangements. The discipline comes from naming decisions, owners, evidence and review dates.

What the journey will test

The chapters test the full operating cost, human review under real workload and whether people can correct an error. Chapter 5 supplies the experiment contract. Chapters 8 and 9 examine performance, incidents and recovery. Chapter 10 follows the arithmetic from baseline through experiment to live use. Chapter 11 shows how authority is renewed, restricted or retired; Chapter 12 returns to the strategy Tom requested.

How to use this book

You can read the chapters in sequence. They follow the path from an initial demand to the decision to continue, restrict or retire a capability.

If you already face a live issue, enter where the work is:

• A new consequential request has arrived: use Chapter 1 and the first-pass Demand Note. For routine use within existing permission, use the proportionality check in this Introduction.

• Employees or providers already use AI: start with Chapter 1 to record activity and apply necessary boundaries; Chapter 6 develops the risk screen.

• A pilot appears successful: Chapters 5 and 7 examine whether its evidence supports production authority.

• A capability is operating: Chapters 8 to 11 address outcomes, changed assumptions, recovery, cost and renewed authority.

A free companion website launches with this Opening Edition on 2 October 2026. It carries dated updates and the interactive fill-in tools, and will later add jurisdiction-specific guidance. The templates included here work without it. No website tool is required to use this edition.

If your demand requires a new decision, bring it with you. Preserve the words in which it was expressed. If you are uncertain whether existing approval covers the use, ask its owner to clarify that boundary first.

Write down who said it, what created the urgency and what they expect to change.

Chapter 1 begins with that record.