Author: estebanf

Many companies are not building AI automation capabilities. They are rebuilding the same hidden machine in different departments.

Finance funds an invoice automation project. Legal buys contract AI. Product teams add a research synthesis tool. Compliance experiments with policy review. Each team writes a separate business case, evaluates separate vendors, defines separate workflows, and argues that its use case is special. On the surface, they are right. An invoice is not a contract. A customer interview is not a compliance filing. A missed payment discount does not carry the same risk as a bad legal interpretation.

But underneath, many of these projects converge on the same operating model: capture unstructured inputs, extract the facts that matter, classify them against a business taxonomy, validate uncertain outputs, and route the result into the systems where work happens. This matters now because scattered AI tools do more than duplicate spend. They create governance debt. Every isolated workflow adds its own review logic, audit trail, exception handling, vendor dependency, and learning loop. The longer each team treats its project as unique, the harder it becomes to scale AI without multiplying risk.

The answer is to identify the hidden machine, reuse the parts that genuinely repeat, and protect the domain-specific edge where expertise, risk, and judgment still matter. You do not have to pretend every workflow is the same to recognize that most of them share a core.

Three teams, one hidden machine

Picture three teams working in different parts of the company.

The finance team wants to process supplier invoices faster. Invoices arrive by email, portal, scan, and EDI. The system reads vendor names, purchase orders, line items, tax, and totals. Then it checks the invoice against purchase orders and receipts, flags duplicates, sends exceptions to review, and routes approved invoices into ERP for posting and payment.

The legal team wants to review contracts faster. Contracts enter from a repository or sales workflow. The system extracts clauses, obligations, dates, entities, and risk markers. It classifies contract type and risk level, checks deviations against the legal playbook, escalates exceptions, and routes the output into approvals, obligation tracking, renewal alerts, or CLM updates.

The product team wants to synthesize customer interviews and feedback. The inputs are transcripts, support tickets, surveys, call notes, and product reviews. The system extracts themes, quotes, pain points, requests, and sentiment. It classifies them by taxonomy, persona, journey stage, or urgency. Researchers validate the interpretation and source traceability. The output flows into backlogs, insight repositories, roadmap inputs, and stakeholder reports.

These teams think they are solving different problems. They are also building the same machine under different names. This does not make the domains interchangeable. Legal review needs legal playbooks. Finance needs matching rules and approval thresholds. Research needs source traceability and interpretive review. But the underlying operating model repeats often enough that treating each project as a blank-page build slows learning and scatters control.

The market is showing the pattern, not proving the platform

The shift is visible in how vendors and analysts describe the category. Gartner’s 2025 work on intelligent document processing frames the market around a pipeline that ingests content, extracts information, classifies it, and connects it to downstream systems. ABBYY and Camunda describe a similar split: document AI handles classification, extraction, validation, and human review, while process orchestration routes work forward. Hyperscience invoice examples follow the same pattern: classify, extract, validate, and feed structured data into financial systems.

The same logic is spreading beyond classic document processing. Customer feedback platforms ingest comments from many sources, structure them into product or customer themes, classify urgency or risk, and route alerts to teams. IBM’s Tokio Marine case shows customer feedback from calls and other channels being captured and classified into industry codes, with human approval reducing review time. Compliance monitoring examples apply a similar pattern to policies, filings, expense reports, contracts, obligations, risk categories, expert review, and remediation workflows.

These examples do not prove that every company should build one cross-domain platform. They show something narrower: the workflow grammar is repeating. Capture, extract, classify, validate, route. The pattern appears in enough places that leaders should stop evaluating each automation request as if it came from a different species of work.

Many AI workflows do not fit this pattern. Conversational agents, creative work, negotiation, strategy, and highly judgment-intensive decisions do not reduce neatly to a linear pipeline. But a large class of unstructured knowledge-work automation does converge on a shared architecture. Companies that see that pattern can stop buying the same capability in fragments.

The mistake is treating the domain as the architecture

A domain changes the rules of the workflow. It does not always require a new architecture.

An invoice project needs invoice schemas, PO matching, duplicate detection, tax logic, approval thresholds, and ERP integration. A contract project needs clause definitions, fallback positions, obligation models, legal playbooks, jurisdiction rules, attorney review, and CLM integration. A research synthesis project needs taxonomy design, quote verification, respondent context, bias checks, and links back to source material. Those are real differences.

But many of those differences live in configuration, validation, governance, and adoption. The reusable core is usually more basic and more durable: ingestion connectors, extraction infrastructure, classification services, review queues, confidence thresholds, exception handling, audit trails, observability, integration scaffolding, and governance patterns. The edge changes by domain: schemas, prompts, labels, model choices, thresholds, review protocols, compliance requirements, and routing targets.

This is the core-edge rule: standardize the machine, specialize the judgment.

The danger is oversimplifying it. Some domains require more than light configuration. Compliance, legal, healthcare, and financial workflows often need different extraction logic, model evaluation, escalation rules, and audit standards. In judgment-heavy work, domain expertise shapes the extraction and classification stages themselves. A legal risk model does not behave like an invoice field extractor. So the better claim is this: reuse the core where the overlap is real, and be explicit about where domain expertise must change the edge. It is not “build once and reuse everywhere.”

Validation is not a bolt-on

AI automation often stalls when validation is treated as cleanup. Validation is the control layer that makes an AI pipeline production-grade. It decides which outputs move forward automatically, which require human review, which need more evidence, and which should stop the workflow entirely.

In invoice processing, validation can mean three-way matching, duplicate detection, tax checks, and review of low-confidence fields. In contract analysis, it can mean checking a clause against a playbook, sending deviations to counsel, and preserving a trace from extracted obligation back to the original contract. In customer research, it can mean verifying that a theme is grounded in enough evidence, preserving the quote and speaker context, and preventing one loud customer from becoming a false product priority. In compliance, it can mean audit trails, rule checks, severity scoring, and escalation to a compliance officer.

Human review is not simply a safety net. It can become the bottleneck that destroys the business case. If every item falls into the review queue, the company has automated the easy part and preserved the delay. If reviewers lack clear thresholds, they become the system’s hidden logic. If corrections do not feed back into the pipeline, the same errors repeat.

That is why the validation layer has to be designed, not improvised. The workflow needs confidence thresholds, exception categories, escalation rules, reviewer roles, evidence trails, and a way to learn from corrections. It also needs throughput monitoring so the human review step does not become a permanent workaround. This is where many AI projects move from impressive demo to disappointing production system. The model can extract. The workflow cannot absorb uncertainty.

Capability building beats point solutions when the opportunity repeats

A point solution can make sense. If a workflow is narrow, isolated, and unlikely to repeat elsewhere, a focused tool may be enough. Specialized tools may also outperform a generic platform when the domain demands deep accuracy, certifications, or focused product investment.

But organizations with multiple document-heavy or knowledge-heavy workflows face a different problem. They are deciding whether to create a reusable way to automate many processes, not just one. The payoff changes when the pattern repeats. A reusable capability gives the organization shared intake templates, reference architectures, validation UI patterns, integration adapters, evaluation approaches, dashboards, governance checklists, and ROI calculators. Some assets stay highly domain-bound, especially schemas, prompts, taxonomies, and training sets. Others travel well, especially review queues, observability, audit trails, exception workflows, integration patterns, and delivery methods.

The second project starts with more than a blank page. The third project inherits lessons from the first two, as long as the organization is honest about which lessons transfer and which ones do not. Internal centers of excellence and platform teams can turn this into a repeatable delivery method: discovery identifies candidate workflows, volumes, error costs, cycle-time pain, decision points, and risk levels. Blueprint defines input sources, extraction targets, classification taxonomies, validation logic, routing destinations, governance needs, and operating roles. Build configures reusable components, prompts, models, review queues, integrations, dashboards, and audit trails. Pilot runs the system beside the current process, measures accuracy and throughput, tunes thresholds, and captures exceptions. Scale expands document types, increases straight-through processing where evidence supports it, monitors drift, and improves the operating model.

That is a different business than shipping one AI tool at a time. It is also harder. A shared platform can become a lowest-common-denominator tool. A central team can become a bottleneck. A single platform can create internal lock-in as surely as an external vendor can. The point is to make reuse an explicit architectural and operating decision instead of an accident, not to centralize everything.

The hidden machine diagnostic

The practical question is not “Can AI automate this?” That question is too broad. It invites demos, vague optimism, and tool-first thinking. A better question is: “Can this workflow be configured on top of a reusable automation core, or does it require a bespoke approach?” Use the hidden machine diagnostic to find out.

1. Capture

Identify the unstructured inputs: invoices, contracts, transcripts, emails, support tickets, forms, filings, policies, messages, scans, call recordings, or records. If the input sources are chaotic, optimize the intake process first. Automating a messy intake flow turns disorder into faster disorder.

2. Extract

Define the decision-relevant material: fields, entities, clauses, themes, risks, signals, anomalies, obligations, or quotes. The more interpretive the extraction, the less portable the configuration. The more traceability the workflow needs, the more deliberately the source evidence has to be preserved.

3. Classify

Map the extracted material to a business taxonomy: document type, risk category, customer segment, workflow status, urgency, obligation, severity, or topic. Rule-based classification often scales well. Judgment-based classification needs stronger review, evaluation, and governance.

4. Validate

Decide what must be checked before action: confidence scores, business rules, human review, exception handling, source traceability, duplicate checks, playbook checks, audit logs, or compliance review. This is the stage that separates useful automation from risky shortcut.

5. Route and act

Send the validated output where work happens: ERP, CLM, CRM, backlog, case system, insight repository, approval workflow, reporting process, remediation queue, or alerting channel. Routing is not clerical. It is where the automation becomes operational.

6. Learn

Feed outcomes and corrections back into the system. Human corrections, exception patterns, false positives, missed fields, reviewer overrides, and downstream outcomes should improve the workflow. If review produces no learning signal, the organization is paying people to catch errors without reducing future error rates.

7. Govern

Treat governance as a cross-cutting layer, not a final approval step. Governance includes audit trails, access control, retention policies, model and prompt change review, bias checks, drift monitoring, evaluation, ownership, and accountability. Standardization improves reuse, but it also concentrates risk. The platform that makes the tenth workflow cheaper is the platform that can break the first five with a single model update.

The real test: what repeats, what changes, what must be proved

The model works best when it forces separation. Do not ask whether invoice processing, contract review, and customer synthesis are “the same.” They are not. Ask which parts repeat.

The ingestion layer often repeats. Extraction infrastructure often repeats. Classification patterns often repeat. Validation queues often repeat. Observability and audit patterns often repeat. Integration scaffolding often repeats. Then ask which parts must change. The schema changes. The taxonomy changes. The prompts and models may change. The thresholds change. The reviewer changes. The audit burden changes. The risk tolerance changes. The route changes. The adoption problem changes.

Finally, ask what must be proved before scale. Accuracy is not enough. The workflow must prove that reviewers can manage exceptions, downstream systems can absorb outputs, governance can explain decisions, and users trust the result enough to change how they work. Forrester’s critique of AI adoption is right to push beyond technology architecture. Many AI programs fail because organizations do not redesign the work around the system. A reusable architecture helps, but it does not replace process redesign, operating ownership, training, or change management. The hidden machine is useful for many workflows. It is not sufficient by itself.

How to use the model before funding the next AI project

The next time a team asks for a new AI automation project, do not start with vendor selection. Start with gateways.

Is the process ready to automate? If the current workflow has unclear ownership, unstable inputs, inconsistent rules, or no agreed definition of success, fix the process first. AI will not rescue a workflow the organization cannot describe.

Does the workflow fit the hidden machine? Look for unstructured inputs, extractable decision material, a usable taxonomy, a validation point, and a downstream action. If those pieces are missing, the model may not fit.

What can be reused? Identify reusable ingestion, extraction infrastructure, classification patterns, validation queues, observability, governance, and integration scaffolding. If nothing repeats, a point solution may be the better choice.

What must be domain-specific? Name the schemas, prompts, taxonomies, thresholds, review protocols, compliance rules, and routing targets that cannot be generalized. Do this before anyone promises speed from reuse.

Where can the system act without review? Set confidence thresholds and exception rules early. If every output needs human approval, the project may still help, but it is a decision-support system, not automation.

Can the organization explain the result? If the company cannot reconstruct the source, rule, model output, human decision, and downstream action, the workflow is not ready for high-stakes use.

Will corrections improve the system? If human review produces no learning signal, the organization is paying people to catch errors without reducing future error rates.

What happens to the tools already running? If the organization already has scattered automation investments, do not rip them out first. Gate new requests, map the existing estate against the hidden machine, and look for renewal windows, integration points, or high-risk workflows where consolidation makes sense.

Does standardization create new risk? A reusable platform can reduce fragmentation and can also increase lock-in. The right question is which risk the organization can manage better.

The companies that get this right will not treat every AI workflow as a one-off experiment. They will build a shared operating model and then configure it carefully where the domain demands it. The real shift is from overlooking the hidden machine to deliberately engineering it, then tuning each domain edge with the rigor it demands. Not from human work to full automation, not from expert judgment to generic AI, and not from every tool to one platform.

When you work on AI in a regulated environment, you will hear the same question again and again: can the model say the same thing twice? The question is not wrong. It just aims too low. The real standard for regulated AI is whether the workflow can prove what happened.

Consider a finance team. They do not need a chatbot that can answer a question about revenue. They need to know which records the system could see, which permissions applied, which prompt version ran, which model generated the answer, which retrieval results shaped it, who approved it, and what became the official record.

A health insurer faces the same challenge. They do not need an algorithm that can recommend a care decision. They need to prove that a qualified human reviewed the evidence before the denial, delay, or modification of care. California’s SB 1120, the Physicians Make Decisions Act, now puts that principle into law for health plans that use AI or algorithms in medical necessity decisions.

In my experience, the conversation about AI governance keeps circling the wrong center. We keep asking whether the model is deterministic when we should be asking whether the workflow is reconstructable. Can the organization show what happened, why it was allowed, who had authority, and what became official? That is the Reconstructability Standard. The goal is to build workflows that make AI variation visible, bounded, testable, reviewable, and reconstructable, not to make probabilistic models pretend to be calculators. Regulated organizations will not trust AI because it is intelligent. They will trust AI when the workflow can prove what happened.

Why lowering the temperature is not enough

A common answer to AI unpredictability is: lower the temperature. That answer works for demos. It is too small for regulated work.

Lower randomness can help. Fixed model versions, fixed seeds, controlled infrastructure, deterministic tools, and careful sampling settings can make a system easier to test and debug. In some environments, they can make model behavior highly repeatable. But repeatability is not accountability.

Even if the model gives the same answer twice, the workflow around it may not. The source document may have changed. The user may have different permissions. The retrieval layer may return different evidence. A prompt or tool schema may have been updated. A human reviewer may edit the draft before approval. Production adds integration, security review, compliance checks, drift, broken tool contracts, downstream edits, and audit requests. A demo never has to survive that burden.

This is why AI pilots often stall at the handoff to production. The model may be capable, but the workflow cannot answer basic questions:

• Which facts did the AI rely on?
• Which version of the prompt shaped the output?
• Which tool call changed the result?
• Which human approved the action?
• Which policy allowed it?
• Which final record became authoritative?

If the organization cannot answer those questions, the system is not production-ready for regulated use. This is one of the most common failure modes I see: a capable model embedded in a workflow that cannot answer basic audit questions.

The three kinds of determinism, and which one matters

There are three different ideas that often get collapsed into one word. The first is model-level determinism: the model gives the same output for the same input. For LLMs, that is useful where teams can achieve it, but it should not be the only operating assumption.

Computational determinism means the same calculation produces the same result. In finance, actuarial work, optimization, and official business records, this still matters. If two users ask for the same approved revenue number, the answer cannot depend on location, timing, or prompt phrasing. In those cases, deterministic code or clear-box systems should handle the exact computation.

Workflow reconstructability means the organization can rebuild the decision context after the fact. It can show what inputs were available, what the AI produced, what controls ran, what humans decided, and what became the official record.

Regulated AI needs the third idea as a baseline. In some workflows, it also needs the second. The mistake is treating the model as the place where all accountability must live.

I want to be explicit about something that matters for audits. A model-generated explanation is not an audit trail. Chain-of-thought text is generated by the same probabilistic system as the answer. It may be useful as a draft explanation, but you should not treat it as verified evidence of what actually happened. The audit record has to live outside the model, in tamper-resistant systems the organization can inspect and defend.

It lives in the input packet, the evidence set, the prompt registry, the model configuration, the tool logs, the policy checks, the review decision, the approval record, and the final artifact. That is the artifact layer. It is where AI accountability becomes possible.

When the prompt replay is not enough

Imagine a compliance reviewer investigating an AI-generated recommendation that changed between Monday and Friday. Replaying the prompt is not enough.

On Monday, the user may have had access to one set of documents. By Friday, a source record may have changed. The retrieval layer may have returned different evidence. A policy prompt may have been updated. A tool schema may have failed validation. A model version may have changed. A human reviewer may have edited the draft before approval.

If the team only stored the prompt and response, the investigation stalls. What the organization needs is the whole workflow path: the original input and user instruction, the records and documents available at that moment, the permissions and retrieval boundaries in force, the prompt and policy versions, the model and configuration, the retrieved evidence, the tool calls and validations, the draft output before review, the human edits and approval decision, and the final record that entered the business system.

That is the Reconstructability Standard in practice. Not that the model will repeat the same words tomorrow, but that the organization can reconstruct why this outcome happened today.

Regulation is moving toward the artifact layer

This is no longer only an engineering preference. The EU AI Act requires high-risk AI systems to provide transparency for deployers, support human oversight, and maintain logs. NIST’s AI 600-1 Generative AI Profile names risks such as hallucination, data provenance, synthetic content, and human oversight as governance concerns for generative AI. Banking model risk expectations under SR 11-7 already push institutions toward conceptual soundness review, independent validation, ongoing monitoring, change management, and documentation.

Insurance is making the separation between AI output and human decision especially explicit. California’s SB 1120 requires physician or qualified health care provider oversight for medical necessity determinations involving AI or algorithms. New York’s Department of Financial Services has told insurers using AI and external data that they need governance, documentation, testing, and controls that explain how models function, what inputs they use, and how outputs affect decisions.

The direction is clear: regulators care less about whether an AI system sounds confident and more about whether the organization can explain, review, and control the path from input to outcome.

The UnitedHealthcare nH Predict controversy shows the risk. A Senate Permanent Subcommittee on Investigations report found that UnitedHealthcare’s post-acute care prior authorization denial rate rose sharply from 2020 to 2022 as the company expanded automation initiatives. Litigation has alleged that algorithmic predictions helped drive denials that were later reversed on appeal. Whatever the final legal outcome, the controversy illustrates the danger of insufficient transparency, weak oversight, and unclear authority when AI touches clinical coverage. In consequential workflows, the algorithm should not be treated as the decision by itself.

Keep the LLM on one side of the line

A probabilistic model can generate useful artifacts. It can draft a memo, summarize a claim file, extract fields from intake documents, propose inventory adjustments, identify missing evidence, or produce a structured recommendation.

But the workflow must decide what is true, safe, allowed, and final. That separation matters most when the output triggers a consequential action: a payment, denial, system-of-record update, legal filing, clinical coverage decision, credit decision, or regulated communication.

Consider an insurance claims intake workflow. A safe design does not ask an AI agent to approve or deny complex claims on its own. It asks the system to ingest documents, extract facts, flag exceptions, cite evidence, record confidence, route uncertain cases, and present a reviewable packet to a human decision-maker. The final disposition belongs to the authorized reviewer, not the model.

The same pattern applies to finance. An AI assistant can help a finance team find records, summarize variance, or explain a metric. But if the question asks for an official number, the LLM should not invent the answer through token generation. A deterministic calculation layer should compute the number from governed data. The AI can explain the result, but it should not become the source of truth.

The pattern also applies to law. An AI tool can draft a brief section or summarize precedent. But the filing becomes an official legal record only after citation validation, source checking, attorney review, and approval. Court sanctions for hallucinated legal citations show the danger of letting generation pass into the record without a validation layer.

Human review alone is not enough if it means a rushed rubber stamp. Meaningful review needs evidence, authority, time, training, workload design, and a recorded decision. The reviewer must be able to approve, reject, edit, escalate, or override the AI output under a defined policy. The artifact layer does not guarantee good judgment. It makes judgment visible enough to test, challenge, and improve.

Measure variation before you deny it

The goal is not to deny AI variation. You need to measure it before the workflow reaches production.

A regulated team should test the same workflow across repeated runs, realistic inputs, changed retrieval states, edge cases, permission differences, tool failures, and model updates. If a target field changes across runs when it should not, the workflow is not ready for that use case.

This is not only a model benchmark problem. Benchmarks can show capability. They do not prove the system will perform delegated work consistently inside the enterprise. A tool-calling agent can fail because the schema changed. A retrieval workflow can fail because the source boundary is too loose. A clinical support workflow can fail because the human approval step happens after the harm, not before. A finance workflow can fail because the model generated a plausible number instead of calling the governed calculation layer.

Variance testing should answer a practical question: is the variation acceptable for this workflow’s consequence level? For low-risk drafting, more variation is tolerable. For official records, financial outputs, legal filings, clinical coverage, and system updates, variation must be tightly controlled or moved out of the LLM.

The five questions a regulated workflow must answer

A regulated AI workflow is accountable enough when it can answer five questions without heroic investigation.

1. What shaped the output?

The workflow should preserve the input packet: documents, records, data, user instructions, permissions, system state, retrieval boundaries, prompt versions, policy versions, model configuration, tools, schemas, and runtime controls. If two users receive different answers, the input packet should show whether they had different permissions, different source access, different timing, or different instructions.

2. What evidence did the AI use?

The workflow should preserve the evidence set: retrieved documents, citations, records, facts, confidence scores, source boundaries, and validation results. For regulated work, sources are not background material. They are audit objects.

3. What happened during execution?

The workflow should preserve the execution path: tool calls, validations, policy checks, fallback flows, memory writes, system actions, blocked operations, and delegation chains. Agentic workflows need more than prompt-response logs. They need records of actions, state changes, failed operations, and the authority each agent or tool used.

4. Who reviewed and approved it?

The workflow should preserve the review path: the generated artifact, later edits, reviewer identity, approval decision, rejection, escalation, override, and governing policy. The record should show who initiated the action, whether the actor was human or AI, and why the action proceeded.

5. What became official?

The workflow should preserve the final business record: the approved artifact, decision, communication, update, filing, or system-of-record change. The final record should link back to the draft, evidence, controls, and approval path. A workflow that cannot be reconstructed is difficult to defend in a dispute, audit, incident review, or regulatory examination.

You do not need to store everything forever. You need to define the minimum evidence required to defend the workflow at the level of risk it creates.

Not every workflow needs the same controls

Not every AI workflow needs the same controls. A drafting assistant for internal brainstorming does not need the same artifact stack as an AI-assisted claims decision. A customer support summarizer does not need the same assurance as a system that updates a bank’s official ledger. A legal research assistant does not need deterministic computation for every sentence, but it does need citation validation before anything enters a filing. In my experience, a simple three-tier framework is usually enough.

Tier 1: AI-assisted drafting

The AI generates candidate text, summaries, or options. A human owns the final artifact. The main controls are source capture, draft comparison, review, and final approval.

Tier 2: AI-generated output with human approval

The AI recommends an action that affects a customer, patient, employee, counterparty, or regulated record. The main controls are evidence packets, policy checks, reviewer authority, approval records, escalation paths, and audit trails.

Tier 3: AI-linked consequential action

The workflow can trigger financial, clinical, legal, operational, or system-of-record changes. The main controls are deterministic computation where exactness matters, runtime enforcement, strong permissioning, mandatory pre-approval, rollback, monitoring, and incident response.

The framework does not make every workflow heavy. It helps teams stop applying light controls to heavy-risk work. That is the mistake I see most often: a team treats a Tier 3 workflow like a Tier 1 prototype because nobody named the difference.

Start with the artifact layer, not the governance framework

A governance checklist fails if nobody owns the records. Platform teams often own model access, logging, gateways, and tool permissions. Application teams own workflow design, user experience, and business logic. Compliance teams own policy interpretation, documentation, testing evidence, and regulatory response. Business owners own the risk of the final process. A production AI workflow needs all four.

The first move is not to build a massive new governance platform. Start by picking one workflow and defining its artifact layer:

• The input packet
• The evidence set
• The prompt and policy registry
• The model, tool, and schema versions
• The execution and validation log
• The review and approval record
• The final business record
• The variance tests required before release

That package can start as a sidecar log, a decision artifact store, a prompt registry, or an event stream tied to the existing application. The architecture matters less than the discipline: the workflow must create records while work happens, not after someone asks for an audit.

The platform can record the model call, but it may not know whether the output became an official record. The application can show the user journey, but it may not know whether a retrieved source was permitted. Compliance can define review standards, but it cannot manually inspect every AI output. The business owner can approve the use case, but only if the system shows the evidence path.

This is why AI governance cannot live only in a policy document. It has to live in the workflow.

The standard is controlled accountability, not perfect sameness

Before trusting the output, can we show which inputs shaped it? Before accepting the answer, can we show which evidence supports it? Before letting the AI act, can we show which authority it used? Before treating it as official, can we show the final record and its source trail? Before scaling it, can we show how it behaves across repeated runs? Those are the gateways. If the answer is no, the problem is that the workflow still cannot prove what happened. Intelligence is not the missing piece.

When you are responsible for putting AI agents into production, you will face a governance question that sounds like security but turns out to be about operating standards. A policy tells a team what an AI agent is allowed to do. It does not tell the team whether the agent deserves to keep doing it. That distinction matters more as agents move from demos into production, where a customer-support agent can resolve cases, issue refunds, update records, and escalate when customers show frustration, a software-development agent can open pull requests, change dependencies, and trigger deployment steps, and a finance or insurance agent can gather documents, apply rules, and recommend decisions that affect real people.

In each of these cases, the governance question is not only “Is this agent allowed?” The better question is “What evidence would make this agent worth trusting in production?”

Many organizations already have AI policies, committees, intake forms, and approval gates. In my experience, the gap is not in having a policy. The gap is operational: teams approve or deploy agents without defining what the agent must improve, what it must never do, what evidence will prove it is working, and when humans must intervene.

This does not mean permission controls are secondary. Security reviews, access limits, legal review, vendor risk checks, and compliance policies all matter. Granular access control, context-aware permissions, least privilege, and just-in-time authority can prevent real harm. The problem is that permission controls define what an agent can attempt. They do not define whether the agent is improving the workflow, interpreting policy correctly, escalating the right exceptions, or still deserves the autonomy it has been given.

Agents need governance that starts with a provable obligation: value created, behavior bounded, risk constrained, actions visible, controls tested, and ownership assigned. Call that the production autonomy standard: the risk-scaled evidence an agent must meet to earn, keep, expand, or lose the right to act.

Why permissions are not enough

Most organizations first encounter agent governance as a permission problem: securing system access, gating customer data, limiting tool use, approving external communications, or deciding whether the agent can execute transactions. Those boundaries are necessary. They are not sufficient.

Consider a support agent with permission to issue modest discounts. It stays inside that permission. It does not break into a system, exceed its refund limit, or access data it should not see. But it starts offering discounts in cases where customer history, fraud risk, pricing rules, or policy ambiguity should have triggered review. A better permission model might bind the discount to customer status, fraud checks, policy flags, or approval thresholds. The broader problem remains: the organization needs an operating standard that tests whether the agent’s decisions remain appropriate, not only whether its permissions were respected.

The same pattern appears in public examples. Klarna said in 2024 that its AI assistant was doing the work of 700 customer-service agents. By 2025, the company was again hiring humans for customer support after its CEO acknowledged that an overemphasis on cost had lowered quality. Public reporting does not prove that a different governance standard would have prevented that outcome. It does show the danger of treating efficiency as a sufficient production standard.

Air Canada offers the legal version of the same lesson. Its chatbot gave a passenger incorrect information about bereavement fare refunds. In 2024, a Canadian tribunal held the airline responsible for the chatbot’s statement. The agent did not need exotic permissions to create liability. It needed a policy-alignment standard, a failure definition, and a handoff rule.

This is where agent programs drift. They measure task volume, response speed, cost reduction, or hours saved, but they do not measure whether the workflow actually improved. They celebrate activity because activity is easy to count. Production trust requires a different standard.

For a software-development agent, the right metric is whether the agent improves merge-request-to-deployment time, defect rate, deployment frequency, review burden, rollback rate, and security quality, not lines of code generated. For a customer-support agent, the right metric is whether the agent resolves the right issues, escalates the right cases, protects user trust, and stays inside policy, not messages sent. For a regulated workflow, the right metric is whether the agent can operate inside legal, audit, data, and human-review constraints, not automation rate.

Business outcome matters. But it must sit inside a constraint envelope. In healthcare, financial services, insurance, employment, and other regulated contexts, an agent cannot optimize for speed or revenue if that optimization compromises rights, statutory duties, auditability, or required human judgment. The first useful governance move is therefore simple: define what improvement means, and define what the agent must not do to get there.

What makes agent governance different

Traditional software can still fail, but its behavior is usually specified through deterministic logic. Given the same input and state, the system should produce the same result. Governance can often focus on access, change control, testing, and policy compliance.

Agents change the standard because non-determinism combines with tool access, memory, retrieval, delegation, and action across systems. Their behavior can vary. Their mistakes can compound. A single bad interpretation can lead to several downstream actions before a person notices. That is why governance has to start before architecture hardens.

A team needs to define acceptable behavior. It needs thresholds for autonomy, risk boundaries, escalation rules, and observability from day one. It needs an answer to the question “What will we do when the agent behaves plausibly but incorrectly?” Agentic systems raise risks that ordinary software governance does not fully cover. OWASP’s Top 10 for Agentic Applications names risks such as goal hijacking, tool misuse, identity and privilege abuse, memory poisoning, and cascading failures. These risks do not make agents unusable. They make vague approval dangerous.

A high-authority agent in a complex environment needs stronger constraints than a low-authority agent summarizing internal documents. An agent that can send external communications needs different controls than one that drafts but cannot send. An agent that can modify production systems needs least privilege, reversible actions, circuit breakers, and explicit approval thresholds. Governance starts by making those distinctions visible.

The production autonomy standard

Before an agent moves from pilot to production, teams need a shared artifact that translates governance into operating decisions. The point is not to create another document for a review folder but to force the right conversations before the agent has power.

A production autonomy standard is the risk-scaled evidence an agent must meet to earn, keep, expand, or lose the right to act. A low-authority internal research assistant does not need the same depth of review as an agent that can move money, alter customer records, or modify production systems. But every agent needs explicit answers to the same basic questions: what it is for, what it can do, what it must not do, how success will be measured, how failure will be seen, and who can stop it.

The lightweight version might be a one-page standard for an internal research assistant: outcome definition, allowed data sources, uncertainty disclosure, one human escalation path, and a quarterly review. The full version belongs on customer-facing, financial, regulated, security-sensitive, or production-changing agents: documented failure thresholds, traceability, sampled audits, human override, incident response, and named shutdown authority.

Proportionality matters. Without it, governance becomes a launch-blocking ritual. With it, governance gives low-risk agents room to learn and high-risk agents the controls they need. A practical standard should cover eight areas.

Purpose and scope

Define the workflow, user, task, autonomy level, tools, systems, data, memory, and external channels. State explicitly what is out of scope. The minimum viable criterion is that the team can state in plain language what the agent does, where it acts, what it can access, and exactly what it is prohibited from doing.

Business outcome

Define the measurable workflow result the agent must improve. Include the baseline, target KPI, operating cost, quality measure, risk measure, and user or customer outcome. The minimum viable criterion is that the team can name the outcome that proves the agent is worth operating and the result that would make it not worth continuing.

Permission boundaries

Define what systems, tools, data, actions, and transactions the agent can access or execute. Apply least privilege. Separate read, recommend, draft, approve, and execute authority. Bind the agent’s authority to the user, task, session, and risk level wherever possible. The minimum viable criterion is that the team can distinguish what the agent can see, suggest, change, approve, and execute without human approval.

Task performance

Define what good performance looks like. Include accuracy, completeness, usefulness, repeatability, evidence handling, policy adherence, citation quality, and acceptable human correction. The minimum viable criterion is that the team can evaluate outputs against a documented standard, not a general impression that the agent seems useful.

Failure criteria

Define unacceptable failure modes, error thresholds, policy violations, user harms, operational risks, and evidence that the agent is no longer safe or useful enough to continue. The minimum viable criterion is that the team can answer, before launch, what evidence would force restriction, suspension, redesign, or retirement.

Escalation criteria

Define when the agent must hand off to a human. Include confidence, complexity, ambiguity, customer sentiment, exception type, regulated decision points, financial exposure, and risk thresholds. The minimum viable criterion is that the team can identify which situations require human review, who receives the escalation, and how quickly they must respond.

Human control model

Define ownership, override authority, pause and deactivation rights, user appeal paths, exception accountability, and manual review requirements. The minimum viable criterion is that the team can name the human accountable for the agent in production and the humans who can override, restrict, or shut it down.

Monitoring and lifecycle decisions

Define the traces, logs, samples, evals, audit trails, review datasets, governance metrics, and decision cadence required from day one. Specify what evidence justifies launch, expansion, restriction, retraining, redesign, suspension, or retirement. The minimum viable criterion is that the team can show how production evidence will change the agent’s autonomy over time.

Why visibility is not optional

A success criterion you cannot observe in time to inform a decision is an aspiration, not a control. That is why success criteria become architectural requirements.

If the team says the agent must cite sources, the system needs to preserve source references. Escalation based on low confidence requires confidence signals, routing logic, and records of escalations. Avoiding sensitive data exposure requires access boundaries, monitoring, and logs that show what data the agent touched. Policy compliance requires samples, evals, and audit trails that show whether the policy held in real use.

Teams need traces for agent actions and model calls. They need conversation-level trace IDs, replayable interactions, real-user query datasets, and automated checks. They need deterministic tests for rules the agent must always follow. They need review of real usage, not only lab prompts. Without visibility, human monitoring becomes a ritual.

Let me be direct about why this matters. A person asked to approve an opaque agent decision is not exercising control. They are signing off without evidence. In regulated workflows, that “human in the loop” model is especially weak. If the reviewer cannot see why the agent acted, what data it used, what policy thresholds applied, and what authority it exercised, the review is not meaningful enough for consequential decisions.

Decision-level provenance matters most when the agent’s action has consequences. Logs that show timestamps, tool calls, and actors are useful. But they are not enough if they do not show the rule version, evidence evaluated, approval authority, and threshold applied at the time of action. Without that record, teams reconstruct compliance from fragments after the fact. An agent cannot be wrong and invisible at the same time.

Human in the loop is not a plan

“Keep a human in the loop” sounds responsible. In practice, it is often too vague to be useful. You need to specify which human, at what point, with what information, under what threshold, with what authority, within what response time, and for which actions.

A support agent might be allowed to answer routine questions on its own, but it must escalate when sentiment worsens, confidence drops, the customer asks for a refund above a threshold, or the case involves legal risk. A financial services agent might require a high confidence threshold before recommending certain actions, with lower-confidence cases routed to a trained reviewer. A general operations agent might use a target escalation range so routine work proceeds autonomously while high-risk exceptions receive review. The exact thresholds vary by use case. The important point is that the thresholds exist.

Human control also needs suspension logic. Escalation sends a case to a person. Suspension pauses the agent’s ability to act until someone clears it. Those are different controls. An agent that gives one uncertain answer might need escalation. An agent that starts sending confidential data into an unsecured workflow needs suspension. An agent that takes several unexpected actions across tools needs a circuit breaker. An agent operating in a regulated domain might need mandatory manual review for entire classes of decisions, regardless of confidence.

The organization also needs an owner. Not a committee in the abstract. A named accountable team or executive who owns the agent’s production behavior, approves scope expansion, accepts residual risk, and has authority to restrict or retire the agent.

This is not about pretending agents must be flawless where humans are fallible. Humans also misread policy, miss context, and make inconsistent judgments. The difference is scale and speed. An autonomous agent can repeat the same bad interpretation across thousands of interactions before the organization understands the pattern. Governance often fails because no one is answerable when the criteria fail. If no one can say who can turn the agent off, no one has governed the agent.

From approval to autonomy decision

The standard works because it turns approval into an autonomy decision. Imagine a SaaS company testing a billing-support agent. The agent can answer billing questions and issue refunds below a defined threshold. During a limited launch, it improves first-contact resolution and keeps refund errors below the sampled audit threshold. On routine cases, it performs well.

But the review shows a pattern. Escalations spike when customer sentiment turns negative. Audit samples show inconsistent policy interpretation on annual-plan proration and grandfathered pricing. The agent is not dangerous enough to shut down, nor ready for expanded refund authority.

A permission-only review might say the agent stayed inside its access rights. A production autonomy standard enables a better decision: keep the agent live for routine billing inquiries, restrict refund autonomy for churn-risk or high-value accounts, require human review above the refund threshold, tighten escalation rules, and review again after a defined operating window. Binary approval is not the goal. The decision is launch, restrict, monitor, expand, redesign, or stop, based on evidence.

What the standard changes about how you govern

The standard changes the order of governance. Instead of asking a committee to approve a vague agent concept, the team must define the operating evidence first. Instead of debating policy in the abstract, security can inspect tool access and privilege, legal can identify the constraint envelope, product can define workflow outcomes, operations can define escalation and incident response, compliance can require audit trails and documentation, and engineering can build traces, evals, circuit breakers, and reversible actions into the system.

This does not make governance lighter. It makes governance usable. It also exposes weak use cases early. If a team cannot name the workflow outcome, the agent is not ready. If the agent needs broad access to several systems but no one can justify the permission set, it is not ready. If humans are expected to supervise but cannot see why the agent acted, it is not ready. If a vendor-managed agent cannot provide the traces, controls, or contractual assurances required for the workflow risk, it is not ready for that level of autonomy.

That sounds restrictive. In practice, it helps teams move faster on the right work. A team that defines success criteria before launch can build the right observability from the start, test the right risks, avoid automating a broken process, give the agent enough autonomy for routine work while protecting high-risk decisions, and scale only after the evidence supports scaling. The alternative is familiar: a promising pilot, a vague approval, a production incident, then a scramble to reconstruct what happened.

Governance as a lifecycle, not a gate

A success criteria standard should act as an operating license, not another shelf document. Before launch, it tells the team whether the agent is defined well enough to build. During testing, it tells the team what to measure. At production review, it tells approvers what evidence to inspect. After launch, it tells operators when to expand, restrict, pause, or retire the agent.

That lifecycle matters because agents do not stay still. Usage changes. Models change. Tools change. Policies change. Users discover edge cases. Attackers find new openings. Vendors update systems. Workflows drift. A governance model that only approves launch will age quickly. The better standard is continuous: the agent must keep proving it deserves production autonomy.

When you put permission on one axis and production governance on the other, four patterns emerge. Low permission and low governance: a sandbox assistant where neither matters much. Low permission but high governance: an overcontrolled low-risk tool. High permission but low governance: dangerous autonomy where the agent has power without controls. High permission and high governance: earned production autonomy, which is the only sustainable target for agents with real authority.

The riskiest agent is not always the one with the broadest permission. The harder risk to spot is the agent with meaningful permission and weak operating governance, because it can keep producing plausible, consequential errors without triggering an access-control alarm.

Agent governance is the operating standard an agent must meet to remain in production, and it starts with a question every team should answer before launch: who can turn it off, and under what evidence would they do it?

When you watch a customer support agent resolve tickets end to end in a demo, the workflow looks complete. It reads the complaint, checks the account, drafts the response, applies the credit, and closes the case. The room nods. Then the product reaches production and the real questions begin.

Which refunds can it issue? What happens when the customer threatens legal action? Can it change account status? What data can it read? Who approves edge cases? Where does the audit trail live? How do you reverse a bad action?

These are not secondary concerns you add after the demo. They are the product problem. Agentic products should not expand autonomy until the control system around them can constrain, inspect, evaluate, escalate, pause, and recover from their actions. The first requirement for an autonomous agent is a control system, not independence.

Capability is not the same as control

A capable agent can plan and act. A controlled agent can be limited in scope, tools, duration, and authority before it acts, not just investigated afterward. This distinction matters because agents are no longer only chat interfaces. They can touch files, credentials, commands, customer records, workplace messages, regulated data, and production systems. Once that happens, the product changes category. It stops being only an interface design problem and becomes an operating system for delegated action.

Operating systems do not trust every process equally. They isolate, schedule, interrupt, log, and revoke. Agentic products need the same product instinct. Not because agents are malicious by default, but because delegated action without boundaries turns small model errors into operational incidents.

In a copilot, the user is often the control surface. The system suggests, the user decides, and the scope of damage stays small. In an agentic workflow, the product itself must carry more of that control. It needs permission boundaries, approval gates, escalation paths, logs, evals, rollback paths, and shutdown controls. The team is no longer designing only what the agent can do. It is designing what the agent is allowed to do, how the system knows when to stop it, and who can reconstruct the run afterward.

This is one reason enterprise adoption moves more slowly than the agent narrative suggests. The technology can already perform meaningful multi-step work, but high autonomy remains rare because governance, reliability, integration, and risk tolerance all have to catch up with capability. In my experience, teams are not only asking, “Can the agent do the work?” They are asking, “Can we trust the system around the agent when the work goes wrong?”

The agent control ladder

The practical question when you design an agentic product is not, “How autonomous should this agent be?” The better question is, “What has to be true before this agent earns more autonomy?” I use the Agent Control Ladder as the operating model.

1. Bound the task

Define the exact job the agent can perform. What is in scope? What is out of scope? What counts as overreach? If the agent’s job description sounds like “handle customer operations” or “manage internal work,” the scope is too broad. A controlled agent has a narrow mandate. “Draft refund recommendations for accounts under $500 using approved policy rules” is a better starting point than “resolve billing issues.”

2. Limit the scope of damage

Decide what systems, files, tools, and data the agent can access. Access should be least-privilege, task-specific, and time-bound. Dangerous combinations should be blocked. For example, an agent should not freely combine private customer data, external web content, unrestricted shell access, and production write permissions. The more sensitive the system, the more explicit the boundary.

3. Define human control

Choose the control mode by risk. Some actions require approval before execution. Some allow monitoring with veto power. Some can run unsupervised because the cost of a bad action is low and the workflow is well measured. Human review is a spectrum, not a single pattern.

4. Set escalation rules

Define the thresholds that route work to people. Low confidence, ambiguous intent, policy exceptions, regulated data, customer harm, financial impact, security risk, or missing context should trigger escalation. The queue should have an owner. The owner should have enough context to decide quickly. Escalation cannot be a vague instruction to “ask a human.” It has to be part of the workflow.

5. Evaluate independently

Build evals outside the agent doing the work. Independence is a spectrum. A first version might use out-of-band checks, manual review of traces, red-team cases, and policy tests. Over time, the evaluation layer should become more decoupled from the goal-seeking agent and more continuous in production. The eval layer should review execution logs, not only final outputs. It should test routine cases, edge cases, adversarial inputs, tool failures, and policy conflicts. Manual checks should come before production. Automated checks and production metrics should follow. As autonomy increases, evaluation has to become more continuous.

6. Make behavior inspectable

Log prompts, actions, tool calls, decisions, handoffs, configurations, approvals, and delegated authority. A human should be able to reconstruct what happened. Security should be able to trace access. Compliance should be able to inspect the record. Operators should be able to see where the agent stopped, escalated, or acted. If the trace is incomplete, the autonomy level is too high.

7. Prepare recovery paths

Every serious agent needs pause, override, shutdown, and rollback paths. The team should know how to halt the agent, collect logs, trace access, reverse bad actions, and update controls after an incident. Recovery is part of the product, not an emergency procedure invented later.

Human review is a control mode, not a speed bump

The wrong response to agent risk is to put a person in front of every action. In many systems, that does not scale operationally, and it confuses oversight with control. The useful question is not whether a human should always approve the agent, but which actions need which control mode.

A low-risk, high-confidence workflow can run with more freedom. A medium-risk workflow may need monitoring with veto power. A high-impact workflow needs approval before execution. Some workflows should stay as copilots because the action is too sensitive, too ambiguous, or too hard to reverse.

Consider a support agent. It can summarize a ticket, draft a reply, suggest a policy article, and classify urgency without much friction. It might even issue a small refund when the customer meets clear criteria and the amount falls below a defined threshold. But it should not close an enterprise account, change billing terms, or disclose sensitive customer data without review. If confidence drops, policy language appears, or the customer asks for something outside the agent’s scope, the task should route to a human queue.

That is how autonomy becomes usable. Humans should define success, constraints, allowed actions, stopping points, and review gates. They should not have to micromanage every step. Their job is to set the control plane, not become the agent’s full-time supervisor.

Permissions are the first hard boundary

The more useful an agent becomes, the more access it wants. That is the bargain. A workplace assistant wants email, chat, documents, and project tools because that is where the work lives. A DevOps agent wants logs, terminals, tickets, repositories, and deployment systems because that is where incidents get solved. Every new permission expands what a mistake can touch.

This is why permission design has to come before autonomy design. Agents need narrow tasks, least-privilege access, time-bound permissions, and clear limits on dangerous tool combinations. Sensitive actions need approval. Production writes need review and rollback. Regulated data needs stricter boundaries.

For most high-stakes enterprise workflows, smaller agents with explicit rights reduce risk better than broad “super agents.” Some work requires broad context, but broad context does not require broad authority. A workplace agent that summarizes Slack, email, and documents should not automatically gain the ability to send messages, invite external users, update HR records, or post to company-wide channels. Draft-before-send is a control pattern. So is approval-before-post. So is granting access for one task and expiring it afterward.

Agent identity also matters. If agents act through borrowed human credentials, the audit trail gets muddy. Enterprises need nonhuman identities, delegated rights, session controls, and logs that show which agent acted, under whose authority, with what context, and against which system. Modern IAM already has useful building blocks: delegated access, short-lived credentials, service identities, policy engines, and audit logs. Agent chains expose gaps in how many organizations apply those patterns. If Agent A can spawn Agent B, and Agent B calls Agent C, the organization needs to know where authority started, how it moved, what each agent was allowed to do, and where authority stopped.

Evals have to grow up with autonomy

Teams should not jump from a good demo to production autonomy. A demo shows that an agent can complete a task under favorable conditions. It does not prove that the agent can handle bad inputs, ambiguous policies, poisoned context, missing data, tool failures, or adversarial instructions. Autonomy without measurement is trust by assertion.

The eval system needs to mature with the agent’s freedom. Early workflows can start with manual checks before production. As the agent becomes more central, teams need automated evals in CI/CD, red-team exercises, production metrics, guardrail tracking, and review of execution logs. Agents should not grade their own homework. At minimum, the evaluation path should be out of band from the execution path. The stronger version is a separate evaluation layer that inspects full traces, compares outcomes against customer-specific criteria, and flags failure patterns.

This matters because agent failures often hide in the path, not only the final answer. The output may look plausible while the agent used the wrong data, skipped a policy check, exceeded its authority, or ignored a conflicting instruction. If the system cannot reconstruct the run, it cannot reliably learn from it.

Trust comes from inspectability and recovery

Enterprise buyers do not trust agent products because the model sounds confident. They trust them when the whole operating system around the model can answer operational questions. Who owns this agent? What can it access? What can it change? Where are the logs? How do approvals work? What happens when it fails? Can we shut it down? Can we roll back the action? Can compliance inspect the record later? These are not secondary controls. They are adoption requirements.

A DevOps agent makes the point clearly. It may be useful if it can investigate an incident, read logs, identify the likely cause, and propose a fix. But production writes belong in a different control tier. The agent can draft the change. A human reviews it. The system logs the recommendation, approval, deployment, and rollback plan. If the change misfires, the team can pause the agent and reverse the action. That is a controlled workflow. Without those controls, the same agent becomes hard to approve. It may be technically impressive, but the organization cannot explain what happened after the fact. That kills trust faster than a lower benchmark score.

The ladder in practice

Take a finance or HR agent. At the first rung, it handles routine lookups. It answers policy questions from approved sources, summarizes employee requests, and drafts responses. At the second rung, it gains narrow access to specific records. It can retrieve payroll status or benefits information only for authorized users and only for the task at hand. At the third rung, it starts preparing actions. It can draft a payroll correction, but it cannot execute the change. A human must approve anything involving bank details, regulated data, compensation, or employment status.

At the fourth rung, it uses thresholds. Routine, low-risk requests flow through. Exceptions escalate. Confidence drops trigger review. Policy conflicts route to a specialist. At the fifth rung, independent evals review full traces. They check whether the agent used the right policy, accessed the right records, respected permissions, and escalated correctly.

Only then should the team consider more autonomy. The goal is to let the system earn speed.

The market sells autonomy. Enterprises buy control.

Agent vendors often describe the future as a move from copilots to agents to autonomous operations. That path may be directionally right, but it skips the hard middle. The hard middle is control design.

Enterprises need agents that can act, but they also need agents whose freedom can be bounded, measured, explained, and revoked. They need identity, authorization, auditability, monitoring, escalation, evals, and recovery. They need policy choices about when verification is valuable, morally required, or legally required. That is where many deployments stall. Not because agents are useless, but because a risk owner asks basic control questions and the team cannot answer them yet.

Before asking whether an agent can act, ask whether the organization can constrain the action. Autonomy is useful. But in agentic products, autonomy is the reward for getting control right, not the starting point.

The dangerous question in agentic AI is no longer, “Can the agents talk to each other?” It is, “Who gave them permission to decide?”

That question sounds simple until a workflow goes live. A customer support agent triages a complaint. Another agent retrieves account history. A third drafts the response. A fourth recommends a credit or issues one under a configured threshold. The demo looks clean because the agents coordinate. Then an executive asks why a $2,000 refund was approved. The logs show that the refund happened. They show which tool ran and when. But they do not show which policy version applied, what evidence the agent used, who approved that level of authority, or which human role should have reviewed the exception.

That is one of the governance problems agentic AI exposes most quickly. The shift is from judging outputs to controlling delegated actions. The hard part is not only whether agents can connect to tools, data, models, and each other, but whether the organization can define, constrain, observe, override, and audit what those agents are allowed to do at runtime. Multi-agent orchestration solves a technical problem. It also creates an operating model problem.

The control point has moved

Teams often treat agent orchestration as plumbing. Which model calls which tool? Which agent hands work to the next? Which protocol connects one system to another? Which memory store preserves context? These choices look technical. In agentic systems, many of them carry governance consequences.

If an agent can route a case to collections, that is not just workflow logic. In a governance sense, it is delegated authority. If an agent can send a customer email, modify a record, approve a discount, or submit a purchase order, the organization has granted it action rights. If another agent decides whether a human should review the case, the system now controls an escalation path. Connectivity answers whether agents can interact. Authority answers whether they should be allowed to act.

This distinction matters because enterprise deployments are still hybrid. Most organizations are not handing entire business processes to fully autonomous agent networks. They are combining agents with rules, configuration, human review, service commitments, access controls, and workflow systems. The result is delegated work under constraints, not pure autonomy.

For agentic workflows that can affect real systems, sensitive data, money, customers, employees, or regulated outcomes, deployment review alone is not enough. Traditional AI governance often starts before launch. A team reviews the use case, checks the model, validates risks, approves release, and monitors performance. That still matters. But agentic workflows keep making choices after deployment. They perceive context, reason over goals and constraints, call tools, trigger downstream systems, and coordinate with other agents. They do not merely produce an answer for a human to inspect. They can act. So the control point moves from “Was this system approved?” to “What is this system allowed to do right now?”

General AI risk frameworks still help define governance expectations. Identity governance, privileged access management, segregation of duties, workflow controls, internal audit, NIST AI RMF, ISO/IEC 42001, and the EU AI Act all cover important ground. They do not disappear because agents arrive. The issue is that agentic systems turn those expectations into runtime delegation questions. An AI management system can say the organization needs human monitoring. The workflow still has to define where review happens, what threshold triggers it, which role receives it, and what the agent can do while waiting. A security policy can say least privilege applies. The architecture still has to separate standing privileges from dynamic, session-level permissions. A regulation can require logging. The system still has to preserve the rule version, evidence, approval authority, and action trace for each meaningful decision.

The missing layer is an agent-specific map of authority, accountability, enforcement, and auditability, not “more governance” in the abstract.

Authority is the design unit

An enterprise agent is a delegated actor, not simply software that completes a task. It can be granted rights to see data, update memory, call tools, invoke services, route work, draft communications, make recommendations, and trigger actions. In some cases, it behaves less like an application and more like a privileged user that moves quickly across systems. Before asking what an agent can do, we should ask under what authority it acts.

A procurement agent makes this clear. It might search vendors, compare terms, check budget codes, draft a purchase order, and submit an order. Those tasks do not carry the same risk. Search rights are not purchase rights. Recommendation rights are not approval rights. Drafting a purchase order is not the same as submitting one. Updating a vendor record is different from reading it.

A useful governance model separates those rights instead of treating the agent as one object with one permission level. It asks what the agent can perceive, what it can decide, what it can do, when it must stop, who owns the outcome, and how the organization can reconstruct the decision later. Without those distinctions, teams often overcorrect in one of two directions. They either grant broad authority because the workflow needs speed, or they require human approval everywhere because the risks feel unclear. Both choices are blunt.

Bounded autonomy is the better target. Agents should act independently where the risk is low, the policy is clear, and the action is reversible. They should escalate when the stakes, ambiguity, or irreversibility cross a defined threshold. The goal is to make every autonomous action bounded and traceable.

Decision orphans are the real failure pattern

The risk is not only that an agent does something unauthorized. A quieter risk is that an agent does something no one can explain, own, or resolve. Call these decision orphans: machine-made decisions with no clear origin, no responsible owner, no visible rule version, no preserved evidence, and no escalation path.

They become more likely as agent systems become networks. One agent classifies intent. Another retrieves context. Another applies policy. Another takes action. A vendor tool enriches the record. A workflow engine triggers a follow-up. A human sees only the final result. From the outside, this can look like one automated workflow. Inside, several authorities are at work.

Super-orchestrator designs create a specific version of this risk. They simplify the external interface by hiding multiple internal agents behind a single boundary. That can help the product feel clean. It can also make independent review harder unless the orchestrator exposes internal decision paths explicitly. If the orchestrator made the decision, which internal agent supplied the evidence? Which policy check passed? Which component had action rights? Which team owns the exception?

This is where ordinary telemetry falls short. A log that says “refund approved at 10:42” is not enough for agentic work. Agentic audit trails need to go beyond typical telemetry by explicitly linking actions to the evidence, policy version, delegated authority, approval rule, and accountable owner. Many current implementations stop short of this. The organization needs to answer not only what happened, but why the system was allowed to make it happen.

The agent authority map

Before scaling an agentic workflow, teams need a practical way to see where authority enters the system and how it is controlled. The Agent Authority Map is a review tool for that purpose. It does not replace AI governance programs. It translates them into the operating details of agentic work. Its method is authority decomposition: break the workflow into perception rights, decision rights, action rights, escalation rules, runtime controls, audit requirements, and accountable owners before the system scales. Use it for each agent, agent cluster, or orchestrated workflow.

Identity and ownership. What the agent is, which workflow it serves, who owns it, and whether it acts for a user, team, business unit, or enterprise. The agent has a named business owner, technical owner, risk tier, and operating context.

Delegation chain. Which owner, policy, upstream agent, user, or system can authorize it to act. Authority can be traced across handoffs, including agent-to-agent delegation.

Perception rights. What data, context, tools, and memory the agent can see, use, or update. Sensitive data access changes by purpose, user intent, and risk tier.

Decision rights. What judgments the agent can make, recommend, escalate, or never make. Independent decisions are separated from recommendations and approvals.

Action rights. What systems it can affect and which actions are allowed, denied, or approval-gated. “Can use the CRM” becomes concrete actions such as draft a case note, update status, or request a supervisor-approved refund.

Escalation rules. When the agent must stop, who receives the escalation, what response time applies, and what happens if no one responds. Human review is designed as a trigger, role, channel, SLA, and fallback, not a vague safety promise.

Runtime controls. Which policies are enforced at point of use and which privileges are dynamic rather than standing. Policy checks, session-level authorization, monitoring, and revocation happen during action.

Audit requirements. What must be reconstructable later. Evidence, policy version, approval authority, model output, tool call, memory update, handoff, and action trace are linked.

Accountability. Which humans and forums remain responsible for outcomes, exceptions, changes, and incidents. Delegation changes the operating model without making responsibility disappear.

The map is not meant to create paperwork for its own sake. It gives product teams clearer lanes. If low-risk actions are explicitly bounded, they can move faster without blanket manual approval. If high-risk actions have clear thresholds, governance stops being a last-minute veto and becomes part of the design. Implementation will vary. Some teams will use policy-as-code engines, session-level authorization tokens, AI gateways, runtime guardrails, or platform-native audit hooks. The point is that enforcement has to meet the agent at the moment it tries to act, not the tool category used for enforcement. A system that only authenticates the agent asks, “Who are you?” A governed system also asks, “What are you allowed to do in this context, and how will that rule be enforced right now?”

How the map changes the conversation

Imagine a product team wants to launch a multi-agent customer support workflow. Without an authority map, the review conversation tends to stay broad: Is the model accurate? Are the integrations working? Is there a human review option? Are logs available? Those questions help, but they miss the operating details.

With the map, the conversation becomes sharper. The triage agent can classify tickets and route them. It cannot close regulated complaints. The account agent can retrieve history. It cannot expose payment details to other agents unless the customer intent and risk tier justify it. The response agent can draft messages. It cannot send them when the case involves legal language, policy exceptions, or high-value credits. The credit agent can recommend refunds up to a threshold. It can issue small credits automatically only when the customer type, complaint category, and policy version allow it. Above that threshold, it escalates to a named role. Every credit decision preserves the evidence, rule version, approval authority, and action trace. That is accountable autonomy, not anti-autonomy.

The same logic applies to procurement, finance operations, HR case handling, incident response, claims processing, and field service. Anywhere agents perceive context, make judgments, and act across systems, the authority model has to be visible.

Gateways before scale

The next stage of agentic AI will not be governed by asking whether agents are useful. Many will be useful. The better question is whether the organization can absorb the delegated authority it is creating.

Before scaling an agentic workflow, the organization needs a few gates. Can it trace who delegated authority to whom? Has it separated perception rights, decision rights, and action rights? Does it know which actions are low-risk enough to run independently and which require threshold-based escalation? Are authorization and enforcement happening at the point of use? Can the organization reconstruct the evidence, rule version, approval authority, and action trace after the fact? Can someone pause, revoke, or narrow the agent’s authority when the workflow changes?

If the answer to any of these is no, the workflow is not ready to scale. It may be technically impressive. It may even work most of the time. But it is creating decisions the organization cannot fully own. The organizations that get agentic AI right will not be the ones that connect the most agents fastest. They will be the ones that govern delegated action clearly enough for agents to move quickly without making responsibility disappear.

AI will not replace product managers. It will replace the parts of product management that never required much judgment.

That distinction matters because the current debate is too broad. One side says PMs are safe because product work is human, strategic, and cross-functional. The other says PMs are exposed because AI can draft specs, summarize calls, analyze feedback, update tickets, and generate roadmap decks. Both are partly right.

AI is making product artifacts cheap. A PM can now turn customer notes into a PRD, acceptance criteria, launch messaging, a stakeholder update, and a backlog of tickets in minutes. Agents can summarize meetings, categorize research, draft requirements, analyze customer data, and help with bounded prototypes. That is real disruption. But cheap artifacts do not make product judgment cheap. They make weak judgment easier to spot when teams know what to inspect.

The real story is that AI separates product work that records decisions from product work that merely formats them. The function survives. Many roles as currently practiced will not. As output gets cheaper, the scarce work becomes deciding what matters, understanding customers, making trade-offs, and owning the consequence when the recommendation is wrong.

The floor went up

For years, a lot of PM work looked valuable because the artifacts looked valuable. A well-formatted PRD suggested clarity. A roadmap deck suggested strategy. A business case suggested rigor. A research synthesis suggested customer understanding. Sometimes those artifacts carried real thinking. Often they carried ambiguity in a cleaner container. AI changes that bargain.

If everyone can produce a competent-looking PRD, the PRD no longer proves much. If every team can generate ten analysis cuts, the analysis no longer creates advantage by itself. When every stakeholder request can become tickets, FAQs, launch plans, and update docs by the end of the afternoon, artifact volume stops being a signal of product value. In many product tasks, the floor rises. The ceiling matters more.

This is why the strongest PMs are protected by their ability to make the documents mean something, not by their ability to write better documents. A high-judgment PRD says: we are solving this problem, for this customer, now, because this evidence changed our view. We are not solving these adjacent problems. We accept these risks. We will know we were wrong if this signal moves. A low-judgment PRD says: there is an opportunity to improve the user experience. AI can produce both. Only one is product management.

The artifact is not the problem

It is tempting to say AI automates artifacts and humans keep judgment. That is too clean.

Artifacts matter. Specs, tickets, roadmaps, research summaries, and stakeholder updates create shared reality. They force teams to write down assumptions. They help engineers, designers, sales, support, and leadership coordinate around the same decision. The problem is not the artifact itself. What matters is whether the artifact avoids the decision.

A roadmap deck can be high-judgment if it explains why the company is choosing one market over another. A ticket can be high-judgment if it constrains scope around the smallest useful version. A research synthesis can be high-judgment if it separates a loud anecdote from a recurring pattern. But a deck that lists every stakeholder priority is not strategy. A ticket that translates a request without challenging it is not product work. A synthesis that treats correlation as causation is not insight.

AI can also make shallow work easier to hide, at least for a while. A flood of polished documents can overwhelm scrutiny. That is why teams need to look past format and ask what decision the artifact changed. When they do, AI makes the gap harder to ignore because the container is no longer scarce. The remaining question is whether anyone made the call.

The new scarcity is selection

When production gets cheaper, selection gets more valuable. A PM asks AI to draft a PRD from research notes. The tool produces structure, user stories, success metrics, and risks. A low-judgment PM forwards it for review. A high-judgment PM asks harder questions: which customer problem does this actually solve? Which segment matters most? Which metric would prove value instead of activity? What feature should we remove because it does not serve the core use case? Same artifact. Different work.

Or take analysis. A leadership team gets three polished AI-generated reads on churn. One says churn rose because of a recent product launch. Another points to seasonality. A third points to segment mix. All three sound plausible and cite data. None of them is the decision. The PM’s job is to decide what evidence is causal enough to act on, what remains uncertain, and what change the team will make despite incomplete information, not to admire how well the AI synthesized the data. AI can surface patterns and rank inputs. It can summarize every customer call and every support ticket. But surfacing information is not the same as deciding what matters.

The order-taker PM is exposed

The most exposed version of product management is the order-taking version. This PM receives stakeholder requests, converts them into PRDs, writes tickets, attends meetings, routes status, and produces updates. They may be busy, responsive, and keep the machine moving. But if they do not bring customer evidence, clarify the problem, define trade-offs, challenge scope, or own the outcome, AI can do much of the visible work. In fact, AI may do it faster and with better formatting.

That does not mean the person is lazy or useless. Many organizations trained PMs into this shape. They rewarded responsiveness over judgment. They treated PMs as coordination buffers between executives, engineering, design, sales, and customers. They asked for more documentation instead of clearer decisions. AI exposes that operating model when leaders stop rewarding volume and start looking for accountable decisions.

A stakeholder asks for “just a quick feature.” AI can instantly create a PRD, tickets, a launch plan, a sales FAQ, and a stakeholder update. The product question is still untouched: should this exist, for whom, at what cost, and what will we stop doing? That is the line. If the PM’s value is producing the package around the request, the role is vulnerable. If their value is changing the quality of the decision, the role becomes more important.

Headcount can shrink while judgment gets more valuable

There is a hard truth inside this argument: saying product judgment remains valuable does not mean PM headcount stays stable.

Some AI-native companies are already testing smaller product teams, founder-led product judgment, and prototype-first workflows. Some larger companies are asking a related question: before adding people, what would this area look like if AI agents were already part of the team? These are early signals, not proof of a broad law.

The likely outcome is fewer PMs in some contexts doing work with higher impact, plus more product judgment distributed across founders, engineers, designers, data people, and operators. That last point needs care. Product judgment is a function, not always a job title, but it does not distribute itself. If no one owns customer reality, scope, trade-offs, and the cost of being wrong, the company has not distributed product judgment. It has abandoned it.

In a small AI-native team, a technical founder or senior engineer may own customer reality, prioritization, and trade-offs without a dedicated PM. But in a large company with multiple markets, complex dependencies, and high switching costs, the PM function becomes harder to compress. The question is not “will there be a PM in the room?” The question is: who owns the product judgment?

Strong PMs will use AI more, not less

The answer is not to avoid AI. That would miss the whole shift.

The most effective PMs will use AI aggressively to create options, speed up synthesis, test prototypes, draft first versions, inspect edge cases, and reduce the cost of being wrong early. A PM working on activation might ask AI for ten onboarding variants, generate rough prototypes, summarize recent support tickets, and draft an experiment plan. That is useful. But the product work starts when the PM chooses which customer segment matters, which friction is worth removing, which metric proves progress, and which variant should not ship because it teaches the wrong behavior.

When prototypes are cheap, the PM does not prove value by writing a perfect spec before anything exists. The PM proves value by noticing which experiment deserves more attention, which behavior from users matters, which trade-off the team is about to miss, and which promising demo should not become a product. AI changes the operating model from artifact-first to judgment-first.

It also changes the PM’s relationship to implementation. A technically fluent PM can use AI to explore a prototype, write a precise spec for a bounded change, or understand a code path well enough to ask better questions. But in large-scale production systems, code safety remains engineering work. The PM’s job is to choose the right task, define the right boundary, and preserve expert review, not to pretend expertise in engineering.

AI can also weaken the judgment it rewards

There is a trap here: the PM who uses AI to multiply thinking gets stronger, while the PM who uses AI to replace thinking gets weaker.

This is the risk behind polished work slop. AI-generated professional content can look competent while being hollow. A PM can ask for a research synthesis and receive a confident summary that strips out the messy customer context. They can ask for prioritization and receive a ranked list that reflects broken inputs, biased surveys, incomplete event tracking, or a taxonomy nobody trusts. They might ask for strategy and get a plausible memo that says nothing risky enough to matter.

The real threat is that the PM stops building the muscles to know when the output is wrong. If AI does all the synthesis, the PM loses contact with the raw material. They stop hearing the customer’s phrasing, noticing what sales and support disagree about, and forming the pattern recognition that later looks like taste.

AI should widen the PM’s context, not narrow it into a private prompt loop. That means adding friction in the right places. Before reading an AI-generated research synthesis, write down what you expect to be true based on the last customer conversations you personally heard. When AI clusters feedback, require specific quotes or source links and spot-check the raw material. When it ranks priorities, ask what data is missing, who disagrees, and what the model cannot know from the prompt.

The best PMs will use AI as a thinking partner and production accelerator. They will still talk to customers, argue with engineers, inspect the data, and decide.

The product judgment test

A task is not high-judgment because it has a strategic-sounding name. Someone calling it “strategy” does not make it strategy. A task is not low-judgment because it produces a document. The same PRD can be either, and so can the same roadmap review or AI-generated prototype. Use this test instead.

A product task requires real judgment if it answers at least one of these questions:

1. Customer reality: what first-hand customer evidence changes the decision?
2. Problem selection: is this the right problem to solve now?
3. Trade-off: what are we choosing not to do?
4. Causality: do we know what is driving the signal, or only what correlates with it?
5. Scope: what is the smallest useful version that preserves the customer value?
6. Accountability: who owns the call if the recommendation is wrong?
7. Taste: which of several plausible options is actually worth making?
8. Cross-functional truth: what would engineering, design, sales, support, or customers see that the prompt did not include?

That test changes how teams should assign work: ask AI to draft the PRD, but do not ask it to decide whether the PRD should exist. Ask AI to cluster the research. Do not let the cluster replace customer understanding. Ask AI to generate prototype directions. Do not confuse having ten options with knowing which one deserves the roadmap. Ask AI to summarize stakeholder feedback. Do not mistake consensus for strategy. Ask AI to find signals in the data. Do not let a confident synthesis become causal proof.

Before generating the artifact, ask what trade-off the artifact must record. Before trusting the synthesis, ask what customer reality or cross-functional context the prompt did not include. Before adding headcount, ask which judgment the person will own that AI cannot be accountable for. Before cutting PM headcount, ask who will own customer reality, scope, trade-offs, and the cost of being wrong.

What to do on Monday

If you are trapped in a low-judgment environment, do not start by announcing a new philosophy of product management. Start by changing the artifact.

In your next PRD, add a section called “The trade-off.” Name what you are choosing not to do and why. If there is no trade-off, the PRD may be a delivery note, not a product decision. In your next stakeholder request, answer with the customer evidence you would need to justify it. You can still be responsive. The difference is that you are moving the conversation from preference to proof. In your next AI-generated synthesis, force the output back to source material. Ask for the three customer quotes, data cuts, or support examples that would change the recommendation. Then check at least one yourself.

These are small moves. They retrain the organization to expect judgment inside the work, not decoration around it.

The practical future of PM work

The future PM will spend less time proving they can produce artifacts and more time proving they can improve decisions. That changes what companies should value. Do not measure PMs by document volume. Measure whether they clarify customer reality, reduce wasted work, make trade-offs explicit, and improve decisions under uncertainty.

Do not celebrate AI adoption because teams produce more. Ask whether they learn faster. Do not replace product judgment with AI-generated prioritization. Use AI to reveal more options, then hold someone accountable for choosing.

That does not rescue low-judgment PM work. It raises the bar. More product surface area means more need for people who can decide what matters, not more tolerance for people who can format ambiguity. AI will make product work faster. That is exactly why product judgment matters more. When building gets cheaper, building the wrong thing becomes harder to excuse.

If you work in a large organization, you already know this, even if you have never named it. Most organizations have two versions of the same workflow. One appears in the process map. It has swim lanes, systems of record, approval paths, owners, and service-level expectations. The other lives in the work itself: the spreadsheet someone updates every morning because the dashboard cannot be trusted, the Slack thread that becomes the escalation path, the email chain where decisions happen, and the person every new hire learns to ask because she knows which exception matters.

Leaders often dismiss these workarounds as disorder. Some are exactly that. A few create compliance, safety, privacy, quality, or control risk and need to be corrected, not celebrated. But many workarounds are evidence of a missing operational capability. They show where process, data, ownership, judgment, and systems have drifted apart. That is where AI strategy should often begin.

For COOs, CIOs, transformation leaders, and AI program owners, the question is not where AI can be inserted. The question is where the organization has already invented unofficial work to compensate for missing capability. A missing operational capability is a recurring need the official workflow cannot satisfy: trusted data, accountable ownership, timely escalation, exception handling, cross-functional translation, decision rights, or usable visibility. A use-case list says what AI might do. A roadmap says which workflow constraints must change for AI to matter.

The next wave of agentic AI makes this more urgent. Organizations are being asked to approve agents that route work, prepare decisions, trigger actions, and coordinate across systems. If those agents are pointed at the visible artifacts of broken workflows, they may make the artifacts cheaper while leaving the operating problem intact. I have seen this play out enough times that it is now the first place I look.

The green dashboard problem

Consider a composite example from manufacturing. A production dashboard is green. The formal system says the process is healthy. But three people are watching three different systems. A camera feed shows something odd, but nobody owns the camera. No work order opens. No escalation rule triggers. A Slack channel fills with messages. Someone prints a screenshot. A huddle forms only after the line stops.

The dashboard did not fail because it was green. It failed because the real workflow was somewhere else. The real workflow was in the judgment that the camera mattered, the confusion about who owned the signal, the Slack thread that became the escalation path, and the human huddle that made a decision after formal mechanisms did not.

That is the conformance gap: the difference between the workflow as designed and the workflow as executed.

AI strategy often skips this gap. A team sees the Slack chaos and asks whether AI can summarize the thread. Someone sees the screenshot and asks whether computer vision can detect the issue. Another person sees the huddle and asks whether an agent can schedule meetings faster. Those questions may be useful later. They are not the first questions.

The first question is: why did the formal workflow fail to convert an observed signal into accountable action? The answer might be better instrumentation, clearer ownership, an escalation rule, workflow-native alerting, AI-assisted exception detection, or a change to the operating rhythm. In many cases, automating the visible artifact before addressing the underlying gap preserves the broken workflow at higher speed. In a few cases, automation can surface the failure and force redesign. Either way, the artifact is the clue, not the diagnosis.

The artifact is usually not the real problem

Workarounds announce themselves as artifacts: a 20-tab Excel dashboard, a daily status email, a duplicate tracker, a personal checklist, a side approval path, a risk log, a standing meeting, a shared spreadsheet that everyone pretends is temporary. The artifact is tempting because it is visible. You can point at it, count it, and imagine an AI tool producing it faster.

But the problem is rarely the spreadsheet. The problem is what the spreadsheet has been forced to become.

In frontline logistics, teams share spreadsheets and scheduled daily emails because the formal system does not give them enough confidence about tomorrow’s execution. Supplier updates sit buried in email. People reconcile status manually because no trusted communication layer shows what changed, who owns the next step, and what risk needs attention.

In a go-to-market handoff, the workaround might be a meeting between marketing and sales because the systems disagree. One team defines a lead one way. Another team reports pipeline another way. A CSM checks accounts in a separate place. The handoff depends on memory, relationships, and clarification after the fact. Adding AI to summarize the meeting does not fix unclear routing, missing fields, conflicting reports, or undefined response rules.

The same is true of the “ask Sarah” dependency. Sarah appears to maintain updates, send summaries, clean up docs, run coordination meetings, and remember the status of every exception. But Sarah is reading weak signals. She knows which stakeholder will object. She translates between teams that use the same words differently. She absorbs role ambiguity. She carries informal legitimacy that no system has been given. An AI system can draft Sarah’s update and summarize her meeting. It can generate a risk log. That may give Sarah more capacity for higher-value work. But if the organization has not captured the judgment, trust, timing, legitimacy, and informal feedback loops that made Sarah’s work matter, the AI will make the artifact cheaper and miss the capability.

Preserve the signal, not the workaround

This argument has a hard boundary. Some workarounds are not clever adaptations. They are control failures.

In financial services, regulators have fined major institutions after employees used private messaging apps and personal channels for business communications outside required record-keeping systems. That was a compliance failure, not a shadow workflow to productize.

Healthcare offers a different warning. Research on electronic health record workarounds has found that locally rational behavior can harm patient safety, quality, and efficiency at the system level. Clinicians may bypass a system to complete urgent work, but the workaround can break the audit trail, hide risk, or create downstream errors.

This is why leaders need a triage gate before they treat any workaround as an AI opportunity. If the behavior touches safety, regulated records, privacy, security, financial controls, auditability, or deliberate circumvention, the response starts with risk review, correction, and governance. A behavior that would not pass an audit should not be renamed innovation. If a person could be disciplined for the behavior, do not productize it before the control issue is resolved.

Workarounds are evidence. Evidence can show a missing capability. It can also show unsafe behavior, misconduct, poor training, user resistance, or a control design that people have learned to evade. The work is to tell the difference.

Why AI makes the gap matter more

Before AI, a broken workflow created human cost. People copied data, reconciled reports, chased approvals, sent reminders, and sat in meetings to rebuild context the system should have carried.

Now AI risks amplifying the cost of those failures when leaders misunderstand the work. The evidence on the magnitude of that effect is still developing, but the mechanism is straightforward. AI can produce more reports nobody acts on, route tasks through systems without clear owners, make recommendations from data nobody trusts, and automate approvals without knowing which exceptions require judgment.

McKinsey’s March 2025 State of AI survey found that workflow redesign was the attribute most strongly associated with reported EBIT impact from gen AI among 25 attributes tested. The same report found that only 21% of respondents at organizations using gen AI said their organizations had fundamentally redesigned at least some workflows.

That does not prove workflow redesign causes AI value. Organizations with stronger AI results may simply be more likely to redesign workflows, or another factor may explain both. But the finding is consistent with a practical lesson: AI value is tied to how work changes, not just whether tools get deployed.

Gartner has issued a related warning. In June 2025, it predicted that more than 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value, inadequate risk controls, or insufficient data quality. Gartner also warned that many use cases marketed as agentic do not need agentic implementation.

These are not abstract readiness categories. They show up in workarounds every day. A reconciliation spreadsheet is often a trust problem. A daily email is often a signal problem. An approval thread is often a decision-rights problem. An “ask Sarah” dependency is often an undocumented-judgment problem.

This is why workaround analysis is different from generic AI brainstorming. It begins with operational evidence. It asks where people already had to invent a shadow workflow to keep the business running, then tests whether fixing that workflow would change something that matters.

Before and after, treated carefully

Public examples are imperfect because many come from vendors. They are still useful when treated as illustrations, not neutral proof.

Axis Bank is one useful case. According to a Microsoft customer story, the bank had manual, email-based, and spreadsheet-driven workflows across branch operations, audit, finance, compliance, and approvals. These were not random bad habits. They signaled missing structured tracking, governance, visibility, and reusable workflow ownership. Axis Bank built a Power Platform Centre of Excellence and scaled governed low-code workflows. Microsoft reports that the bank created more than 120 solutions, reached more than 50,000 users, processed more than 100,000 transactions per month, and reduced operational latency by 40%.

The lesson is not “replace spreadsheets with apps.” What the shadow workflow revealed was a capability gap: structured tracking, governed workflow design, reusable components, and a clearer operating layer.

A similar pattern appears in finance operations. A ServiceNow customer story says Standard Chartered’s Global Finance Operations team moved multiple spreadsheet- and email-based processes into automated workflows, improving transparency and traceability and saving more than 16,800 annual hours. Again, the spreadsheet was not the diagnosis. It was the clue.

The shadow workflow diagnostic

Leaders need a practical way to turn shadow workflows into decisions. Not every workaround deserves investment, not every painful task is worth automating, and not every AI candidate is ready. In my experience, the following diagnostic helps teams decide what a workaround means and what response it deserves.

1. Triage the risk

Before diagnosis, screen the workaround. Does it involve safety, regulated records, privacy, security, financial controls, auditability, or deliberate circumvention? If yes, treat it as a risk issue first. The question is not, “Can AI make this easier?” The question is whether the behavior violates a control or creates unacceptable risk.

2. Observe the workaround

Capture the behavior without judging it too early. Ask what official workflow people bypassed, who uses the workaround, when it happens, what decision or exception it supports, what data people recreated, who became the informal owner, what artifact it creates, and what risk it introduces.

This step matters because many organizations diagnose from complaints instead of evidence. “The CRM is bad” is not enough. “Sales managers export pipeline data every Friday, reconcile it in a spreadsheet, and use that version in the forecast call because they do not trust stage definitions in the CRM” is evidence. Now there is something to study.

3. Measure friction and value

Score the pain, but do not stop there. Look at frequency, labor, delay, error risk, dependency load, and business value.

A workaround that forces 200 employees to copy data across systems every day deserves a closer look. It may also be the best available solution under current constraints. Frequency signals importance. It does not prove the answer.

Every candidate needs an outcome hypothesis. What should change if the workaround is fixed: cost, margin, cycle time, revenue, risk, quality, employee capacity, or customer experience? If no important measure changes, set it aside.

4. Diagnose the capability gap

Name the reason the workaround exists. Most shadow workflows trace back to one or more gaps: data, trust, visibility, ownership, platform fit, judgment, or governance.

A data gap means the system lacks needed information. A trust gap means people do not trust the data, default decision, or approval path. A visibility gap means nobody can see status, ownership, risk, or progress. An ownership gap means roles, queues, escalation paths, or service boundaries are unclear. A platform-fit gap means the system tracks records but does not support the flow of work. A judgment gap means the workflow depends on expertise, interpretation, or legitimacy that has not been captured. A governance gap means review, approval, audit, override, or risk controls are not explicit.

This is where many AI programs go wrong. They identify an artifact, skip the root cause, and automate the artifact.

Take access requests. A request may involve a ticket, an application owner, a manager, billing, license availability, and security review. The tempting answer is an AI agent that approves access. The better answer separates the routine path from the judgment path. If 90% of requests match clear rules, automate that path. If 10% require a real decision, escalate them with context. The goal is to stop wasting human judgment on cases that do not need it while making the real exceptions more visible, not to remove approval altogether.

5. Classify the response

Choose the response before choosing the technology. A workaround may need to be eliminated, standardized, governed, redesigned, integrated, productized, automated, AI-enabled, or deferred.

High-friction, high-value workarounds with high readiness are prime opportunities. Those with low readiness are strategic dependencies: fix the data, ownership, controls, integrations, or process clarity first. High-friction, low-value workarounds are local efficiency problems. Simplify them, template them, or automate lightly. Low-friction, high-value workarounds are risk watches. Monitor, govern, instrument, or clarify ownership. Low-friction, low-value workarounds are noise.

“AI-enable” should trigger a readiness check. Is the data searchable, reusable, and trusted? Are the relevant systems connected? Are decision rights explicit? Are identity, access, authorization, and delegation governed? Can the organization monitor what the AI did and why? Are exceptions defined? Do users understand how their work will change? Is there a business metric tied to the change? If those answers are weak, the opportunity may still be real. It is just not ready.

Not process mining with a new name

Organizations already have ways to study work. Process mining uses event logs to show how processes run through systems. Task mining captures lower-level user activity: application use, clicks, spreadsheets, websites, and repeated desktop behavior. AI use-case workshops gather ideas about where AI could help. All three can be useful.

Shadow workflow analysis asks a different question: what recurring need does the official workflow fail to satisfy? It is especially useful where the important work happens outside clean event logs: judgment calls, verbal handoffs, political navigation, trust gaps, informal escalation, side spreadsheets, and expert dependencies. Process mining shows where work moves inside systems. Shadow workflow analysis shows where the human system repairs what the official system cannot handle. Use both when both are available.

Psychological safety is evidence quality

Shadow workflow discovery fails if people think it is surveillance, blame assignment, or a pretext for replacement. Call it a data-quality point instead of a soft culture point.

If surfacing a workaround feels like volunteering for punishment, the useful evidence will stay hidden. People will clean up the story before they tell it, describe the official process instead of the lived one, and protect the spreadsheet that protects them.

Harvard Business Impact, drawing on Amy Edmondson’s work, defines psychological safety as the ability to ask questions, admit mistakes, and challenge ideas without fear of embarrassment or retribution. In this context, the practical rule is simple: leaders must frame the inquiry as a study of where the system of work fails the work, not where employees failed the system.

That means a few operating rules. Name the purpose before collecting examples: “We are studying where the system forces workarounds, not who broke the process.” Separate discovery from discipline, unless a safety or legal issue requires escalation. Collect patterns before names. Protect the practical expert. The person everyone asks for help is often compensating for missing translation, context, or decision rights.

Make the response menu explicit. The outcome is not automatically automation or headcount reduction. It might be eliminating duplicate work, governing a risky behavior, redesigning a handoff, integrating systems, productizing a local practice, or deferring until the basics are fixed.

Show one closed loop quickly. Pick one low-risk workaround, diagnose it with the team, remove friction, and report back. Trust turns shadow workflow discovery from confession into repair.

The better AI question

The weakest AI strategies ask, “What can AI automate?” A stronger question is, “Where has the organization already created a shadow workflow because the official workflow cannot support the work?”

The strongest question is more precise: what failure made this workaround necessary, and what response would remove, govern, redesign, or productize the need for it?

That question forces leaders to slow down in the right place. It separates artifacts from causes, friction from value, opportunity from readiness, and useful adaptation from dangerous circumvention. It also respects the people doing the work.

A workaround is often a sign that someone cared enough to keep the business moving despite a system that did not fit the job. But respect does not mean preservation. Some workarounds should become supported capabilities, some should become governed workflows, some should disappear, and some should remain deliberately human with better tools around them rather than a new bureaucracy on top of them.

The person maintaining the spreadsheet, the team working in Slack after the dashboard stayed green, and Sarah carrying the unofficial map of how work gets done are not side characters in the AI strategy. They are showing leaders where the official system has lost contact with reality.

Follow that signal carefully. Protect the people who reveal it. Then decide what should be removed, governed, redesigned, productized, automated, or left human. The workaround is the clue, not the strategy.

The worst AI question is also the most common one: “How do we use AI?”

It sounds responsible. It sounds urgent. It sounds like the kind of question a leadership team should ask when the board, investors, or an executive offsite demands proof that the company is moving fast. But it points the organization in the wrong direction. Once the question starts with AI, the answer usually becomes activity: pilots, tools, demos, task forces, infrastructure programs, and slide decks showing where AI might fit. Some of that work teaches. Most of it never turns into value.

A real AI strategy starts somewhere less glamorous: with painful customer or business problems. It asks which workflows are expensive, slow, repetitive, judgment-heavy, document-heavy, or hard to coordinate. Then it asks whether AI changes what is now possible, whether the value is measurable, and whether the solution can survive production.

That distinction matters now because the first wave of enterprise AI experimentation is running into a wall of unrealized business impact. Gartner’s 2025 IT spending research found that failed AI proofs of concept commonly break down because they do not demonstrate value, reveal additional needs too late, or fail to show enough business impact. Other industry research points in the same direction: many AI leaders are under pressure to justify investments that still have not produced the returns executives expected. AI can create value. The issue is that many organizations confuse AI activity with AI strategy.

AI activity looks productive until it has to produce

Picture the pattern. A board asks the CEO, “Where is our AI strategy?” The CEO turns to the executive team. The executive team turns to business units, IT, product, and outside consultants. Soon the company has 20 proofs of concept.

One pilot summarizes customer calls. One adds a chatbot to an internal portal. One drafts sales emails. One searches policy documents. One promises to automate reporting. The demos look polished. The steering committee sees motion. Everyone can say the company is doing AI.

Then the hard questions arrive. Which customer pain does this solve? Which business metric moves? Who owns the workflow after the pilot? What data does it need? What happens when the system is wrong? Who approves production access? How does this affect cost, throughput, revenue, risk, or retention? Too often, no one has a good answer.

This is why “how do we use AI?” is such a dangerous starting point. It sends teams looking for places to attach the technology instead of problems worth solving. It rewards visible experimentation, not disciplined selection. The failure data points in the same direction: AI initiatives often stall because they fail to demonstrate value, lack sufficient business impact, or uncover additional needs too late. That does not mean the starting question is the only cause. Data readiness, governance, integration, risk, ownership, and change management all matter. But starting with AI makes those problems easier to avoid until the demo is over.

A proof of concept asks “can we make this work?” A proof of value asks “does this change anything that matters?” Most AI strategies need fewer proofs of concept and more proofs of value.

The better starting point is painful work

The strongest AI opportunities often begin with boring work. Not visionary work. Not brand-new work. Not work that makes for the most exciting demo. The best candidates are the tasks people already hate: reading documents, comparing reports, cleaning spreadsheets, routing exceptions, checking status across systems, preparing summaries, reconciling records, drafting first-pass responses, or finding the few issues that deserve human attention.

These workflows share a pattern. They are repetitive enough to matter, but not simple enough for older automation. They involve text, judgment, messy inputs, unstructured data, or context spread across systems. They waste time, but they also require enough interpretation that a basic rule or script could not handle them. That is where current AI capabilities change the economics of work.

A customer does not wake up wanting an AI feature. They want to get rid of the spreadsheet, stop digging through reports for three hours, have fewer manual follow-ups, or see a claim, invoice, ticket, or underwriting file move faster without losing control. The same logic applies inside the company. A workflow owner can usually name the pain before anyone mentions AI: “Our onboarding takes too long.” “The system says we have inventory, but the warehouse cannot find it.” “Managers spend hours reading reports before they know what to fix.” “Our team handles the same customer exceptions every day.” “People are copying data between tools because the systems do not talk.”

Those symptoms are strategy inputs. They tell you where work is breaking, where cost hides, and where current tools have failed. AI strategy begins when the team stops asking where AI can fit and starts asking what work should change.

AI is not the differentiator. Redesigned work is.

For a while, saying “we have AI” sounded like a product strategy. That window is closing. As generic AI tools become widely available, access to AI stops being the source of advantage. The durable advantage comes from workflow design, domain expertise, proprietary data, operational discipline, and a clear understanding of customer constraints.

That explains why so many AI features feel thin. A vendor adds an AI widget to the corner of a product. A team embeds a chatbot into a workflow no one wanted to use in the first place. A product markets itself as agentic without changing the actual customer outcome. The AI model is visible. The value is not.

The stronger pattern hides the AI model behind a solved workflow. In insurance, for example, the valuable work is not “ChatGPT for underwriting.” The valuable work is reading documents, extracting context, identifying missing information, comparing details, preparing the file, and reducing the busy work before a regulated human decision. In that setting, the system does not need to replace the decision maker to create value. It needs to make the decision path faster, clearer, and more reliable.

That is the strategic shift. The question is not “where can we add AI?” The question is “what work can now be redesigned because machines can interpret language, documents, patterns, and context at scale?”

Pain is necessary, but not enough

Problem-first does not mean “pick a painful workflow and start building.” That is still too loose. A painful problem can fail as an AI initiative for at least five reasons.

First, the use case can be too small. Saving 26 minutes a day for one person may be useful, but it does not automatically create a financial case. CFOs will ask whether the time savings become lower cost, higher throughput, faster revenue, better retention, reduced risk, or avoided hiring.

Second, the use case can be too complex. Some workflows need too many integrations, too many permissions, too much judgment, or too much exception handling to make sense as an early project.

Third, the data can be unready. Generic AI tools do not fix broken enterprise data. If the required data is fragmented, low quality, trapped in legacy systems, or governed inconsistently, the AI system inherits the mess.

Fourth, the risk can be wrong. The more useful an AI system becomes, the more important access controls, monitoring, escalation paths, and human review become. A summarizer with no system access has one risk profile. An agent that can update records, send messages, or trigger transactions has another.

Fifth, the pilot can fail at production. A demo can work with clean examples and still fail when it meets real users, edge cases, security rules, latency requirements, audit needs, and workflow ownership.

This is where many AI strategies collapse. They mistake relevance for readiness. A problem-first approach removes one kind of failure: building something no one needs. It does not remove the harder failures of data readiness, integration, governance, change management, and measurement. That is why the strategy cannot stop at problem selection. It has to test whether the problem can become a production system.

The value-readiness gate

Before the next AI initiative gets budget, it should pass a simple test. Not a 60-page business case. Not a theoretical AI roadmap. A practical set of questions that force the team to move from AI activity to strategy.

Problem and value fit

1. What painful customer or business problem are we solving? If the answer starts with the technology, stop. A strong answer names the pain in operational terms: manual report review, delayed claims processing, duplicate data entry, slow customer follow-up, inventory mismatch, document comparison, exception routing, or hours spent searching across systems. The problem should be painful enough that someone already feels it.

2. Why can AI solve this better now than older tools or processes could? AI is not better for every problem. It is more likely to matter when the work involves unstructured data, language, pattern recognition across large datasets, judgment support, or context spread across many sources. If a rules engine, workflow tool, dashboard, or process fix solves the problem more simply, use that. AI is not the goal. Solving the problem with the right tool is.

3. Who experiences the value, and what KPI proves it? User delight is not enough. Time savings are not enough unless they convert into something the business can measure. The value might show up as lower cost per case, higher cases per employee, faster cycle time, fewer stockouts, reduced external agency spend, better first-contact resolution, lower risk, or avoided backfill. Different problems need different metrics.

This is where the CFO becomes useful, not obstructive. Finance forces the team to define whether the gain is real, measurable, and worth scaling. A useful pressure test is simple: if the value case converts time saved into financial return, who has already agreed that time saved will change headcount, throughput, spending, or capacity?

Workflow and operating fit

4. What workflow, task, or decision will actually change? A strategy-grade initiative changes work. It might reduce the number of steps in a claim review. It might prepare an underwriting packet before a human decision. It might route customer issues automatically when confidence is high and escalate uncertain cases when confidence is low. It might turn four hours of seller research into 15 minutes of account preparation. If the team cannot say what changes in the workflow, the initiative is still a concept.

5. What data, systems, permissions, and integrations are required? This question separates demos from deployable systems. A customer-service agent that only suggests responses has one set of requirements. A self-directed system that resolves issues across billing, shipping, and CRM systems needs governed data access, identity controls, audit trails, permissions, and integration with core systems. Many failed AI projects do not fail because the model is weak. They fail because the surrounding system is not ready.

Risk and production fit

6. What risks, guardrails, and human review points are needed? The right level of autonomy differs by workflow. Some tasks can be automated end to end. Some should be drafted by AI and approved by a person. Some should use AI only to focus human attention on the right issue. Some should not be automated at all. In regulated workflows, the best design often separates preparation from judgment: AI can read, summarize, compare, flag, and route, while a human still makes the final decision. Good strategy names that boundary before deployment.

7. What has to be true for this to move from demo to production? This is the question most pilots avoid. Production means ownership, support, controls, measurement, training, feedback loops, and exception handling. It means the system works when data is messy, when users push back, when the answer is uncertain, and when the workflow crosses departments. A pilot that cannot answer this question is not ready to scale. It may still be useful for learning, but it should not be mistaken for strategy.

The seven questions do not prove the project will succeed. They do something more immediate: they reveal whether the team is ready to spend real money, or only ready to produce another impressive demo.

The counterargument is real: infrastructure matters

Some technology leaders will object to the problem-first frame. They will say an AI strategy has to start with data infrastructure, governance, security, and platform investment. They are partly right. If the company’s data is siloed, untrusted, poorly governed, or trapped in decades-old systems, no problem-first workshop will magically create production value. Some organizations need serious work on data ownership, lineage, access controls, integration, and platform architecture before AI can scale.

But that does not make the argument infrastructure-first instead of problem-first. It means the two have to meet. Platform investment needs a portfolio of real problems to justify its shape. Problem selection needs infrastructure reality to avoid fantasy. The mistake is treating them as alternatives.

The same distinction applies to experimentation. Some organizations need early AI pilots to build literacy, test governance, and learn what the technology can do. That is legitimate capability building. But capability building has to be named as such. It is not the same as claiming the company has a value-producing AI strategy. Experimentation teaches. Strategy selects.

Before you fund the next AI initiative

A good AI strategy does not look like a list of tools to test. It looks like a set of operating choices. It names the painful workflows worth changing. It explains why AI changes the solution space. It defines the business value before the build. It decides where the human stays in the loop. It identifies the data and systems required. It names the risks and controls. It sets the threshold for production.

That kind of strategy can still move fast. Problem-first does not mean slow. It means directed. A team can pressure-test the value-readiness gate in a short sprint, then decide where deeper discovery is needed. The point is to stop funding initiatives that cannot explain why they should exist, not to bury AI work in analysis.

This is also how companies find stronger opportunities. Much of the highest-return work in enterprise AI will not be where budgets first went. Back-office automation, operational workflows, and domain-specific work often create more value than visible front-office experiments because the pain is clearer and the work is closer to cost, capacity, and throughput. That should not surprise anyone who has watched enterprise software closely. In large organizations, the most valuable technology frequently starts in the least glamorous workflow.

Before asking “how do we use AI?” ask “what painful work deserves to change?” Before calling something strategy, ask whether it can pass the proof-of-value test. An AI idea says “here is where AI fits.” An AI strategy says “here is the problem we are solving, why AI changes the answer, what work will change, how value will be measured, and what must be true for this to run in production.” That is the difference between looking serious about AI and doing serious work with it.