The Invisible Workforce — Why AI Taxation Fails Before It Starts, and What Fixes It

On the measurement problem at the heart of the AI labor debate, and the routing infrastructure that quietly solves it

The Tax That Cannot Be Collected

In February 2026, the European Commission published a 214-page consultation paper on "Digital Labour Taxation in the Age of Autonomous Systems." It was the fourth such document in three years. The previous three had each arrived at the same conclusion, dressed in different language: the problem is real, the urgency is acute, and the mechanism remains elusive.

The problem, stated plainly, is this.

When a company employs a human analyst to process financial documents, review compliance filings, draft regulatory submissions, or monitor operational systems, that employment generates a cascade of taxable events. The analyst receives a salary. Income tax is withheld. Employer payroll contributions flow to social funds. National insurance is paid. Pension obligations accrue. The economic value of that labour — its cost to the firm, its benefit to the state — is precisely legible in every jurisdiction on earth. It appears on payslips, on P60s, on Form W-2s, on EPFO records. It is, in the vocabulary of accountancy, recognised.

Now replace that analyst with an AI agent.

The agent processes the same documents. Reviews the same filings. Drafts the same submissions. Monitors the same systems. In many cases it does so faster, with greater consistency, and at a fraction of the cost. The economic value it generates is real — in some industries, measurably larger than what a human team could produce. But none of that value appears on a payslip. None of it flows to a national insurance fund. None of it is recognised in any fiscal sense whatsoever.

The agent costs the firm a few pounds in API tokens.

The state receives nothing.

This is not a future problem. It is a present one. And the reason every policy consultation ends in the same impasse is not a failure of political will. It is a failure of measurement infrastructure. You cannot tax what you cannot see. And AI labour, as currently deployed, is almost entirely invisible.

What Economists Get Right, and What They Miss

The AI taxation debate has attracted some of the most rigorous economic minds of the generation. Their arguments converge on a structural insight that is correct as far as it goes.

The traditional tax base — labour income — is being systematically eroded by automation. When firms substitute AI for human workers, they shift economic value from the wage bill (which is taxed at marginal rates of 30–50% in most OECD countries, including employer contributions) toward compute spend (which is taxed, at best, as a business expense deduction). The fiscal gap this creates compounds annually. IMF modelling published in late 2025 estimated that AI-driven labour substitution, if uncorrected, would reduce OECD government revenue by 4.3% of GDP within a decade — roughly equivalent to eliminating the entire defence budget of France.

What the economists miss is the implementation problem.

Their proposed solutions — a robot tax, a compute levy, an automation surcharge — all share a fatal flaw. They require the taxing authority to know, with precision, how much productive labour an AI system has performed. Not how many tokens it consumed. Not how many API calls it made. Not how much electricity it drew from the grid. How much cognitive work, equivalent to human labour of a specific grade and skill level, the system has performed on behalf of its operator.

A compute levy taxes electricity. A robot tax taxes headcount. Neither taxes work.

And that is the only thing a labour-replacement argument actually justifies taxing.

The Measurement Problem, Precisely

To understand why existing measurement approaches fail, consider what you would need to know in order to tax AI labour fairly.

You would need to know, for each request processed by an AI system:

1. The cognitive complexity of the task — was this a simple lookup or a multi-step analysis requiring expert judgement?
2. The domain of expertise required — was this general text generation, or specialist financial compliance, or regulated operational technology?
3. The equivalent human grade — what seniority level would a human need to perform this task to comparable quality?
4. The market rate for that grade in that domain — what would a firm pay a human to do this, in this industry, in this geography?
5. The volume of work performed — how much of it was done, measured in human-time equivalents, not in tokens?

Current AI infrastructure captures none of this. A typical enterprise AI deployment logs token counts, latency, and API costs. It knows what was spent. It has no idea what was done.

This is not a philosophical limitation. It is an architectural one. The information required to answer these questions exists — it is latent in the content of the requests themselves, in the routing decisions made about them, in the domain context of the systems that issue them. It simply has no place to go. There is no layer in the standard AI stack designed to capture and classify cognitive work.

Until there is, every AI tax proposal is a tax on proxy variables. And proxy variables, as any tax authority that has tried to tax financial derivatives knows, are gamed within eighteen months of enactment.

Routing as the Measurement Layer

Here is what almost nobody in the policy conversation has noticed.

The moment you introduce an AI inference router into an enterprise architecture — a system that sits between the application layer and the model providers, making decisions about which model to use, where to run it, and how to protect the data flowing through it — you have, almost by accident, created the only layer in the stack that sees everything needed to answer those five questions.

A router of this kind receives every AI request before it is processed. It classifies the request content for privacy sensitivity. It scores it for cognitive complexity. It identifies the domain from which it originates. It records which provider handled it, how many tokens were consumed, what the actual cost was, and how long the response took. It sits, in other words, at the exact intersection of task content, cognitive classification, and cost accounting.

This is precisely the architecture PrivEdge was built around.

PrivEdge is a hybrid edge-cloud AI inference router, originally designed to solve a different problem: how to route AI requests to local (on-device) or cloud inference based on privacy sensitivity and task complexity, while enforcing a strict network security policy. Its patent-protected routing engine scores every request on two axes — a privacy score and a complexity score — and uses those scores to decide whether the request can safely leave the enterprise perimeter.

The routing decision requires, as a precondition, exactly the information that AI taxation requires.

To decide whether a request should be routed to a local Ollama instance or to a cloud provider, PrivEdge must already know: how sensitive is this content? How complex is this task? What domain does it belong to? These are not outputs of the tax calculation — they are inputs to the routing decision. The tax calculation is, in a very real sense, a free by-product of the routing infrastructure that already exists.

Equivalent Labor Value: A Formal Definition

The PrivEdge Equivalent Labor Value (ELV) engine formalises this by-product into an accounting primitive.

For each request processed by the router, ELV is defined as:

ELV = hourly_rate(role, domain) × human_time(complexity, tokens)

Where:

role is derived from the complexity score using a four-band classification:

domain applies an industry multiplier drawn from ONS and comparable labour market data:

human_time is calculated from the token envelope of the request, adjusted for complexity:

human_minutes = (input_tokens ÷ 250 wpm × 0.75)   # reading time
              + (complexity_score × 0.5)             # analysis time
              + (output_tokens ÷ 40 wpm × 0.75)     # writing time
              + domain_verification_overhead          # +20% for regulated domains

The result is not a compute cost. It is a labour-equivalent cost — what a firm would have paid a human worker of the appropriate grade to perform the equivalent cognitive task, measured against actual market salary data.

The AI system's actual cost — tokens × provider rate — is recorded alongside it. The ratio of ELV to actual cost is the leverage multiplier: the factor by which AI amplifies human-equivalent productivity.

In current deployments, this multiplier ranges from approximately 800× for routine analytical tasks to over 3,000× for specialist compliance work. These numbers are not aspirational. They are measured, per request, with full audit trails.

What This Means for Fiscal Policy

The ELV primitive, once established, makes several previously intractable policy questions tractable.

A levy on substituted labour value becomes possible. A government wishing to capture fiscal benefit from AI labour substitution could levy a percentage of ELV generated by AI systems within its jurisdiction. This is structurally equivalent to an employer's national insurance contribution, applied to AI labour rather than human labour. The base is well-defined, measurable, and resistant to gaming — because it derives from the routing decision, which must be made correctly for the system to function at all.

Regulatory audit trails become available. For sectors where regulators already require disclosure of automated decision-making — financial services under MiFID II, healthcare under the EU AI Act, critical infrastructure under NIS2 — the ELV audit trail provides a machine-readable record of what cognitive work AI systems performed, at what grade, in what domain, and on what timeline. This is precisely the disclosure that regulators have been requesting and that enterprises have had no practical means of providing.

Transfer pricing disputes become resolvable. Multinational firms that deploy AI agents across jurisdictions face an emerging transfer pricing question: if an AI agent based in Ireland processes compliance work for a UK subsidiary, where does the economic value arise? ELV provides a principled answer — value arises where cognitive work is performed, and cognitive work can be localised by routing metadata.

Social fund contributions can be designed with precision. If the political decision is made that AI labour substitution should contribute to unemployment funds, retraining levies, or universal basic income schemes, ELV provides the accounting basis on which contribution rates can be set and verified. A firm replacing ten senior analysts with an AI fleet generating equivalent ELV would contribute at the senior analyst rate, not at the token rate.

The Sovereignty Dimension

There is a dimension of this that goes beyond taxation.

PrivEdge was designed, from its first architecture, with data sovereignty as a non-negotiable constraint. Requests carrying high privacy scores are routed exclusively to on-device (edge) inference — they never leave the enterprise perimeter. This is not a configuration option. It is an invariant enforced at the routing layer, with zero cloud fallback permitted when privacy scores exceed the threshold.

This design has an unexpected implication for AI taxation.

The routing metadata that enables ELV calculation is generated and stored locally — it never passes through a third-party provider. An enterprise using PrivEdge can produce a complete ELV audit log without disclosing the content of any request to any external party, including the tax authority itself. The audit log contains task classifications, complexity scores, domain identifiers, timing data, and ELV calculations — everything a regulator needs to verify compliance — with all sensitive content remaining behind the enterprise perimeter.

This is, in the language of privacy engineering, a verifiable disclosure without revelation. The firm can prove what work its AI systems performed, and what fiscal obligation that generates, without exposing the underlying data that would compromise client confidentiality, national security, or competitive position.

For industries operating under strict secrecy requirements — defence, intelligence, legal, medical — this may be the only practically viable path to AI tax compliance. Without it, any AI tax regime faces an immediate and irresolvable conflict: regulators cannot audit what they cannot see, and firms cannot show regulators what they are prohibited from disclosing.

PrivEdge resolves this conflict by design, not by exception.

The Enterprise Argument

The case for ELV is not only a regulatory one. Enterprises have independent reasons to want this measurement.

Every CFO deploying AI at scale faces the same boardroom question: what is this actually worth? Token costs are legible. Headcount reductions are legible. But the economic value of the cognitive work AI systems perform — the work that justifies the deployment, that determines whether the ROI calculation is 2× or 2,000× — is invisible. Most enterprises are flying blind.

ELV makes this visible in real time. A fleet dashboard showing £284,000 of equivalent labour value generated by twenty-three agents at an actual AI cost of £127 is not a theoretical construct. It is an operational metric with immediate management utility — for procurement decisions, for capacity planning, for make-or-buy analysis, for investor disclosure.

The enterprise that can say, with precision, "our AI agents performed the equivalent of thirty-eight full-time senior analysts last month, at 0.04% of the equivalent salary cost" is not merely managing its tax exposure. It is making a fundamentally different quality of strategic decision than the enterprise operating without this information.

A Standard, Not a Product

The argument of this article is not that any single vendor's implementation is the answer.

It is that the measurement problem is the answer.

Every serious AI tax proposal — and there are now dozens of them, from the IMF, the OECD, national governments, central banks, and think tanks across the political spectrum — founders on the same rock: the absence of a standard accounting primitive for AI cognitive labour. Without such a primitive, every proposed mechanism taxes proxies. Proxy taxes are gamed. Gamed taxes fail.

The Equivalent Labor Value primitive, implemented at the inference routing layer, provides what all of these proposals need: a principled, auditable, privacy-preserving measure of cognitive work performed by AI systems, expressed in the same units — human-equivalent salary — that the existing tax system already knows how to process.

It does not require new legislation to implement. It requires new infrastructure — infrastructure that, in architectures like PrivEdge's, is already being deployed for independent reasons, and already captures the data needed to compute it.

The taxation mechanism can follow the measurement. It always could.

The measurement, for the first time, is available.

Frequently Asked Questions

What is Equivalent Labor Value (ELV)? ELV is a metric that expresses the value of AI cognitive work in human-equivalent salary units. For each AI request, ELV calculates the human grade that would perform the equivalent task, the market rate for that grade and domain, and the time a human would require — producing a labour-equivalent cost that can be used as a tax base, ROI metric, or compliance disclosure.

Why do AI robot tax and compute levy proposals fail? Most AI tax proposals tax proxy variables: compute power, electricity consumption, or headcount reduction. None of these reliably measure cognitive labour substitution — the actual economic activity the tax is meant to address. Without a standard accounting primitive for AI cognitive work, tax mechanisms tax the wrong thing, get gamed within months of enactment, and are eventually abandoned.

How does inference routing create the measurement layer AI taxation needs? An AI inference router classifies every request by content sensitivity, domain, and cognitive complexity — the exact information needed to compute AI labour value. This classification is required for routing to function correctly, making the tax calculation a by-product of existing infrastructure rather than a new reporting burden on enterprises.

Can ELV audit logs be produced without exposing sensitive content? Yes. PrivEdge's routing metadata — complexity scores, domain identifiers, timing data, and ELV calculations — is generated and stored locally within the enterprise perimeter. An organisation can produce a complete ELV audit log for regulatory purposes without transmitting any underlying document content to external parties, including tax authorities. This is what the article calls "verifiable disclosure without revelation."

Is the ELV methodology publicly documented? Yes. The ELV methodology uses publicly available ONS and OECD salary benchmark data. The patent filings SET-PAT-001 and SET-PAT-002-A describe the routing thresholds, privacy invariants, and audit trail architecture in detail. The routing thresholds and ELV calculation are implemented in the open reference codebase.

Would an AI labour tax apply to all AI use, or only labour-substituting AI? The ELV framework only generates a tax base when AI performs work that a human worker of a definable grade would otherwise perform. Generative tasks with no human-labour equivalent — novel content creation, pattern discovery at superhuman scale — fall outside the ELV calculation by design. The framework taxes substitution, not augmentation.

Priyansh Bhalesain is co-founder of Setient Ltd, developers of the PrivEdge Sovereign AI Router. PrivEdge's patent-protected routing engine and Equivalent Labor Value architecture are described in SET-PAT-001 and SET-PAT-002-A, filed January 2026.

The ELV methodology described in this article uses publicly available ONS and OECD salary benchmark data. The routing thresholds, privacy invariants, and audit trail architecture are implemented in the open reference codebase.