# Designing a business AI copilot: architecture, data and guardrails

Design a copilot around real work, with business context, sources, permitted actions, interface choices, human approval and quality measurement.

Author: Binov

Published: 2026-10-02

Canonical: https://www.binov.com/en/guides/design-business-ai-copilot

A business AI copilot assists a person with a specific task in their working context. It can retrieve information, prepare content or suggest a next action. Its value comes less from general conversation than from its integration with business data, rules and approvals.

## Start with a task, not a chat window

Describe the moment when assistance becomes useful. Who is working? In which tool? What information is missing? Which outcome must remain under that person’s control?

Consider a fictional case manager who opens a record and prepares a summary before a call. The copilot can retrieve permitted events, cite their origins and suggest a draft. It must not display notes restricted to another team, send the summary or change the record without an explicit action.

| Scoping question | Example of a verifiable answer |
| --- | --- |
| User | Case manager authorised for the current record |
| Trigger | Explicit request from the record page |
| Outcome | Structured draft with links to sources |
| Prohibited action | No automatic sending or record changes |
| Handover | Report missing or conflicting sources |

A conversational interface is optional. A contextual button, an inline form suggestion or a side panel may fit the existing journey better.

## Choose the context to provide

Useful context combines record data, applicable rules and information provided by the user. Each source needs an owner, an access rule and an update policy. Sending more data does not automatically improve the result.

When knowledge lives in documents, retrieval with sources may be required. First prepare the corpus, versions and permissions with the [enterprise RAG guide](/en/guides/enterprise-rag-knowledge-base). For structured data, prefer calls limited to explicitly permitted fields.

Treat incoming text, attachments and documents as untrusted data. An instruction found inside a document must never expand the copilot’s permissions.

## Separate preparation from action

A copilot can read, propose or act. These capabilities should not be conflated.

| Level | Capability | Expected control |
| --- | --- | --- |
| Consult | Read data relevant to the current role | Check authorisation before retrieval |
| Prepare | Produce a draft or suggestion | Show sources and flag uncertainty |
| Propose an action | Present the parameters of a change | Full preview before confirmation |
| Execute | Call a business tool | Approval, audit record and duplicate prevention |

Start at the lowest level that already creates value. A suggestion properly connected to the record may be more useful than an autonomous action that is difficult to control.

## Design an architecture that fails cleanly

The application journey should remain usable when the AI service is slow or unavailable. Separate orchestration, business access and interface concerns so that one part can change without rebuilding the whole product.

A common flow includes user identity, loading authorised context, optional retrieval, generation, deterministic checks and result presentation. Access rules, format validation and sensitive actions stay in code and business systems. They should not rely only on an instruction given to the model.

The guide to [integrating AI into an existing application](/en/guides/integrate-ai-existing-application) covers dependencies, fallback behaviour and progressive rollout.

## Design the control experience

Show users what was produced, which information supported it and what its scope is. A useful interface lets them correct, ignore or retry without losing the original work. It clearly distinguishes a draft from saved business data.

Prepare difficult states as well: no source, conflicting sources, denied access, late response or an action already completed. The copilot should stop with an understandable status and preserve a manual path.

## Evaluate before expanding

Create a set of ordinary, boundary and prohibited cases. Measure outcome correctness, source quality, review time, adoption and critical errors. A general impression that the experience feels smooth is not enough.

Use the [AI agent test plan](/en/guides/evaluate-ai-agent-test-plan) to define cases, thresholds and owners. Then launch to a limited scope with a simple way to disable the feature.

## Frequently asked questions

### Is a copilot an AI agent?

The concepts can overlap. “Copilot” generally describes visible assistance controlled by a user, while “agent” places more emphasis on multi-step work and tool use. Actual behaviour matters more than the label.

### Must a model be trained on company data?

Not necessarily. Depending on the need, instructions, document retrieval or calls to business tools may be enough. The choice depends on examples, precision requirements and data constraints.

### Where should human approval happen?

Before any sensitive or difficult-to-reverse consequence. The person should see the content, sources and exact parameters of the action they are approving.