The Missing Trust Layer in Enterprise AI
Most enterprise AI conversations still start with the model. Which one is fastest, which one is the best and which one costs less per unit or even token. Those are all fair questions. They're also the wrong place to start once AI leaves the pilot and starts touching payroll runs, benefits eligibility, invoices and compliance filings.
At that point the question that matters is simpler and harder: can we trust the data the AI is working from?
The answer at most companies is "partly” and "partly" is a dangerous place to build automation. A model that summarizes, recommends or acts on bad information will be wrong with total confidence, at scale, in a format that looks finished. Yes people, AI hallucinations are real, and they even change over time. What's missing in many enterprise AI stacks is a layer whose job is to confirm the information is right before anything downstream uses it. Think of it as a trust layer, and most organizations haven't built one yet.
AI Accuracy is a Data Problem First
A Large Language Model (LLM) knows businesses only through what they are handed: the employee record, the rate table, the contract, the ticket history. If the record says an employee is in Ohio and they moved to Pennsylvania in March, the model will calculate Ohio withholding and explain its reasoning clearly. The reasoning will be sound, but the answer will be wrong.
That's why so many AI accuracy problems get misdiagnosed. Teams see a bad output, blame the model and start tuning prompts or swapping vendors. Sometimes that helps, but more often the model did exactly what it was asked with the inputs it was given, and the fault sits upstream in a field nobody has checked in two years, or bothered to monitor it regularly.
Did anyone clearly define the output first before even trying to get it?
The research points the same way. In a July 2024 Gartner survey of 1,203 data management leaders, 63% said their organizations either lack the right data management practices for AI or aren't sure whether they have them. Gartner also predicted that through 2026, organizations would abandon 60% of AI projects that aren't supported by AI-ready data. The window is closing, and the pattern continues to show up in the operations work seen each week.
Where the Data Goes Wrong
Few enterprises have one source of truth, sometimes there are multiple versions.
Take a mid-size employer. The HRIS holds job titles and start dates. Payroll holds pay rates and tax setup. The benefits platform holds enrollment. Time and attendance lives somewhere else, and a spreadsheet on someone's desktop fills the gaps between them all. Each system was accurate when it was set up. Each has drifted since, through manual edits, one-off imports, acquisitions and integrations that sync some fields and quietly skip others.
So when an agent pulls from three systems to answer "Is this employee eligible for the new plan?", it may get three different answers and pick one. It may merge them into something that exists in none of the systems. Or it may take whichever source it queried first. These issues may be harder to spot in demos that use clean sample data rather than the inconsistent records companies work with every day.
Remember, AI makes decisions, but it may not be honest about how; instead, it may rewrite history and justify it in another way that may not be the truth.
It is clearly one thing to ask for an output that is a decision, but teams should exercise caution when they workflow that data to a next step or an action.
What Changes When AI Scales
Bad data has always existed. Historically, humans have served as the filter. A person processing 40 records a day is likely to notice when an employment tax is off by a decimal place or a termination date comes before a hire date. They pause, question it and seek clarification.
Automation removes that pause. An AI workflow processing 40,000 records a day can apply the same error 40,000 times before anyone has an opportunity to review the output. That creates three distinct risks.
The first is compounding errors. A real-world example is the State Unemployment Tax. Some systems allow down to four decimal places and some to two; allow those calculations to occur in bulk and after 40,000 teams may have themselves a material error in the making.
Second, errors can appear authoritative. AI-generated output is typically fluent, organized and easy to read. A reviewer scanning a polished summary may be less inclined to question it than a visibly messy spreadsheet.
The third is that accountability becomes harder to establish. When a regulator, auditor or employee asks why a decision was made, “the model said so” is not sufficient. Organizations need records that show what information was used to reach a decision, whether it was current and how it was verified.
Do companies have a log of the decisions made by AI? Probably not.
That issue is particularly important in regulated work such as payroll, benefits administration and claims, where traceability may be required by regulation or contract. An AI program that cannot show its inputs may stall during a compliance review, regardless of how capable the underlying model is.
Check the Data Before the AI Sees It
The usual solution is a data cleanup project. While these projects can help, their benefits can also diminish over time. Six months after the cleanup, new errors may have crept back in through the same manual edits and partial syncs that caused the initial issues.
A more durable approach treats verification as part of the workflow itself. Before any record reaches an AI system, it should be checked. In practice, that check has four parts. Check and check again.
The process starts by reconciling across sources. When payroll and the HRIS disagree on a pay rate, flag the conflict instead of letting the agent guess. The next step is validating against rules. A hire date after a termination date, a Social Security number in the wrong format and a pay rate outside the band for the role are all inexpensive issues to catch with straightforward logic.
Humans should be watching workers and agents not only to monitor, but to improve. Freshness matters too. Teams should know when each field was last updated and by which system, because a two-year-old address deserves less trust than one confirmed last week.
Finally, route exceptions to people. Verification will surface records it cannot resolve, and those should go to someone with the context to decide. Log that decision so the same conflict doesn't resurface the following month.
None of this is glamorous. Most of it consists of work operations teams already handle by hand. The difference is doing it systematically, at the point where data enters an AI workflow, and maintaining a record of what was checked.
What a Trust Layer Looks Like
A trust layer sits between a company’s systems of record and its AI workflows. It does not replace either one. Its job is to take in data from multiple sources, confirm what is accurate, flag what is not and pass along only information it can verify, with a record of how it got there.
For companies scoping a trust layer, there are six questions that provide a practical starting point.
First, which decisions carry the most risk if the data is wrong? Payroll, eligibility and anything filed with a regulator should take priority over internal reporting.
Second, which systems feed those decisions, and where do they disagree today? Operations staff can usually answer this quickly, since they have often been working around these conflicts for years.
Third, what does “verified” mean for each field? It might mean agreement across two sources, a rule check or human sign-off above a certain dollar threshold.
Fourth, where do exceptions go, and who owns them? A verification step without an owner can quickly become a queue nobody clears.
Fifth, can the organization show its work? For any AI-driven output, teams should be able to trace it back to the source records, their timestamps and the checks they passed.
Finally, what is the legal liability and do companies’ cyber policies, assuming they have one, have a rider to exclude AI? Companies are taking great risk with sensitive information; are they covered if it goes wrong?
One practical consideration is to build the layer once and share it across use cases. Companies that add validation separately to each AI project can end up with five slightly different definitions of a correct employee record, recreating the very problem they set out to solve. Multiple agents or the combined term of workers is best; never rely on one.
Where to Start
The models will continue to improve. What will not improve on its own is the condition of the records those models read, and every month an organization runs AI on unverified data, it builds more decisions on top of that risk.
John Sansoucie serves as the Chairman and CEO of CogNet, a top business process management solutions company. In 2004, Sansoucie established CogNet, drawing on his 27 years of experience in TPA, HRO and PEO. He has implemented and set up four global service operations and began actively managing human resource businesses in the India market in 2004. Prior to founding CogNet, Sansoucie served in several senior executive positions at leading HR outsourcing firms, including CFO at US Personnel, VP of Finance and Product Management at Advantec and Group Controller for a division of Dun & Bradstreet. Sansoucie graduated from the University of Missouri with a degree in Finance. He also has an MBA from the University of South Florida.
