How to Handle New-Hire Background Checks with an AI Company Brain

Use AI around a background check and never inside the decision. We recommend that the company brain explain the approved process, show a minimal status, route the person to a human owner, and release onboarding only when the screening process records a final permitted state, while reports, findings and decisions stay in the screening system. The EEOC says employers should not use a policy that excludes people with certain criminal records if it significantly disadvantages a protected group and does not accurately predict who will be a responsible, reliable or safe employee, and a model that scores screening content gives you no way to show that it does.

Why a checklist cannot hold screening

A checklist assumes one completion flag per task. Screening has eight independent states: the employer has defined a lawful, job-related package; the candidate has received the disclosure and given permission; the provider has collected and checked information; an authorized person has reviewed the result; any notice and response period has finished; any dispute is resolved; the employer has recorded the final decision; and downstream onboarding has been released, paused or cancelled. They belong to different systems and owners. A provider can report that its search is complete without deciding whether the person proceeds, a recruiting system can show an accepted offer while a dispute is open, and a company brain that retrieves both records can produce a confident, false answer.

The EEOC's joint guidance with the FTC shows how much of this is legal process. When you use a screening company in the United States, the Fair Credit Reporting Act requires a written, stand-alone notice and the person's written permission before the check, a copy of the report and a summary of rights before an adverse action, and a second notice after it. Other jurisdictions differ, so review the workflow for every place you hire.

Set the boundary before connecting systems

The company brain must never become a screening database. It may explain the approved process from current policy, show a candidate-facing status such as action_required or under_review, name the People Operations contact for the next step, pause onboarding tasks that depend on final clearance, release them after an authoritative final event, and record workflow identifiers, timestamps and safe state transitions. It must not ingest a consumer report or a copy of its supporting records, summarize criminal, credit, employment, education or identity findings, infer whether a result is acceptable, rank candidates by screening content, generate or approve an adverse decision, expose status to a manager outside the approved process, or retain candidate explanations in chat, analytics or a searchable page.

NIST's Privacy Framework is voluntary, so it does not create the duties in this post. Those come from the FCRA and the equal employment laws summarized in the EEOC guidance, and from state and local law. Use the framework only as a design test: the company brain receives the state and routing data needed to coordinate onboarding, and the screening system and the restricted case record keep the evidence. An ordinary onboarding checklist is the wrong place for a screening state, which only the screening owner should see, so the onboarding surface gets held, released or cancelled and nothing else.

A minimal screening status contract

Do not sync a vendor's full response into the HR system or the knowledge index. Translate provider events into an internal contract with an allowlisted state model:

screening_workflow_id: scr_20491
person_id: candidate_817
job_id: support_manager_us
policy_version: screening_us_support_v3
jurisdiction_profile: us_ca
consent_state: recorded
provider_case_id: vendor_992104
provider_state: review_complete
employer_review_state: pending
candidate_action_state: none
final_decision_state: pending
onboarding_release_state: held
owner_queue: people_ops_screening
state_checked_at: 2026-08-31T14:20:00Z

The contract excludes report contents. provider_state describes the vendor's work, employer_review_state the accountable review, and candidate_action_state whether the person must use a private route. final_decision_state stays pending until the authorized employer process finishes, and only then may onboarding_release_state change. Keep the vocabulary small and documented:

provider_state = requested | collecting | review_complete | provider_error
employer_review_state = pending | in_review | complete
candidate_action_state = none | notice_sent | response_window | dispute_open | resolved
final_decision_state = pending | proceed | do_not_proceed
onboarding_release_state = held | released | cancelled

Reject unknown states. A new vendor label should stop the adapter and raise an operator alert, and it must never fall through to proceed.

One owner for every transition

Automation can move data, but people own the consequential transitions, so document the owner and the required evidence for each change.

The assistant must not invent missing evidence. If a final decision event lacks an owner, a policy version or a timestamp, route it to the case queue and leave onboarding on hold.

Three surfaces, kept apart

Guidance. The company brain answers process questions from approved policy: who conducts screening, when a status update is expected, where to send a question, and why some onboarding tasks are unavailable. Each answer links the current policy and names the human owner. If a person asks what the check found, the assistant opens the private case route. It does not search chat history, summarize a report or ask the candidate to paste details.

Restricted case. The case system holds reports, notices, candidate responses, dispute documents, reviewer notes and the final decision record, with access limited to the screening team and counsel where required. Do not embed it in the knowledge index. The joint EEOC and FTC guidance says background reports and the information gathered from them must be disposed of securely, in a way that cannot be read or reconstructed, once recordkeeping duties are met. Every report detail in a prompt log, an index or an embedding is therefore a copy you must find and destroy later, and the safest architecture keeps case data out of retrieval entirely.

We recommend putting the safe-transition log on the HR retention clock and not on the assistant's. The same guidance says hiring records must be preserved for one year after they were made or after the personnel action, whichever is later, and until the case concludes if a charge is filed. The state log holds no report content, but it may count as a hiring record. Ask counsel, and store it where HR keeps hiring records, so a short chat-log expiry cannot delete it early.

Onboarding. The plan sees only held, released or cancelled, plus a safe reason code and an owner queue. A hold blocks only the tasks that truly depend on the final decision. Neutral pre-start communication may continue if policy permits, but account creation, equipment shipment, broad announcements and access grants follow explicit dependency rules. Kipwise's employee onboarding workflow shows the product context for assigned reading, searchable company knowledge, and onboarding progress. Use that surface for current guidance and task coordination. Keep screening evidence in the restricted system built for it.

Release as a signed event, not a lookup

Polling a vendor page and reading the word "complete" is fragile. Publish a signed internal event after the authorized employer decision finishes:

{
 "event_type": "screening.onboarding_release_changed",
 "workflow_id": "scr_20491",
 "person_id": "candidate_817",
 "release_state": "released",
 "decision_record_id": "decision_3048",
 "policy_version": "screening_us_support_v3",
 "decided_by": "people_ops_42",
 "decided_at": "2026-09-02T11:15:00Z",
 "event_id": "evt_600183"
}

The adapter verifies the event type, issuer, schema version, person mapping and decision timestamp, and processes event_id idempotently so retries cannot create duplicate accounts or messages. A handler can enforce the boundary:

def handle_release(event):
    validate_signature(event)
    require_known_schema(event)
    require_authorized_decision_owner(event.decided_by)

    if already_processed(event.event_id):
        return

    if event.release_state == "released":
        start_allowed_onboarding_tasks(event.person_id)
    elif event.release_state == "cancelled":
        cancel_pending_onboarding_tasks(event.person_id)
    else:
        raise UnknownReleaseState(event.release_state)

    record_safe_transition(event.event_id, event.release_state)

record_safe_transition stores no report details. It keeps enough to prove which event changed onboarding, who owned the decision, which policy governed it and whether the downstream actions succeeded.

Disputes and changed decisions

A dispute is a first-class state that keeps onboarding held while the private case process runs. When candidate_action_state becomes dispute_open, stop new dependent actions, keep existing accounts disabled or narrowly scoped according to policy, cancel scheduled welcome messages that have not gone out, route the candidate to the restricted case owner, show a neutral status such as "review in progress", and reconcile any action that ran before the hold took effect. Do not tell the hiring manager why the dispute exists, do not predict when it will resolve unless the case system gives an approved service target, and do not let the assistant coach the candidate on the facts. If you publish targets, publish the queue's closed days with them: GitLab's onboarding handbook documents the dates on which People Operations cannot assist with onboardings, such as national holidays.

The notices in this process are legal documents with required content, so the assistant should trigger them and never write them. Under the FCRA, the notice before an adverse action must include a copy of the report and a summary of the person's rights, and the notice after the decision must name the reporting company, say that it did not make the decision and state the right to dispute the report and to get a free second report within 60 days. Keep approved templates under counsel's control, let the workflow send them, and have the assistant say only that a notice is on its way and who to contact.

If a released decision changes, treat it as a compensating transaction: freeze new side effects, list what was already created, assign each reversal to an owner and verify the final state. Cancelling the HR task does not recall equipment, remove a calendar event, disable an account or retract an announcement.

Test with synthetic data, then search for leaks

Test state transitions and data absence, because a green happy path is not enough. Build fixtures for missing permission with a provider request already open, provider review complete while employer review is pending, a response window opened by a notice, a dispute after onboarding was released by mistake, the same vendor event three times, an event mapped to the wrong person, a missing or obsolete policy version, a release event that arrives after a start-date change, a cancellation after equipment or account tasks started, and an unauthorized manager asking the company brain for report details. For each fixture, check the visible result and the data trail: the assistant shows a safe status and the right owner, and the search index, prompt log, analytics event, task comments and notification payload hold no report detail, candidate explanation or reviewer note.

Then run a negative search for known synthetic report terms across the knowledge index, chat export, observability store and onboarding task history. The expected result is zero matches. That check proves what ordinary background-check and onboarding pages leave open, which is that restricted evidence never entered the company brain.

Monitor the boundary after launch

Track workflow health without turning screening outcomes into onboarding analytics: events rejected for an unknown schema or state, cases held because an owner or policy version is missing, time between final decision and successful release, dependent actions that failed after a valid release, duplicate events ignored by the idempotency check, and negative privacy scans that found restricted synthetic terms. Do not publish pass rates by protected characteristic or show individual outcomes on a general dashboard. The same guidance describes an exclusion policy that significantly disadvantages a protected group and does not accurately predict who will be a responsible, reliable or safe employee as having a disparate impact, so any fairness or impact analysis belongs with employment counsel and compliance, on controlled data and for an approved purpose. Alert on state integrity and not on report content: page an operator when a released workflow has no decision record, a held workflow starts a dependent task, or a cancellation leaves access active.

Put the first control in place

Inventory every field that your screening provider, applicant tracking system, HR system and company brain exchange, and remove report contents and free-text findings from the company-brain path. Define the allowlisted state contract, name each transition owner, and test one held to released flow and one dispute flow with synthetic data. Do not enable automated release until the negative search shows that report details stay out of prompts, indexes, logs and onboarding tasks.