AI as a Value Transformer, Not an Employee: Placing AI in Organisational Value Flows

Full text

1 Introduction

Organisations that adopt AI tools usually describe them in the language of staffing. A support assistant "handles" a share of requests. A coding assistant "does the work of" a number of engineers. A business case compares the cost of a model subscription with the cost of a full-time employee. The AI system is treated as a digital employee: it receives tasks, it completes them, and its contribution is counted as tasks completed or headcount avoided.

This paper argues that the employee frame is a category error, and that the error is not harmless. It directs measurement to the producer side of a value flow, where AI is strongest, and away from the receiver side, where value is actually realized. The result is a familiar pattern: dashboards that show rising output while customers, colleagues and reviewers absorb rework that no report attributes to the AI system.

The alternative proposed here comes from Value Management Theory (VMT) and the Æilus methodology. In VMT a transformer is a role, not an entity: an actor in that role consumes value and produces new planned value for someone else (A7). AI fits this role exactly. Placed as a transformer in a value flow, an AI system has inputs that cost something, outputs that are hypotheses until a receiver consumes them, and by-products that may be anti-value. Once it is placed in this way, the right questions about adoption and measurement become visible.

This is the fourth paper in an eight-part series on applying Æilus in organisations; definitions follow the first paper, "Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners". The formal apparatus of VMT and the value currency Æ are not re-derived here; they are set out in Bolshakov (2026), "Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective". The paper is conceptual. It contains no measured data, and the only numbers in it belong to a scenario that is explicitly labelled as hypothetical.

2 Scope, value system and theoretical basis

2.1 Whose value is measured

VMT holds that value exists only inside a defined value system (A1) and that the same event can be read differently in different systems (A2). Statements about "the value of AI" are therefore incomplete until the system is named. This paper uses one value system throughout: a delivery organisation and its direct receivers. Its actors are the organisation's teams and functions, the AI system in its transformer role, the people who review or correct AI output, and the external receivers of the organisation's work (customers, users, or internal consumers in another function). Its flows are the requests, artefacts and decisions that move between them. The AI vendor, the labour market and society at large are outside the boundary and are treated only through external flows (A10).

The choice matters. Inside the vendor's value system, every generated token is realized revenue. Inside the organisation's system, the same token may be value, noise or anti-value depending on what the receiver does with it. As T15 states, moving the boundary changes the conclusion without changing reality. The analysis below holds only for the boundary declared here.

2.2 Axioms and theorems used

The argument relies on A4 and T3 (planned and realized value diverge), A5 (anti-value is independent of value), A6 (value is realized on consumption), A7 (transformation), A8 and T7 (participation conditions), T4 and T6 (resistance and distortion accumulate), T5 (local optimisation does not guarantee global improvement), T8 (redundancy of a transformation role increases sustainability), and T16 and T17 (interpretation not confirmed by realization is unstable and accumulates anti-value).

3 The category error of the "digital employee"

3.1 What the employee frame counts

The employee frame imports a measurement habit from staffing. An employee is hired against a role, given a workload, and evaluated by throughput and cost. When AI is placed in the same frame, three numbers dominate: volume of work items processed, share of a workload "taken over", and full-time-equivalent (FTE) cost avoided. All three are measured where the work leaves the producer.

For human employees this habit is tolerable for a reason rarely stated: a human operator observes the receiver. A support agent hears that the customer is still angry. Much of the gap between planned and realized value is corrected informally, inside the person, before any metric records it. The producer-side metric works because a receiver-side sensor is built into the producer.

An AI system does not carry that sensor by default. It produces the planned side of value very well: fluent, fast and confident output in large quantity. It does not, unless explicitly connected to it, observe whether the output changed the receiver's state. The employee frame therefore measures AI where AI looks best and stops measuring where the difference between plan and fact appears.

3.2 What the frame hides

Four things disappear from view under the employee frame.

1. The consumption side of the AI transformer. Headcount comparisons count the model's licence or compute cost and ignore the human attention, review effort and data preparation that the transformer also consumes.
2. The receiver's verdict. "Completed" is declared by the producer. Whether the receiver's state improved is not recorded.
3. Displaced work. Work that the AI output fails to finish moves downstream to the receiver or to a reviewer. In the producer's report it is gone; in the system it is still present.
4. Accumulation. Rework, trust loss and skill erosion are not one-time costs. Under T4 and T6 they accumulate and reduce the system's future ability to realize value.

The FTE replacement framing also assumes that the human role and the AI role are substitutes with the same output. In VMT terms they are different transformers with different input and output profiles.

4 AI as a transformer role

4.1 Transformer, not entity

VMT and Æilus define a transformer by what it does in a flow, not by what it is. A person, a team, a service or a tool can hold a transformer role; in a Value System Schema the role is drawn as a converter, the Æilus name for a transformer node. This framing removes the question "is AI a worker or a tool?" and replaces it with a more useful one: what does this transformer consume, what does it produce, and who receives the output?

4.2 What an AI transformer consumes

An AI transformer has at least four kinds of input. Each is a value element consumed from somewhere in the system.

• Data and context. Prompts, documents, tickets, code, customer history. Someone created, curated and maintains them, and their quality sets an upper bound on the output.
• Compute and licences. The visible cost, usually the only one in the business case.
• Human attention. Writing instructions, framing tasks, steering the interaction. This is consumed from people who would otherwise be doing other work.
• Review effort. Reading, checking, correcting and approving output. For many uses this is the largest input, and it sits on someone else's budget.

4.3 What an AI transformer produces

The outputs are value elements in the sense of the series: drafts, answers, code, classifications, summaries, decisions. Each starts as a value hypothesis. It carries planned value as interpreted by the producer and becomes measurable only when the next transformer consumes it (A6). The AI transformer may also produce anti-value: wrong answers, misleading summaries, code that must be removed later, and the effects described in section 7.

The Æilus definition of converter efficiency makes the balance explicit. Efficiency of a converter is

E = (produced value - produced anti-value) / (consumed value - consumed anti-value)

with all terms expressed in Æ within the declared system. Two features of this formula matter for AI. First, the denominator includes review effort and human attention, not only compute. Second, the numerator subtracts produced anti-value, which the employee frame never records. An AI transformer with impressive output volume can have low or negative efficiency once both corrections are made. The same transformer can be efficient in one value system and destructive in another.

5 Planned versus realized value of AI output

5.1 Why AI looks strong on the planned side

A4 states that planned and realized value generally differ; T3 adds that zero divergence is an unstable special case. For human work the divergence is moderated by the producer's own observation of the receiver. For AI output the divergence has a structural bias. Generated output is optimised to look like a correct answer. Fluency and confidence belong to the planned side; correctness and applicability belong to the realized side.

AI raises planned value quickly and cheaply. Unless realized value is measured separately, the organisation reads that rise as progress: the pattern T16 describes as structurally unstable.

5.2 Hidden rework

When realized value falls short of planned value, the shortfall does not vanish. It turns into work somewhere else in the flow. A customer contacts support again. A manager rewrites a generated email. An engineer corrects generated code.

The AI transformer's report shows a finished item, and the receiving transformer absorbs the cost: a case of T5: a local improvement in one transformer's throughput does not guarantee improvement of the system. It also matches the general observation from flow-based management that work hidden in queues and rework is invisible to activity metrics (Reinertsen, 2009). The VMT reading adds one point: the hidden work is not neutral delay but anti-value, and under T4 it accumulates as flow resistance at the interface between the AI transformer and its receiver.

6 The receiver-side metric

If value is realized on consumption (A6), then the receiver, not the producer, validates it. This is the central measurement rule of the paper: the value of AI output is measured at the transformer that consumes it, not at the AI transformer that produces it. Lean thinking makes a related point when it defines value from the standpoint of the end customer (Womack and Jones, 1996); VMT generalises it to every internal receiver in a flow.

A receiver-side metric pairs every producer-side count with an observation of what happened next. Some examples:

The gap between the two columns is the most informative number an AI programme can track. It estimates the displaced work and the anti-value produced at the interface. A widening gap indicates that the programme is scaling interpretation faster than realization.

Receiver-side metrics also guard against a predictable failure. A producer-side metric that becomes a target will be met by producing more of what it counts, a dynamic usually associated with Goodhart (1975). AI makes this cheap. An assistant targeted on "closed requests" will close requests. Anchoring the target on the receiver's state makes it harder to satisfy without delivering value.

7 Anti-value specific to AI

A5 treats anti-value as independent of value: an AI transformer can produce real value and real anti-value in the same period, and the two do not cancel in the receiver's experience. The following kinds of anti-value are characteristic of AI transformers. They are listed as categories to observe, not as measured frequencies.

• Confident errors. Incorrect output presented with the same fluency as correct output. The receiver cannot use tone to tell them apart, so every output must be checked or the error passes downstream.
• Review burden. The effort required to verify output. It grows with output volume, not with output quality.
• Erosion of skills. When the AI transformer takes over the first draft of work, the people who used to produce it may lose the practice that made them good reviewers. Under T6, this accumulated distortion reduces the system's future ability to realize value, including its ability to detect AI errors.
• Trust loss. Each failed interaction lowers the receiver's trust in the channel. Under A8 and T7, when a participation condition is violated, the actor leaves or changes the form of participation.
• Interpretation inflation. AI output can be quoted, summarised and passed on faster than it is checked. Under T17, influential interpretations that are not confirmed by realization accumulate anti-value: a generated summary cited in three decisions spreads its errors three times.

None of these appear in an FTE comparison. All of them are observable if the receiver side of the flow is instrumented.

8 Naming and placing the AI role

8.1 Name the role by its output and receiver

"AI replaced the analyst" hides the flow. "AI produces the first draft of the weekly report; the analyst verifies the conclusions" names a transformer, its output, its receiver and the review step. A useful naming rule has three parts:

1. the value element the AI produces (draft, answer, classification, code change);
2. the receiver that consumes it (customer, reviewer, next team);
3. the condition under which the receiver accepts it (verified, approved, used without rework).

8.2 Ownership

An AI system cannot hold accountability for value, because it does not interpret changes in its own state as value or anti-value. In Æilus terms it occupies a transformer role but not an owner role. The Value Transformer Owner (VTO) of the transformer that contains the AI is responsible for its realized and retrospectively re-evaluated value, for the anti-value it creates, and for its ability to keep participating without degrading the system. The Value System Owner (VSO) is responsible for whether adding the AI transformer keeps the system as a whole sustainable and keeps the participation conditions of other actors intact, including the reviewers whose load it increases.

Where the interface between the AI transformer and its receiver becomes a persistent source of resistance, the Flow Owner role applies.

8.3 Paired roles and redundancy

Under T8, redundancy of a transformation role increases sustainability. Pairing AI and a person on one role, so that each catches the other's failures, is such redundancy. The pairing should be visible in the schema, so that the human half is counted as an input and not treated as free.

8.4 Placement in a Value System Schema

In a Value System Schema (VSS) the AI role is drawn as a converter with explicit inputs and outputs. A minimal placement includes:

• incoming flows: data and context, compute, human instruction effort, review effort;
• outgoing flows: the produced value elements, each going to a named receiving converter;
• an anti-value flow: confident errors and rework returned or passed downstream;
• planned and realized values in Æ on each outgoing flow, with realized value recorded at the receiver.

Drawn this way, the schema often reveals a flow the business case omitted, typically review effort. Under T9, if the structure does not explain observed costs, there are latent flows or the boundary is wrong.

9 Implications for adoption and for measuring AI programmes

9.1 Adoption decisions

The transformer view changes the adoption question from "which jobs can AI do?" to "in which flows would an AI transformer raise realized value at the receiver, net of the anti-value and review effort it adds?".

• Prefer flows where the receiver can validate cheaply. If checking an output costs nearly as much as producing it, the AI transformer adds little. If the receiver can confirm quality quickly, the transformer can add a lot.
• Be cautious where errors are silent. Where a wrong output is not detected until much later, retrospective value can turn negative long after the programme has been declared a success.
• Count the review budget before deployment. The people who will review output are actors with their own participation conditions. A deployment that violates them (A8) will lose them or change how they participate (T7).
• Plan growth only when delivery is confirmed. Æilus asks VTOs to increase planned value only when demand, inflow and delivery capability are confirmed (T16).

9.2 Measuring AI programmes

For a programme review, this paper suggests four measurements, all within the declared value system:

1. Realized value at the receiver, per flow, in Æ or a stated proxy, recorded by the receiving transformer.
2. The plan-fact gap: producer-side count minus receiver-side confirmation, tracked over time.
3. Full consumption: compute and licences plus estimated review effort and human attention.
4. Anti-value indicators: repeat contacts, reverted changes, corrected outputs, complaints, and signs of skill erosion or reduced trust.

A programme that reports only volume and FTE savings is reporting planned value. It may be correct, but it has not yet been confirmed.

10 Illustrative scenario

The following scenario is hypothetical. The numbers are chosen for arithmetic convenience and do not describe any organisation or measurement.

A product organisation introduces an AI assistant into its support flow. In a hypothetical month the flow receives 1,000 requests. The assistant marks 700 of them as closed, and the internal report states that the assistant "handles 70 per cent of support". Under the employee frame this reads as seven-tenths of an operator team's workload removed.

Now place the assistant as a transformer and look at the receiver side. Suppose that 250 of the 700 closed requests come back within a week as repeat contacts on the same issue, now handled by human operators and now from customers who are more frustrated than before. Suppose also that operators spend time reading the assistant's transcript before answering each repeat contact.

The receiver-side view does not say the assistant failed. In this hypothetical, 450 customers had their issue resolved quickly, which is real realized value. It shows that the planned value of 700 closures included 250 hypotheses that the receivers rejected. Those 250 turned into three kinds of anti-value: extra operator work on cases that are harder than average, transcript review effort, and reduced customer trust in the channel. The operator workload fell by less than the report implied, and the remaining workload became harder.

A VTO who owns the support transformer would act on the gap, not on the 70 per cent. Options include restricting the assistant to request types where receivers confirm resolution, routing uncertain cases to people earlier, and adding a receiver-side check ("did this solve your problem?") before a request is counted as closed. Whether any of them raises net realized value is an empirical question; the scenario only shows which numbers are needed to answer it.

11 Limitations

This paper is a conceptual analysis derived from VMT axioms and theorems and from Æilus methodology material. It reports no empirical data. The anti-value categories in section 7 are proposed as observable categories; their frequency and size in real organisations are not known from this work.

Receiver-side measurement can be expensive, and some receivers cannot report their state. Converting review effort, trust and skill erosion into Æ requires an aggregation policy defined by the VSO, and such values are only partially commensurable (A13). A different boundary, for example one including the AI vendor, would produce different conclusions (T15). The paper also treats the AI system as a fixed transformer, while systems that learn from receiver feedback may change their plan-fact gap over time.

Validation would require longitudinal observation of AI transformers in several value systems, with planned value, receiver-side realized value, review effort and anti-value indicators recorded on the same flows over time.

12 Conclusion

Treating AI as a digital employee measures it at the producer side of a flow, where it is strongest, and leaves unmeasured the receiver side, where value is realized. Treating AI as a transformer role (A7) makes the full exchange visible: it consumes data, compute, human attention and review effort, and it produces value elements that remain hypotheses until a receiver consumes them (A6). Planned and realized value of AI output diverge (A4, T3), and the divergence turns into hidden rework and anti-value that accumulates (A5, T4, T6).

The practical consequences: declare whose value is measured. Name the AI role by its output and its receiver. Draw it in the Value System Schema with all its inputs, including review. Measure value where the output is consumed, and track the gap between producer-side counts and receiver-side confirmation. Assign ownership to a VTO, not to the system itself. Scale only what receivers have confirmed. An AI programme measured this way may look less impressive in its first report and be considerably more useful in its later ones.

References

• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Bolshakov, V. Æilus Methodology v2.0. aeilus.tech, 2026.
• Bolshakov, V. Rethinking Efficiency: Value Systems, Flows, Converters, and Elements. aeilus.tech, 2026.
• Bolshakov, V. Value Elements: What We Actually Produce and Consume. aeilus.tech, 2026.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.
• Womack, J. P. and Jones, D. T. Lean Thinking. 1996.