AI Cannot Ignore Ambiguity
What humans can leave implicit in the work has to become accessible to the system.
Definition
Organizational ambiguity exists when the information available to perform work does not fully specify how a decision should be made, which information should govern, or what should happen under particular conditions.
Human workers can often navigate that ambiguity using accumulated organizational context that was never formally specified. AI cannot rely on the same persistent, tacit knowledge unless the relevant information is represented somewhere accessible to the system.
Accessible does not mean exhaustively documented. Relevant context may be supplied through instructions, retrieval, examples, system state, tools, encoded policy, or other mechanisms.
What humans can leave implicit in the work has to become accessible to the system.
Mechanism
The interesting mechanism isn't merely: AI lacks context → give AI context. It's that the apparent task can remain unchanged while the informational conditions under which it is performed have changed.
Apparent equivalence. AI is assigned work previously performed by a person, often using ostensibly the same instructions or artifacts.
Context asymmetry. The human's actual informational environment was larger than those instructions or artifacts. Experience, precedent, corrections, relationships, and situational knowledge participated in the outcome even though they weren't represented in the formal task.
Evaluation mismatch. The AI produces from the context it can access. Humans may then evaluate the result using additional context that was not available during production. That difference becomes visible only when someone says, effectively, "That's not how we do it here."
The response is not necessarily "write better instructions." The missing context might need to become available through retrieval, examples, state, policy, tooling, escalation, or some combination.
Organizations can give AI the same task without giving it the same context.
Observable indicators
The pattern becomes visible when people repeatedly evaluate AI-generated work using context that was not available to the system when the work was produced.
- Corrections introduce information the system never had. Reviewers can explain why an output is wrong or inappropriate only by adding precedent, history, situational context, or other information that was absent from the system's available context.
- "Technically correct" outputs still fail organizational expectations. The output satisfies the explicit instruction or documented rule, but experienced workers reject it because additional context changes what the correct outcome should be.
- Exceptions appear during review rather than production. People repeatedly invoke rules such as "we normally do X, except when…" only after seeing an output that followed the stated rule.
- Different reviewers supply different missing context. The same output is evaluated differently depending on which person reviews it, because each person brings different experience, precedent, relationships, or institutional knowledge to the decision.
- Improvement depends on transferring context, not improving task execution. The AI can perform the stated task competently, but acceptable results require supplying examples, precedent, source authority, decision boundaries, or other context that experienced workers were already using.
No single correction demonstrates that relevant organizational context was unavailable to the system. People make mistakes, requirements change, and AI systems can fail for ordinary technical reasons. The stronger signal is recurrence: the same kinds of human corrections repeatedly depend on information that was not available when the output was produced.
Applications
Customer support
A support agent and an AI support system may receive the same apparent task: resolve a customer issue or determine whether it should be escalated. The experienced agent may recognize signals that are not part of the formal routing logic: a pattern of previous contacts that suggests the stated issue is not the real problem, a combination of otherwise ordinary symptoms that has historically preceded a serious failure, or a customer interaction that warrants escalation even though no individual rule has been triggered. If those patterns are unavailable to the AI system, following the documented workflow more consistently does not necessarily produce the same decision. The revealing correction is not "you applied the policy incorrectly." It is: "Nothing here technically requires escalation, but this is the kind of case we escalate."
Software delivery
An engineer and an AI coding agent may receive the same requirement and work in the same repository. The engineer, however, may know why an apparently reusable pattern was abandoned six months ago, which architectural convention takes precedence when two conflict, or which technically valid implementation will create problems for another team. If that history or precedent is unavailable to the AI, producing better code against the information it does have does not necessarily close the gap. The revealing correction is not "the code is bad." It is: "That would normally be right, but not here."
Procurement and vendor approval
A procurement specialist and an AI-enabled workflow may appear to be applying the same vendor requirements, risk criteria, and approval process. The specialist may also know that a particular contractual term has previously been accepted under certain conditions, that one risk criterion is treated differently for strategic vendors, or that an apparent exception requires approval from a specific stakeholder because of prior decisions. None of that necessarily appears in the formal approval criteria. An AI system can therefore apply the documented process consistently and still produce a recommendation that experienced reviewers reject using precedent or organizational context the system could not access.
Across all three cases, the task did not necessarily change. The available context did.
What this framework is not
This is not an argument that organizations need to document everything before AI can perform useful work. AI systems can infer from available context, retrieve information, use examples and tools, maintain state, and operate successfully without every decision being reduced to an explicit rule. The relevant question is whether the context that matters to an outcome is available somewhere the system can use it.
It is also not an argument that tacit knowledge is inherently a problem. Human organizations rely on experience, relationships, precedent, situational judgment, and other forms of knowledge that would be impractical or undesirable to formalize completely.
Nor does making tacit knowledge accessible necessarily mean discovering and encoding a single correct organizational answer. Different people may be resolving the same ambiguity differently. Precedents may conflict. Exceptions may be negotiated rather than settled. Before an organization can represent what should govern, it may first have to discover that its own practice is inconsistent.
Finally, this is not simply a model-capability problem. More capable AI may infer more from incomplete context. But greater inference capability does not make unavailable organizational knowledge available. A system cannot reliably use a precedent, exception, relationship, or decision rule it has no way to access.
The problem is not that AI needs everything made explicit. It is that organizations cannot assume the context humans use is automatically available to AI.
Related frameworks
AI Costs Are Often Ambiguity Costs
AI Cannot Ignore Ambiguity establishes the upstream structural condition: human workers may rely on organizational context that is not automatically available when AI participates in the same work. AI Costs Are Often Ambiguity Costs examines one downstream consequence. When making that context accessible requires additional retrieval, validation, exceptions, escalation, or rework, some of the resulting operational cost may become an economic trace of unresolved ambiguity.
The Proxy Was the System
Proxy Was the System examines what happens when an observable measure or behavior has been standing in for an underlying function that was never explicitly represented. The frameworks intersect when people can interpret a proxy correctly because they understand what it was intended to represent, while an AI-enabled workflow has access only to the proxy itself. AI Cannot Ignore Ambiguity exposes the missing contextual relationship; Proxy Was the System asks whether the proxy was ever an adequate representation of the function in the first place.
Practical use
When AI-generated work appears reasonable but experienced people repeatedly change or reject it, do not begin by assuming either that the model performed poorly or that the instructions simply need more detail. Start by reconstructing the informational conditions under which the output was produced and evaluated.
- What did the system have access to? Identify the instructions, sources, examples, state, tools, history, and other context available when the output was produced.
- What did the reviewer use to reach a different conclusion? What precedent, exception, relationship, prior decision, situational cue, or accumulated experience changed the judgment?
- Was that context available to the system? If the correction depends on information the system could not access, improving execution against the same available context may not resolve the discrepancy.
- Is there actually a shared organizational answer? Would experienced people use the same missing context and reach the same conclusion, or does the disagreement reveal inconsistent practice, competing precedents, or an unresolved decision?
- What, if anything, should become accessible? Determine whether the relevant context belongs in instructions, retrieval, examples, state, policy, tooling, escalation, or another part of the system of work.
The goal is not to reproduce everything an experienced person knows. It is to identify which context actually changes the outcome, determine whether the organization itself agrees about what should govern, and make deliberate choices about what the system needs access to.