Good AI advice includes knowing when not to automate.

A useful AI conversation should leave room for a decision not to build.

That does not mean dismissing the technology. It means choosing the intervention that fits the problem rather than choosing a problem to justify the intervention.

Before commissioning a system, ask what is actually making the task difficult.

Is the process understood?

A team may describe a task as repetitive while relying on undocumented judgement at several points. People know which requests are unusual, which source to trust and when to ask a colleague.

Write those decisions down before assuming the whole process is a straightforward automation opportunity. The mapping itself may reveal a useful improvement.

An unclear process can still be worth investigating. It just needs a discovery question before it needs a deployment promise.

Would a simpler change help?

A better form can improve the inputs. A shared template can make expectations clearer. An ordinary rule can route a request when the conditions are explicit.

Compare these alternatives with AI assistance. What additional capability is needed? What additional review and maintenance would it introduce?

The answer may favour AI, a simpler solution or a combination. The comparison makes the decision more deliberate.

Is the information usable?

A system built around fragmented, outdated or unowned material inherits questions about that material. Establish who owns the source, who can access it and what should happen when information conflicts.

Do not treat the ability to retrieve or summarise a document as proof that the document is appropriate for the decision.

Sometimes the useful first project is organising the information and its ownership. That work is less theatrical than a new interface, but it may be the necessary foundation.

What happens when it is wrong?

The answer determines how much review, escalation and fallback the design needs. A draft internal note and a consequential external decision do not carry the same requirements.

Name the person responsible for the result and the route for pausing the process. When the boundary is unclear, narrow the test rather than hiding the uncertainty in a broad promise.

Can the benefit be observed?

Define the starting point and the standard of useful work. Include the time spent preparing, reviewing, correcting and maintaining the process.

A small improvement may still justify a simple change. A dramatic-looking demonstration may not justify a complicated system. The decision should use evidence appropriate to the scope.

A good next step can be small

Clarify one process. Collect a set of safe examples. Agree a quality rubric. Resolve an access question. Run a bounded experiment.

Each can be a worthwhile outcome of advice.

The quality of the recommendation is not measured by how much technology it adds. It is measured by whether it helps the organisation make a better decision about the work.

Arrange a Leadership Briefing to identify relevant opportunities, useful boundaries and a considered next move.