Data Governance: Art. 10 dataset practices per system

Governance & QMS → Data Governance is the portfolio rollup of Article 10 — the dataset practices behind every high-risk system: provenance, representativeness, relevance, error-freeness so far as possible, bias examination and the residency of the data itself.

What the screen shows

One row per applicable system, with its Art. 10 obligation progress rolled up: how many data-governance requirements are complete, what's outstanding, and who owns the work. Systems where the engine determined Art. 10 doesn't apply (by role and risk tier) simply don't appear — the engine decides applicability, the workspace just reports it.

Click through to a system and you land on its Data Governance tab, where the actual work happens:

• Dataset inventory — what data trains, validates and tests the system, and where it came from.
• Quality criteria — the checks Art. 10(2) expects: design choices, collection processes, preparation, assumptions, availability, examination for biases, and gaps.
• Residency and lineage — where the data lives and how it flows.

Fields auto-save as you type, and each checklist item takes evidence directly — attach the data-quality report or lineage export right where it's claimed.

Deployers take note

Art. 10 is written for providers, but if you're a deployer feeding a high-risk system your own input data, Art. 26 expects that data to be relevant and sufficiently representative for the intended purpose. The engine surfaces the deployer-side items on your obligations, and this workspace is where you track them.

Related

• Work an obligation — the general checklist/evidence/owner mechanics used here.
• The Evidence hub — one uploaded data-governance policy can satisfy obligations on many systems.