Because the obligation is operational, not just legal. Security and data teams need to show how datasets were sourced, prepared, accessed and maintained across the AI lifecycle. That pushes the work beyond policy review into continuous evidence generation, identity-aware access control and dataset lineage tracking.
Why Article 10 Turns AI Governance into an Operational Security Problem
Article 10 is hard for security and data teams because it turns documentation into an operational control plane. The obligation is not satisfied by a policy or model card alone, it requires evidence that datasets were sourced, prepared, accessed, and maintained in a way that can survive scrutiny across the AI lifecycle. That is why lineage, access control, and auditability become day-to-day security work.
For teams used to treating data governance as a cataloging exercise, Article 10 expands the scope to provenance, stewardship, and repeatable proof. The control expectation is closer to a continuous assurance model than a one-time review, which means the teams responsible for data quality, security logging, and access approvals all need a shared operating picture.
That also changes ownership. The practical question is no longer only whether a dataset is allowed for a use case, but whether the organisation can explain who touched it, under what authority, how it was transformed, and whether those decisions remain defensible after the system changes. In that sense, Article 10 pushes governance into an evidence-backed security workflow.
What Security and Data Teams Must Be Able to Prove
Article 10 creates pressure on four proof points: dataset origin, dataset preparation, access history, and ongoing maintenance. Each point needs enough traceability to support review, exception handling, and later investigation if the AI system behaves unexpectedly or the data is challenged.
Dataset origin means teams should know where the data came from, what rights or restrictions attached to it, and whether it was suitable for the intended AI activity. Preparation means the organisation can show the transformations, filtering, labeling, or curation steps that made the data usable. Access history means the team can identify which humans, services, or automation paths handled the data. Maintenance means the dataset stayed controlled after initial approval, including changes, refreshes, removals, and retention decisions.
Those proof points depend on identity-aware controls because access to training, validation, or fine-tuning data is not just a storage problem. It is an authorization problem. Teams need to know which roles, service accounts, pipelines, or delegated processes were allowed to read, modify, export, or reuse the dataset, and whether those permissions were still appropriate at the time of access.
For that reason, lineage tracking and access control should be designed together. A lineage record that cannot tell you who had access, or an access log that cannot tell you which dataset version was used, will leave the organisation unable to answer the basic compliance question Article 10 raises. The useful evidence set is the one that connects data object, actor, action, and timestamp.
Why the Burden Falls on Security Operations as Much as Data Governance
Article 10 is a governance problem because it creates a recurring verification duty, not a static policy artefact. Security teams must help ensure the evidence is trustworthy, tamper-resistant, and available when needed, while data teams must ensure the underlying dataset remains documented, versioned, and fit for purpose.
That split matters because failures often appear at the seams. Data teams may manage catalogs and quality controls, but miss privilege drift, shadow copies, or undocumented transformations. Security teams may enforce access controls, but miss whether the dataset lineage is complete enough to support an audit or incident review. Article 10 forces both sides to align on the same record of truth.
It also increases the cost of weak process discipline. If a dataset is copied into a new environment, reused by a downstream team, or combined with other data sources without updated lineage, the organisation can lose the ability to demonstrate compliance even if the underlying technical model still functions. In practice, governance breaks when evidence is not generated as part of the workflow.
Risk and Threat Considerations
Weak dataset lineage and access governance create exposure to unauthorized reuse, loss of accountability, and inability to reconstruct what fed the AI system. When the evidence trail is thin, the organisation is also less able to detect or explain data poisoning, stale data, or inappropriate downstream sharing.
Failure mechanism: The control fails when dataset handling is spread across separate tools and teams without a single, durable record that ties source, transformation, access, and version history together. That makes the approval state drift from the operational state.
Impact: The organisation can no longer prove that the dataset was properly sourced and maintained, which raises compliance exposure, weakens incident response, and increases the chance that an AI decision will be challenged on provenance grounds.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Dataset provenance and access history depend on auditable event records. |
| AC-6 — Least Privilege | Article 10 governance depends on limiting who can access and modify regulated datasets. | |
| Recommendation — Log dataset access, transformation, and maintenance events with enough detail to reconstruct lineage. Restrict dataset handling privileges to the minimum roles and service accounts required. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Dataset sourcing and maintenance require an accurate inventory of governed data assets. |
| A.8.15 — Logging | Traceability across the AI lifecycle depends on logs that support evidence and review. | |
| Recommendation — Maintain an inventory that identifies regulated datasets, owners, and lifecycle status. Configure logs to preserve dataset access and change evidence for governance review. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Identity-aware dataset access is central to proving who handled governed data. |
| Recommendation — Tie dataset access to governed identities and review credential lifecycle regularly. | ||
Practitioner Guidance
What to prioritise: Build a dataset registry that captures source, purpose, owner, approval basis, and current access path before expanding to more advanced metadata. If the basics are missing, lineage tooling will only automate ambiguity.
What to verify: Confirm that access records and lineage records can be joined at the dataset-version level. If you cannot trace a specific model run back to the exact dataset state and the identities that handled it, the control is not yet operationally useful.
Common mistake: Treating Article 10 as a documentation task that can be finished once. The hard part is keeping evidence current as data changes, pipelines change, and permissions change.
Practitioner takeaway: The organisations that cope best are the ones that treat dataset provenance and access governance as living security controls, not retrospective paperwork.