Design recommendations and hypothetical risks—not findings from an audit of a Slovak AI system. Applying these criteria to a particular product would require its purpose, inputs and actual role in decisions.

An algorithm finds a business whose invoice pattern differs from its peers. What has it found? Perhaps a reporting error, an unusual contract, a seasonal change or a transaction worth investigating. It has not, merely by producing a score, established fraud.

This is the central governance question for artificial intelligence in tax administration. The issue is not whether software can assist analysis. It is how a statistical or generated output becomes an administrative action, and what prevents uncertainty from disappearing along that route.

I would welcome tools that help officials ask better questions. I would oppose a process in which a company must disprove an unexplained label because the authority cannot reconstruct how the label became a finding. That is a proposed boundary for responsible use, not a claim that a particular Slovak system already behaves this way.

Do not treat every algorithm as the same tool

A rule that flags a duplicate invoice number is not the same as a model that ranks unusual trading relationships. A generative assistant summarising a case file performs another task again. The inputs, failure modes and appropriate safeguards differ.

A duplicate rule may still produce an ambiguous result if numbering conventions or corrections are mishandled. An anomaly model can identify rarity without understanding the business explanation. A generated summary can distort the evidence if it omits a qualification or introduces an unsupported statement. These are design risks to test, not measured findings about any deployed national product.

Before procurement, distinguish three proposed responsibilities: the reporting sponsor justifies the control objective and required information; the implementation team translates the authorised specification into tested software; the competent rulemaker authorises changes to legal duties. This is an accountability model, not a description of Slovakia’s organisation. Specify whether AI selects files, proposes questions or supports adverse decisions; implementation cannot supply its own legal mandate.

A hypothetical seasonal business

Imagine a hypothetical wholesaler that buys heavily before a seasonal sales period. Its purchases rise while sales temporarily remain low. An analytical system flags the change against a comparison group with steadier trading patterns.

That signal could be useful. An official might discover a genuine error. But the wholesaler might also provide orders, stock records and a financing explanation showing an ordinary seasonal cycle. The signal does not establish which explanation is correct.

Now imagine that a generated case summary says the firm has “unexplained purchases” even though the explanation is already in an attachment. The problem is no longer just the model’s ranking. It is the workflow that allowed a compressed narrative to displace the underlying documents.

A defensible process would preserve the flag, the comparison basis, the company’s response and the reviewer’s reasoning. It would distinguish “selected for clarification” from “non-compliant” in both the interface and the official record. Those labels should not become interchangeable because a dashboard uses one colour for both.

An invoice line is not the whole case

My shorthand example, “supply of goods under contract no. XXX, amount Y,” makes the evidence gap visible. It does not mean that such wording always meets invoice requirements or that analysis becomes impossible. The parties, amounts and timing can still support useful questions. In my own experience of bank checks in Spain, an invoice sometimes had to be supplemented with a contract, delivery records or transport documents. That personal experience of anti-money-laundering (AML) checks illustrates the need for underlying evidence; it does not establish a universal banking practice or equate bank checks with tax audits. An analytical system should preserve the distinction rather than claim to know facts absent from its inputs.

It is tempting to say that every public-sector tax algorithm is automatically a high-risk system under the . The legislation does not support that blanket statement. Regulation (EU) 2024/1689 classifies high-risk uses through its operative provisions and listed use cases, rather than simply through public ownership.20

Recital 59 is particularly relevant: it says systems specifically intended for administrative proceedings by tax and customs authorities should not be classified as the high-risk law-enforcement systems used for preventing, detecting, investigating and prosecuting criminal offences.20 That is an interpretive distinction, not a universal exemption from the Act.

The legal review should identify the purpose, affected persons and supported decision, then check the relevant operative article and annex and the application date of each obligation. A recital helps interpretation; it is not a standalone exemption. The intended purpose, actual use and relevant category still need assessment. Administrative tax work and criminal investigation should not be casually merged. Nor should an authority assume that calling a system “decision support” settles the analysis if its practical role is more consequential.

A product label cannot settle this classification. Deployment review must use the AI Act as amended by Regulation (EU) 2026/1744, rather than the original timetable alone. The amendment revises high-risk application dates, while other provisions and transitional rules have separate dates. Review the provisions applicable to the particular purpose and deployment; do not assume every obligation starts together.22

GDPR is relevant, but not in the simplistic way often claimed

Article 22 of the addresses decisions based solely on automated processing, including profiling, that produce legal or similarly significant effects concerning a data subject.21 It also contains exceptions, including decisions authorised by Union or Member State law with suitable safeguards.21

The data subject is a natural person. Recital 14 distinguishes processing concerning legal persons, including their names, legal forms and contact details.21 It would therefore be wrong to say that every risk score about a limited company automatically violates Article 22.

Personal data may nevertheless be involved: a sole trader, a director or an employee can appear in the underlying records. The nature of the data, the decision’s effects and the real degree of automation all matter. A nominal human signature should not be treated as my preferred safeguard if the reviewer cannot examine or challenge the result.

Beyond Article 22, Article 5 sets principles including accuracy, purpose limitation and data minimisation, while Article 32 requires security appropriate to risk.21 None of this establishes that a specific project is unlawful. It establishes questions the project must answer with more precision than “AI is allowed” or “AI is banned.”

Measure the whole control process

A useful evaluation should distinguish several outcomes: files flagged, issues confirmed after review, findings changed after taxpayer explanation, and decisions changed on challenge. These are proposed measurement categories, not reported performance statistics.

The authority should also examine missed cases. Measuring only the proportion of selected files that produce an adjustment can reward an overly narrow system while concealing what it never selects. Conversely, rewarding the volume of flags encourages low-quality inquiries and shifts the cost of screening onto businesses.

Testing should use a defined population and comparison method. Seasonal firms, new businesses and unusual business models deserve attention because an unrepresentative comparison group may make legitimate behaviour appear suspicious. A model should not be judged only on historical decisions if those decisions contain the same selection patterns the model will reproduce.

For a generative assistant, evaluation should include whether summaries preserve qualifications, attribute claims to the correct document and avoid presenting missing information as adverse evidence. Reviewers need access to the source passage, not only a fluent paraphrase.

Data access is a separate risk decision

Invoice-level information may reveal customer relationships, prices and purchasing patterns. Giving an analytical service broad access because it is called AI does not explain which of those fields it needs. Where personal data are processed, data minimisation still applies.21

Delivery, support and security operations, customer-ordered analytics and unrelated model development are distinct services and purposes. Operating invoice delivery alone should not carry a general right to train unrelated models. Any ordered analytics needs its own scope, conditions and legal assessment; this is a procurement safeguard, not a finding that every delivery provider runs tax analytics. I would also separate model development, testing and operational case access. Synthetic examples may be useful for testing interfaces, but they cannot establish real-world effectiveness. Real data used for evaluation should have a documented purpose, access controls and retention rules. A contractor should not gain an unrestricted right to reuse invoice data for unrelated product development merely because it operates the model.

Threat modelling should also examine malicious inputs, compromised accounts and inappropriate extraction of case information. These are possible attack paths, not evidence of a discovered vulnerability. Security claims should come from tested controls and documented boundaries rather than promises that a particular architecture makes compromise impossible.

The strongest objection: secrecy and scarce resources

Authorities can reasonably argue that publishing every detection threshold would help evasion and that manually redoing every calculation would remove the value of automation. Meaningful accountability cannot require public release of every operational detail.

The answer is layered transparency. The explanation should match the action and applicable rules: a request needs an intelligible factual question, not automatic disclosure of internal scores; an adverse finding needs reviewable evidence and reasons. These recommendations are not findings that safeguards are currently absent. Authorised reviewers and oversight bodies should be able to inspect the model, its evaluation and its role in decisions. Sensitive detection details can be protected without making the evidence behind an individual adverse finding unknowable.

Human review should be concentrated where consequences justify it. A low-impact internal ordering tool and a proposed adverse tax decision need not have identical procedures. But review must be real where the institution claims it as protection: the official needs time, competence, underlying records and authority to disagree.

A practical deployment threshold

Before operational use, I would require a documented purpose, a legal classification, a tested data pipeline, an evaluation plan, an accountable owner and an escalation route when results look wrong. Before an adverse conclusion, I would require the evidence and reasoning to stand independently of the model’s authority.

That approach does not reject AI. It gives it a properly bounded job. An invoice pattern can tell an investigator where to look; a model can help organise the material; a draft can save writing time. The conclusion must still follow from evidence and applicable rules. A useful signal becomes valuable precisely when the institution remembers that it is not yet proof.

For a business, the immediate step is simpler: retain the orders, seasonal explanations and correction history that make unusual activity intelligible. Answer the factual questions in a request rather than speculate about an algorithm’s motives. The label “AI” alone establishes neither an error nor a particular legal remedy.

Sources

[22] Regulation (EU) 2026/1744 — Digital Omnibus on AI, including amendments to Articles 111 and 113

[20] Regulation (EU) 2024/1689 — Artificial Intelligence Act, especially Article 6 and recital 59

[21] Regulation (EU) 2016/679 — GDPR, especially Articles 5, 22, 25, 26, 28 and 32