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 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 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.