I Don't Want to Read What Your AI Didn't Write: The Trust Deficit in AI Tools

You verify AI-generated internal documents and code the same way you verify anything else you didn't personally do: by checking the underlying claims against a system of record, not by trusting how confident or polished the output sounds. For documents, that means provenance metadata, disclosure norms, and cross-checking facts against primary sources. For code, it means re-running tests instead of trusting reported results, checking dependencies against the actual package registry, and requiring a negative control that proves the new tests would have failed on the old code. Neither problem is solved by asking the AI to grade itself, and neither is solved by a detector.

The question everyone is quietly asking

You open a document, a pull request, or a Slack message and a small, specific question forms before you've finished the first paragraph: did a person write this, or did an agent, and did anyone actually check it? A few years ago that question would have felt paranoid. Now it's just due diligence.

The honest answer is that you often can't tell, and neither can the person who sent it. In a controlled test of workplace messages, 48% of employees picked the human-written message wrong when asked to identify which of two was AI-generated, and 74% of them were confident in the wrong answer.¹ Confidence and correctness have quietly decoupled. That's the real starting condition for anyone trying to verify AI-generated internal documents and code: your gut is not a verification method, it's a coin flip with extra swagger.

The trust deficit is measurable, not just a vibe

This isn't a mood. It shows up in survey data at a scale that's hard to wave away. A KPMG and University of Melbourne study of more than 48,000 people across 47 countries found that 57% of employees admit to hiding their AI use and presenting AI-generated work as their own.² The same study found 66% of employees rely on AI output without evaluating its accuracy, and 56% report having made mistakes in their work because of AI.² Only 40% of workplaces have a policy governing generative AI use at all.²

That combination is the whole problem in three numbers:

• Most people don't check the AI's work.
• More than half have already been burned by not checking it.
• Most organizations still have no formal rule about disclosure.

The Wall Street Journal's Tessa West has documented the interpersonal fallout of this: colleagues increasingly can't tell who is using AI, don't believe denials when they ask, and judge suspected AI use harshly, all while hiding their own use in the same breath. Trust isn't eroding because AI makes mistakes. It's eroding because nobody has agreed on who has to vouch for what.

Workslop: when polish substitutes for substance

The clearest evidence that fluency is a bad verification heuristic is a term researchers at BetterUp Labs and Stanford now call workslop: AI-generated work that looks finished but lacks the substance to actually move a task forward. In a study of 1,150 U.S. full-time employees, 40% said they'd received workslop in the past month.³ It doesn't save time. It transfers the cognitive burden from the person who generated it to the person who has to figure out what's actually wrong with it. Each incident costs nearly two hours to resolve and averages $186 per employee per month, which scales to more than $9 million a year in lost productivity at a 10,000-person company.³ And 42% of people who received workslop said it made them see the sender as less trustworthy afterward.³

That last number is the one worth sitting with. Workslop doesn't just waste time. It burns the actual asset, trust between coworkers, that lets teams move fast in the first place. If "it reads well" is your verification bar, you are already inside the failure mode workslop describes.

Code has the same problem, with sharper teeth

Engineering teams like to believe code is more rigorous than prose because it either runs or it doesn't. The data says otherwise. AI now generates 42% of all code committed by developers surveyed by Sonar, a share expected to hit 65% by 2027.⁴ Yet 96% of those same developers say they don't fully trust AI-generated code to be functionally correct, and only 48% say they always verify it before committing.⁴ AWS CTO Werner Vogels has a name for the gap between those two numbers: verification debt.⁴

The supply-chain version of this is worse than a bad Slack message. A USENIX Security 2025 study generated 2.23 million code samples across 16 models and found that 19.7% contained at least one hallucinated, nonexistent software package name, with open-source models hallucinating packages at 21.7% versus 5.2% for commercial models.⁵ Worse, 43% of those hallucinated package names reappear every time you rerun the identical prompt, which means an attacker can predict exactly which fake package name a popular model will suggest, register it in advance, and load it with malware before anyone else gets there. Security researchers call this slopsquatting, and real instances have already racked up tens of thousands of downloads.⁵ That's not a code-quality problem. It's a supply-chain attack surface built entirely out of your own tooling's confidence. This is the same failure surface covered in Securing the Code Your AI Wrote: fast code generation without a governance layer isn't a productivity win, it's deferred risk.

Why 'ask the AI' and 'run a detector' don't work

The two most common shortcuts people reach for are both dead ends.

• AI text detectors are unreliable. Multiple studies have found detection tools are neither accurate nor consistent, producing high rates of both false positives and false negatives; one Washington Post study found a false-positive rate as high as 50% against a tool that had claimed under 1%.⁶ A tool that flags human writing as machine-made half the time is not a verification layer, it's a coin with a different bias.
• Domain-specific AI tools that market themselves as hallucination-free still hallucinate. Stanford HAI and RegLab tested legal research tools built specifically to ground answers in real case law. Lexis+ AI and Practical Law AI got things wrong more than 17% of the time, and Westlaw's AI-Assisted Research hallucinated more than 34% of the time.⁷ If a purpose-built, retrieval-grounded legal tool still fails one time in five or worse, a general-purpose chatbot checking its own homework is not a real answer either.

The pattern here matters: you cannot outsource verification to another model, however specialized, because the failure mode you're trying to catch, confident wrongness, is the same failure mode the checking tool is prone to.

How do you verify AI-generated internal documents?

Verification has to happen at the level of claims and provenance, not tone. That looks like:

1. Provenance metadata, not vibes. Content Credentials built on the C2PA standard, backed by Adobe, Microsoft, OpenAI, Google, Meta, Amazon, and more than 500 other companies, attach cryptographically signed metadata recording a file's AI-generation origin and edit history. It's a technical foundation for provenance, though OpenAI itself is clear that these signals confirm origin, not accuracy.
2. Disclosure norms with teeth. Only 40% of organizations currently have any policy on generative AI use.² A norm that requires people to flag AI involvement isn't bureaucratic overhead, it's the only thing that closes the 57% gap of people quietly passing AI work off as their own.²
3. Source-checking every load-bearing claim. Any number, quote, or factual assertion in an AI-assisted document should trace back to a primary system, a database, a filing, a transcript, not to the model's own paraphrase of it. The document doesn't get credit for citing a source; it gets credit for the source actually saying that.
4. Treating fluency as a red flag, not reassurance. The smoother and more confident the writing, the more scrutiny it should get, not less. That's the opposite of how most of us read, which is exactly why 48% of people misjudge AI authorship and are confident doing it.¹

None of this requires distrusting your colleagues. It requires distrusting the artifact until it's earned belief through a check you can point to.

How do you verify AI-generated code before it ships?

Code has the advantage that verification can be procedural and automatic, which makes the current 48% always-verify rate look even worse.⁴ A rigorous check runs on evidence the agent doesn't control:

1. Never trust a claimed test result. An agent's report that all tests pass is a claim, not evidence. Re-execute the suite yourself.
2. Run a negative control. Take the agent's new tests and run them against the pre-change code. They should fail. If they pass against the old, broken code too, the tests aren't testing anything, they're theater.
3. Mutation-test the diff. A green suite on unchanged logic proves nothing about the lines that actually changed. Mutation testing on the diff catches tests that were written to pass rather than to catch bugs.
4. Verify every AI-suggested dependency against the real registry. Given that 19.7% of AI-generated code samples reference at least one hallucinated package, and nearly half of those names are predictable and reusable by attackers, no new dependency should be added without confirming it exists, is maintained, and matches the intended library.⁵
5. Require human sign-off for any agent with install or package permissions. The agents most capable of introducing supply-chain risk are exactly the ones that should have the least autonomy to pull in new code without a person in the loop.

This is more work, not less. Engineers report that reviewing AI-generated code often takes more effort than reviewing a colleague's, precisely because nobody on the team wrote it and nobody fully understands it by default.⁸ That's the cognitive debt version of the same verification debt Vogels describes.⁴ It's also the exact failure mode that shows up later as an incident nobody can diagnose quickly, the subject of The Knowledge Cliff: the outage isn't the real risk, the absence of anyone who understands the system well enough to fix it fast is.

The shadow AI economy makes this everyone's problem

Even a perfect internal verification policy runs into a wall: most AI use at work is already happening outside official channels. MIT's Project NANDA found that employees at more than 90% of companies use personal AI chatbot accounts for work tasks, while only 40% of companies have an official, sanctioned LLM subscription.⁹ That gap means most AI-assisted documents and code are being produced entirely outside whatever provenance or review infrastructure IT thinks it has built.

Sixty-two percent of employees say AI has been significantly overhyped, and 86% aren't confident in the accuracy and reliability of AI tools at work, yet they keep using them for exactly the tasks they're least sure about.¹⁰ That contradiction, distrust plus continued use, is why verification can't live only in IT's hands. It has to be a skill every employee practices, the same way the Accidental Engineers piece on this blog describes prompts and saved memories quietly becoming unowned business logic, and the same way Shadow AI Governance argues that employee-built tools need to be treated like production software rather than personal experiments.

Ownership, not detection, is the real fix

Strip away the specific numbers and the trust deficit is really an accountability gap. When a document or a pull request has no clear author, no disclosed AI involvement, and no verification trail, the organization has quietly agreed to run on content nobody can fully vouch for. That's not a tooling failure. It's an ownership failure.

Provenance metadata, disclosure norms, negative controls, dependency checks, human sign-off gates: none of these are exotic. They're the same discipline organizations already apply to financial statements and production deployments, applied to a new category of output. The point isn't to catch AI in the act. It's to build a chain of custody solid enough that a human can stand behind the result, whether or not they typed every word or line themselves.

That discipline is also what separates owning your AI-augmented workflow from renting blind trust in whatever a vendor's model happens to output that day. Teams building their own verification layer around agents, rather than platforms like Remy that treat provenance and review as first-class parts of the workflow rather than an afterthought, are the ones who will be able to answer the question that started this piece with something better than a shrug: yes, a human checked this, and here's how.