There is no shortage of AI activity inside the modern enterprise. Customer service teams have copilots. Finance has anomaly detection. HR has screening tools. Procurement has intake automation. Operations has dashboards that flag exceptions before a human ever sees the queue.

So, why hasn’t the ROI followed?

Every capable AI tool arrives with the same implicit assumption: that the organization will supply the knowledge it needs to be useful. The pricing interpretation a senior analyst applies instinctively. The way an operations lead reads a non-standard clause. The exception-handling logic teams have refined over a decade. None of that lives in a format any AI tool can read.

The result is predictable: organizations invest in the tool and underinvest in everything around it. The AI runs against generic inputs, produces generic outputs, and the team concludes that “AI isn’t ready for this.” In document-intensive workflows in particular, this plays out in a specific way: tools surface the easy fields first (dates, names, standard terms, etc.). But the judgment-heavy work (the pricing nuances, the billing exceptions, the non-standard rate structures, etc.) remains untouched, still requiring manual intervention. The tool layer cannot function without context on the proprietary knowledge layer above it.

Gartner’s 2026 survey found that only 28% of AI use cases fully meet ROI expectations, with 20% failing outright and over half delivering only partial results, leaving most organizations with no meaningful financial return.¹

IDC’s research identifies the underlying cause: 7 in 10 IT and business leaders cite fragmented data and undocumented organizational knowledge as the primary barriers to realizing AI value – not model capability, and not tool access.²

The gap is not in access to tools. It is in the translation layer between what the tool needs to know and what the organization has ever written down.

Five structural blockers prevent tacit expertise from reaching the tools designed to use it.

1. Tool-first procurement. Organizations spend months selecting between AI vendors and days (if that) on the inputs each will receive. The tool is chosen before its required context is defined. The result: the selected tool is configured against generic assumptions and evaluated against unrealistic expectations.
2. Fragmented ownership. Technology teams own the tool. Operations teams own the process. SMEs own the knowledge. Nobody owns the translation layer that connects all three. When outputs disappoint, each function points at the others.
3. Domain & AI fluency gap. The best domain experts are often furthest from prompt engineering, retrieval design, and tool configuration. Expecting billers and legal reviewers to become AI power users, in addition to doing their actual jobs, is not a deployment strategy. It is a bottleneck.
4. Tacit knowledge never codified. Decades of biller judgment, procurement interpretation, and legal reasoning exist in people’s heads. It is rarely captured in a form any AI tool can consume. Without codification, every AI-assisted review starts from scratch, with no context, no logic, and no edge cases handled.
5. Weak feedback loops. Off-the-shelf tools offer limited ability to incorporate domain-specific feedback. When they do, it is opaque: which rules were absorbed is invisible, which weren’t is unknown, and the model’s reasoning is unknowable to the people closest to the work. Garbage in, confident garbage out.Why can’t Claude just do it?Claude, or any frontier model, can reason capably once it has the right context. The constraint is feeding it that context, which requires understanding what the business actually does and how decisions actually get made. That understanding lives in people. It has to be extracted, structured, and routed before any model, however capable, can add value.Rarely does a product handle the feedback loop well enough to incorporate domain-specific learning without sacrificing transparency or control. The knowledge problem is not a model problem. It is a translation problem.

Most firms can define exactly what they want AI to fix. But to solve it, there are additional key inputs that are required beyond an off-the-shelf AI tool.

Subject-matter-expert (SME) knowledge is the starting point: the judgment and unwritten rules experts apply every day. A senior analyst doesn’t just read a document. They interpret it through years of accumulated context that no off-the-shelf tool has ever been given.

That knowledge must then be codified into artifacts, decision rules, and structured examples a model can actually ingest.

The final piece is workflow integration: where the output surfaces, who reviews it, and how results flow back into downstream systems. Without it, even well-configured AI produces outputs that sit unused.

Together, these form the translation layer – what takes a well-defined problem statement and a capable model and turns the combination into something that actually works.

The highest-leverage AI role is not “choose the right tool.” It is “build the layer the tool cannot build for itself.”

Translation is a sequence of work that most organizations have no one assigned to do. It starts with fleshing out the workflow as it actually operates and ends with a tool that improves each time a new edge case surfaces.

1. Workflow shadowing: Observe the work before documenting it. The rules that matter most live in judgment calls experts make daily without naming them.
2. Knowledge extraction: Structured interviews to surface what experts actually do when a claim is ambiguous, an exception arrives, or a term doesn’t match the standard structure.
3. Artifact codification: Translate extracted knowledge into domain artifacts, decision rules, and annotated examples a model can ingest. This is the step most builds skip entirely.
4. RACI and operating model design: Define who owns inputs, who reviews outputs, who escalates exceptions, and who updates the rules when the workflow changes. Without this, the tool degrades the moment the project team rolls off.
5. Tool-agnostic deployment: Design artifacts so the underlying model is replaceable. The knowledge encoded this year should make any future model smarter on day one.

The translation layer compounds in value every time it is applied – each workflow faster to build than the last, each solution more durable than the one before it. Organizations that develop this capability early don’t just solve one problem; they build an advantage no off-the-shelf tool can replicate.

Once an organization understands what the translation layer requires, the next question is who should be accountable for it. There are three common paths. Each carries different implications for speed, quality, and durability, and in practice they do not perform equally.

1. Operations team owns translation. The people closest to the work, such as collections, billing, and operations, understand the exceptions and can spot bad outputs immediately.

Strength: Domain knowledge is deepest here. Rules reflect how the workflow really runs, not how it looks in a process document.

Weakness: These teams are already running the business. Translation work competes with core responsibilities, so artifacts are created in bursts and then stall. Partial codification becomes the norm.

2. Technology team owns translation. Technology controls the tool budget, can make vendor decisions, and has the skills to configure models and pipelines.

Strength: The team that controls tooling and architecture can move quickly from design to deployment, without waiting on others for technical decisions.

Weakness: Technical fluency does not guarantee a detailed understanding of billing, legal, or procurement edge cases. Logic often reflects how the process is imagined to work rather than how it behaves under pressure.

3. A translation partner owns the work. A specialized partner combines structured bandwidth with a repeatable method for translation and learns the workflow in enough depth to codify it properly.

Strength: Translation is a primary responsibility, not a side task. The partner can invest the time to shadow workflows, interview SMEs, and design artifacts without being pulled back into day-to-day operations or other technology projects. This typically produces a more complete and better maintained translation layer than either internal path can sustain on its own.

Weakness: Organizational knowledge is not automatic. A partner must earn trust, ask the right questions, and validate its understanding with the people who run the work. Early progress depends on how well that knowledge transfer is set up.

A common concern with using a partner is dependency: if they design the artifacts and run the feedback loop, it can feel risky to imagine life after the engagement. That risk is real when the work is treated as a one‑off build rather than an asset that belongs to the firm. The strongest partnerships solve for this by making the translation layer transparent, documented so internal teams can maintain the artifacts long after the partner steps away.

Ultimately, the best path depends on domain complexity, internal capacity, and how quickly the organization wants to build its own muscles. In many cases, a partner-led model performs best where internal options struggle, because it pairs dedicated focus with a mandate to connect technology, SMEs, and ownership into a single, coherent translation layer.

Organizations can apply the translation layer in a range of workflows where documents, exceptions, and judgment calls slow teams down.

In legal review, a translation layer can capture how attorneys interpret ambiguous clauses, apply risk thresholds, and decide when to escalate. That knowledge becomes clause artifacts, risk rules, and annotated examples that guide an AI system to highlight true issues and draft markups that match firm practice.

In billing, translation focuses on how experts read pricing terms, map them to internal rate structures, and handle non-standard agreements. The team codifies that logic into fee mappings, clause patterns, and decision rules so the AI can extract the right fields, flag discrepancies, and feed structured outputs into existing billing workflows.

In customer service, translation work documents how front-line agents infer intent, apply policy, and recognize when an account is at risk. Those patterns are turned into intent taxonomies, policy rules, and example transcripts that help AI copilots suggest responses and actions that align with how the best agents already serve clients.

Across these settings, the underlying model can be swapped or upgraded without rebuilding the solution. What carries forward is the translation layer: the knowledge artifacts, workflow rules, and operating model that encode how the organization actually works, and that the organization itself can maintain over time.

Organizations can apply the translation layer in a range of workflows where documents, exceptions, and judgment calls slow teams down.

In legal review, a translation layer can capture how attorneys interpret ambiguous clauses, apply risk thresholds, and decide when to escalate. That knowledge becomes clause artifacts, risk rules, and annotated examples that guide an AI system to highlight true issues and draft markups that match firm practice.

In billing, translation focuses on how experts read pricing terms, map them to internal rate structures, and handle non-standard agreements. The team codifies that logic into fee mappings, clause patterns, and decision rules so the AI can extract the right fields, flag discrepancies, and feed structured outputs into existing billing workflows.

In customer service, translation work documents how front-line agents infer intent, apply policy, and recognize when an account is at risk. Those patterns are turned into intent taxonomies, policy rules, and example transcripts that help AI copilots suggest responses and actions that align with how the best agents already serve clients.

Across these settings, the underlying model can be swapped or upgraded without rebuilding the solution. What carries forward is the translation layer: the knowledge artifacts, workflow rules, and operating model that encode how the organization actually works, and that the organization itself can maintain over time.

The AI tool market is commoditizing fast. The translation layer is not.

While most organizations see efficiency gains from AI, far fewer see meaningful revenue impact, because the work of modernizing and integrating workflows has not been done.3

Organizations that codify SME knowledge and design workflows around AI output can turn every model upgrade into additional value. Those that skip that step are likely to keep running pilots that look promising in a sandbox but fail to change day-to-day work.

Where a translation partner can help:

• SME knowledge discovery & alignment: Structured interviews and workflow shadowing to surface judgment, edge cases, and unwritten rules, while aligning leadership on what “good” looks like.
• Artifact & rulebook design: Translating tacit expertise into domain artifacts, decision rules, and annotated examples that a capable AI tool can reliably ingest and use.
• Operating model & ownership: Defining RACI for inputs, outputs, review, escalation, and maintenance, supported by simple governance routines.
• Workflow, UX, & change adoption: Embedding AI output into existing workflows, shaping reviewer experiences around real tasks, and supporting training so teams trust and use the solution.