Every enterprise AI risk register I've reviewed this year covers roughly the same 6 items. Hallucination, data leakage, bias, vendor lock-in, regulatory exposure, cost overrun. All real, all worth tracking, and all sharing one property that makes them the easy half of the problem. They announce themselves.
AI risk management, as it's currently practiced, is built around failures that are loud. Something breaks, somebody complains, an alert fires, and a number moves. The expensive risks don't work that way. They fail quietly, produce no error, trigger no alert, and never reach a post-incident review because no incident was ever declared. The system keeps running and the dashboards stay green while the damage compounds over quarters, ultimately until someone asks a question nobody can answer.
To give you a reasonable head start before they cost you anything, here are 5 risks that often go hidden and what to do about them.
Why does AI risk management miss the quiet failures
AI risk registers are inherited from software risk, and software risk assumes deterministic failure. A service is up or down. A job succeeds or throws. A permission check passes or denies. Detection is cheap because failure is discrete and self-reporting.
AI systems degrade continuously and keep producing well-formed output the whole way down. A retrieval system that's lost half its index still answers. A classifier that's drifted 12 points still classifies. Fluency in the output isn’t correlated with correctness. So the usual signal of somebody noticing that something looks wrong, either arrives late or never arrives at all.
Stanford's 2026 AI Index measured hallucination rates across 26 leading models and found a range from 22% to 94% depending on the model and the task. The ceiling isn't the interesting number. The floor is. Even a strong model produces wrong answers often enough to matter. And it produces them in exactly the same register as the right ones. Detection has to be engineered deliberately. It won't emerge from users complaining.
What happens when accuracy decays and nothing throws an error
Every production AI system has an accuracy curve, and almost nobody measures theirs after launch because the mechanism is mundane. Source documents change format. A team renames fields in the system of record. The retrieval index falls behind because a nightly job started failing silently a few months ago. Or maybe somebody swaps the embedding model without treating it as a schema change. None of these produce an error. They produce slightly worse answers, and slightly worse compounds.
What makes it invisible is the absence of ground truth in production. During evaluation you know the right answer, which is why quality looks fine in testing. In production nobody knows the right answer, which is the whole reason the system got deployed. So the only feedback channel is user complaint, and users stop complaining about a tool they've quietly stopped trusting. Adoption decay is usually the first observable symptom of accuracy decay, and by the time it shows up in usage metrics you've lost two quarters.
The fix is a standing evaluation set that runs on a schedule against production configuration, refreshed quarterly, with results tracked as a time series rather than a pass/fail gate. Treat a four-point drop the way you'd treat a latency regression. Most of it traces upstream to data quality, which is how bad data fuels AI errors and erodes trust long before anyone thinks to blame the model.
Whose permissions is your AI agent actually using
Ask your team which identity the retrieval layer authenticates as. The answer is often a service account provisioned during the pilot with read access to everything, because scoping it properly would have delayed the demo by a few weeks.
That account now sits between your users and your document stores, and it collapses your entitlement model. A user who can't open the compensation folder can ask a question whose answer is derived from it. No access control got bypassed in any way a log would record. The agent held the permission. The audit trail shows a legitimate read by an authorized service.
IBM's 2025 breach research found that 97% of organizations reporting an AI-related security incident lacked proper AI access controls, which is close enough to all of them that it stops being a tail risk. The scary part is that permissions is the branch that's already true in most enterprises before anyone builds an agent.
For that reason, OWASP moved excessive agency from 6th to 3rd in the LLM Top 10 released this month, and split it into excessive functionality, excessive permissions, and excessive autonomy.
The correct design enforces the requesting user's entitlements at query time rather than at index time, and re-checks them per retrieval instead of trusting a permission snapshot taken at ingestion. That's a harder architecture and it's the one that survives a security review. More on secure AI deployment and on why context rather than prompts defines agent behavior at scale.
What if the process you automated was a workaround
This one has no technical signature whatsoever, which is why it never reaches a risk register. Somebody maps a process for automation. They interview the team, watch the work, document the steps, and build an agent that reproduces it faithfully. The agent works. Throughput improves. Everybody signs off.
What nobody asked is why step four exists. Step four is a manual reconciliation somebody invented because two systems disagreed, and fixing them properly needed a budget request that never got approved. The workaround was tribal knowledge, held loosely by a handful of people who all understood it was a patch. Now it's code. It runs 900 times a day, it's documented as the process, and the 5 people who knew it was a hack have moved on.
You've made a temporary fix permanent and load-bearing, and you've removed the human judgment that used to catch the cases where the workaround produced a wrong result. Automation didn't create that risk. It deleted the last thing compensating for it.
The tell is usually in the interview. When you ask why a step exists and the answer starts with a date, a person's name, or the phrase "we've always," you're looking at process debt rather than process design. Nobody documents a workaround as a workaround. It gets written up as the procedure once the person who invented it stops working there.
The diagnostic is to ask, for every step you're about to encode, whether a competent designer starting today would build it this way. If the answer is no, understand why it's there before automating it. Skipping that step is a reliable way to end up with a pilot that worked and a rollout that didn't.
Why does the exception queue get more expensive after automation
Automation reporting looks at what got handled. The cost lives in what didn't. A document processing deployment moves from fully manual to 80% automated. The business case counts that 80% at near-zero marginal cost, and it's right about that part. What it misses is that the remaining 20% is no longer a random sample.
Automation takes the clean, structured, well-behaved cases first. The residue is the structurally hard material, and it now arrives at a human team that's lost the routine work which used to keep it calibrated.
Per-case handling time on the exception path rises. It rises further because the reviewer now starts from a machine-generated draft they have to verify rather than compose, which is a different and frequently slower cognitive task. Meanwhile the team shrank because the business case said it could.
The second-order effect is worse. Exception handlers who spend all day on hard cases burn out faster and leave, taking the judgment that made them good at it. Replacing them is harder because the training ground you used to develop that judgment was the routine work you just automated away. Two years in, the exception path is staffed by people who never saw the easy version of the job.
The number to instrument before go-live is cost per exception, not deflection rate. Track it monthly. If deflection climbs while cost per exception climbs faster, your total cost curve is heading the wrong way and your dashboard is reporting success. This is the most common shape of enterprise AI value leakage we see in year two, and it compounds when agent sprawl puts four teams on four versions of the same workflow.
Can you reproduce a decision the system made last quarter
Some fraction of your AI-influenced decisions will eventually be disputed. A customer challenges an outcome, a regulator samples a file, or an opposing counsel asks how a determination got reached.
At that point you need to re-derive one specific decision from one specific moment. That requires the model version, the prompt and configuration in force, the retrieved context, and the state of the index, all as they were, all linked.
Most deployments retain the prompt and the completion. Neither is sufficient because the answer depended on documents that have since been updated, and a model version the vendor has since deprecated.
Teams assume they have this covered because they kept the conversation log. A conversation log tells you what was said. It doesn't tell you what the system knew when it said it, which is what actually gets asked in a dispute.
Changes on the vendor side is the part teams underestimate. Hosted model versions get retired on the provider's schedule, not yours. If your evidence depends on re-running inference against the exact version that produced a decision 18 months ago, your evidence has an expiry date you don't control.
The alternative is capturing the output and its full context at the time, rather than planning to regenerate it later. That's the difference between AI auditability as a property of your records versus a hope about somebody else's roadmap.
How do you get these onto the risk register
None of the 5 will surface from an incident review, because none of them generate incidents. Each has to be instrumented deliberately and each has a metric that makes it visible. This is the point where AI risk management stops being a quarterly document and starts being a set of dashboards somebody owns.
- Track evaluation-set accuracy as a monthly time series against production configuration.
- Track the identity and entitlement scope of every retrieval path.
- Track which automated steps were workarounds at the moment they were mapped.
- Track cost per exception alongside deflection rate.
- Track whether a decision from 3 months ago can be reconstructed on demand, and test that the way you'd test a backup restore.
The last discipline is the one to adopt first. Grant Thornton's 2026 survey of roughly 950 senior executives found that while nearly 75% of organizations are piloting, scaling, or running autonomous AI, only about 1 in 5 has tested a response plan for AI failure. The distance between having a plan and having tested one is exactly where quiet risk lives.
Good AI risk management isn't a longer register. It's a shorter list of things you actually measure, chosen specifically because they'd otherwise stay invisible. Uncontrolled AI is a business risk, and control starts with instrumentation rather than policy. The same logic applies to shadow AI and tool sprawl, where the systems you can't see are the ones setting your exposure.
.svg)