What to Say When Staff Distrust the Data Behind AI

When someone says they don't trust the data behind an AI answer, ask them to show the answer and the record they expect it to use. Agree what staff should do while the team investigates, then assign the issue and report the result. A manager earns a stronger basis for adoption by making concerns inspectable and corrections visible.

Respond to a specific concern

Begin with the case the person has seen. Ask what the assistant said, which task they were doing, and what made the result questionable. They may have found a stale stock balance, a missing amendment, or a customer count that doesn't match their report. Each concern needs a different investigation.

You can say: “Show me the answer you couldn't use and the record you compared it with. We'll check which source and definition the tool used. Until we resolve it, use the agreed existing process for this decision.” This gives the person an immediate next step and states the boundary of the investigation.

Ask how the discrepancy affects their work. A wrong description in an internal draft may need a correction before sharing. An incorrect quantity used to promise delivery may require a pause and a review of affected orders. Let the process owner decide the operating response with the technical team.

A recent analytics discussion about trusting AI in reporting asks how much manual verification teams still perform and whether plausible generated code can be subtly wrong. It captures a reader question, not a measured failure rate. Your team's response should state the checks required for its own task.

Don't assume that reluctance is a training problem. Staff may understand an exception that the implementation misses. Ask them to demonstrate it, and give them time to do so. If the concern is broader anxiety about role changes or monitoring, address that question separately through the company's actual policy and commitments.

Show the source, definition, and cutoff

Open the source record alongside the answer using the person's authorised access. Show its identifier, relevant fields, version, and update time. For a total, show the approved measure and reporting period. A link to a large folder doesn't give the reviewer enough evidence to check a specific claim.

Explain how the information reached the assistant. For example: “This stock answer reads the warehouse export completed at 06:00. It doesn't include receipts entered after that cutoff. Check the live allocation screen before confirming an order.” That explanation ties a limitation to an action staff already understand.

Make the distinction between a displayed citation and a verified claim clear. A citation can point to the wrong document version or to text that doesn't support the answer. Staff need to inspect the relevant evidence, and the evaluation should test whether the cited source actually supports the result.

Use the same display in normal work, not only in a demonstration. Put the source and cutoff where a reviewer can reach them from the answer. Test that the links work for the actual user roles. A reviewer who can see a number but can't access its permitted supporting evidence needs an escalation route.

NIST's AI RMF 1.0 discussion of trustworthiness distinguishes transparency from accuracy and describes notifying users about adverse outcomes. It supports making the evidence and limitations visible. The framework is voluntary guidance, and showing a source doesn't by itself establish that an answer is correct.

Find which part of the answer is wrong

Trace the disputed result before changing a prompt. Compare the source, its transformation, the approved definition, and the final answer. If the assistant faithfully repeats a wrong source record, a prompt edit won't repair the record that other workflows also use.

These are starting points, and a case can involve several faults. An old customer mapping may select the wrong account while a stale export omits a recent change. Keep the investigation tied to the particular answer and identify each confirmed cause.

Where definitions differ legitimately, name the intended measure rather than treating every difference as an error. Our guide to data ownership across departments shows how to approve customer, contract, order, and margin meanings. Staff need to know which approved meaning applies to the decision in front of them.

Keep unresolved findings explicit. Say: “We haven't established why these totals differ. Finance is checking the population and cutoff, and the application owner is tracing the calculation. Don't use this total for the forecast while that check is open.” Assign a follow-up time that the responsible owners can meet.

Give staff a correction path they can follow

Provide a way to flag an answer from the screen where staff encounter it. Capture the answer reference, task, and reason for concern. Keep access to the issue within the approved team. Don't ask people to paste sensitive customer or employee records into a general chat channel.

Make the route short enough to use during normal work. A staff member should be able to identify the case and explain the discrepancy without reconstructing a technical log. The support team can obtain permitted diagnostic details using that reference. Treat the reporter's time as part of the workflow cost.

State who acknowledges the issue and who decides its priority. The process owner assesses business consequences; the relevant operator investigates the faulty layer. Give staff a status they can check and an approved route for urgent cases. If nobody monitors the queue, a feedback button doesn't provide a functioning correction process.

Preserve the original result and reviewed evidence so the team can reproduce the issue. Link any source correction or application release to the investigation. Staff may correct a draft through the approved review workflow, but changing the final wording alone doesn't resolve a source error that can affect the next answer.

Allow staff to report a suspected problem without having to prove the entire root cause. The manager can say: “You don't need to work out whether this is a data or model problem. Flag the case and tell us what doesn't match your task. The support owner will trace it and tell you the outcome.”

Work through a disputed answer with the team

Consider an illustrative distributor whose assistant says an item is available for an order. A warehouse coordinator points out that the stock report includes units already reserved for another customer. The case is invented to show the conversation and investigation; it isn't a client incident or a performance benchmark.

The manager begins: “You're checking whether we can commit these units to this order. Let's compare the assistant's source with the live allocation record before anyone promises delivery.” The team pauses use of this answer for commitments and follows its existing allocation process.

The investigation finds that the assistant reports on-hand quantity from an export, while the task needs the company's approved available-to-promise calculation. Those concepts aren't interchangeable. The operations owner confirms the required calculation and where reservation and timing rules apply; the application owner tests how the assistant selects it.

The team then tests reserved stock, a partial reservation, a recent receipt, and a missing allocation update. It checks the expected results and the answer's source label. If the permitted source can't support a current commitment, the answer should direct staff to the approved allocation process instead of presenting on-hand stock as available stock.

The follow-up is specific: “The approved answer now uses the allocation calculation for this task and shows its cutoff. We've checked the reservation cases with operations. If the refresh fails, the assistant won't confirm availability; you'll use the allocation screen. Flag any case where those instructions don't match what you see.”

Keep that message within the actual release evidence. Don't claim the system handles every warehouse exception after a narrow test. Record which sites, items, and states the release covers and assign the checks needed before expanding it.

Explain when staff can use the result

Publish a short task-specific operating rule. State what the assistant can prepare, what staff must check, and what approval authorises action. A general instruction to check everything can leave the team duplicating the whole task without knowing which errors matter most.

Show an acceptable result and a result that requires escalation using authorised examples. For contract questions, that may include an approved amendment and a missing effective date. For reporting, it may include a known total and an ambiguous period. Have the relevant process owner explain what evidence makes the answer fit for use.

Measure the checks themselves. If reviewing an answer takes longer than doing the task through the current process, revisit the design and business case. Include verification and correction time in the full cost of the AI workflow. Staff shouldn't carry an uncounted review burden while the project reports gross time savings.

Give reviewers an approved way to reject or amend a proposal, with the reason recorded. Cheng and Chouldechova's 2023 CHI study comparing process and outcome control partly reproduced earlier findings on outcome control and found different effects for different controls. Its online experiments don't establish adoption outcomes in your workplace. Test whether your review mechanism helps staff make better decisions in the actual task.

Keep permission to act separate from confidence in an answer. A reviewer may agree with a suggested credit while lacking authority to issue it. Our guide to AI reading, recommending, and acting describes that boundary. Preserve the company's approval route when introducing the new interface.

Close the loop after an investigation

Report what the team found, what it changed, and what staff should do next. Where the investigation finds no error, explain the different source or definition with evidence. Invite the reporter to check the explanation against their task rather than closing the issue with an unexplained label.

For a confirmed fault, identify the affected scope and have the process owner review decisions that may have used it. A connector repair doesn't automatically correct an order already accepted or a message already sent. Record the operational follow-up separately from the technical fix.

Re-run the relevant cases and regression checks before restarting the paused use. Ask the business reviewer to inspect the repaired outcome, not just the application owner's release note. NIST's AI RMF guidance on validity and reliability connects assessment with representative testing and ongoing monitoring; it doesn't supply a universal acceptance threshold for your workflow.

Give the reporter the resolution and keep a concise record available to the affected team. Use an anonymised or access-controlled example where the underlying case contains restricted records. Include open limitations and the point of contact. That record lets the next shift follow the same operating rule.

If the team can't resolve the issue, say so and maintain the agreed fallback. A manager can say: “We can't establish a dependable current source for this task yet. We'll keep that part of the assistant paused while the source owner and delivery team work on the gap.” A bounded pause gives the company a decision it can inspect.

Measure the operating work behind trust

Track more than logins and favourable survey answers. Record confirmed error types, repeated defects, time to acknowledgement and resolution, and the staff effort needed to review outputs. Include whether the team completes the intended work correctly after the change.

Interpret reporting volume carefully. More flagged cases can reflect easier reporting or broader use; fewer reports can reflect less use or an abandoned queue. Compare the volume with workflow activity and investigate the reasons. A falling complaint count alone doesn't establish better data.

Choose a short review cadence during the pilot and name who attends when a recurring issue needs a decision. Include the process owner, the source steward, and the application operator where relevant. Use clear ownership after launch to keep the investigation route working when the project team leaves.

A PE team should budget for source repairs and local review when comparing portfolio-company AI results. A VC investor can ask to see disputed cases and their resolutions alongside an adoption claim. An SME or corporate sponsor can use the same evidence to decide whether a narrow task is ready to expand.

End the next team meeting with a concrete operating agreement: the permitted task, its evidence and checks, the correction route, and the person responsible for the next unresolved case. Staff can then judge the tool through their work and the company's response when they challenge it.