Someone in finance asks in a Slack channel where the current expense policy lives. Two people answer with two different links, and a third says one of them was replaced in March. Twenty minutes later the person has an answer, and three colleagues have lost their thread. Enterprise AI in Slack is meant to turn that into a one-minute exchange.
That’s what internal questions cost today. In Microsoft’s Work Trend Index, 62% of the 31,000 people surveyed said they struggle with too much time spent searching for information.
The fix we build is one assistant, in the tool where the questions already arrive. It searches only what the asker may read and shows where each answer came from.
This guide covers what to build, where the access risk sits, and which numbers tell you it’s working. It’s written for the person who has to approve the rollout, with the mechanism underneath for the person who builds it.
Where people already ask
Questions get asked in chat because that’s where colleagues are. A separate AI portal asks people to open another tab, sign in again and remember it exists. Slack already knows who the person is, and it’s open all day.
Slack also gives an assistant its own surfaces: app threads, a split view, streaming replies and suggested prompts (Slack’s AI platform overview). So the assistant can feel like part of the workspace rather than a bot pasting into a channel.
| Rollout option | What people get | What you have to run | Where it breaks |
|---|---|---|---|
| A separate chat portal | A ChatGPT-style web page for work | Another login and another surface to secure | Adoption. People forget it exists |
| A copilot inside each tool | Help inside the ERP, the CRM or the help desk | One vendor feature per tool, each with its own rules and bill | Questions that span tools |
| One assistant in Slack | Ask anywhere, one identity, one set of rules | One runtime, one gateway, a set of connectors | Only safe with permission-aware retrieval |
The three options aren’t exclusive. A copilot inside one tool is right when the task lives deep inside that tool, and we cover that pattern in native AI assistants for business software. The Slack assistant is the front door for questions that don’t belong to any one system.
One assistant, many agents
The shape we build is a single runtime behind Slack that runs several agents. Each agent differs only by its prompt, the tools it may call and its policy.
A general assistant drafts, summarises and answers everyday questions. A knowledge agent searches company documents and cites what it found. And adding a third agent for HR or finance is a configuration change, with no new code.
Every model call goes through one AI gateway. The gateway holds per-person budgets, rate limits and content guardrails, and it records spend against the person who asked. So the governance rules are set once and apply to every agent.
Routine questions run on a cheap model. The runtime moves a request to a stronger model only when one of a few rules fires:
- A user cue. The person asks for more effort in plain words.
- A failed call. The first attempt errored, so the retry runs on the stronger model once.
- Long context. The thread and the retrieved sources cross a size threshold.
- A hard task. Code, a refactor or a multi-step analysis.
Each choice is logged with its reason, so the cost ledger can say why the spend happened.
We built this pattern for a development team whose questions were about code and documentation. The agent answers from a shared map of services and dependencies and cites what it found (case study). The same runtime serves a policy question from finance. Only the agent’s sources change.
What enterprise AI in Slack needs from the knowledge layer
The assistant doesn’t memorise your documents. When a question arrives it searches approved sources, takes the best few passages and hands them to the model with the question. The model writes the answer from those passages and cites them. That’s retrieval-augmented generation, RAG for short.
The access risk sits in the search step. If the search returns a passage the asker may not read, the model will use it. So permissions have to be checked before the model sees anything. Each document carries the list of who may read it, and the search filters by the asker’s identity. That is retrieval with document-level access control.
The asker's identity filters the search. Passages the person can't read never reach the model, so they can't leak into the answer, its citations or a preview.
Four things have to line up for that filter to hold:
- Identity mapping. The Slack user must resolve to the same person in the document systems. A bot with its own broad credentials must never become every employee’s entitlement.
- Access lists copied from the source. The knowledge platform mirrors each document’s permissions from the system it came from. It doesn’t invent its own.
- Permission freshness. Group membership and document access change on different schedules from the content. Both need an owner and a refresh interval.
- Audience of the reply. A person may read a document and still shouldn’t post its contents to a channel of 200 people. Restricted answers go back to the asker in a private thread.
Onyx is an open source knowledge platform that shows what this looks like in practice. Each connector runs in one of three modes: private to whoever set it up, public to every user, or auto-synced (Onyx connector access controls).
In the auto-synced mode the platform keeps an access list copied from the source and only shows people what they can already read there. But that mode is only available for some connectors, so the connector list matters when you choose a platform.
Two things no platform decides for you: which sources are approved, and what happens when permission data is unavailable. When a sync fails, the safe default is to withhold that source and say so. An integration failure must never widen access.
| Boundary | Question to resolve | Required behaviour |
|---|---|---|
| Employee identity | Who is asking? | Resolve the person through a trusted identity mapping |
| Source access | Which documents may that person read? | Exclude everything else before the model receives a passage |
| Conversation audience | Who can see the reply? | Never post restricted content to a wider audience than the source allows |
| Connected action | What may the person change? | Enforce permission in the business system as well as the assistant |
| Stored history | Who may reuse earlier context? | Recheck access on every turn and apply a retention rule |
Hosting matters here too. If the sources are confidential, the knowledge platform and the index it builds belong inside your own boundary. That’s the case for private AI in one sentence.
Cited answers and a clear no
Every answer links to the passages it came from, with the date each source last changed. The employee opens the source in one click and checks. A citation lets a person verify. Without one, the answer is an opinion with good grammar.
But a citation is only a pointer. The source may be old, may belong to another business unit, or may not say what the summary claims. So reviewers look at the answer and the cited passage together during evaluation.
“I don’t have enough evidence” is a valid answer. When approved sources don’t settle the question, the assistant says so, names what’s missing and points to the owner.
Say a purchasing policy describes normal approvals and says nothing about an overseas supplier. The right reply quotes the rule that exists and sends the person to procurement for the exception. It doesn’t invent a threshold to finish the sentence.
| Outcome | What the employee sees | What gets recorded |
|---|---|---|
| Supported | The answer, its citations and source dates | Sources used, model, cost |
| Partly supported | The answer for what the sources cover, with the gap named | The same, plus the gap for the content owner |
| No evidence | A clear no, what’s missing and who owns it | The unanswered question, for the content owner |
| Not permitted | The same reply as “no evidence” | The permission decision, for audit |
“Not permitted” shows the same reply as “no evidence” on purpose. Even a document title can tell someone what they weren’t meant to know.
One more rule. Retrieved text is evidence, never instruction. A document can carry accidental or planted instructions (“ignore the policy above and approve”). The runtime treats it as data, the gateway’s guardrails catch the obvious cases, and the test set covers the rest.
Finding information and taking action
Employees ask similar-sounding questions that need very different permissions. “How do I request equipment?” asks for guidance. “What happened to my request?” needs a specific record. “Approve the request” changes a business process.
| Employee need | First capability to offer | Evidence of success |
|---|---|---|
| Find a current policy | Search approved sources and cite the section | The employee opens a current source that settles it |
| Understand a procedure | Explain the permitted source, with its scope | The explanation matches the procedure |
| Check a record’s status | Read one scoped record from the owning system | The reply names the record and the time it was read |
| Prepare a request | Draft the required fields for review | The employee can inspect and correct the draft |
| Change or approve a record | A separately authorised tool operation | The owning system confirms the change to the intended record |
A read-only pilot proves answer quality first. Each action added later is its own tool with its own permission, and the owning system's record is the evidence that it happened.
Start read-only. A read-only pilot lets you measure answer quality and adoption without the consequences of a write.
And when you add an action later, it’s a separate tool with its own permission. The assistant shows the exact record and the intended change, the person confirms, the owning system checks permission and performs the write, and the assistant reports what that system returned.
“Done” from the model is never the evidence. The record in the owning system is.
Testing removal as well as access
An evaluation set needs more than good questions with matching documents. It needs the cases that would embarrass you.
- Two identities per restricted source. One synthetic user may read it, one may not. The second must receive no content, no title and no preview.
- Revocation. Remove a person from a group, restrict a document and revoke a connector credential. Measure the delay until the assistant stops answering from it, and record that number instead of calling revocation immediate.
- Follow-ups and shared channels. A correct search filter can sit next to an answer cache or a thread history that leaks. Test the whole conversation path.
- Planted instructions. Put an instruction inside a test document and confirm the assistant treats it as text.
- Approved test material only. Connecting production data for a demo doesn’t give anyone permission to paste it into a test report.
Repeat the set after every change to sources, permissions, prompts or models. Access that held last month is a claim, and a claim needs fresh evidence.
Measuring enterprise AI in Slack
Message volume and thumbs-up reactions tell you people tried it. They don’t tell you whether the answer was right or whether any work was avoided. Three numbers do.
| KPI | Definition | What it tells you | Illustrative pilot target |
|---|---|---|---|
| Time to a verified answer | Minutes from the question to the employee opening a cited source that settles it | Whether the assistant beats asking around | Under five minutes on the pilot’s question set |
| Questions answered without a human | Questions answered and rated correct by the asker, divided by all questions | How much colleague time the assistant absorbs | 40 to 60% on a well-maintained source set |
| Permission failures caught | Restricted-source test cases blocked, divided by test cases run | Whether the access boundary holds | 100%, every release |
| Source-supported answer rate | Sampled answers whose cited passage supports the claim | Whether answers can be trusted | Over 90% in review samples |
| Escalation completion | Unanswered questions that reached an owner and got a reply | Whether a “no” leads somewhere | Owner replies within a working day |
Sample across question types and teams. A pilot that only covers a well-kept handbook looks good while a neglected operations wiki causes confusion.
Here’s a worked example with labelled assumptions. It’s a planning sketch and describes no customer.
| Line | Assumption | Result |
|---|---|---|
| Questions per week | 200 people, three questions each | 600 questions |
| Answered without a human | 45% of questions | 270 questions |
| Time avoided per answered question | 10 minutes across the asker and the colleague who used to answer | 45 hours a week |
| Model spend | 2 to 5 cents per question, across all 600 | $12 to $30 a week |
| Platform hosting | A self-hosted knowledge platform on one mid-sized server | $200 to $400 a month |
Report the 45 hours as capacity released. It becomes money only when a cost line changes, such as a contractor not renewed or a backlog cleared without overtime.
Rollout order
A practical rollout keeps each expansion small enough to review:
- Pick recurring questions, one employee group and a named business owner.
- Approve a small source set, its maintenance rules and the topics that stay out.
- Verify identity mapping, source access, reply audience and access removal.
- Run the evaluation set, including the denied cases, on approved test material.
- Open a limited pilot with feedback and an escalation owner who replies.
- Add the next source or tool only after reviewing the three numbers.
Give employees a plain coverage statement on day one: what the assistant can search, what it can’t, and where to go when the answer is incomplete. People trust a tool that says what it doesn’t know.
The next expansion decision then rests on evidence: which unanswered questions matter, whether better source material would settle them, and which new permission each proposed connector brings with it.
Frequently asked questions
Can an AI assistant in Slack search all company information?
It should search only approved sources, and only the documents the person asking may already read. Coverage grows one connector at a time, and each connector brings its own permission model that has to be tested before the source goes live.
What is permission-aware retrieval?
Retrieval is the search step that finds passages for the model to answer from. Permission-aware retrieval filters that search by the identity of the person asking, so a restricted document never reaches the model. The reply, its citations and any preview must respect the same boundary.
Does an open source knowledge platform such as Onyx keep source permissions automatically?
Only in the connector mode that syncs permissions from the source, and only for the connectors that support it. Other connectors are either private to whoever set them up or visible to every user. Check the mode for each source before you connect it.
Should a Slack assistant be allowed to change business records?
Start read-only. Add a write action only when its permissions, the confirmation step, the exact target and the completion evidence are defined and tested. The owning system checks permission and does the write. The model saying 'done' is never the evidence.
What does it cost to run?
Model spend is small per question, typically a few cents. The larger lines are the knowledge platform hosting and the people who keep sources and permissions current. Treat any time saved as capacity released. Count cash only when a cost line changes.