Choose a task before choosing a model
The starting question is not which model currently leads a benchmark. Describe the work a person does today: where an input comes from, how they decide, what they verify and where the result is recorded. Measure volume, handling time, common errors and the share of exceptions. Only then can automation be judged against real work rather than a demonstration. Some processes benefit more from a clearer form, better search or a deterministic script.
A useful candidate has a repeated shape, available data and a clear test of correctness. A decision with high impact on a person, ambiguous input or rare exceptions requires a more cautious design. Keep the first pilot narrow: one understandable task and a representative set of real cases, including those currently passed to an expert. Define in advance when the system must stop and ask a human.
Split the process into dependable steps
A workflow may receive a request, validate data, retrieve context, draft a decision, ask for approval and record an outcome. Not every step needs generative AI. Format checks and fixed business rules are often safer as deterministic code. A model may help with varied text, classification or drafting, but its output still needs checks proportionate to risk. Decomposing the flow makes failures explainable and allows one component to be changed without rewriting everything.
For example, an incoming commercial request could be checked for unsafe attachments, assigned a topic, matched with a relevant product and turned into a draft response. A person may still approve anything sent to a customer. An unfamiliar request or missing source should stop the flow and transfer the case to a worker. Benefit is measured as time to a good response and fewer corrections, not the count of messages sent automatically.
Data, permissions and sharing boundaries
Before information reaches a model, define its origin, sensitivity, owner and retention rules. Automation must not give a user broader access than the original system allowed. For internal documents, preserve permissions after indexing and avoid joining fragments from incompatible contexts in an answer. Logs should support repair without becoming an uncontrolled copy of personal or contractual information.
The choice of external API, private deployment or ordinary rule based technology depends on actual constraints. For a provider, check data handling and retention terms for the specific service and contract. For a self operated model, account for infrastructure, updates and security. The label private proves little when access, backups and operating visibility are not controlled.
Human approval must be a real check
A person should approve work where they can recognise an error and have authority to correct it. The interface should show supporting information, uncertainty and the exact change proposed. An approve button without context creates the appearance of safety rather than a useful control. Sampling may suffice for lower risk cases; financial, security or reputation sensitive actions need stricter boundaries. Approval thresholds should follow pilot evidence, not a promise of autonomy.
Rejection and correction are also part of the design. Record why a reviewer changed a proposal so recurring weaknesses can be found. When information is insufficient, the system should be able to say it does not know and request what is missing. Final accountability needs a named owner. Automation that cannot be interrupted safely or handed back to manual work is not ready for production.
Evaluate on representative cases
A few pleasing examples do not establish quality. Assemble cases from normal work, exceptions, conflicting inputs and known mistakes. Define the correct result and unacceptable errors for each. Measure accuracy, completeness, human time after automation and the share referred for review. In a text task, factual correctness and a traceable source may matter more than similarity to one reference sentence.
Compare pilot results with the original process, including the cost of checking and repairing outputs. Keep test cases separate from examples used to tune the prompt. Run the same regression check when a model, source or instruction changes. NIST provides an AI risk management framework and a profile for generative systems; a real product must turn those principles into measurable rules.
Integrations and instruction security
A model output must not automatically gain the right to invoke arbitrary internal tools. Every action needs limited authority, validated input and a record of who triggered it. Text from a document, email or web page is material to analyse, not an overriding instruction to the system. This boundary matters when processing third party content and chaining actions. OWASP describes risks in generative AI applications; specific controls should follow the harm possible in the chosen workflow.
Integrations also have ordinary operating failures: timeout, duplicate call, format change and partially recorded result. Design for idempotency, explicit states and manual repair. An automated message, purchase or data change needs a boundary it cannot cross without further approval. An audit trail records input, instruction version and final action within the organisation's data protection rules.
Operation, cost and change
After launch, watch quality, rejection count, exception share, handling time and cost per resolved case. Cost per model request alone is misleading when low quality creates extra human work. Limit spend with a ceiling, input length controls, appropriate model choice and a way to stop the flow. When a provider changes the model or terms, retest critical scenarios. Recovery planning includes a return to manual processing.
Someone must own automation throughout its lifetime: approve sources, change rules, address incidents and decide whether it still helps. New document types and exceptions can gradually reduce quality even if the code stays the same. An operating view should show trends rather than only a green API status. A useful pilot shows benefit, checking costs, limits and the next decision.
Start without a large commitment
For an initial discussion, describe one process, volume, inputs, outputs, system owner and cost of an error. Add a few anonymised representative examples and the rule for when a human must decide. A model provider need not be chosen beforehand. An initial stage can deliver a workflow map, a choice of steps to automate, test cases and a cost estimate. Integration into normal work should follow the evidence.
If a rule change or better search removes the same problem with less risk, that is a good result. The goal is not to force AI into every task. This page does not present hypothetical cases as EXCOIN client projects or promise a particular saving. The decision to continue should rest on the client's own data and an open list of what has not yet been verified.
Handover material should be understandable to a team that did not build the workflow. It should name system boundaries, source owners, tool configuration, outage procedures and examples of bad output. In particular, explain how a decline in quality will be noticed, such as more manual corrections for one input type. If measurement would require collecting more sensitive information than the task needs, redesign the measure. Operating controls should remain proportionate to the work automation saves.