Connecting AI to business systems is a workflow decision before it is a connector decision. A sales assistant that summarizes approved CRM notes has a different scope from one that changes an ERP order. Write down the user, the business question, the source of truth and the permitted action. A first release can deliver useful assistance while leaving final decisions with the existing operator.
Specify one complete journey
Consider a hypothetical service desk: an employee asks for an order update, the system finds the relevant customer and order, and it drafts a response with source references. The employee checks the draft before sending it. Keep inventory changes, refunds and customer messages outside this initial scope. The output is a reviewable draft, not an unrestricted assistant across the company.
- 01Authenticated user
- 02Allowed records
- 03Source-backed draft
- 04Human approval
- 05Recorded outcome
Create a source and ownership map
| System | Questions to resolve | Evidence to request |
|---|---|---|
| CRM | Which customer identifier links records? Which notes are restricted? | Sample records, field definitions and a permission matrix |
| ERP | Which system owns order status? How current must the answer be? | Read access, sample status transitions and availability limits |
| Internal knowledge | Which document is approved? Who retires old versions? | Named content owner, version dates and deletion rules |
Name one owner for each source and one owner for the combined workflow. Resolve conflicting identifiers, duplicate customers and missing fields before a demonstration becomes a delivery commitment. Request representative sample data through an approved channel. An API existing does not establish that your subscription, administrator or implementation can expose the required records.
Make permissions part of the answer
Define what each user may read and do. Carry those restrictions into retrieval and check authorization before an external action. A useful acceptance test asks the same question as two users with different access: each must receive only permitted information. Also test revoked access and a user moving between Organizations. In an organization-scoped product, resolve the Active Organization from the authenticated session.
Treat retrieved documents and messages as source material, not permission to change system behavior. Include documents that try to redirect the assistant in the evaluation. Keep credentials outside model-visible content. Separate read access from write access, restrict available actions and validate proposed fields before execution. A prompt asking the model to behave is not the whole control design.
Define freshness, failures and safe fallback
For every answer, decide whether the source must be current or whether an explicitly dated snapshot is acceptable. If an order status cannot be refreshed, show that uncertainty instead of presenting an old value as current. Agree how updated, deleted and restricted documents leave any search index. Decide how long operational records are retained and who can inspect them.
- Unavailable source: show which information is missing and return the case to the normal manual process.
- Unclear customer match: ask the authorized operator to select the correct record before continuing.
- Unsupported answer: say that the available sources do not establish an answer; do not invent a policy.
- Unconfirmed write: check the destination status before retrying, so uncertainty does not produce duplicate actions.
For later write capabilities, show the exact change and destination at approval time. Record the approving user and outcome. Agree which changes can be reversed, who handles recovery and what happens when approval expires. Financial or irreversible actions need a separately agreed scope; a successful read-only pilot does not authorize them.
Evaluate the real workflow and plan handover
Build a test set with ordinary cases, permission differences, stale records, missing sources and ambiguous requests. Score source support, correct record selection, access isolation and reviewer effort separately. Agree thresholds with the business owner based on the consequences of errors. Measure the whole path from request to reviewed result, including latency, retries and human work.
Before rollout, request the source map, access configuration, evaluation results, monitoring instructions and a pause procedure. Identify the owner who renews credentials, handles source changes and reviews failures. Start with a limited user group and a manual fallback. Expand only after the observed results meet the agreed acceptance criteria.
Use AI integration to scope the connections and permission boundaries. Use AI automation when the wider process also needs redesign. The cost guide helps budget source preparation, ongoing maintenance and reviewer time alongside model usage.