Where this goes wrong

A weak answer is rarely a wrong one. It is usually a true statement doing less work than it appears to — a policy that exists but binds nobody, an artefact produced once and never since, a judgement recorded without the person who made it or the basis they made it on. Each entry below names the specific failure for its provision; the obligation page it links to sets out what discharges the duty instead.

The answer that does not hold

• Article 5Prohibited AI practices

  Treating Article 5 as somebody else’s problem because nothing in the estate is high-risk. The prohibitions are the one part of the Regulation that never required a classification exercise, and the organisations most exposed are the ones that concluded early they were out of scope. Emotion analytics in a contact centre, engagement scoring in a training platform, a vendor feature enabled by default — none of these arrive announced as prohibited AI, and none of them is caught by a programme that starts with an Annex III inventory.

• Article 6Classification rules for high-risk AI systems

  A classification that exists only as a conclusion. Someone decided, the programme was scoped from the decision, and no record shows which route was considered or which conditions were tested. It survives until a supervisor, an acquirer or a customer asks — at which point the organisation cannot demonstrate that the second condition of the product route was ever reached, or that profiling was ruled out before a derogation was claimed. Where the conclusion was "not high-risk", the Regulation requires that record to exist, so its absence is itself the breach.

• Article 9Risk management system

  The register mistaken for the system. A spreadsheet of severities and likelihoods is the smallest component of what Article 9 asks for, and it is routinely offered as the whole of it. What it cannot show is that anything was decided: no author against the acceptance, no date on it, and no line connecting a mitigation to a test that established the mitigation works. Organisations that fail here are rarely careless — they have done the thinking and kept no record capable of demonstrating it, which from the outside is indistinguishable from not having thought.

• Article 10Data and data governance

  A data quality report answering the wrong question. It reports completeness, null rates and duplicate counts — a competent engineering artefact — and says nothing about whether the data represents the people the system will be used on, what is known to be missing from it, or whether examination for bias changed anything. Article 10 is not a data hygiene requirement. It asks whether the data supports the intended purpose for the population in question, and a report that never names that population cannot answer it.

• Article 11Technical documentation

  The folder that is complete and unusable. Every artefact an assessor might want exists somewhere — a wiki, a ticket system, a model registry, a shared drive — and the provider offers access to all of it in place of a file. What Article 11 asks for is arrangement rather than volume: material a national authority can read and reach a conclusion from without first learning how the engineering organisation is structured. Providers who fail here have usually done more work than those who pass and cannot show it, because nobody was ever made accountable for the document as a document.

• Article 12Record-keeping

  Volume offered as traceability. The provider produces retention periods, storage figures and a list of every event class emitted, and cannot point to a single occasion on which any of it was used to establish anything. Article 12 is not satisfied by writing data; it is satisfied by a system whose records make the three named downstream activities possible. An assessor with limited time will skip the schema and ask what the logs have ever shown.

• Article 13Transparency and provision of information to deployers

  A sales datasheet wearing a compliance label. It is accurate, it is current, and it was written to make a purchase easy — which means it says what the system does well and stays quiet about the conditions under which it does not. Article 13(3) asks for limitations of performance, circumstances that may lead to risk, behaviour under reasonably foreseeable misuse, and results for particular groups of people. None of those helps a sale. The document that discharges this article is the one an operations team needs at three in the morning, and it is rarely the one marketing signed off.

• Article 14Human oversight

  Oversight that has never changed an outcome. The arrangement exists, the policy names it, a person occupies the role — and no decision in the system’s history has gone differently because of them. This is the rubber stamp, and it is the specific failure Article 14(4)(b) anticipates rather than an unfortunate side effect. It is also the easiest thing on this page to test, which is why an assessor asks for the override log before asking for the policy.

• Article 15Accuracy, robustness and cybersecurity

  A marketing figure promoted into a compliance artefact. The number in the instructions for use is the same number on the datasheet and the website, because it was written for a buyer rather than for a deployer who has to calibrate oversight against it. The tell is that nobody can say where it came from: the team that produced the evaluation has moved on, the test set was not retained, and the figure has survived two model versions unchanged — which, if it were a measurement, would be remarkable.

• Article 26Obligations of deployers of high-risk AI systems

  An escalation path that ends in a ticket. Almost every deployer can produce a monitoring dashboard, an owner and a route to the vendor; far fewer can produce the point at which that route obliges them to stop. Article 26(5) is the only place in the deployer’s obligations where the required action is to cease using the system, and a runbook whose most severe step is "raise a P1 with the supplier" has quietly written the statutory step out.

• Article 27Fundamental rights impact assessment for high-risk AI systems

  An assessment written by the wrong people. A FRIA produced entirely inside legal or compliance, without the caseworkers who will operate the system and without anyone who can speak for the people it will be pointed at, reliably identifies the risks already known to the organisation and misses the ones specific to this deployment. Article 27(3) sends the result to the market surveillance authority, so the document is read by someone outside the organisation — a test most internal drafting is not written to survive.

• Article 50Transparency obligations for providers and deployers of certain AI systems

  A privacy notice doing the work of a disclosure. Organisations treat the AI Act’s transparency duties as a variation on data-protection information duties, and answer them with a paragraph in a policy nobody reads at the moment of interaction. The Act asks for something narrower and harder: a clear, distinguishable statement at first exposure, in the interface, meeting accessibility requirements. Compliance with it also establishes nothing about lawfulness — the Regulation says so expressly.

• Article 72Post-market monitoring by providers and post-market monitoring plan for high-risk AI systems

  An MLOps stack offered as post-market monitoring. Drift detection, alert thresholds, dashboards and a retraining cadence — genuinely good engineering, pointed at model behaviour rather than at continued conformity. The tell is that no signal has a requirement behind it, so nothing the monitoring observes can ever become a compliance finding. The remedy is usually mapping rather than building, which is why this is among the cheaper findings to close and among the more common to leave open.

• Article 73Reporting of serious incidents

  A security incident process retimed to the wrong event. Severity is assigned, an investigation opens, and the decision to notify waits on a confirmed cause — which is how a fifteen-day outer limit becomes six weeks. Article 73 never asks for certainty: paragraph 2 runs on reasonable likelihood, and where someone has died paragraph 4 runs on suspicion. The second half of the failure is jurisdictional. Nothing in the runbook captures when the customer knew, so the organisation cannot demonstrate whether its window had already been running for a week when its own ticket opened.