TL;DR: Privacy stacks are colliding under AI growth, cross-border expansion, and mergers because role- and attribute-based access models do not answer why data is being used, leaving accountability diffuse and policy enforcement fragmented, according to Ethyca. Purpose-based access control becomes the more durable governance pattern when data use must be authorized in real time across systems, jurisdictions, and AI consumers.
At a glance
What this is: Ethyca frames privacy governance as an architectural problem, arguing that purpose-based access control is needed when AI, cross-border operations, and M&A make identity-based data access too blunt.
Why it matters: This matters because IAM, privacy, and data security teams need controls that govern why data is used, not only who can reach it, especially when human users, pipelines, and AI agents share the same estate.
Context
AI adoption and cross-border growth have turned data governance into an architectural problem rather than a policy-writing exercise. Traditional role-based or attribute-based access models can still work for narrow environments, but they struggle when many systems, jurisdictions, and consuming applications need to agree on why data is being used.
The article’s core privacy question is no longer just who has access. It is whether that access is authorised for a declared purpose across analytics, applications, and AI consumers, including privacy by design considerations when policy, architecture, and data use all have to line up.
Key questions
Q: Should privacy, data, and identity teams share ownership of AI data access?
A: Yes. AI data use depends on lawful access, policy enforcement, and traceability, which no single function usually owns end to end. Shared ownership creates clearer accountability for consent, purpose limitation, and access scope, especially when automated systems are consuming customer data at scale.
Q: When does role-based access control stop being enough for IAM governance?
A: RBAC stops being enough when access depends on resource attributes, tenant boundaries, environment, or time, rather than a small set of static roles. At that point, teams need attribute-aware or policy-based decisions. If new edge cases keep forcing new roles, the model has already exceeded the usefulness of simple role assignment.
Q: What breaks when organisations do not maintain a current data map for their data estate?
A: The main failure is loss of traceability. Teams cannot confidently answer what data is stored, where it is processed, whether it is shared or deleted, or which systems expose access gaps. That makes privacy requests slower, impact assessments weaker, and security governance more reactive because the organisation is managing an environment it cannot fully describe.
Q: What should organisations re-evaluate after a merger or acquisition from a privacy perspective?
A: They should re-evaluate whether the combined estate can actually support one governed data model. Different schemas, consent definitions, and retention policies often survive long after the transaction closes. The practical test is whether the new environment can apply consistent purpose rules without relying on manual exceptions and one-off local decisions.
Technical breakdown
Why role-based and attribute-based access start to fail
Role-based access control and attribute-based access control answer who may access data, but they do not inherently express why the access is justified. That gap becomes painful when the same record is consumed by dashboards, pipelines, and AI systems under different legal or operational purposes. In large estates, the model breaks down because policy intent lives in documents while enforcement lives elsewhere, so engineering teams end up compensating with exceptions and manual review. The result is not just complexity, but weak accountability for each data-use decision.
Practical implication: Treat purpose as an enforceable control dimension, not a policy note.
How purpose-based access control changes the enforcement layer
Purpose-based access control evaluates each data request against a declared purpose at decision time. In practice, that means the policy engine sits between consumers and data sources, checks the stated purpose, and either authorises or denies access based on the rules in force. This approach is especially relevant when AI agents, applications, and analysts all need different permissions over the same underlying dataset. The architecture shifts governance from static identity grants to contextual decisioning, which is closer to how modern data use actually behaves.
Practical implication: Build policy enforcement where data is consumed, not only where identities are provisioned.
Why data discovery is the prerequisite for governed access
Purpose controls cannot work if teams do not know where sensitive data lives or how it is classified. Discovery layers map catalogs, schemas, metadata, and APIs so governance rules can attach to real assets rather than assumed inventories. In distributed enterprises, that living map becomes the foundation for retention, classification, and access-policy decisions. Without it, privacy controls remain aspirational because the organisation cannot reliably trace where regulated or sensitive data flows.
Practical implication: Inventory data assets first, then bind purpose rules to the assets that actually exist.
NHI Mgmt Group analysis
Purpose-based access control is the right answer to a governance problem that identity alone cannot solve. The article shows why RBAC and ABAC become insufficient once data use spans many systems, jurisdictions, and AI consumers. When policy has to answer why a query is allowed, not just who asked, the control model has to move closer to the data decision itself. Practitioners should treat purpose as a first-class governance signal.
The harmonisation gap is now a privacy risk, not just an operational inconvenience. Mergers, acquisitions, and international expansion create multiple schemas, retention rules, and consent definitions that do not merge cleanly. That is where liability accumulates, because the organisation may believe it has unified governance while the underlying estates remain inconsistent. Teams should assume post-merger data governance is a re-architecture problem, not a cleanup task.
AI governance will keep exposing the weakness of policy written outside the execution path. The article’s most important implication is that AI agents and automated workflows force privacy controls to be machine-enforceable, not manually interpreted. That brings privacy engineering closer to identity governance, because access decisions now have to be evaluated for context, purpose, and traceability in real time. Practitioners should design controls that can govern both human and non-human data consumers.
Data discovery is becoming a governance control, not an inventory exercise. A living map of datasets, metadata, and API surfaces is what makes policy enforcement feasible across complex estates. Without that foundation, every downstream privacy rule is partial because the organisation cannot reliably classify what it is protecting. Teams should treat discovery coverage as a prerequisite for scalable governance.
What this signals
Purpose-aware governance will increasingly shape how privacy and identity teams divide responsibilities. As data use becomes more dynamic, access control cannot remain a one-time identity grant. Teams will need shared policy language that can travel from privacy policy to enforcement logic without losing meaning.
AI agents will force privacy controls to behave like runtime security controls. If a non-human consumer can request data at machine speed, the organisation cannot rely on periodic review to catch misuse. The control point has to shift to the moment of access, where purpose, context, and traceability can be checked together.
Living data discovery is the new baseline for trustworthy governance. Once estates span multiple regions, acquisitions, and analytics pipelines, static inventories age too quickly to support policy decisions. Practitioners should expect discovery coverage to become a material measure of programme maturity.
For practitioners
- Define explicit data-use purposes Write purpose statements that map to real business and AI use cases, then reject access requests that cannot be tied to an approved purpose.
- Bind enforcement to the decision path Place policy evaluation between data consumers and source systems so every query, pipeline, or AI request is checked at runtime.
- Unify post-merger data rules Compare schemas, retention policies, and consent rules across acquired estates before promising a single governed data model.
- Inventory sensitive data continuously Keep a living map of data assets, metadata, and APIs so privacy controls can attach to the systems that actually store or expose data.
Key takeaways
- Privacy governance now fails most visibly where identity-based access control cannot explain why a data request is legitimate.
- The article’s main operational point is that AI, cross-border expansion, and M&A all increase governance complexity at the decision layer.
- Teams need runtime policy enforcement and continuous discovery if they want privacy rules to remain enforceable across a distributed estate.
Related NHI Mgmt Group resources: Privacy by Design Guide for Engineering Teams
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0 and NIST AI RMF set the technical controls, and GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Purpose-based access control changes how permissions are evaluated at decision time. |
| GV.PO-01 — Policies, Processes and Procedures | The article centres on privacy policy becoming executable governance. | |
| Recommendation — Align access decisions to PR.AA-05 by enforcing contextual authorisation for each data request. Translate privacy policy into enforceable procedures that engineering can implement and audit. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article ties AI adoption to policy design and accountability for data use. |
| Recommendation — Use GOVERN to assign accountability for AI data-use policy, enforcement, and review. | ||
| GDPR | Art.25 — Data protection by design and by default | Purpose-based governance and data minimisation align directly to privacy by design. |
| Recommendation — Build privacy controls into architecture so data use is limited by design and default. | ||
| OWASP Non-Human Identity Top 10 | NHI-10 — Human Use of NHI | The article explicitly includes AI agents as data consumers, which creates non-human governance concerns. |
| Recommendation — Treat AI agents as governed non-human consumers and restrict their data access to declared purposes. | ||
Key terms
- Purpose-Based Access: An access model that allows or denies AI use based on why the request is being made, not only who the requester is. It is more precise than role alone because it can combine identity, data labels, and request context to control sensitive AI interactions at runtime.
- Data Discovery: Data discovery is the process of finding where information lives across cloud, SaaS, endpoints, backups, and analytics systems. In practice, it creates the inventory that makes classification, access decisions, recovery planning, and AI governance possible rather than speculative.
- Privacy Engineering: Privacy Engineering is the practice of building privacy requirements into systems, data flows, and controls from the start. It covers data minimisation, purpose limitation, access control, retention, and user rights handling. Without it, teams rely on policy alone and leave privacy failures in the design.
- Cross-Border Data Governance: Cross-border data governance is the set of policies and controls used to manage data when it is stored, processed, or transferred across jurisdictions. It requires visibility into residency, transfer conditions, access rights, and local compliance obligations so governance can be enforced consistently.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is a useful baseline for practitioners who need to connect identity governance to broader security and data programmes.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org