According to a YouGov poll from December 2025, just 5 percent of Americans trust AI “a lot,” while 41 percent express outright distrust. Past surveys by Pew Research have also discovered that more than half of US adults say AI’s growing presence in daily life makes them more concerned than excited, while just 10 percent feel the opposite. It’s also interesting to note that across 25 countries surveyed by Pew, the median trust level among adults in the United States to regulate AI is 37 percent, well below the European Union at 53 percent.
These numbers have not improved with increased usage of AI and more sophistication. They have gotten worse. For builders, buyers, and executives staking real budgets on AI deployments, that is the actual problem to solve because even when the technology works, it just isn’t trusted by customers, and there are often very valid reasons for that.
The Pilot Ceiling and the Production Floor
A common mistake in AI procurement is treating the pilot as the product.
Pilots showcase a system at its best: clean inputs, ideal scenarios, the ceiling of what the model can do. Production is the opposite. It is the floor, the worst-case moment, the second when a goal is being scored, the commentator’s voice cracks with excitement, the crowd is louder than ever, and an auto-translation system has to deliver in sub-second latency across forty languages. That is when the system is most likely to fail. That is also when the most people are watching. This is the P99 problem. A model that is correct 95 percent of the time fails one in twenty times. At the consumer scale, that is millions of failures a day. In aviation or healthcare, those failures are unacceptable.
Teams that only test on representative data miss the edge cases that define their reputation. Edge cases are underweighted in training data by definition. They are rare, but rarity is not the same as unimportance. The scenarios that show up once in ten thousand events are often the ones that determine whether a system survives a production incident or becomes a headline.
Confident Hallucinations Are Worse Than Honest Uncertainty
The most dangerous AI output is not a wrong answer. It is a wrong answer delivered with conviction. A user can verify uncertainty. They cannot verify the confidence they assume to be earned.
Part of the fix is at the prompt level. A simple change, such as instructing a model to report when it cannot find supporting evidence, shifts the dynamic entirely. Instead of confabulating an answer to fill the silence, the system flags its own gap. That signal is the difference between a tool that is useful and one that quietly poisons downstream decisions.
There is a structural version of this problem in confidence scoring. A system that reports 95 percent confidence on nine fields and 20 percent confidence on one, then averages those into a single overall score, will report something close to 87 percent overall. The user sees a high number. The wrong field stays hidden. A more honest design weights uncertainty inversely, so a single weak field drags the overall score down harder than a strong field can lift it. The result surfaces the system’s weakest point rather than burying it.
What Real Due Diligence Looks Like
It has never been easier to build a polished AI demo. Logos, testimonials, case studies, signed letters of recommendation, and even architectural diagrams can be produced in minutes with off-the-shelf AI tools. The signals that used to indicate substance now indicate competent prompt engineering, and not much else.
That changes what due diligence has to look like. A few practices separate the buyers who get burned from the ones who don’t.
The first is testing before paying. Ask every vendor whether you can deploy their system in your own environment for a week. If the answer requires routing your data through their SaaS, weigh that risk against what they have done to earn it. Strip a representative slice of your data of personally identifiable information and run a real workload through the system. Most failures surface in the first three days.
The second is talking to actual customers rather than reading testimonials. Two reference calls beat ten case studies. The questions to ask are operational. How long was the implementation? What broke? Where does the system still fail? What does support look like at 3 AM?
The third is probing beyond the first click. Many AI products are deep on the demo path and shallow everywhere else. The second-level features, the integrations, the error states, the recovery paths are where the gaps live. A product that handles the showcase scenario flawlessly may have nothing behind it.
We also talked about AI and ethics in this episode of Not Another AI Podcast.
The Vibe Coding Mixed Bag
The collapse in development time is real. Tools like Claude Code, OpenAI Codex, Cursor, and similar AI-assisted IDEs have made it possible to spec a working application in days that would previously have taken months. Research found that roughly 92.6 percent of developers use an AI coding assistant at least monthly.
However, research also found that 45 percent of AI-generated code samples introduced vulnerabilities classified under the OWASP Top 10. That pass rate did not improve across multiple testing cycles from 2025 through early 2026. The Vibe Security Radar at Georgia Tech’s Systems Software and Security Lab, which tracks CVEs directly attributable to AI coding tools, recorded six such vulnerabilities in January 2026, fifteen in February, and thirty-five in March. Researchers estimate the true count is 5-10 times higher because most AI tools do not leave attribution metadata in commits.
Specific incidents have made the abstraction concrete. For example, CVE-2025-55526, a directory traversal vulnerability with a CVSS score of 9.1 in n8n-workflows, was linked to AI-generated code in August 2025. The Replit autonomous coding agent deleted production databases despite an explicit code freeze instruction. Vulnerabilities in Anthropic’s MCP server, in Gemini’s CLI, and in Claude Code itself have all been disclosed.
The pattern is consistent.
Code that runs is not the same as code that is secure and trustworthy. Speed compresses the development phase but expands the testing burden. A six-week build can demand six months of testing, hardening, and refactoring before it is safe to ship. The deeper problem is that AI-generated code is opaque to the humans who shipped it. When something breaks, the instinct is to ask the model to fix it. The model touches things it was not asked to touch. New issues appear. The cycle repeats. A more durable practice is to fix the requirements document instead of the code, then regenerate the affected modules cleanly. When the spec is solid, rebuilding is faster than patching.
Narrow Agents Beat General Ones
Across production deployments, one pattern keeps proving out: agents that do one thing well are easier to trust than agents that do ten things passably. A narrow scope means predictable failure modes. Predictable failure modes are testable. Testable failure modes can be hardened. The right architecture is often a chain of focused agents passing structured outputs to one another, not a single monolithic system trying to handle the entire workflow on its own.
The trade-off is engineering overhead. Multi-agent systems require more orchestration, more contract definition between agents, more observability. The payoff is reliability at the seams, which is exactly where black-box systems fail.
The Bias Problem Is a Training Data Problem
The most public lesson in AI bias remains Google’s February 2024 Gemini image generation incident. In an attempt to correct historical underrepresentation, the model overcorrected and produced images of America’s founding fathers as people of color, Vikings as Asian women and men, and racially diverse Nazi soldiers in World War II uniforms. Google paused image generation of people for months while retraining the system. The episode became a case study in how an attempted fix can become a worse failure than the original problem.
The underlying issue has not changed. Models reflect the data they were trained on. Today’s frontier models are heavily skewed toward English-language internet text, which encodes the biases of who writes online and what they write about. No amount of post-hoc filtering eliminates that lean. The available choices are narrow: accept the bias, build artificial training data that compensates for it (which introduces its own choices about what an ideal world should look like), or layer human review at the points where bias would do the most damage.
Most enterprise buyers have not consciously chosen any of these. The default is the first one, which is also the riskiest.
Explainability Is Mostly a Story
The question of why a model produced a specific output is genuinely hard to answer. Tracing weights and activations across attention heads can show what the model attended to, not why it weighted those attentions the way it did. Cryptographic auditing can prove what the system did. It cannot prove the output was correct. Formal verification works mathematically, but only for systems far too small to be useful at the frontier scale.
What works in practice is a layered architecture where each component compensates for the failure modes of the others. Tool-calling provides traceable decision trees. Deterministic guardrails catch the worst cases. Human-in-the-loop checkpoints sit where stakes are highest.
None of this is true explainability in the mathematical sense. It is a system that behaves as though it is explainable, which is enough for most practical trust-building.
What Trust Actually Requires
Trust is not a single feature.
It is an emergent property of a system designed in defense in depth: honest uncertainty, narrow scope, observable failure modes, real testing under load, deliberate handling of bias, and humility about what cannot be explained. Confidence without those elements is theater.
For executives buying AI, the question is whether the vendor talks about the floor or the ceiling. For engineering teams building it, the question is whether the system surfaces its own weakness or hides it. For everyone else, the question is whether the people deploying these systems are willing to be uncomfortable about what they do not yet know.
That last part may be the hardest of all.