Slack AI: Built on First Principles for Data Protection
Slack has long approached new technology cautiously, applying rigorous standards before adoption. When the company began exploring large language models (LLMs) for AI-powered features, it faced a challenge: finding an implementation that could meet enterprise-grade customer data stewardship requirements. Early product tests showed promise — 90% of users who adopted Slack's AI features reported higher productivity — but the generative model industry itself was young and largely research-focused, offering few existing enterprise security patterns to follow.
Rather than adapt to immature industry norms, Slack's engineering team started from first principles. They defined a set of guiding requirements specifically for generative AI:
- Customer data never leaves Slack's trust boundary.
- LLMs are not trained on customer data.
- Slack AI only operates on data the requesting user can already see.
- Slack AI upholds all of Slack's enterprise-grade security and compliance requirements.
These principles shaped every architectural decision — and in some cases, made the engineering substantially harder.
Keeping Models Inside the Trust Boundary
The most consequential decision was how to use a top-tier foundation model without letting customer data leave Slack's infrastructure. Most foundational model providers treat their models as proprietary and weren't eager to let customers deploy them on their own hardware. Directly calling hosted services was the norm, but that path would conflict with Slack's FedRAMP Moderate authorization and its associated compliance requirements, which prohibit sending customer data outside the trust boundary.
The breakthrough came through AWS, which can serve as a trusted broker between model providers and customers. Slack hosts and deploys closed-source LLMs inside an escrow VPC, giving Slack control over the data lifecycle while ensuring model providers never have access to customer data. This arrangement made it possible to run a top-tier model inside Slack's own trust boundary.
A Stateless, RAG-Based Approach
The second major decision was avoiding model training entirely. Slack's existing privacy principles — such as preventing data leakage across workspaces and offering customers choices — were established for traditional ML models like search ranking. For generative AI, given the industry's nascency, Slack determined it couldn't make strong enough guarantees if it trained a model on customer data.
Instead, Slack adopted Retrieval Augmented Generation (RAG), using off-the-shelf models in a stateless manner. With RAG, all context needed for a task — say, the messages to summarize alongside instructions — is embedded in each request. The model retains nothing afterward. Besides being a privacy benefit, this approach grounds all results in a company's own knowledge base rather than the public internet, improving relevance and accuracy.
RAG does introduce tradeoffs. Context windows must be large enough to hold the task's data, and more context means slower request processing. Slack evaluated several models and selected one suited to its initial use cases — summarization and search — while dedicating significant effort to prompt tuning and chaining traditional ML models with generative models to refine output quality.
Enforcing Existing Access Controls
A core tenet of Slack AI: it sees only what the requesting user can already see. Search results will never surface content that standard search wouldn't show. Summaries won't include anything a user couldn't read directly in a channel.
Technically, this was straightforward — but it was an explicit, deliberate design choice. Slack AI fetches data using the requesting user's Access Control List (ACLs) and leverages the same existing libraries that power channel displays and search results pages. Reusing Slack's core feature sets ensured consistent permissioning, with AI augmentation applied only at the end. Additionally, only the user who invokes Slack AI can see its output — no shared AI results.
Enterprise Compliance, Applied to AI Outputs
Since Slack AI is built on Slack, it had to inherit all of the platform's enterprise compliance offerings. The team followed the principle of least data: store only what's needed, only as long as necessary. Where possible, that means no data at all — conversation summaries and search answers are ephemeral, point-in-time responses never written to disk.
Where persistence was unavoidable, Slack reused existing compliance infrastructure — like Encryption Key Management and International Data Residency — and built new support where gaps existed. One notable addition: derived content like summaries is aware of the source messages. If a message is tombstoned due to Data Loss Protection (DLP), summary derived from it are automatically invalidated. This means administrative controls that already govern Slack messages also govern AI outputs.
Slack's initial focus on security and privacy was deliberate, establishing trust before wading deeper into model evaluation, prompt engineering, and handling demand spikes — topics the team plans to cover as Slack AI evolves.
