AI integration
A company-wide assistant becomes another search box when nobody defines the work it improves.

The short answer
An internal AI copilot should improve a defined employee task, not answer anything about the company. Give it only the sources and tools that job needs, preserve user permissions, separate drafts from actions, evaluate real tasks and difficult cases, make citations and escalation visible and measure completion quality rather than conversation volume.
The phrase internal copilot can describe a useful assistant or a blank chat window connected to too much information. The difference is the job. A good copilot knows the user, the task, the evidence it may use and the point where a suggestion becomes an accountable business action.
Choose one role and one repeated job.
Start with work employees already perform: preparing a case summary, drafting a response from approved sources, finding the procedure for an exception or assembling information before a handoff. Observe recent examples and record what people search, copy, compare and decide.
The task should have a recognisable output and a person who can judge it. Saving time is useful, but quality and follow-through matter too. A faster draft that requires a complete rewrite has moved effort rather than removed it.
Avoid a company-wide first release. Different roles have different terminology, permissions and consequences. A bounded copilot can use a smaller source set, clearer tools and a meaningful evaluation. Later roles can reuse the platform without pretending they share one job.
Give the copilot the minimum sources and tools its job requires.
Connect approved knowledge with owners, access and freshness rules. Preserve the employee's existing permissions so the copilot cannot reveal a document or record they could not open directly. Keep sensitive values out of prompts and logs unless the task genuinely requires them and the handling is designed for it.
Tools need narrower permissions than the user interface may suggest. A copilot that drafts a CRM note does not automatically need authority to change account ownership. Expose specific actions with validated inputs, keep consequential changes behind confirmation and record the result returned by the system.
1. Map the employee task
Follow real examples from trigger to completion and identify the research, drafting, comparison and action steps involved.
2. Choose approved context
Limit sources to what the role needs, preserve permissions and assign owners to the information the copilot relies on.
3. Separate draft from action
Define what the copilot may suggest, what it may prepare for review and which validated actions it may execute after confirmation.
4. Test in the working surface
Place the copilot where the task happens and evaluate the full handoff, not a disconnected chat demonstration.
Design interaction around evidence, edits and accountability.
Show the sources behind factual answers and make the original material easy to open. For a draft, distinguish copied facts, generated language and fields that still require the employee's judgment. A polished paragraph should not hide a missing customer identifier or an unsupported statement.
Let the user edit before a consequential send or write. Preserve the final version, the approving person and the action result. Do not attribute generated wording to the employee without a review step when the message carries their authority.
Use structured controls when the task has a known shape. A button to summarise the current case with cited evidence can be safer and faster than expecting every employee to write a careful prompt. Conversation remains useful for follow-up, but the product should carry the repeated instruction.
| Level | Copilot behaviour | User control |
|---|---|---|
| Retrieve | Find and cite approved information | Open and judge the source |
| Draft | Prepare a summary or response | Edit and approve the final wording |
| Recommend | Suggest a category or next step | Choose with evidence and policy context |
| Act | Call a narrowly defined company tool | Confirm consequential changes and inspect the result |
Evaluate the task, not whether the conversation sounds intelligent.
Use real completed work to build evaluation cases. Include missing information, conflicting sources, unusual terminology, denied access and requests outside the copilot's role. Record the expected evidence, acceptable output and action boundary for each case.
Measure factual support, task completeness, edit distance, review time, escalation and the correctness of any tool action. Ask whether the employee reached the outcome with less effort and no new hidden risk. Satisfaction alone can reward a fast confident answer even when the underlying work is wrong.
Run a controlled pilot with users who perform the task at different levels of experience. An experienced person may correct subtle problems automatically while a newer person accepts them. The copilot should make good judgment easier without requiring expertise to detect every mistake it produces.
Adoption depends on trust, placement and an owner who keeps it current.
Put the copilot inside or beside the system where the work already happens. Copying information into a separate chat and back again can erase the time saved and increase the chance that the wrong record or stale context is used.
Explain the boundary to employees: which sources are used, which conversations are retained, what the copilot can change and when a person remains accountable. Give them a useful way to report a weak source, missing instruction or unsafe recommendation without treating every correction as automatic training data.
We assign an operating owner, evaluation set and release process with the first version. Models, sources and company procedures change. The copilot stays dependable only when those changes trigger review instead of arriving quietly behind the same interface.
Set a review rhythm with the team leaders responsible for the work. Look at strong outputs, corrected outputs, ignored suggestions and tasks people still complete outside the copilot. The gaps may point to the interface, the source material or the process itself, and each needs a different response.
Keep a practical exit path as well as a rollout plan. Employees should be able to complete the job when the model, connector or tool is unavailable. A copilot is support for accountable work, not a new single point of failure hidden behind a helpful tone.
Worth knowing before you start
Name one role, repeated job and judgeable output before designing a general company assistant.
Preserve existing document and record permissions in retrieval and tool access.
Use structured task controls for repeated work and keep the underlying instruction out of every employee's prompt.
Measure factual support, edits, completion and action quality rather than counting conversations.
Further reading
Common questions
It is an assistant designed around a specific employee task, using approved company context and narrowly defined tools. It can retrieve, draft, recommend or act within written boundaries. A useful copilot is part of a workflow with permissions, evidence, evaluation and accountability, not only a private chat interface.
It should not by default. Give it the minimum sources and records required for the role, and preserve the employee's existing access. Broader access increases the permission, privacy and evaluation surface without improving a task that only needs a bounded set of information.
Only through narrowly defined tools with validated inputs, traceable results and authority proportionate to consequence. Start with retrieval and drafting, then add confirmed or low-risk actions when evaluation supports them. A general instruction to use company systems is not a safe action model.
Improve a real task inside the place people already work, explain the data and action boundaries, make evidence visible and give users a clear correction path. Adoption follows usefulness and trust. Requiring a separate chat for work that still has to be repeated elsewhere usually creates another tool to maintain.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.