Why it matters
An AI audience defines who an application serves and what knowledge it may access on their behalf. Without explicit audiences, every AI app drifts toward one-size-fits-all retrieval that violates internal boundaries.
A customer chatbot and an employee copilot share sources but serve different audiences with different trust levels. The chatbot must never retrieve internal playbooks meant for sales reps. The copilot may see both but must label internal citations differently.
Audience scoping turns implicit assumptions into explicit policy. When a product manager asks "can customers see this?" the answer lives in audience definitions, not guesswork.
Regulated industries require audit trails showing which audience accessed which knowledge. Finance, healthcare, and enterprise vendors cannot answer "we index everything and let the model decide."
Audience drift happens gradually. A copilot launched for support agents expands to sales, then partners, each with different knowledge boundaries. Without audience governance, the original access model becomes fiction.
Explicit audiences also simplify test design. You write test cases per audience, not per user, and catch boundary violations before customers do.
How it works
Define audiences during AI application setup: customer, employee, partner, admin, or custom segments. Each audience binds to collections and policies that control retrieval scope.
Access rules enforce audience boundaries at query time. A customer audience retrieves only from public-safe collections. An employee audience may add internal collections with citation rules that flag sensitivity.
Audiences carry claim boundaries too. A customer audience may be prohibited from quoting legal disclaimers as advice. An employee audience may see the same disclaimers with different framing.
Test suites run per audience. A refund policy test passes for employees who should see internal exceptions and fails for customers who should not.
Audience membership can be static (all logged-in customers) or dynamic (users with a partner flag). Policies bind to audiences, not individual users, keeping rules manageable at scale.
When onboarding a new user segment, create a new audience or extend an existing one deliberately. Shadow retrieval logs show what the new audience would see before you commit.
Example
Nintendo Support Assistant defines two audiences: public customers and internal support agents. Customers retrieve from Help Center and FAQ collections only. Agents add internal runbooks and escalation playbooks.
When a new partner program launches, Nintendo creates a partner audience with access to public docs plus partner-specific API guides, but not internal agent playbooks. The partner audience runs its own test suite before launch.
Common mistakes
- 1Treating audience as a display label instead of a policy boundary
- 2Sharing one audience across customer and internal apps
- 3Skipping audience-specific test suites
- 4Adding new user segments to existing audiences without reviewing knowledge scope
- 5Assuming model output filtering replaces audience-scoped retrieval
Your AI does not need more access. It needs the right access.
Set policies that control what each AI application can read, cite, and answer from.
See AI access policies