AI & automation
AI Automation Readiness: Where to Begin and What to Control
The best first AI automation is rarely the most impressive demo. It is a bounded workflow where the inputs, allowed actions, review points, failure modes, and operating owner can be made explicit. Readiness is less about whether a model can produce an answer and more about whether the business can govern the complete system around that answer.
Choose a workflow, not a technology label
Start with a recurring decision, handoff, search task, document flow, or service interaction that causes measurable friction. Describe the current inputs, people, systems, exceptions, and consequences of an error. This produces a stronger starting point than asking where to add an agent across the business.
Good early candidates have enough volume to matter, enough structure to evaluate, and a failure mode that can be contained. A workflow with unclear ownership, rapidly changing policy, or irreversible high-impact actions may still benefit from AI, but it needs a more deliberate control model and is usually a poor first deployment.
- The task occurs often enough to justify operational ownership.
- Inputs and intended outputs can be described and sampled.
- A knowledgeable reviewer can judge useful versus unsafe results.
- Failures can be detected, contained, and corrected.
Define the level of authority
An AI system can retrieve information, draft content, classify work, recommend an action, prepare a transaction, or execute one. Those levels are not interchangeable. The more authority the system receives, the stronger the identity, permission, approval, audit, and rollback requirements become.
A useful design names what the system may read, what it may produce, what it may change, and what always requires a person. Human review should not be a vague promise. It needs an owner, a review interface, enough context to make a decision, and a rule for what happens when no reviewer is available.
A drafting assistant with explicit approval is a different product from an agent permitted to change a customer or financial record.
Inspect data before selecting the model path
The workflow may depend on policies, tickets, contracts, product records, messages, or external systems. Assess whether that information is current, complete, consistently structured, permissioned, and legally appropriate for the intended use. A model cannot repair an undefined source of truth on its own.
Decide what data is sent to each provider, how long it is retained, whether it may be used for provider training, and how access is revoked. For retrieval systems, define document ownership, indexing cadence, citation behavior, deletion, and how conflicting sources are handled. For structured actions, validate values against authoritative records before execution.
- Authoritative sources and their owners
- Data classification, permissions, and retention
- Quality, freshness, duplication, and missing fields
- Provider boundaries and prohibited data
- Deletion, correction, and access-revocation behavior
Build an evaluation that reflects real work
A small set of polished examples is not enough. Create representative test cases from routine work, difficult exceptions, ambiguous inputs, prohibited requests, and outdated information. Define what a reviewer considers correct, useful, incomplete, or unsafe before comparing approaches.
Evaluation should cover more than the text of an answer. Measure whether retrieval used the right source, whether tools were called with valid parameters, whether permissions were respected, whether the system stopped when required, and whether a person could understand what happened. Re-run the suite when models, prompts, data, or tools change.
Design for failure and change
Models, APIs, documents, and operating rules change. The production design should expect timeouts, unavailable providers, malformed output, prompt injection attempts, stale knowledge, tool errors, and an answer that is plausible but wrong. Safe fallback is a product behavior, not just an infrastructure concern.
Define when the system retries, asks for clarification, routes to a human, returns a bounded unavailable state, or takes no action. Keep an audit trail appropriate to the risk without storing more sensitive content than necessary. Monitoring should make drift, rising error rates, cost changes, and unusual tool activity visible to an accountable owner.
- Timeout and provider-unavailable behavior
- Permission and tool-call validation
- Human escalation and no-action states
- Versioned prompts, policies, models, and evaluation sets
- Operational monitoring, cost limits, and incident ownership
Pilot toward an operating decision
A pilot should answer a defined question: whether the workflow is useful, governable, and worth operating. Limit the user group, data boundary, and authority. Observe how people review output, where exceptions appear, and whether the proposed control points fit real work.
At the end, decide to expand, revise, narrow, or stop. Document what changed from the original assumptions and what production ownership requires. A successful prototype is evidence about feasibility; it is not yet evidence that the business is ready to rely on the system at scale.