Practical guide

How to build employee trust during AI adoption

Employee trust in an AI programme depends on whether people can predict how the system will affect their work, what evidence is collected, who can act on it, and how errors are corrected. Replace broad reassurance with a testable trust compact for each workflow. The compact should state the purpose, boundaries, evidence use, human responsibilities, challenge path, and review date.

By Two Prune

Employee trust in an AI programme depends on whether people can predict how the system will affect their work, what evidence is collected, who can act on it, and how errors are corrected. Replace broad reassurance with a testable trust compact for each workflow. The compact should state the purpose, boundaries, evidence use, human responsibilities, challenge path, and review date.

Start with a workflow-specific trust compact

Write the compact beside the actual task design, not in a distant policy page. The NIST AI Risk Management Framework notes that AI risk management requires perspectives and actors across the lifecycle. This supports involving the people who perform and review the work before a workflow is rolled out.

A compact should answer seven questions:

Avoid a single enterprise statement such as “AI is used responsibly.” People need to know what happens in the workflow they encounter.

  • What task is the system supporting?
  • Which decisions remain with a person?
  • What inputs can the system access?
  • Which actions and artifacts are retained?
  • Who can view each evidence type?
  • How can a worker challenge an incorrect record or interpretation?
  • When will the workflow and compact be reviewed?

Sources: [1]

Separate assistance, observation, and decision use

Create three columns for every feature. Assistance describes what the system helps produce. Observation describes what activity or artifact is recorded. Decision use describes what someone may conclude or do with that evidence. The NIST Privacy Framework offers a voluntary structure for identifying and managing privacy risk, which is relevant when adoption introduces new data flows or secondary uses.

For example, an AI writing assistant may help draft a customer response. The product may retain the prompt, source references, revisions, and submitted response. A quality reviewer may use those records to discuss a specific case. That does not automatically authorize using the same trace for unrelated workforce decisions. Any new use should be named, reviewed, and communicated separately.

This separation also prevents a common trust failure: a programme presents a tool as support while silently treating activity volume as evidence of capability.

Sources: [2]

Work a synthetic trust compact

Consider a service team piloting an AI assistant on synthetic support cases. The compact states:

Now test the compact with three cases. Ask what happens if a participant never encounters the intended verification opportunity, if an event fails to save, or if a reviewer interprets a click as intent. The compact should direct the team to limit the claim or record missing evidence, not fill the gap with an assumption.

  • Purpose: practice drafting accurate responses from approved guidance.
  • Human responsibility: the participant chooses sources, verifies the draft, and owns the submitted response.
  • Evidence retained: opened documents, AI exchanges, revisions, saved sources, and the final response.
  • Access: the participant and named assessment reviewers; no line manager receives raw prompts by default.
  • Interpretation: evidence is limited to observed performance in the simulation.
  • Challenge path: the participant can flag an incorrect event record or missing opportunity before the report is finalized.
  • Review date: after the first small cohort, before any change in evidence use.

Prove the compact through operations

Run a walk-through with a participant, manager, reviewer, privacy specialist, and workflow owner. Give each person a scenario and ask them to predict access, escalation, and correction outcomes. Record every disagreement. A policy is not operationally clear when reasonable stakeholders expect different behavior.

The NIST Privacy Workforce Taxonomy distinguishes work roles and responsibilities. Use that principle to name an owner, performer, reviewer, and consulted specialist without implying they control the same decision.

Track operational trust signals rather than a single sentiment score: unanswered questions, challenged records, correction time, access exceptions, opt-out or fallback use where applicable, and differences between stated and observed practice. Pair those signals with voluntary qualitative feedback. A low question count may mean clarity, disengagement, or fear of asking.

Sources: [3]

Review changes before expanding use

Reopen the compact when the model, data access, evidence capture, reviewer group, or decision use changes. Publish a concise change note before the new behavior takes effect. Preserve the prior version so people can see what changed and why.

Two Prune provides realistic work simulations and structured evidence for human interpretation. It is not an automated employment decision system. Trustworthy adoption therefore means describing the assessment purpose accurately, limiting evidence to the stated use, handling missingness explicitly, and giving participants a practical route to question records and interpretations.

Sources

  1. 1.NIST AI Risk Management Framework · National Institute of Standards and Technology
  2. 2.NIST Privacy Framework · National Institute of Standards and Technology
  3. 3.NIST Privacy Workforce Taxonomy · National Institute of Standards and Technology