Many AI pilots start with a visible use case and a model. The harder question comes first: can the company trust the information and rules behind that use case? A fast answer from an old policy is still wrong. In cross-border logistics, stale customs, customer or safety guidance can turn a helpful interface into a new source of risk.
AI enablement is therefore an operating-system problem as much as a model problem. The organisation needs owned knowledge, clear rules, permission boundaries, evidence and a way to stop or correct each automated step.
Audit company knowledge before adding agents
List the sources the proposed workflow will use: policies, customer terms, price logic, product data, compliance rules and operating procedures. For each source, record an owner, last review, next review and what should happen when sources conflict. Remove duplicates and label expired material.
The aim is not to collect every document. More context can make answers worse when irrelevant shorthand, obsolete versions or private notes are included. Give each task only the information needed for the decision. A single structured source may help, but it remains useful only when named people maintain it.
Separate rules by how firmly they must hold
| Tier | Meaning | Best control |
|---|---|---|
| Invariant | A non-negotiable limit, such as an approved safety threshold or a calculation rule | Code, validation or database constraint |
| Policy | A current business choice, such as an approval limit or escalation route | Visible, versioned rule with authorised override |
| Advisory | Judgement about wording, tone or how to present options | Model guidance plus human review where needed |
Do not place all three in one long prompt. A model can interpret a vague request, but it should not be asked to enforce a hard financial limit by persuasion alone. Equally, hard-coding every writing preference removes the flexibility that makes the model useful.
Let the model interpret and the system verify
Consider the question: do we have enough of this item for Thursday's order? A model can identify that this is a stock question with a deadline. The current quantity, reserved quantity and order requirement must come from the live system of record. The answer should show the time of the data and the calculation used.
The same pattern applies to quotes, bookings and compliance. Use the model for language and routing. Use controlled queries and deterministic checks for current facts. If the required data is missing or cannot be joined safely, the workflow should decline and say what is missing.
Put human checkpoints where consequence lives
Retrieval, summarising and drafting can often run with limited risk. A final price, customs declaration, customer commitment, payment or external message needs an authorised checkpoint unless a separately approved policy allows otherwise. Permissions should be narrow: read access is not send access, and draft access is not approval authority.
Every AI step needs an off switch and a fallback. Log the input, data source, rule version, output and human decision in a form the organisation can review. This is not a promise that every model call will be correct. It is a design that makes failure visible and recoverable.
Use a narrow rollout sequence
- Audit and assign ownership to the relevant knowledge.
- Classify invariant, policy and advisory rules.
- Choose one task with a clear input and outcome.
- Set permissions and a human checkpoint.
- Build a test set from known examples, including difficult and missing-data cases.
- Run in draft or shadow mode before any live action.
- Measure correctness, corrections, declines and operational value.
- Add coordination across tools only after the narrow task is stable.
A coordinator can route work between specialist tools and maintain the hand-off trail. It is useful when a request genuinely spans systems. It is not a substitute for clean knowledge or tested controls.
Measure the decisions, not the volume
Count whether answers were supported, whether required approvals happened and whether people could correct the result. A large number of automated replies is not proof of value. For example, a system that attempts every question may be less useful than one that answers fewer questions and clearly declines the rest. Any percentages used in planning should be labelled as targets or sample scenarios, never presented as Summerhill results without evidence.
Begin with the decision that is currently slow, repetitive and checkable. If it cannot be evaluated against known-correct examples, it is not ready for a wider rollout.