AI strategy & automation
Start with the workflow, not the model
A practical way to scope automation: identify the handoffs, separate rules from judgment, and agree how exceptions will be handled.
An automation proposal should explain which part of the work will change, who remains responsible, and how the business will judge the result. A model demonstration cannot answer those questions on its own. Before selecting a tool, describe the process as it runs today, including the inconvenient exceptions.
Map one complete piece of work
Choose a bounded process, such as receiving a supplier invoice and preparing it for approval. Follow it from arrival to a recorded outcome. Note where someone copies information, checks a system, waits for a reply, or makes a judgment. Include the person who handles the work, not just the person requesting the automation.
- Inputs: what arrives, in which formats, and what makes it incomplete?
- Handoffs: which teams and systems exchange information?
- Decisions: which outcomes follow a written rule, and which require interpretation?
- Exceptions: who handles a disagreement, missing field, or failed integration?
- Baseline: how long does a case take, including waiting and correction?
Choose the simplest suitable intervention
A workflow can contain conventional software, AI assistance, and human review. Treat each step separately. Google’s Rules of Machine Learning recommends establishing metrics and considering simpler approaches before introducing machine learning. The table below is our suggested starting framework, rather than a universal rule.
Scroll horizontally to view all columns →
| Task | Starting approach | Reason |
|---|---|---|
| Check whether a required field is present | Explicit validation rule | The condition can be stated and tested directly. |
| Extract a reference from varied documents | Evaluate extraction with review | Layout and wording vary; uncertain results need a route to correction. |
| Approve a payment or resolve a dispute | Accountable human decision | The decision includes authority, context, and consequences beyond extraction. |
| Transfer an approved record | System integration | Reliable delivery and reconciliation are the main requirements. |
Define the pilot before running it
Build the evaluation around a representative sample of real work, using data the team is permitted to process. Include difficult cases and known exceptions. Record the current handling time and error types, then compare the assisted process with that baseline. Agree acceptance thresholds with the process owner before reviewing the results.
- Track completed cases and correction time, rather than counting generated outputs alone.
- Separate harmless formatting mistakes from errors that could change a business decision.
- Include software fees, integration support, and ongoing review in the cost comparison.
- Specify a fallback: what happens if the tool is unavailable or the output cannot be trusted?
Leave with an accountable decision
The pilot should lead to a decision to proceed, revise the scope, or stop. Assign an owner for the live process, the review queue, and changes to the underlying rules. NIST’s AI RMF Playbook provides a broader reference for organizing these risk-management responsibilities. A useful first deliverable is a short process brief with the proposed intervention, its evaluation plan, and a named operational owner.
References & further reading
External guidance informing this perspective. The examples and decision frameworks above are Kōt Dynamics’ editorial guidance.
- NIST · AI Risk Management Framework Playbook
A reference for identifying context, measuring risk, and assigning responsibility across an AI system's lifecycle.
- Google · Rules of Machine Learning
Rules 1 and 2 discuss simpler starting points and establishing metrics before introducing machine learning.
Apply this to your business.
Discuss the requirements, trade-offs, and next steps with our team.
Start a conversation