How to Personalize AI Onboarding by Role Without Leaking Internal Knowledge

Personalize onboarding in two separate steps. The source system decides what the hire may read, and the hire's open tasks decide which of those pages come first. A longer system prompt can do neither: if retrieval searches every document and asks the model to ignore forbidden results, the restricted text has already crossed the boundary that matters. We recommend inheriting access from the source system instead of maintaining it in the AI layer, ranking by open checklist items with role and stage as tie-breakers, and treating an empty result in the first days as a possible provisioning lag before a content gap.

Authorization and relevance are different jobs

A prompt can tell a model that the user is a designer in London. That improves wording and enforces nothing. Two people with the same title may sit in different teams, use different systems, work under different local policies and receive access on different dates, so a role label is not an onboarding plan either. The failures look like this: a new engineer asks how to request production access and the assistant retrieves a finance procedure because both pages mention approval, or a contractor gets a useful answer backed by a page only employees should see. The first is a relevance error and the second an authorization error, and one model judgment should not cover both. Decide which sources the person may retrieve, then which of those fit their current task.

The GitLab onboarding handbook shows the split in practice. Its onboarding issue gives every team member the baseline entitlements, while role-based access arrives through an access request that is generated on day 2 only if a template exists for the role, and that the IT team owns. A process with an owner decides access, and the knowledge layer reads the result.

The context the assistant needs

Start with attributes your identity and HR systems supply consistently, and avoid collecting personal details because they might make an answer feel more tailored:

user_context:
  user_id: u_1842
  employment_type: employee
  department: engineering
  team: platform
  role_family: software-engineering
  location: united-kingdom
  manager_id: u_0311
  start_date: 2026-08-03
  onboarding_stage: first-week
  open_task_ids:
    - task-prod-access-request
    - task-local-environment
  group_ids:
    - all-employees
    - engineering
    - platform-team

Treat user_id and group_ids as authorization inputs. Treat department, team, location, stage and open tasks as relevance inputs unless a policy explicitly uses them for access. That keeps a convenient personalization field from becoming an improvised security control. Keep the vocabulary controlled: software-engineering, engineering and eng should not become three accidental roles, and each role family, location and stage needs an owner. When an employee changes team, update the source system and let the company brain consume the change. Do not keep a second, hand-edited identity record in the AI application.

Inherit access, link relevance

Each indexed page needs an access policy and enough descriptive fields to rank it. We recommend keeping those two groups of fields under different rules. The access fields are copied from the page's home, the wiki space or drive folder where its owner already manages who can read it, and they are read-only in the AI tool. Only the relevance fields are edited there. If someone can widen a page's audience in the AI tool without touching the source, you have built a second permission system, and it will drift from the first.

{
  "document_id": "access-prod-requests-v4",
  "title": "Requesting production access",
  "owner": "platform-operations",
  "access": {
    "source": "wiki-space:platform",
    "allowed_groups": ["engineering", "platform-team"],
    "denied_groups": ["contractors"]
  },
  "relevance": {
    "role_families": ["software-engineering", "site-reliability"],
    "locations": ["global"],
    "onboarding_stages": ["first-month"]
  },
  "effective_from": "2026-06-01",
  "review_by": "2026-09-01",
  "status": "approved"
}

Google Cloud's IAM overview says you can't grant permissions directly to a principal: permissions travel in roles, and an allow policy is a list of role bindings between roles and principals. Mirror that shape. The hire holds groups, a page names the groups that may read it, and nothing in the AI layer names a person. Microsoft's document-level access guidance for Azure AI Search lists the same benefit for its native approaches: Microsoft Entra and SharePoint identities stay the source of truth, which reduces identity duplication and the overhead of a parallel permission store. Whatever search product you use, apply the authorization predicate inside retrieval, not after the model has read the result.

Relevance is the part that decays. Roles get renamed, pages get edited, and nobody re-tags a hundred pages with role families and stages. Tasks are already maintained, by the people who run the checklist. We recommend ranking pages linked from the hire's open tasks first, and using role family, location and stage as tie-breakers. Two engineers on the same team ask different questions this week because their open tasks differ, and the checklist knows which one has "Request production access" open. Hard-filter only on access and validity. A page tagged global may be right for every location, and a company glossary helps every role.

Run each request in this order

1. Resolve trusted identity from the authenticated session. A chat message never sets department, group_ids or employment_type. If identity resolution fails, stop, or fall back to a deliberately public onboarding collection.
2. Load the current context (role, team, location, manager, start date, stage, open tasks) from the authoritative systems. Cache it briefly if you must, and define how role changes and terminations invalidate the cache: context that is easy to load and slow to revoke is a security problem.
3. Build the authorization filter from identity and group membership. Deny rules win over allow rules, and expired, unapproved or archived pages are excluded by default.
4. Rank only the allowed set: pages linked from open tasks first, then role, location and stage. A first-week employee should usually see account setup before advanced deployment guidance, and a UK employee the local policy before a global page that omits regional requirements.
5. Generate from the evidence and show citations, with the page title and link beside important instructions. The hire can inspect the approved procedure, and the owner can find the source when an answer looks wrong.
6. If no allowed source supports the question, say so and route it to the source owner, manager, IT service desk or People Ops queue. Do not search a broader collection to be helpful. Store the question, the attempted retrieval and the eventual resolution so the content owner can repair the gap.

def retrieve_for_onboarding(question, user):
    identity = identity_service.require_user(user.session_id)
    context = hr_directory.onboarding_context(identity.user_id)

    access_filter = {
        "access.allowed_groups": {"intersects": identity.group_ids},
        "access.denied_groups": {"not_intersects": identity.group_ids},
        "status": "approved",
        "effective_from": {"lte": today()},
        "review_by": {"gte": today()},
    }

    candidates = search(question, filter=access_filter)
    linked = pages_linked_from(context.open_task_ids)
    ranked = rerank(candidates, boost_ids=linked, tie_breakers={
        "role_family": context.role_family,
        "location": context.location,
        "onboarding_stage": context.onboarding_stage,
    })
    return answer_or_escalate(question, ranked, identity, context)

The example is an implementation pattern, not a guarantee provided by any vendor. Adapt the filter syntax to your index and policy engine.

Kipwise describes onboarding with assigned reading and searchable company knowledge. In a role-based flow, assignments can establish the expected path while search handles questions that arise between tasks. The AI response should complement the maintained source, not replace it.

Decide with release rules, not a confidence score

A single model confidence score is hard to audit. Tie the decision to retrieval and source quality. Answer when all of these are true:

• at least one approved, in-date source directly supports the requested action;
• every cited source passed the user's access filter;
• the top sources agree on the required steps;
• the answer names any role, location or stage condition that changes the procedure;
• the source owner and review date are present.

Escalate when any of these is true: the allowed result set is empty; two current sources conflict; the question requests access the employee does not have; the source is expired, ownerless or a draft; or the action has a high consequence and the procedure requires human approval.

An empty allowed set can be the correct security outcome, so do not widen access to fill it. In the first days, though, check provisioning before content. A hire whose group sync is late holds only the baseline groups and looks exactly like a hire with no documentation. We recommend routing an empty result from the first days to IT with the hire's group list attached, and only then to the content owner.

Test relevance and permissions as separate properties

Before new hires use the flow, cross user personas with questions and expected source sets. Include an engineer, a sales employee, a manager, a contractor and a recently transferred employee, and add location variants where policy differs. The NIST AI Risk Management Framework asks that test sets, metrics and details about the testing tools are documented (MEASURE 2.1), so keep this matrix in version control next to the access metadata and rerun it when either changes. For each test, record:

Spend more time on negative tests than on happy paths. Ask a contractor for payroll guidance and a new salesperson for production credentials. Remove a group from a test user and repeat the same query. Transfer the user to another team and verify that old access disappears before new personalization appears.

Pilot with one role family

Start with one role family and one onboarding stage, such as first-week account setup for the platform team. Inventory its sources, link them from the checklist tasks, copy their access metadata from the source, connect trusted identity and run the persona matrix. Have the content owners read both the successful answers and the refusals. Track source coverage, access-filter violations, citation correctness, unresolved questions and owner response time, and review individual failures instead of relying on an aggregate: one restricted-source leak is not canceled out by many relevant answers. Add the next role or stage only after the pilot passes its release rules and revocation tests.