A tax analyst reclassifies an AI-suggested VAT treatment from standard-rated to zero-rated. Correct call, made by a qualified person, on a real transaction. In a well-designed system that correction is captured and used to improve future suggestions. That improvement is the feature the tool was bought for.
It is also, depending on how the system is built, an amendment to the enterprise's tax determination logic — made by a single analyst, on a single transaction, with no change request, no review, no effective date, and no record that anything changed.
Two Things That Look Identical From the Screen
From the analyst's seat, correcting a suggestion feels like ordinary work. It resembles fixing a coding error on an invoice — a local act with local consequences. Whether that is what actually happened depends entirely on architecture, and the difference is invisible at the point of the correction.
In one design the correction applies to that transaction only. The record is amended, the position is right, nothing else moves. This is a data correction.
In another, the correction feeds a learning loop. It enters a training set, adjusts a retrieval index, updates a rules cache, or is stored as a precedent the model consults on similar inputs. Subsequent transactions resembling that one are now treated differently. This is a logic change.
Enterprises run both patterns, frequently in the same tool for different functions, and the interface rarely distinguishes them. The analyst performs one gesture. Which of the two occurred is a property of the vendor's implementation.
The Governance That Applies to One and Not the Other
Tax logic in an ERP is a governed object. Changing a tax code, a determination rule, or a condition table follows a defined path: a request, an impact assessment, a test in a non-production environment, an approval, a transport to production, an effective date, and a record. This is not bureaucratic overhead. It exists because tax logic applies prospectively to transaction populations, and because when an authority asks what treatment applied in a given period, the enterprise must answer with evidence.
A learning loop that adjusts behaviour from user corrections performs the same function — it changes how future transactions are treated — while bypassing every one of those controls. The change has no request, no approval, no test cycle, and no effective date. Most consequentially, it has no version. There is no state to point at and say: this is the logic that was in force in March.
The enterprise has not decided to run two standards. It has one governed path for tax logic in the ERP and one ungoverned path for tax logic in the AI layer, and it may not have noticed that the second path is carrying tax logic at all.
Why This Is Cognitive Responsibility Diffusion™, Not Carelessness
No participant is behaving unreasonably. Cognitive Responsibility Diffusion™ describes decisions that dissolve across a chain in which every individual link is defensible.
The analyst corrected an error, which is the job. The vendor built a system that learns from feedback, which is the product. The implementation team enabled a feature that was on by default and presented as an accuracy improvement. The tax director approved a tool for classification assistance, not a mechanism for amending determination logic. The change control process governs the ERP, and this did not happen in the ERP.
Every link holds. The chain does not. The result is tax logic that changes continuously, driven by whoever happened to be working the queue, with no one experiencing themselves as having changed anything.
The Reconstruction Problem
The exposure becomes concrete when a position is questioned. An authority asks why a class of supplies was treated a particular way across a past period. The enterprise needs to reconstruct the logic that was in force at the time.
Where determination sat in ERP configuration, this is retrievable — the change log shows what was in effect, from when, approved by whom. Where determination sat partly in a model shaped by accumulated corrections, reconstruction may be impossible in principle. The model has been updated many times since. Prior states may not be retained. The corrections that produced the behaviour may not be individually attributable, and the reasoning behind each is almost certainly not recorded — the analyst clicked a different option, and clicks do not carry rationale.
The enterprise can demonstrate the treatment applied. It cannot demonstrate why, or that the reason was ever reviewed by anyone qualified to review it. That is the distinction between a treatment and a defensible position.
A Second-Order Problem: Silent Divergence
There is a compounding effect worth naming. Corrections are made by individuals, and individuals differ in their interpretation of borderline cases. Where a learning loop absorbs corrections from multiple analysts without adjudicating between them, the model does not converge on a house position. It converges on whatever the correction volume implies — which may be the view of whoever processes the most transactions rather than whoever is most authoritative.
Two analysts holding defensible but different readings of the same provision produce a model that treats similar transactions inconsistently, with no visible moment at which the inconsistency was introduced. This is Interpretive Divergence™ arriving through an unexpected door: not between the enterprise and its counterparty, and not between the enterprise and the authority, but between the enterprise and its own stated position — mediated by a system that averaged the difference without being asked to.
What to Establish Before the Next Tool Goes Live
Ask the architecture question explicitly. For every AI-assisted tax tool in use or under evaluation: does a user correction affect only that record, or does it influence future determinations? The answer is often not in the sales material and is sometimes not known by the implementation contact. It should be obtained in writing and it should be specific — which corrections feed learning, on what cadence, and whether the behaviour can be disabled.
Separate correction from teaching. Where a learning loop exists, fixing a record and amending the logic should be two different actions with different permissions. Any analyst may correct a transaction. Changing how a class of transactions is treated is a different authority, and the interface should reflect that it is a different act.
Route logic changes into existing change control. The governance for ERP tax logic already exists and is already understood. The task is extending its scope, not inventing a parallel regime for the AI layer. A change that alters prospective treatment enters the same queue regardless of which system it lives in.
Require model state retention. If determination behaviour can change, prior states must be reconstructable for the full statutory retention period. This is a procurement requirement. Verifying it after an authority has asked is too late, and no amount of process discipline compensates for a system that did not retain what it would need.
Review the accumulated drift. Where learning loops have been running, the corrections made to date represent an undocumented body of tax positions. Extracting and reviewing them is a real exercise, and the finding is usually a mix — sound corrections that should be formalised into stated policy, and inconsistencies that should be resolved before they propagate further.
The Principle
Tax logic does not become something else because of where it executes. A rule that determines the treatment of future transactions is tax logic whether it is written in an ERP condition table, a tax engine, a script, or the weights of a model.
The governance an enterprise applies to its determination logic should follow the logic, not the system boundary. Where a tool learns from its users, the users are authoring tax rules. The only question is whether the organisation has decided to let them, and whether it can show what they wrote.
Cognitive Responsibility Diffusion™ and Interpretive Divergence™ are frameworks developed in Real-Time Tax Transformation (forthcoming) and the 17-module practitioner course.