How to Build a New-Hire Job Shadowing Plan with an AI Company Brain

Shadowing hands a new hire fragments unless the plan ties each observed action to the rule behind it. We recommend three choices: shadow one bounded task with two different hosts, capture the learner's questions and not a recording of the session, and end with the learner performing a case they did not watch. The company brain assembles approved context, tracks unresolved gaps and keeps the notes clean. It does not record live work, promote one person's workaround to policy, or certify that anyone is competent.

Observation is a snapshot

AIHR's guide describes job shadowing as mostly observational, usually lasting a few days or less, and as a snapshot of the job. Its seven program steps start with purpose and goals and include matching hosts and learners. CIPD's induction factsheet says induction should give a new recruit the knowledge and support needed to perform the role. A snapshot cannot carry that alone, so the plan must end with a task the hire performs. A plan built that way also rules out an invitation that only tells the learner to "shadow Alex for two hours": the host makes dozens of small decisions in that time without saying which ones come from policy, customer context, judgment or system state, and the learner sees the action but misses the rule.

Write the contract before the invitation

Create a small control record in which every field has a human or an authoritative system as its owner:

shadowing_id: shad-2026-018
learner: employee-482
host: specialist-031
process_owner: customer-operations
live_task: resolve-a-standard-account-access-request
learning_objective: explain-and-perform-the-approved-triage-path
approved_source: kb/customer-ops/access-triage-v4
source_owner: support-enablement
allowed_data:
  - synthetic-demo-record
  - redacted-live-record
recording: prohibited
notes_location: onboarding/shadowing/shad-2026-018
supervised_practice_required: true
readiness_approver: manager-084
expires_at: 2026-09-30

The learning objective describes observable behavior. "Learn support operations" is useless, while "explain the triage rule, identify the source that governs it, and process one redacted case under supervision" gives everyone the same finish line. Pick a task small enough to finish in one session, such as validating an access request and choosing the approved routing path, and not a broad process like customer onboarding. Keep the host and the process owner separate when they are different people: the host demonstrates current work, the process owner decides which procedure is authoritative, and a named approver decides readiness.

Store the contract where the role's other onboarding tasks live. GitLab's onboarding handbook links some roles and departments from the main onboarding issue to a supplemental issue template, with support engineers and production engineering among the examples, so role practice sits where its owner maintains it. A calendar invite has no owner and no version.

Shadow the same task with two hosts

We recommend shadowing the same bounded task in two separate sessions with two different hosts before treating anything observed as guidance. Where the hosts do different things, you have found either an undocumented practice or a conflict with the written procedure. Where both do the same thing and the procedure says otherwise, the procedure is stale. A single host can only show one person's habits, and a new hire has no way to tell which of them is policy.

After each session, compare what the host did with the governed procedure and classify every material decision:

• Matched: the action and the explanation agree with the current source.
• Valid exception: the source defines an exception and the case met it.
• Undocumented practice: the action may be useful, but no approved source supports it.
• Conflict: the source and the action disagree.
• Inaccessible: the learner cannot inspect the evidence needed to understand the action.

Only the first two become learning guidance immediately. Send undocumented practice to the source owner, stop the affected learning step on a conflict, and never let the model prefer the host's behavior over the written procedure because the behavior is newer. Each gap gets a named person or accountable function and a due date, since "ask the team" is not a route. If the observed method is better, change the source through its normal review and rerun the comparison against the new version.

Set the boundary for the live session

Live work shows customer records, internal investigations, credentials and pricing exceptions that a generic onboarding page never does, and attending a session does not authorize access to all of it. Pick one of three modes:

• A synthetic walkthrough recreates the decision path with invented data. It is the safest default for restricted workflows.
• A redacted live case shows the handoffs and delays a demo misses. Prepare it in advance, hide unneeded fields, and switch to the synthetic case the moment unexpected sensitive data appears.
• Direct observation fits ordinary, low-risk work where the learner already has the access.

NIST's Privacy Framework is voluntary, so it sets no rule for shadowing, but it states the stake: managing privacy risk while protecting individuals' privacy. In a shadowing session those individuals are the customers and colleagues on the screen, who did not agree to be observed. For each session, name the purpose, show the least data that works, limit who can read the notes, state how long they are kept and give people a way to correct them.

The host's plan should be generated from approved knowledge and approved by the source owner or the host, with a link the learner can open under their own identity for every instruction. If the learner cannot open a cited source, the assistant withholds the instruction and routes an access request instead of paraphrasing restricted content. Azure AI Search offers four document-level options, security filters, ACL and RBAC scopes, Purview sensitivity labels and SharePoint permissions, and all of them check the caller's identity at query time, which is the property you need: restricted text never reaches the model. Filtering the answer afterward is too late. Before the session, use a test identity with the hire's groups and confirm it can open the approved procedure and cannot retrieve restricted case notes, manager records or another team's knowledge.

We recommend against recording the session, even though AIHR counts pre-recorded video as a form of virtual shadowing. A recording of live work holds customer details, investigations and credentials that nobody agreed to put in a searchable archive, and a transcript turns one host's habit into a record the assistant can quote as policy. Capture the learner's questions instead, each tied to a source, in a format that has no place for names, account numbers or screenshots:

{
  "decision_observed": "route request to account security review",
  "learner_question": "Which risk signals require this route?",
  "claimed_source": "kb/customer-ops/access-triage-v4",
  "source_match": "pending",
  "sensitive_case_data": false,
  "owner": "support-enablement",
  "follow_up_due": "2026-09-10"
}

From observation to supervised practice

Observation ends when the learner can explain what happened, and readiness requires a bounded task:

1. The hire restates the task, the decision points and the stop conditions in their own words.
2. They get a synthetic or redacted case they did not watch anyone solve, and they open and cite the governing source.
3. The host watches without taking over, and you inject one realistic ambiguity or failure.
4. You check whether the learner pauses, finds the right owner and keeps the data boundary.
5. The named approver records ready, revise or escalate with a specific reason.

The readiness record holds only the source version, the test case, the observed decisions, the stop-rule result, the reviewer, the outcome and the next action. The company brain may present the case, retrieve the procedure and record the outcome. It may not approve itself, and neither model confidence nor a clicked reading counts as evidence of competence.

Kipwise describes employee onboarding with searchable knowledge and assigned reading. Those features can prepare and support the exercise, but the verification still needs a realistic task and accountable human review.

When a session goes sideways

• If the approved source is stale, pause the affected step. The source owner either approves an update or gives a temporary instruction with a stated scope and an expiry date.
• If sensitive data appears unexpectedly, end or hide the view, keep the data out of the notes, and follow the privacy or incident route if anyone was exposed.
• If the host is unavailable, use a preapproved alternate who can demonstrate the same governed task, not an adjacent colleague who merely keeps the calendar event.
• If the practice attempt fails, record the specific decision that needs revision, assign targeted practice and repeat with a new case. Do not reset the whole plan or label the learner generally unready.
• If the model summarizes the session wrongly, keep the host-approved notes, correct the summary, and find out why the unsupported statement passed. An AI summary is never the process record by default.

Before you invite the hire, create the contract and run three tests with a test identity: the restricted document is absent from retrieval, sensitive text added to the synthetic case never reaches the notes, and only the named human can approve readiness.