Enterprise AI

Adoption changes the operating model

Enterprise AI includes predictive applications, such as identifying suspicious transactions, and assistance that drafts or interprets information. An agent can also choose actions and tools within a delegated task; Agent Engineering explains that mechanism. Enterprise AI predates generative assistants: the OECD’s workplace surveys, conducted mainly in early 2022, examined applications including fraud detection, visual inspection and predictive maintenance. These capabilities change different parts of a job, but do not determine how the surrounding organization should work. [1][2]

Adoption means sustained incorporation into intended work. Providing accounts establishes availability; occasional activity establishes some use. Neither establishes that people complete the intended work effectively. Useful adoption also requires appropriate reliance: recognizing unsuitable tasks, checking consequential outputs and obtaining help when necessary. The UK government’s human-centred adoption guidance makes these distinctions explicit. [3]

An operating model is the arrangement through which an organization delivers work: its people, processes, information systems, suppliers and management decisions. The Operating Model Canvas makes those arrangements visible together. An assistant that prepares a response changes only part of this model if another department still controls approval, maintains the governing policy and handles complaints. [4]

Making that assistant useful requires more than better drafts: staff need the governing information, time to review and authority to resolve exceptions. These supporting skills, procedures, information and authority are organizational complements. Together, people’s working arrangements and the technology form a sociotechnical system. Joint optimization means designing both together so that an improvement in one does not impair the whole. Trist’s account of sociotechnical design also shows why this can be contentious: changing how work is performed can redistribute discretion and responsibility. [5]

Expand ⤢

This makes enterprise adoption different from finding and validating a new product under small-team constraints. Existing services must keep working while their arrangements change. A useful warning comes from Build Dynamic Products, and Stop the AI Sideshow: a separate technology agenda can produce features disconnected from customer needs. Central capabilities can help, but their purpose must remain connected to the outcome the operating teams deliver. [6]

What earlier automation taught

Enterprise AI inherits several enduring problems: organizing work around new equipment, acquiring specialist knowledge, removing unnecessary activity and paying for changes whose benefits arrive later. These contributions developed in different settings. They explain continuing responsibilities, not successive stages that every organization must pass through.

The recurring issue is the relationship between a technical capability and its operating conditions. Contemporary workflow design still distinguishes prescribed paths from agents that choose their next actions dynamically. More discretion can add flexibility, but also cost and opportunities for error. Building effective agents recommends choosing that discretion for the task, rather than treating autonomy as the destination of every deployment. [2]

Agree on the change boundary

Start with a completed outcome and the difficulty preventing it. A process owner coordinates the end-to-end result, with authority to negotiate changes or an explicit route to obtain that authority. Ownership of a drafting tool is narrower than ownership of successful case resolution. A small technical change may therefore require agreements with teams outside the implementation group. [4]

Discovery supplies the facts for that agreement. Observe actual handoffs and exceptions, not only the documented normal path. Vasuman Moza’s field-engineering account emphasizes asking process leads what happens when work goes wrong. The methods belong in Learning from work as it happens and Change the process before automating it; here their output becomes a negotiated boundary. [10]

A baseline records how the work currently performs. Acceptance criteria specify the outcomes and constraints the change must satisfy. A value hypothesis connects the proposed intervention to an expected improvement: for example, assistance might reduce preparation effort without increasing specialist correction. Define this before comparing models. Domain-expert examples and acceptable outcomes then make model comparisons relevant to the actual use. [11]

Assess frequency, mistake consequences, knowledge availability and whether outcomes can be observed. A disputed policy may need clarification before automation; a fixed transformation may need ordinary software. Retaining the current process is also a legitimate decision when expected gains do not justify the burden or risk. NIST’s risk-management core explicitly includes non-AI alternatives and decisions not to proceed. [13]

Improve the whole flow

A value stream includes the actions and information needed to deliver an outcome, including work that adds no customer value. Rother and Shook’s Learning to See distinguishes improving this complete flow from optimizing individual activities. This is a process-level lens, not a claim that every strategic use of “value chain” means the same thing. [14]

A bottleneck constrains the rate of completed work. Faster upstream production can accumulate work in front of it rather than improve completion. Measure hands-on effort separately from waiting and total elapsed time. Rother’s work-release analysis recommends pacing released work to the limiting activity’s capacity; removing that constraint can make another activity determine the pace. [15]

Redesign therefore requires negotiation, not just faster execution. Decide which checks serve a continuing requirement, which handoffs can change and which duplicate steps can disappear. Allocate work and authority separately explains why moving execution to software need not move the right to decide. Domain specialists must participate: engineers may understand the tools without understanding why an apparently redundant control exists. [16]

Hammer’s Ford example makes the distinction concrete. A purchase order records a purchase request; accounts payable handles amounts owed to suppliers. Shared order information and checks when goods arrived replaced matching orders, receiving documents and invoices. Suppliers stopped sending invoices. This was coordinated process redesign, not an AI result. [8]

Faster generation can create a similar problem when review capacity stays fixed. In Moving away from Agile, Martin Harrysson and Natasha Maniar propose that manual review and unchanged coordination practices can limit the benefit of producing more code. Investigate the complete flow: does the changed activity remove work, move it to another team or create additional checking and correction? [17]

Standardize the requirement before standardizing the procedure. Two units may share a completion standard while needing different local knowledge, approval roles or working arrangements. Treat a proposed common procedure as something the receiving unit must understand and reproduce, not as a document whose distribution establishes adoption. [18]

Make knowledge usable and authoritative

Organizational knowledge comprises the facts, policies, routines and practical judgment used to perform work. Explicit knowledge can be expressed in documents or other formal representations. Tacit knowledge rests in experience, skills and mental models that may be difficult to articulate. Ikujiro Nonaka’s 1994 theory of organizational knowledge creation explains how interaction develops shared understanding; organizational knowledge is more than a collection of stored information. Read the original paper. [19]

A system of record is the designated authority for particular business facts. As Name the authoritative records explains, different systems can own different facts. Policy authority, current transaction state and experienced advice must therefore remain distinguishable. The following examples describe different claims, not a universal ranking of sources.

Stewardship is the continuing work of managing knowledge and investigating quality problems; it need not confer authority to change policy. Preserve source versions, applicability and effective dates, and record who resolved a conflict and on what basis. Publication time, retrieval time and the date a rule takes effect answer different questions. A more recent message does not automatically supersede an approved rule. The W3C provenance model provides vocabulary for sources, revisions and derivations; the organization still supplies the authority rules. [20][21]

The Knowledge-Centered Service practices guide illustrates managed readiness: an article can be unresolved or complete but unvalidated, and publishing privileges depend on demonstrated competence. Reusable guidance is separated from customer-specific incident information. That distinction is useful when collecting worker corrections: recording an observation is not the same as approving guidance for everyone. KCS practices make the difference explicit. [22]

Knowledge needs continuing work

An expert system applies encoded specialist knowledge to reach conclusions about a case. In Feigenbaum’s 1977 account, PUFF, developed through Stanford’s collaboration with Pacific Medical Center, reused the machinery for applying rules from an earlier system, MYCIN. But specialists still had to supply the rules for interpreting lung-function results. Running additional cases exposed gaps and inconsistencies that required revision. Reusing the software did not eliminate the work of acquiring and testing domain knowledge. [7]

XCON, which configured Digital Equipment Corporation computers in production from January 1980, exposed the maintenance side. Soloway, Bachant and Jensen’s 1987 study reported approximately 6,200 rules, about half changing annually. Interactions and missing rationale made revisions difficult, sometimes requiring original authors or institutional memory. The proposed RIME organization made domain structure and control relationships more explicit. Productive operation and difficult maintenance coexisted. [23]

Retrieval-augmented generation supplies retrieved material to a model when it prepares an answer. It can make selected sources inspectable, but cannot confer authority on them. Resolve ownership and applicability before expecting answer synthesis to handle disagreement; Applicable sources and unresolved conflicts develops that boundary. [24]

Connect systems through agreed obligations

An integration contract states what information and operations cross a boundary, what they mean and who supports them. A schema describes structure, but cannot settle all these obligations. The Open Data Contract Standard includes quality, support, roles and service expectations as well as schema. Agreement between producers and consumers is broader than successful data transport. [25]

Authentication establishes identity; authorization determines permitted actions on resources. Logging into an assistant does not authorize access to every upstream account. Delegation distinguishes a user from the agent acting for them; a service identity represents an application exercising its own granted authority. Keep these relationships explicit, as developed in Distinguish people and actors. [26][27][28]

Separate permission to read from permission to update. Unauthorized source material must be excluded before it reaches answer generation, including when a document has been split into indexed passages. A generated proposal must then pass an independent action-level check. Enforce current authority explains why neither a tool description nor the model’s promise supplies that enforcement. [29][26]

The business agreement also needs record identity, field meanings, freshness requirements, permitted updates and a definition of confirmation. An accepted request may still be pending; an unavailable response may leave its outcome unknown. Use the authoritative application’s state to establish completion, rather than treating the assistant’s explanation as a receipt. Preserve meaning across applications covers these interface obligations, and recovery from observed effects covers uncertainty. [30]

Where the assistance lives

Choose the integration arrangement with its ownership costs visible. Embedded assistance can keep work near existing records and review procedures. A separate integrated service needs an agreed boundary with each source owner. Exports and manual copying create additional artifacts whose permissions, freshness and disposal must be managed. Treat shadow IT—unofficial systems used to perform organizational work—as a potential second operating path, not merely an unapproved application. [31]

Workday Help provides a concrete embedded example. Its advertised capabilities combine AI-assisted article drafting and translation with author review, version control, approval workflows and case management. Those features connect content preparation to maintained guidance and receiving-team procedures. They do not establish how a particular customer configured the product or whether that customer realized a benefit. [32]

Legacy browser interfaces do not remove these obligations: an agent that can click still needs approved access and action authority. Supplier approval likewise concerns the actual service and data path, including secondary use, incident notification and responsibility for changes. Running a model internally does not remove dependencies on acquired software, weights or external integrations. [33][34]

Assign consequential decisions

Responsibility identifies who performs work. Accountability identifies who answers for a decision or outcome. Decision rights specify who may approve, change or stop something. RACI distinguishes Responsible, Accountable, Consulted and Informed roles; the data ownership model supplies a concrete application. A chart records an arrangement—it cannot grant a missing mandate. [20]

Assign decisions, not just components. A technical operator can repair an integration without being authorized to reinterpret a policy. A reviewer can reject a proposal without being empowered to approve a new organizational use. The following agreement is an example to adapt, not a universal organization chart. One person may hold several roles, but the distinctions still matter. [35]

The implementation team should not become the default destination for every unresolved business judgment. Owners need time, information, resources and a route for conflicting mandates. Assign accountable decisions applies this to information use; AI Engineering Leadership covers wider portfolio and staffing choices. At deployment level, the essential agreement is who can make each consequential decision and who receives unfinished work. [37]

Delegation can move investigation, implementation and testing to agents while retaining accountable ownership of the result. Addy Osmani’s account of engineering responsibility makes this boundary explicit: agents return work-appropriate evidence; owners judge its sufficiency and accept or redirect the outcome. This does not require manual execution of every action. It requires someone able to defend the decision. [35]

Provision the remaining human work

Human oversight is work that inspects, challenges or redirects system behavior. It requires expertise, time, relevant information and authority to intervene. The exception workload is the work outside normal handling, including unresolved cases and correction. Meaningful review and exception operations explain the mechanics; enterprise adoption must supply the people and capacity to perform them. [38]

Do not estimate this burden from case counts alone. If routine cases disappear, the remaining cases may be harder. Greater automated output can also create more checking. Measure handling effort and case mix, identify who accepts unresolved work, and provide cover when a specialist is unavailable. Requiring sign-off everywhere can create a queue that people cannot inspect meaningfully; removing review everywhere simply discards the quality obligation. [39][40]

Lisanne Bainbridge’s 1983 Ironies of Automation identified a related difficulty: automation can remove routine practice while leaving people responsible for abnormal situations requiring operating and diagnostic skill. Applied to AI-supported work, this argues for preserving practical learning and intervention experience, not assuming a training presentation maintains competence. It is a design lesson from industrial control and aviation, not a measured AI deskilling rate. Read Bainbridge’s paper. [40]

Automation bias is inappropriate reliance on automated advice. In Duolingo researchers Belzak, Niu and Ortmann Lee’s 2025 When Machines Mislead, proctors retained decision authority yet accepted some fabricated cheating alerts inserted into historical, previously certified sessions. Revised guidelines emphasizing independent video evidence were associated with estimated rejection rising from 50% to 71%. Different sessions and periods were compared; this was not randomized guideline assignment or a production false-accusation rate. The result demonstrates why observed reviewer behavior matters alongside formal authority. Original study. [41]

Existing quality-assurance and customer-experience teams can contribute where their expertise matches the task. They may recognize difficult interactions, label outputs and define acceptable behavior without building model pipelines. The Build-Operate Divide describes this contribution in contact-center work. It does not make customer-service experience a substitute for credentials required in another domain. Complaints and contested outcomes also need a receiving owner rather than an unattended feedback button. [42][36]

Align incentives and participation

An incentive is a reward, cost or expected consequence that influences behavior. It includes pay, workload, recognition and professional standing. Organizational and individual benefits can diverge: a change may save one team time while adding checking to another. Treat these consequences as part of the design, not as objections to overcome after installation. [43][44]

Atkin and colleagues’ study of soccer-ball producers makes the mechanism concrete. A material-saving cutting technology distributed in 2012 had low adoption after 15 months. Owners benefited from material savings, while piece-rate workers faced initially slower output and lower earnings. A later intervention combined payments for demonstrated competence with owner observation and increased adoption. This supports examining conflicting incentives, not prescribing bonuses or usage quotas for AI. [43]

Participation should examine who gains time, who contributes expertise, who performs new review and what happens when savings are reported. Worker concerns can involve job security, work intensity and employer monitoring. The OECD’s 2023 workplace report found such concerns alongside reported benefits. Training and consultation were associated with more favorable experiences, but the surveys did not establish causation. [1]

Psychological safety concerns whether people can take interpersonal risks such as admitting a mistake or criticizing current practice. Amy Edmondson’s organizational-learning account explains why threats to perceived competence or standing can suppress those exchanges. An AI rollout needs candid reports of bad assistance; rewarding apparent success while penalizing correction makes that feedback harder to obtain. [44]

Set goals around useful outcomes and use activity counts diagnostically, as the KCS guidance recommends. An employee who declines unsuitable assistance may be exercising good judgment. Before prescribing more training for bypasses, examine relevance, available support and whether the official path makes the work harder. Appropriate reliance is not maximized use. [45][3]

Make the practice workable

Change management prepares, equips and supports people whose everyday work changes. It coordinates procedures, roles, skills, support and expectations alongside technical delivery. This people-side meaning, described in Prosci’s definition, differs from software version control. A tested release and a training attendance list do not establish that the new arrangement can be performed routinely. [46]

Normalization Process Theory, developed by May and colleagues in 2009, explains embedding a practice through continuing work: making sense of it, sustaining participation, performing it and appraising its effects. These are interacting concerns, not implementation stages. The original paper helps explain why installation does not finish adoption. A coherent purpose cannot compensate for missing time or access; practical execution cannot compensate indefinitely for a practice people find unhelpful. [47]

Build on Keep the workflow usable and owned with role-specific practice. Users should complete representative tasks, recognize limits and escalate appropriately. Reviewers should practise rejecting wrong proposals; operators should practise interrupted work and service failures. Google’s SRE engagement model illustrates responsibility transfer supported by documentation, instruction, hands-on exercises and continuing help from developers. [48]

Parallel execution needs particular care for agents. A shadow test evaluates a candidate without using its response in the live service. But ignoring its answer does not suppress its tool effects. Route candidate actions to read-only access, mocks or isolated state; do not let two comparison paths independently modify the same business record. Shadow evaluation can still consume resources and process sensitive inputs. Shadow-test documentation establishes the response distinction; action isolation is an additional application responsibility. [49]

Turn task gains into usable benefits

Benefits realization converts improvement into a usable organizational outcome. Released time reduces effort on an activity; usable capacity makes that time available for other work. Realized savings reduce actual spending. The Government Efficiency Framework distinguishes greater output with unchanged spending from spending reductions. Both can matter, but they are different claims. [50]

The conversion depends on what happens after the faster task. Checking and correction may consume the released effort. Another department may constrain completion. Additional capacity produces more completed work only when there is demand, downstream capacity and a decision to put the released time to use. Reduced spending requires a separate change in expenditure while preserving the required outcomes. [51][15][50]

Count integration, training, transition, knowledge maintenance, review and support alongside service charges. Avoid crediting one team’s saving while omitting costs transferred elsewhere, and do not count the same benefit twice. A benefit owner should work with finance and analysts to preserve the baseline and assumptions. Separate savings from allocation develops the accounting boundary. [50]

Keep service quality, employee experience and economic outcomes visible separately. A useful measurement arrangement distinguishes utilization from impact and cost: who used assistance, whether completed work improved, and what resources it consumed. The AI-assisted engineering measurement discussion uses these dimensions to avoid treating more activity as proof of greater value. [52]

Complementary investment also takes time. The Productivity J-Curve analysis explains how resources spent building processes, managerial experience and skills can initially reduce measured output before the accumulated assets contribute. This is a possible accounting pattern, not a promise that an unsuccessful deployment will pay back. Delayed benefits still need an owner, a testable mechanism and a decision about continued investment. [9]

Humlum and Vestergaard’s March 2026 Danish study, Still Waters, Rapid Currents, linked chatbot-adoption surveys with employment records. It reported changed tasks, including oversight and integration work, alongside estimates excluding changes larger than 2% in earnings and recorded hours over the two years after ChatGPT’s launch. Adoption was not randomly assigned, so interpreting the estimates as effects of AI depends on assumptions used to separate adoption’s effects from other changes. Earnings and recorded hours also do not capture all organizational value. Changed work and unchanged paid hours can coexist. [53]

Evaluate the adopted arrangement

A counterfactual is what would plausibly happen under an alternative arrangement. Evaluating adoption requires a credible comparison with that alternative—not merely observing improvement after installation. Choose the live experiment develops experimental designs; Measure the complete process develops the outcome boundary. [54]

Specify the arrangement being compared. If one group receives software, training and revised procedures, the comparison concerns that package, not the model alone. Define eligible work, observation periods and task mix; record nonuse and bypasses. Shared practices can also cross group boundaries when coworkers exchange advice. Such spillovers change the comparison rather than disappearing because assignment was recorded in a spreadsheet.

Selection bias arises when the people or cases observed differ systematically from the population of interest. Volunteers may already be unusually interested or proficient. A survey discussed in AI Consulting in Practice recruited an engaged podcast audience and relied on voluntary reports. Its findings describe those respondents; they do not establish representative enterprise returns. [55]

Measure sustained incorporation into eligible work alongside quality, exceptions, downstream effort and realized benefits. Continue observation long enough to distinguish initial learning from routine operation; report the period rather than assuming a universal duration. Domain-specific success criteria make failures actionable, while production traces and expert annotation can reveal why apparently successful outputs did not complete the task. [59][60]

Use the findings to decide whether to continue, change, restrict or expand the arrangement. Aggregate improvement does not override a consequential failure in an affected group. A rollout decision should identify unresolved risks and the person accepting them; a positive average is an input to that decision, not its substitute. [13][36]

Transfer capability, reassess fit

Organizational replication reproduces a working practice in a receiving unit. Gabriel Szulanski’s 1996 study of internal knowledge transfer, covering 122 transfers in eight companies, identified difficulties involving recipients’ absorptive capacity—their ability to understand and apply incoming knowledge—uncertainty about why a practice works, and source–recipient relationships. The study explains why distributing information is not the same as reproducing coordinated activity. [18]

Separate reusable capability from organizational fit. An AI platform supplies shared software capabilities through supported service boundaries. Common deployment, authentication and observability can reduce repeated implementation work, while local teams still establish what work the service should perform. AI Platform Engineering develops that architecture; AI Engineering Leadership covers organization-wide investment and staffing. [61]

For example, two business units might use the same service but differ in the policies it must apply and the specialist capacity available to review its work. The service can be reused while those conditions are reassessed. The following comparison is hypothetical; it illustrates acceptance obligations, not a measured rollout.

Shared ownership should follow actual common needs. Bloomberg’s agent-scaling account describes integrated teams while product boundaries are uncertain, with horizontal capabilities introduced as recurring needs become clearer. Common guardrails avoid independent interpretations of the same policy. This is a practitioner option, not a required reorganization or proof that centralization always improves delivery. [62]

Document local adaptations as supported differences with owners and acceptance conditions. An unsupported fork is different: it creates another behavior and maintenance path without an agreement to operate it. Expansion should make justified variation explicit while preserving the shared service’s contract. More licenses alone settle neither local suitability nor ongoing support. [61]

Maintain, restrict or retire

A handoff establishes a starting arrangement, not permanent readiness. Demonstrating operating ownership covers practiced transfer. Continuing operation needs owners for business outcomes, knowledge, technical service, support and exceptions. Plan cover and succession so those responsibilities survive staff changes: the next owner needs the knowledge, access and practice to perform the work, not merely their name on an ownership list. [48]

Knowledge maintenance must remain ordinary work. A connected repository or business application is useful only if someone reviews and updates its content; connectivity does not establish freshness. When prompts change, preserve the failure that motivated the revision and the behavior it should correct. Production findings should become reviewed cases for evaluating subsequent releases, rather than disappearing into an incident archive. [63][64][65]

Business continuity means being able to continue necessary work during disruption. Restoring manual work requires available people and retained skill, not only a documented fallback. Rehearse essential operating tasks and check what workload the alternative arrangement can handle. Technical recovery and organizational continuity are related but distinct: a functioning interface does not supply missing reviewers. [48][40]

A use-case registry records which applications depend on particular models, tools and services. The AmplifAI registry demonstration connects these dependencies so teams can trace an affected asset back to business uses. Such a registry can aid response, but only maintained records can support a current impact assessment; the demonstration does not establish automatic discovery or freshness. [66]

Stopping future use and repairing past consequences remain separate responsibilities. Complaints need investigation; incorrect authoritative records may need correction; completed external effects may require a business remedy rather than rollback. Recover from the effects that occurred develops that distinction. Continue the deployment only while its usefulness, accepted risks and operating burden remain defensible. Sustainable adoption includes the ability to narrow or retire it. [67][13]

Open questions

1. 01

   Transfer across units remains difficult to predict because knowledge, authority and support can change while software stays identical. Longitudinal studies tracking receiving units, their adaptations and sustained outcomes would help distinguish reusable capability from genuinely transferable practice. [18]

2. 02

   Long-term oversight must preserve expertise while reducing routine work. Progress would mean showing that practical training and work allocation maintain effective intervention, including during unfamiliar failures and staff turnover—not merely documenting a fallback. [40][48]

3. 03

   Organizational value remains hard to attribute when task gains, changed responsibilities and operating costs emerge at different times. Stronger evidence would follow complete processes, resource redeployment and net benefits together instead of combining activity telemetry with estimated time savings. [56][53]