A convincing compliance answer is not a complete assessment

An EU AI Act compliance checker can be most reassuring at the moment it has done the least demanding part of the work. It identifies a risk category, produces a readable explanation and gives the user somewhere to begin. The answer feels like progress because a difficult regulatory question has acquired a shape. Whether the organisation has enough information to act is a separate matter.

In a September 2026 arXiv preprint, Zhen Tao and colleagues assessed 12 publicly available EU AI Act compliance checkers. They found uneven legal coverage and weaknesses in the usefulness of the resulting guidance. Their conclusion was that the assessed tools were suitable for early orientation, with a risk that reliance on them could create false confidence.

The paper is a useful challenge for anyone building compliance support, including brett. A fluent explanation is an interface achievement. The more consequential test is whether the tool helps the organisation identify what applies, what remains uncertain and what evidence or action is needed next.

The label is the beginning of the work

The researchers examined different tool types and analysed 48 reports from eight questionnaire-based checkers using six scenarios. The paper states that the initial pool of candidate tools was inspected in September 2025, so its September 2026 publication date should not be mistaken for the date of that inspection. The 12-tool assessment should therefore not be described as 12 identical systems undergoing the same report test. Nor were all the tools AI-powered. This is a descriptive evaluation of selected public tools, not an experiment demonstrating the effect of compliance software on organisational outcomes.

Those distinctions matter because the commercial temptation is to turn the study into a verdict on an entire category. Its more useful contribution is to sharpen the question a buyer or product team should ask. What does the output establish, and what work is left to the user?

A risk classification can direct attention without proving that an obligation has been fulfilled. An organisation may still need to establish its role, describe the actual use of the system and supply records supporting the controls it claims to have. If the report collapses those steps into a general statement about compliance, it makes the answer easier to consume by hiding the unresolved work.

Consider an illustrative assessment of an AI assistant used inside a marketing department. Calling it a drafting tool does not describe everything it does. It might also infer characteristics from customer records, rank audiences or prepare an action for another system. A checker that relies on the user’s short description needs a way to expose material omissions. Otherwise, the apparent conclusion reflects the description entered rather than the activity taking place.

Coverage includes the questions that were never answered

A tool is easy to evaluate when it makes an obvious mistake. An omitted question can be harder to detect because the output contains no visible error to dispute. The user receives a coherent report and may have no reason to suspect that a relevant branch of the analysis was never considered.

For a compliance support product, that suggests a design requirement: make the scope of the assessment inspectable. Show which obligations were considered, which were excluded and why. Distinguish a finding that a requirement is satisfied from a finding that it does not apply. Both differ from an assessment that cannot be completed with the available information.

This is an editorial implication, rather than a numerical result from the paper. It matters because the same word, “passed”, can conceal several different states. A tool could have checked the evidence and found it adequate. It could have accepted an unverified user statement. It could have skipped the obligation because an earlier answer sent the user down another path. An organisation needs to know which of these events occurred before it treats the output as authority.

There is a related lesson in the limits of a prompt that omits a known rule. A system cannot reliably protect against an issue that the workflow has failed to make available to it. Better generation may improve the expression of an answer while leaving the scope of the task incomplete.

Uncertainty should have a destination

Compliance judgement often depends on facts that are ambiguous, incomplete or contested. A trustworthy tool should be able to express that uncertainty. Simply adding cautious words to every recommendation, however, leaves the user with an expensive research problem disguised as a report.

The practical question is what follows from the uncertainty. If the result depends on whether a system makes a consequential decision or merely supplies information, the tool should identify the missing fact and the person able to establish it. If a requirement applies but the evidence has not been supplied, it should describe the evidence needed. If specialist interpretation is required, that should be visible as an escalation rather than buried inside general caveats.

A report can then become useful even without a definitive answer. It narrows the work, preserves the assumptions and makes a next step possible. The danger is not uncertainty itself; it is a polished output that leaves uncertainty unowned.

The same principle applies to human involvement. Meaningful oversight needs information and authority, so a reviewer needs to see the basis of the recommendation and be able to change it. A human signature at the end of an unexplained automated assessment does little to strengthen the evidence on which the decision rests.

The assessment should be judged by what it leaves behind

Teams evaluating a checker could use a small set of cases they understand well, including situations where applicability changes with one important fact. The useful comparison is not whether the tool produces the longest answer. It is whether it preserves the decisive fact, covers the relevant obligation and supplies a usable account of the work still required. That exercise should be tailored to the intended scope rather than presented as a substitute for specialist validation.

The paper remains a preprint and a snapshot of selected tools. It does not show that all enterprise compliance products behave similarly, or that automation cannot improve the work. Its findings support a more disciplined standard of evaluation, rather than a blanket rejection of software assistance.

Compliance technology earns trust when the organisation can challenge its conclusions and understand its limits. The most valuable output may therefore be less satisfying than an immediate verdict: an assessment with its evidence attached, its scope visible and its unresolved questions assigned. That leaves the business able to make a decision instead of merely feeling that one has been made.