How to Test an AI Onboarding Company Brain Before New Hires Use It

Test a company brain the way a new hire will use it, and judge it by what reached the model as well as by what it said. We recommend three habits: assert permissions and versions on the retrieval output, not on the answer text; keep a held-out set of cases that nobody tunes against; and start with a file of cases and a script, not an evaluation platform. Block release on critical failures. An average hides a leaked payroll instruction, and an answer can sound polished while citing the wrong policy, skipping an approval step or revealing instructions meant for another role.

A demo is not a test

A demo starts with a friendly question whose answer is already known, run from an administrator account against a document that is easy to retrieve, with someone who knows the company interpreting any ambiguity. New hires have none of those advantages. They use unfamiliar vocabulary, do not know which policy is current, and cannot spot an answer that silently combines two incompatible procedures. The AWS explanation of retrieval augmented generation describes relevance as vector math: the user query is converted to a vector representation and matched against a vector database. A new hire's wording can therefore match a page that shares none of its keywords and miss one that does, so write test questions in new hires' words and not in page titles.

Treat the company brain as an onboarding system and not a text generator. Its job is to help a particular employee finish a particular task from approved evidence, so a test inspects the task outcome, the cited source, the user's access and the behavior when evidence is missing. The NIST AI Risk Management Framework asks (MEASURE 2.3) that performance be measured and demonstrated for conditions similar to the deployment setting, with the measures documented. For this system the deployment setting is a new hire on day three.

Define the release boundary first

Do not test every question an employee could ask. Define the first release around a bounded set of onboarding jobs, such as requesting software access, finding the expense policy, preparing for a customer call or locating the escalation path. Start with the jobs that are both frequent and consequential. A wrong lunch recommendation is annoying, while a wrong security, payroll, benefits, customer data or approval instruction can cause real harm, so those jobs get stricter release rules and a human review of every failure. The GitLab onboarding handbook shows which jobs to rank first: it singles out tasks that must be completed in line with company compliance, naming security and payroll, and has a People Operations specialist chase anything outstanding.

For each job, record the employee role and location, the approved sources, the action the employee should take, the conditions that change the answer, and the owner who can resolve uncertainty. "Help a new sales employee submit a travel expense" is testable because it names a user, task, source and outcome. "Answer questions about expenses" invites subjective grading.

Write cases from real tasks

Keep cases in a structured file so they can be rerun after documents, retrieval settings or models change:

id: expense-policy-remote-us
persona: new-us-employee
question: "Can I buy a monitor for my home office, and who approves it?"
set: tuning
required_sources:
  - remote-equipment-policy
required_facts:
  - spending limit
  - manager approval step
  - reimbursement route
forbidden_sources:
  - contractor-equipment-policy
expected_behavior: answer-with-citation
severity: critical
owner: people-operations

Write several variants of each important task:

• a direct question using the document's terminology;
• a natural question using shorthand or an old internal term;
• a question missing a key condition, such as country or employment type;
• a question that combines two related policies;
• a request from a user who lacks access to the source;
• a question for which no approved answer exists.

The missing-condition case matters because a fluent system may guess when it should ask. If a benefits answer depends on location, the right response may be a clarifying question, and if no approved relocation policy exists, it is a refusal with a named escalation route and not a confident synthesis. Take real questions from People Operations, common access failures from IT and role vocabulary from hiring managers, with personal data and secrets removed. Knowledge owners approve the expected answer. The model's current output must never become the answer key.

Hold some cases back

Every case you fix against becomes training data, and a suite you tuned the system to pass stops measuring anything. Split it in two. The tuning set is visible to the people building the system, who fix against it. The held-out set is written by a source owner who does not work on the system, runs before each release, and is never discussed case by case. When a held-out case fails, fix the cause in the source or the retrieval, then write a replacement case and not a patch for that exact wording. Refill the held-out set from new hires' real questions as they arrive.

Assert on what reached the model

A permission test that searches the answer for a forbidden phrase passes when the model paraphrases the leak. Check instead whether any chunk from a forbidden source appeared in the retrieved set for that persona, and whether a superseded version outranked the current one. Those are deterministic checks on the retrieval log. They are cheap enough to run on every index or permission change, and they fail when restricted text reached the model even if the final answer happens to be clean. Grade the generated answer only for cases whose retrieval assertions pass.

Run each question under more than one identity, and test both directions. The authorized employee should get the needed answer. The unauthorized one should get no protected fact, no revealing summary, no document title that leaks the subject and no link that grants accidental access. Microsoft's document-level access guidance describes a pattern in which the application passes the caller's identity as a string that populates a filter on the query. So test the string too: a missing or mis-mapped identity is the failure that no answer-level test will name. Use synthetic sensitive content in the test environment so a failure exposes no real records. For freshness, publish an old and a current synthetic policy and confirm that retrieval selects the current one, then repeat with effective dates, archived pages, duplicate titles and regional variants. If the system cannot tell which source governs, it should say so.

Score the answer on three more behaviors

• Correctness: does the response keep the required facts, conditions, sequence and owner? A response can be relevant and still fail by omitting the approval step. Mark critical facts explicitly, grade as pass, partial or fail with partial defined before testing, and let partial on a critical case block release.
• Citation support: can the employee open the source, and does the cited passage support the nearby claim? A citation to the right document is not enough when the response relies on a different section. Check source identity, passage and version. When two sources conflict, the expected behavior is to name the conflict and route it to an owner, not to pick the passage that makes the smoothest answer.
• Refusal and escalation: ask questions outside the approved set and questions requesting restricted material. A useful refusal states what the system cannot verify and points to the right person, team or request process. "I cannot help" is safe but not useful, and an invented answer is useful-looking but unsafe. Include injection attempts in both the question and a retrieved test document, and expect the approved workflow, no disclosure and a valid next step.

Gate on severity, not on an average

Nine correct lunch and office answers should not cancel one leaked payroll instruction. Group cases by severity and write the gates before you see results. A practical set: every critical permission test passes, every critical answer cites an approved source, no restricted fact reaches an unauthorized persona, unsupported policy questions refuse or escalate correctly, and every critical failure has an owner and a rerun result. Partial results at lower severity are documented and accepted by the relevant owner. The exact threshold is a governance choice, and its value lies in being fixed in advance. Keep the raw results for audit and regression comparison: system version, document snapshot, identity, question, retrieved sources, answer, grade, grader and failure category.

Pilot with people who do not know the answers

Once the suite passes, run a small pilot with at least one recent hire or an employee outside the policy owner's team. Experts fill gaps unconsciously because they know the process, and a realistic user shows whether the answer explains unfamiliar terms, gives an actionable sequence and makes citations easy to inspect. Ask pilot users to complete tasks and not to rate the chatbot's personality. Watch whether they reach the right document, take the right action and know when to contact a person, and record unanswered questions as new cases or content work.

The Kipwise new hire onboarding workflow combines searchable knowledge with assigned reading. That distinction is useful in a pilot. Some material should be proactively assigned because every hire must acknowledge it. Other knowledge can remain available on demand. Testing should cover both paths rather than assuming chat replaces the onboarding plan. The system also must not stand in for a manager: culture, feedback, prioritization and sensitive personal decisions still need people.

Diagnose failures by layer, and keep testing

When a case fails, name the layer before touching a prompt. Is the source missing, contradictory, stale or badly structured? Is retrieval choosing the wrong passage because of indexing, metadata, filters, query rewriting or ranking? Is the permission or identity context missing, late or inconsistent, in which case stop the release for the affected content, since response instructions cannot repair a broken access check? Did generation drop a condition or add an unsupported claim? Or is a correct answer unusable because the link is inaccessible or the jargon unexplained? This prevents the common mistake of tuning the model when the defect is an obsolete policy or a broken identity mapping.

Rerun the suite when a governing document, permission model, retrieval component or generation model changes, and on a schedule, because indexes drift even when code does not. Use required_sources in both directions: when a governing page changes, rerun the cases that name it and ask their owner to confirm that the expected facts still hold. Add production questions only after review and redaction, and keep a stable core for regression next to a changing set for newly found gaps. Assign each case to a source owner. The system owner coordinates the run but should not decide whether every business answer is correct.

Run the first test this week

You do not need an evaluation platform for the first ten tasks. A file of cases, a script that runs them under test identities and logs the retrieved source IDs, and a sheet for owner sign-off are enough. Adopt a tool when reviewing results by hand becomes the bottleneck. Choose ten tasks a new employee must complete in the first two weeks, name the approved source, required facts, persona, expected refusal conditions and owner for each, and add unauthorized and missing-evidence variants for the critical ones. Run the suite, fix failures by layer, and require explicit owner approval before release.