Choose one task, not an entire department
Begin with work that has a known input, outcome and person accountable for correctness. It might be a draft answer to an internal question, document sorting or preparation of evidence for an approver. Map how long the task currently takes, how often it occurs and what an error costs. A useful pilot can be compared with today's process. A broad ambition to introduce AI across a company provides no criterion for deciding whether anyone's work actually improved.
Distinguish a draft, a recommendation and an executed action. Drafting a message has a different risk from changing a CRM record or approving a payment. In an early pilot, leave decisive writes to a person and measure whether the suggestions help. The NIST AI RMF describes risk management as continuing functions: govern, map, measure and manage. For a small pilot this means naming an owner, mapping impact, measuring errors and repeatedly deciding whether to adjust the process.
Data and permissions define the boundary
Identify which documents and records the assistant needs. Each source has an owner, classification, validity period and access rules. An employee's access to one file does not mean a model should receive the entire company archive. In search or RAG, permissions must be applied before results are passed to the model. Keep a link and version for the source behind an answer so a later reviewer can check what information the system used at the time.
Handle user text and retrieved web pages as untrusted input. OWASP explains prompt injection as an attempt to change model behaviour through instructions embedded in content. A document is data, not an authority that can change workflow permissions. Tools available to the model should have the narrowest useful scope. Separate reading from writing, require further checks for sensitive actions and never place secret keys in a model prompt. Model instructions alone are not an access control system.
Approval is a workflow state
Decide which actions run automatically and which wait for a person. Base the boundary on impact: who receives the result, whether it changes lasting data and whether it can be undone easily. Microsoft's agent design guidance distinguishes mandatory approval from feedback that sends a draft back for revision. Persist the waiting task so work can resume hours later from the same evidence rather than replaying everything and risking a second action.
An approver needs the original input, proposed output, sources and an indication of uncertainty. One click should not approve hundreds of hidden changes. A rejection should record an appropriately brief reason and return the case to a safe state. Check the approver's permission at action time, not only when the request was created. When the person is unavailable, hold or escalate the task under an explicit rule; it must not silently become authorised.
The audit trail should explain one operation
For each run keep the case identifier, instruction version, model, sources, proposed steps, approval and actual changes. The record must explain an incident without copying full personal data or secret documents unnecessarily. Retention follows the company's legal and operational context. If the workflow touches several systems, carry a correlation identifier across their logs. Otherwise it becomes hard to determine where a suggestion turned into an action and who was responsible for that transition.
A model output may be acceptable while the connector that acts on it fails. Log the AI decision, human confirmation and tool result separately. After a timeout you may not know whether the target system performed a write; retry requires an idempotent identifier or safe state check. An audit is more than a list of generated text. It should connect a proposal to the consequence in a real system. Such a record also helps answer a complaint from someone affected by the decision.
Measure quality on real exceptions
Before the pilot, collect cases from ordinary work: easy, incomplete, stale, sensitive and deliberately confusing inputs. Define the expected process for each, not merely one ideal sentence. Measure draft accuracy, human corrections, time to completion and error types. In a search step, separate failure to retrieve the right source from failure to formulate an answer. If average speed improves while critical exceptions become worse, the pilot has not succeeded.
Repeat evaluation when changing model, instructions, sources or permissions. People often use a tool in ways that were not anticipated; monitor new scenarios and feedback rather than technical availability alone. Record processing cost, approver time and maintenance effort. Saving seconds in one step may not outweigh review work. An operational metric should cover the whole process from input to final decision, including cases the model cannot handle and the time needed to resolve them manually.
Fallback and user adoption
When a model or source is unavailable, work needs a clear alternative: a manual route, document search without generation or a paused task. Tell the user what happened and whether any action was taken; a false impression of completion is worse than an admitted outage. Turning off the AI portion should not block access to original data. Decide in advance who can stop the workflow and how pending cases will be investigated. On recovery, prevent those pending actions from being executed twice.
People need to know when the tool helps and when responsibility remains theirs. Short training with concrete examples is more useful than a generic list of model capabilities. Gather reproducible errors and adjust inputs or process based on them. This page does not claim measured time savings for EXCOIN customers or a guarantee of error free output. Useful first deliverables are a task map, permitted sources and actions, evaluation cases and a human approval plan. They show whether AI, simpler rules or a process change best fits the need.
Close the pilot with an explicit decision about what continues and what stops. Assign who maintains sources, who reviews faulty suggestions and how a model change triggers fresh testing. If nobody owns those duties, a technically successful demonstration should not be treated as an internal product ready for daily work.