A new hire probation review can go wrong before the meeting starts. An AI company brain gathers completed tasks, training records, questions, and manager notes, then produces a polished verdict from evidence the employee has never seen. Missing access or unclear instructions can look like poor performance. A private request can appear in the packet. The manager may approve the summary because it looks complete.
Use the company brain to prepare traceable evidence, not to judge the employee. The workflow below defines expectations first, limits what the assistant can retrieve, gives the employee a correction window, and reserves the outcome for an accountable manager. The result is a review packet both people can inspect instead of an automated score that nobody can defend.
Why an AI summary can become the decision
A probation review mixes several kinds of information that should not be treated alike. Onboarding systems record whether a task was clicked or submitted. Learning systems record attempts and completion. Managers record observations. Employees ask questions in channels that may contain health, family, or workplace concerns. None of those records, alone, establishes whether the employee met an agreed expectation.
The distinction gets lost when the company brain retrieves everything under a broad prompt such as “summarize this employee's probation.” A fluent answer hides three problems:
- The sources may measure setup rather than performance. A missing application entitlement is an IT failure, even if it prevented the employee from completing work.
- The employee may not have access to the source or a chance to challenge it. A decision packet built from invisible evidence cannot support a useful two-way conversation.
- The model may collapse facts, interpretation, and recommendation into one paragraph. A manager can mistake generated language for an approved employment conclusion.
Acas describes probation reviews as formal, two-way checkpoints. Its guidance calls for sharing relevant information before the meeting, discussing support and training, keeping records, and avoiding a surprise at the final review. Legal requirements vary by country, contract, and worker status, so employment counsel should adapt the process to each jurisdiction. The workflow here controls evidence and system behavior; it does not replace legal review.
Set the decision boundary before collecting evidence
Write a short operating contract for the employee probation process. Approve it before the first review period begins. The contract should identify who decides, what evidence is allowed, what is excluded, how the employee can respond, and which outcomes the process supports.
Give the company brain four permitted jobs:
- retrieve the current role expectations and their effective dates;
- collect references to allowed evidence, with owners and timestamps;
- flag missing, conflicting, stale, or inaccessible records;
- format a draft packet for employee and manager review.
Prohibit it from assigning a pass probability, inferring attitude or cultural fit, ranking the employee against peers, diagnosing a disability, or recommending dismissal. Those restrictions should be enforced in application logic and access policy, not left in a prompt.
The NIST AI Risk Management Framework treats AI risk management as work across design, use, and evaluation. Apply that approach to this bounded workflow: document the context, assign human owners, test system behavior, and manage failures. The ICO guidance on AI and data protection also covers accountability, transparency, accuracy, fairness, data minimization, and individual rights. Those concerns are concrete here because the system processes employee data near a consequential decision.
Build an evidence contract for every expectation
Start from expectations the manager and employee already discussed. Do not let the model invent criteria after seeing the available records. Each expectation needs an owner, a source, a measurement method, a review date, and a known support dependency.
A usable record can look like this:
expectation_id: support-queue-01
outcome: "Resolve two supervised customer cases using the approved escalation path"
owner: "support-manager"
governing_source: "kb://support/escalation-policy"
effective_from: "2026-08-01"
evidence_allowed:
- "case IDs selected by the manager"
- "employee reflection shared for review"
support_dependencies:
- "helpdesk access"
- "assigned shadow session"
excluded_evidence:
- "private onboarding chat"
- "medical or accommodation records"
decision_authority: "support-director"This structure prevents a common substitution. If helpdesk access arrived two weeks late, the packet records the unmet dependency beside the outcome. It does not convert the delay into a lower employee score.
A role charter can supply the agreed outcomes, but the review contract must go further. It states exactly what can be used to discuss those outcomes. CIPD's induction factsheet frames induction as a planned way to give a new employee the knowledge and support needed to perform the role. Treat missing induction support as a process condition to resolve, not as silent evidence against the employee.
Keep retrieval narrower than the manager's access
A manager may be allowed to read many documents that do not belong in a probation packet. The retrieval identity should therefore represent the review purpose as well as the manager. Build an allowlist from approved evidence types, then intersect it with current document permissions.
Microsoft's document-level access control guidance describes query-time patterns that exclude documents when the user or group identity does not match stored permission metadata. Use the same principle even if the search stack is different. Index each reviewable item with employee, purpose, audience, owner, retention class, and effective date. Reject a result when any required scope fails.
Do not index raw accommodation records, health details, background reports, protected leave reasons, private buddy conversations, or unrelated chat history into the review collection. When one of those processes affects the employee's ability to perform a task, expose only a safe operational state such as support_dependency_pending. The responsible HR owner handles the underlying record in the authorized system.
Add a negative retrieval test. Ask the packet generator for private onboarding questions, another employee's review, and an expired manager note. All three requests must return no content and create an audit event. A positive test alone proves only that search works.
Generate a packet that separates facts from interpretation
The company brain should output an evidence packet, not narrative judgment. Keep each claim attached to its source and show uncertainty as a state that requires work.
Use five sections:
- Agreed expectations and the versions in force during the period.
- Employee-selected evidence and reflections.
- Manager-selected observations with dates and sources.
- Missing support, unresolved conflicts, inaccessible records, and correction requests.
- Blank manager decision fields for pass, extension, or formal escalation under company policy.
The generator should refuse completion when a required source lacks an owner, when two records conflict, or when the employee cannot inspect evidence marked for discussion. A simple control flow is enough:
for expectation in approved_expectations:
records = retrieve(allowlist, expectation.id, review_purpose)
visible = intersect(records, employee_view, manager_view)
if support_dependency_is_open(expectation):
packet.add_process_blocker(expectation)
elif visible.has_conflict_or_stale_source():
packet.add_requires_resolution(expectation)
else:
packet.add_evidence(expectation, visible.with_citations())
packet.leave_decision_blank()Label generated summaries as drafts. Show source dates and owners in the interface. A sentence such as “The employee missed the target” should be impossible unless the target, period, evidence, dependency state, and responsible reviewer are all present. Even then, the sentence belongs in manager-authored interpretation, not model output.
Give the employee a real correction window
Send the packet early enough for the employee to read it and respond. A correction window is not a comment box that closes when the meeting begins. It needs explicit states: received, disputed, corrected, manager response pending, and resolved.
The employee should be able to:
- identify a wrong or stale source;
- add evidence allowed by the contract;
- explain a blocked dependency;
- request correction of factual data;
- ask for a private HR route without putting sensitive details in the packet.
Keep the original and corrected records linked. Do not overwrite the audit trail. The packet shown in the meeting should make unresolved disputes visible instead of selecting whichever version favors a clean summary.
This is where a maintained knowledge base helps. Kipwise's employee onboarding page describes assigned reading, searchable policies and procedures, progress tracking, and workflows for keeping content current. Those features can supply source-linked onboarding context. They should not become a performance scoring system. GitLab's public onboarding handbook provides a practitioner example of explicit tasks, managers, owners, support paths, and linked working knowledge. The review packet should preserve that ownership rather than flatten every item into “complete” or “incomplete.”
Run the meeting and record the human outcome
The manager owns the probation review meeting. Start with unresolved evidence and support dependencies before discussing conclusions. Ask the employee whether the packet reflects the period accurately. Record agreed changes and assign an owner and due date to every open item.
The decision screen should require the manager to enter the outcome and rationale directly. It should show the approved choices from company policy, such as pass, extension, or escalation to a formal process. It should not preselect a choice or display a model confidence score. If the decision could lead to dismissal or another formal action, route the case through the required HR and legal procedure. Acas notes additional procedural considerations for a final review that may result in dismissal, including circumstances where accompaniment rights apply.
After the meeting, share the approved record with the employee through the authorized channel. Record who made the decision, when it took effect, which policy version governed it, and which follow-up actions remain. Limit retention and access according to the organization's employment-record policy.
Work through a realistic failure
Suppose a new support specialist has an expectation to resolve two supervised cases by week six. The ticketing account was provisioned in week four, and the assigned shadow session was canceled twice. The task tracker shows zero completed cases. A generic AI summary calls this “insufficient progress.”
The controlled workflow reaches a different result. The evidence contract lists ticketing access and a shadow session as dependencies. The access log and onboarding schedule show both delays. The packet marks the outcome not_yet_observable, assigns owners to restore the missing support, and leaves the employment decision blank. The manager and employee agree on replacement sessions and a later observation date. If an extension is appropriate under policy, the manager records it for that reason rather than accepting an unsupported performance label.
The company brain added value by finding the relevant source records and exposing the contradiction. It did not decide what the delay meant for employment.
Verify the workflow before the first live review
Test the complete path with synthetic employee records. Include clean cases and cases designed to fail.
Your test set should prove that:
- criteria cannot be added after the evidence period without a visible version change;
- another employee's records never appear;
- private onboarding chat and accommodation details stay excluded;
- stale or conflicting sources block packet completion;
- an unmet support dependency cannot become a negative score;
- the employee can inspect, dispute, and correct allowed evidence;
- the model cannot fill the decision field through a prompt or tool call;
- pass, extension, and escalation each create the required owner, rationale, effective date, and follow-up tasks;
- the final record reaches both manager and employee while excluded data remains absent.
Have People Operations, the relevant manager, HR systems, privacy, and employment counsel review the failed tests, not only the successful packet. Re-run the set whenever the evidence schema, model, retrieval permissions, role expectations, or employment policy changes.
Start with one role and one review date
Choose a role with written expectations and a probation review scheduled in the next month. Map each expectation to an allowed source, owner, support dependency, and employee-visible correction path. Configure retrieval against that allowlist, then run the synthetic negative tests before generating any real packet.
Do not connect private chat archives or ask the model for a recommendation. The first usable milestone is smaller: one cited packet that both the manager and employee can inspect, with every decision field still blank.
References
- Acas: Probation reviews supports the review structure, evidence sharing, two-way meeting, support, records, and final-outcome guidance.
- CIPD induction factsheet supports the role of planned knowledge and support in helping a new employee perform.
- ICO guidance on AI and data protection supports the accountability, transparency, accuracy, fairness, minimization, and rights controls around employee data.
- NIST AI Risk Management Framework supports the risk-management approach across AI design, use, and evaluation.
- Microsoft document-level access control guidance supports query-time exclusion based on document permission metadata.
- GitLab onboarding handbook provides a maintained practitioner example of explicit onboarding tasks, owners, managers, and support paths.
- Kipwise employee onboarding supports the product context for assigned reading, searchable company knowledge, progress tracking, and maintained onboarding content.
