By NHI Mgmt Group Editorial TeamDomain: Identity Beyond IAMSource: Ground LabsPublished July 23, 2026

TL;DR: Global privacy enforcement is converging on AI data use, broker deletion rights, complaint handling, and breach reporting, according to Ground Labs, while Australia’s 2025 notifications hit 1,205 and South Korea fined three organisations for inadequate safeguards. For identity teams, the issue is no longer just compliance paperwork but controlling what personal data enters models, brokers, and verification workflows.


At a glance

What this is: This privacy roundup shows regulators tightening controls around AI data use, broker deletion, complaint handling, and breach notification, with enforcement now spanning Europe, the UK, North America, Asia, and Australia.

Why it matters: It matters because IAM, identity verification, and data governance teams now have to control personal data lifecycle decisions before, during, and after processing, not just authenticate users.

By the numbers:

👉 Read Ground Labs' privacy roundup covering AI data use, broker deletion rights, and breach reporting


Context

Privacy regulation is moving from notice-and-consent language toward operational control of personal data. The core problem is that organisations still treat personal data as something to collect first and govern later, which breaks down once AI models, brokers, complaint systems, and deletion workflows all depend on the same data estate.

That matters for IAM, identity verification, and NHI governance because identities are the access path to personal data, not just the subject of it. When data is scraped into generative AI pipelines or reused across broker networks, the control question becomes who can collect, retain, repurpose, or delete identifiable information at each stage of its lifecycle.


Key questions

Q: How should organisations govern access to data used by AI systems?

A: Treat AI data access as an identity governance problem, not just a data storage problem. Define who or what can use each dataset, what purpose is allowed, and what runtime restrictions apply. Then review humans, service accounts, and AI agents separately so entitlement scope matches actual behaviour rather than a generic AI policy.

Q: Why do data deletion requests fail in practice?

A: They fail when organisations can delete one record but not the copies, derivatives, partner feeds, or repopulated data that continue to exist elsewhere. Effective deletion depends on record matching, system inventory, and validation across downstream storage. Without those controls, a request can be completed administratively while the data remains operationally present.

Q: How do you know a privacy complaint process is actually working?

A: You know it is working when complaints are acknowledged within the required time, routed to the correct owner, and resolved with evidence that the underlying data issue was addressed. If the team cannot show who handled the case, which records were affected, and what control changed, the process is failing as a governance mechanism.

Q: Should identity verification teams retain full identity documents after checks are complete?

A: Usually no. Verification teams should retain only what they need for lawful recordkeeping and ongoing risk management, because full documents expand exposure without improving control after the check is complete. Retention should be minimised, access should be restricted, and deletion or truncation should be governed by clear legal and operational requirements.


Technical breakdown

Web scraping for generative AI and data minimisation

The EDPB consultation reflects a simple control reality: web scraping turns public content into regulated processing the moment it is collected for model development. Purpose limitation and data minimisation require controllers to decide up front whether a dataset is necessary, lawful, and proportionate. In practice, that means filtering for personal or sensitive information before ingestion, not trying to clean it after training has begun. Synthetic data can reduce exposure, but only if the organisation has a reliable pre-ingestion review process and clear accountability for what enters the model.

Practical implication: build pre-ingestion screening and approval into AI data pipelines before training or retrieval begins.

Deletion requests, identity matching, and repopulation risk

California's DROP mechanism changes deletion from a single request into a distributed identity-resolution problem. Data brokers must find matching records across systems, reconcile identifiers, and remove copies, derivatives, and repopulated records that can reappear through later collection. That creates a governance challenge similar to identity lifecycle management: if the matching logic is weak, the organisation can comply on paper while the data persists operationally. The hardest part is not receiving the request. It is proving that the deleted data stays deleted across downstream systems and partner feeds.

Practical implication: test deletion workflows against duplicate records, derived data, and downstream repopulation paths.

Personal data in AI governance and complaint handling

Singapore's PDPC guidance and the UK's complaint requirements both point to the same operating model: privacy controls must exist across development, deployment, and user recourse. For AI systems, personal data governance is not separate from model governance because the data shapes outputs, retention risk, and user rights handling. For organisations, complaint intake is also a control point, because missed acknowledgements and unclear ownership often reveal that privacy accountability is fragmented. A mature programme aligns data processing records, AI workflow controls, and complaint handling into one auditable chain.

Practical implication: align privacy operations, AI governance, and identity access records so complaints and data requests can be traced end to end.


Threat narrative

Attacker objective: The objective is to exploit the value and persistence of personal data across collection and AI processing paths for theft, reuse, or monetisation.

  1. Entry begins when personal or sensitive data is scraped, brokered, or collected into systems that were not designed with lifecycle controls in place.
  2. Escalation occurs when weak matching, retention, or downstream sharing allows the same data to persist across multiple repositories, models, or partner feeds.
  3. Impact follows when organisations cannot delete, correct, or explain the use of that data, creating regulatory exposure, breach amplification, and loss of trust.

NHI Mgmt Group analysis

Data minimisation now functions as a control, not a policy statement: the article shows regulators pushing responsibility upstream into collection, filtering, and model ingestion decisions. If an organisation cannot prevent sensitive data from entering a pipeline, downstream privacy controls are already too late. That makes pre-ingestion screening and purpose control the real governance boundary for AI and data teams.

Deletion and redress are becoming identity problems: California's broker deletion workflow shows that privacy compliance depends on locating the same person or record across fragmented systems. That is structurally similar to identity lifecycle governance, where duplicates, derived data, and partner copies defeat neat policy claims. Practitioners should treat deletion success as a record-resolution problem, not a form-handling exercise.

Complaint handling exposes accountability gaps: the UK's requirement to acknowledge complaints within 30 days is not just a service rule, it is an accountability test. Where organisations cannot route complaints quickly, they usually also lack clear ownership for personal data decisions, which weakens both privacy and IAM governance. The practical conclusion is that complaint intake, access records, and data inventories must be linked.

AI governance and privacy governance are converging: Singapore's guidance shows that personal data in AI systems cannot be managed as a separate compliance stream. The same controls that govern lawful collection, retention, and subject rights also govern model inputs, outputs, and stakeholder responsibilities. Teams that keep AI and privacy in separate programmes will keep finding gaps at the point of use.

Privacy enforcement is now operational, not abstract: the combination of record fines, breach reporting, and data broker obligations shows that regulators expect evidence of control, not just documentation. This is a governance shift that affects IAM, IGA, and data security together because personal data is handled through identity-mediated access paths. The programme implication is clear: control evidence must be observable across the full data lifecycle.

What this signals

Personal data governance is becoming a control-plane issue: when data moves through AI pipelines, broker ecosystems, and complaint processes, the relevant control is not just policy wording but provable lifecycle enforcement. For identity and data teams, that means access governance, record resolution, and retention controls need to be designed as one operating model.

The most important programme signal is that privacy obligations are now touching identity work directly. Verification, retention, deletion, and complaint handling all depend on knowing which records belong to which person and who can act on them, which means IAM and data governance can no longer be run as separate disciplines.


For practitioners

  • Move privacy review before AI ingestion Require pre-ingestion review for scraped, brokered, or contributed datasets, with explicit checks for personal and sensitive data before model training or retrieval starts.
  • Test deletion across copies and derivatives Validate that deletion requests remove matching records, backups, derived datasets, and reimport paths across every connected system, not just the first repository that receives the request.
  • Link complaint handling to data ownership Assign a named owner for every complaint path so acknowledgement, investigation, and remediation can be traced to a specific privacy or identity control owner.
  • Treat identity verification as retention-limited Keep the verification outcome, not the full identity document, once AML or customer due diligence checks are complete unless a specific legal basis requires retention.

Key takeaways

  • Regulators are moving privacy enforcement upstream, so organisations must control data before AI ingestion and broker processing begin.
  • Deletion and complaint handling are now operational governance tests, not administrative tasks, because they depend on record matching, routing, and evidence.
  • IAM, identity verification, and privacy operations are converging around the same lifecycle problem: who can collect, retain, repurpose, and delete personal data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST AI RMF, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while GDPR define the regulatory obligations.

FrameworkControl / ReferenceRelevance
NIST AI RMFGOVERNAI data governance and accountability are central to the article's model-ingestion guidance.
NIST CSF 2.0PR.DS-1The article centres on controlling data throughout collection, retention, and deletion.
NIST SP 800-53 Rev 5AU-11Complaint and deletion workflows require auditable evidence of processing and disposition.
GDPRArt.5Purpose limitation and minimisation are directly implicated by web scraping and AI ingestion.
NIST SP 800-63SP 800-63CIdentity proofing and federation concepts inform how records are matched across deletion workflows.

Treat personal-data handling as a protected asset lifecycle and validate retention and disposal controls.


Key terms

  • Claim Minimisation: The practice of including only the identity attributes required for a specific access decision. In API security, claim minimisation reduces unnecessary data exposure, simplifies token review, and lowers the risk that broad identity context becomes a hidden authorisation dependency.
  • Purpose limitation: The rule that data should be used only for the specific business purpose allowed by policy and context. In AI environments, this means a dataset may be technically accessible but still inappropriate for a given model, assistant, or agent if the use case exceeds the approved scope.
  • Data Broker Deletion Workflow: A data broker deletion workflow is the process used to locate, match, and remove personal information after a request is received. It must handle duplicates, copies, derived records, and repopulation risk across connected systems to be effective.
  • Privacy Complaint Handling: Privacy complaint handling is the operational process for receiving, acknowledging, investigating, and resolving complaints about personal data use. It is both a service obligation and a control signal, because weak routing or delayed acknowledgement often reveals poor accountability.

What's in the full article

Ground Labs' full blog post covers the operational detail this post intentionally leaves for the source:

  • Country-by-country privacy law updates and how each one changes compliance workflows for AI and data teams
  • Specific obligations for web scraping, deletion requests, complaint handling, and personal data in generative AI
  • Regulatory context behind Australia, the UK, Singapore, South Korea, California, and New Jersey
  • The article's practical emphasis on where privacy controls should sit in the data lifecycle rather than in legal review alone

👉 Ground Labs' full roundup covers the country-by-country privacy changes and their practical compliance implications.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps security and identity practitioners connect access control to the broader governance demands of modern programmes.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org