Privacy and Data Governance

References

A synthesis of selected conference talks and technical references. Citations link to the source material; they do not imply that every talk on this subject is included.

1. NISTIR 8062: An Introduction to Privacy Engineering and Risk Management in Federal Systems

   NIST distinguishes privacy risks arising from planned, authorized processing from security risks involving unauthorized activity. A system can meet its intended operational purpose while creating adverse consequences for people. The report uses persistent activity monitoring to illustrate how a security measure can reveal information unrelated to its security purpose. Privacy engineering therefore requires examining what processing does to people, alongside protecting information against unauthorized access.

2. UK Government: Data ownership model

   This model treats data ownership as organizational accountability rather than possession. Senior data owners decide major uses and changes, understand flows and ensure retention arrangements. Stewards manage daily governance, maintain definitions, coordinate access and deletion, and escalate issues. Technical custodians implement storage, disposal and access policies and make changes auditable. The guidance identifies unclear responsibilities as an obstacle to sharing and reusing data across organizations.

3. Regulation (EU) 2016/679: definitions, processing principles and correction

   Personal data concerns an identified or identifiable person, called the data subject; identification can be indirect. Processing includes storage, use, alteration, disclosure and erasure. Pseudonymization separates identifying information under safeguards rather than necessarily removing identifiability. Purpose limitation constrains collection and incompatible subsequent use; minimization limits data to what the purpose requires; storage limitation constrains identifiable retention. Accuracy, security and lawfulness are separate requirements. Article 6 provides multiple lawful grounds, so consent is not universally required. Article 16 addresses rectification; Article 19 requires communicating qualifying corrections, erasures and restrictions to recipients, subject to impossibility or disproportionate effort.

4. Saltzer and Schroeder: Basic Principles of Information Protection

   Least privilege limits each program and user to the authority needed for its task, reducing the damage from error or compromise. Complete mediation requires authorization checks for every access, including lifecycle paths such as recovery, and reliable identification of the requester. Cached authorization decisions must account for changed permissions. Fail-safe defaults make access depend on explicit permission. Applied to an agent, these principles require enforcement where a proposed operation actually reaches a protected resource; a model promise or a tool description is not that enforcement.

5. OECD Recommendation: Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data

   The OECD guidelines connect privacy protection with cross-border information flows. Purposes should be specified by collection time, and subsequent uses constrained by compatibility and stated changes of purpose. The revised recommendation makes accountability operational through a privacy management programme proportionate to processing scale and sensitivity, integrated oversight, risk assessment, monitoring and periodic reassessment. Controllers remain accountable for personal data under their control regardless of its location.

6. LLM Quality Optimization Bootcamp

   Real production prompts paired with responses from a stronger LLM are presented as a middle ground between fully human and fully synthetic training data.

7. CNIL: Ensuring the lawfulness of the data processing—Defining a legal basis

   Valid GDPR consent must be freely given, specific, informed and unambiguous. CNIL illustrates purpose specificity with company-event photographs: agreement to use an image for communications does not establish agreement to reuse it for AI training. Separate purposes require granular choices when relying on consent. Employment relationships can undermine voluntariness; the guidance describes employee consent as exceptional, requiring refusal and withdrawal without adverse consequences. Including product-improvement processing in contractual terms does not itself make that processing necessary to perform the service contract.

8. CNIL: Ensuring the lawfulness of data processing—Additional verifications when reusing data

   CNIL distinguishes reusing an organization's own data, downloading public datasets and acquiring datasets from suppliers. Compatibility review considers the original purpose, collection context, reasonable expectations, sensitivity, consequences and safeguards. For acquired datasets, recommended documentation covers sources, collection circumstances, legal basis, notices and sharing conditions. A contractual promise that a supplier obtained consent is insufficient proof that valid consent exists; arrangements should provide the underlying evidence. Using statistical machine-learning techniques does not automatically make the processing a statistical purpose under the GDPR.

9. U.S. Copyright Office: Copyright and Artificial Intelligence, Part 3—Generative AI Training

   The report distinguishes internet availability from authorization. Downloading and preparing copyrighted training material can implicate reproduction rights. Different uses during development and deployment require separate consideration. Fair use depends on circumstances including the works, their source, the purpose and output controls; the report does not declare all training permissible or infringing. Voluntary licensing can authorize uses and impose contractual conditions, but availability varies across sectors. The Office recommends allowing licensing markets to develop rather than immediately imposing a compulsory regime.

10. Records, Computers and the Rights of Citizens: Summary and Recommendations

    The HEW committee identified an imbalance: computerization expanded organizations’ capacity to collect, link and use records while individuals had fewer ways to influence their handling. It proposed fair-information safeguards covering openness about record systems, access to information and its uses, control over secondary uses, correction, reliability and protection against misuse. Its concern about Social Security numbers becoming general identifiers connected privacy risk to linkage across otherwise separate systems.

11. Privacy by Design: The 7 Foundational Principles

    Ann Cavoukian describes developing Privacy by Design during the 1990s in response to expanding networked information systems. The approach extends beyond privacy-enhancing technologies to business practices and infrastructure. Its principles call for preventive design, protective defaults, privacy embedded in functionality, lifecycle protection, transparency and independent verification. It asks designers to pursue legitimate functionality and privacy together rather than assume that protecting privacy necessarily requires abandoning the service.

12. Beyond Memorization: Violating Privacy via Inference with Large Language Models

    The free-text experiment gives pretrained models author-grouped Reddit comments through a fixed prompt, without subreddit metadata or added retrieval information, and asks for personal attributes. Evaluation uses 520 profiles and 1,066 author-annotated labels meeting a certainty threshold; GPT-4 reaches 85.5% top-one accuracy across attributes. An introductory example infers Melbourne from a commuting comment mentioning a locally characteristic turning maneuver, illustrating location inference without an explicit address or name.

13. NIST Privacy Framework 1.0: lifecycle and minimized audit evidence

    The framework inventories data elements, processing purposes, actions, owners and flows. Policies define permitted uses and retention periods; the data lifecycle aligns with system development and operations. Authorizations must be maintained and revocable, access limited by least privilege, and deletion and destruction performed under policy. Audit records themselves must incorporate data minimization. Engineering application: define the decision evidence needed for review, its purpose, authorized readers, retention trigger and disposal method before logging. Retain the necessary decision, model and policy versions and relevant evidence without indiscriminately copying personal data into logs, prompts or backups. Where review requires sensitive evidence, constrain fields, access and retention rather than treating auditability as permission to keep everything. Assess removal and disclosure across downstream copies and service providers.

14. ICO: Data protection impact assessments

    A DPIA systematically examines a project’s processing and risks to people. The ICO calls for describing nature, scope, context and purposes; assessing necessity and proportionality; identifying risks and mitigations; consulting relevant stakeholders; documenting decisions; and implementing identified measures. It distinguishes legally required assessments for likely high-risk processing from good practice for other major personal-data projects. Its checklist calls for renewed assessment when processing changes and a documented review schedule.

15. LLM Safeguards: Security, Privacy, Compliance, Anti-Hallucination

    Treat a model server as an API service requiring endpoint monitoring and ordinary infrastructure security.

16. Microsoft: How data is protected and audited in Microsoft 365 and Microsoft Copilot

    Microsoft documents that Copilot summarizes or references content the user is authorized to access. For supported content-generation paths, new content inherits the highest-priority sensitivity label among labeled sources; Copilot Chat can also display source sensitivity. The system creates additional governed artifacts: interaction records, retained versions of referenced files, uploads in OneDrive and Copilot Pages in SharePoint Embedded containers. Retention and deletion depend on configured Purview policies.

17. Text Embeddings Reveal (Almost) As Much As Text

    Text embeddings represent text numerically for uses including retrieval, but that transformation need not conceal the source. The authors train Vec2Text to reconstruct inputs from embeddings and demonstrate recovery of names from clinical-note embeddings. Their threat model includes access to embeddings and text–embedding pairs from the relevant encoder. The experiments provide a concrete reason to include retrieval representations in sensitive-data inventories rather than treating them as automatically anonymous.

18. Towards Making Systems Forget with Machine Unlearning

    Cao and Yang distinguish removing training records from reversing their effects on learned features and models. Retraining after removing records supplies a straightforward but potentially expensive approach. Their alternative restructures suitable learning algorithms around stored sums, subtracts the removed samples’ contributions and updates the model. Evaluations include a recommendation system, spam filtering and malware detection. Their broader proposal treats forgetting as a problem of both completeness and timeliness across derived information.

19. OpenTelemetry: Handling sensitive data

    Telemetry instrumentation cannot determine on its own which fields are sensitive in a particular application. OpenTelemetry recommends collecting only attributes that serve an observability purpose, reviewing instrumentation output, and considering aggregates or anonymized data. Collector processors can remove attributes, filter whole records, transform values, or enforce an attribute allowlist. This makes observability a data-design decision: retain enough context to answer a specific diagnostic question, while recognizing that full prompts, tool results, tokens, and identifiers can create an additional sensitive dataset.

20. NIST AI Risk Management Framework 1.0

    NIST organizes lifecycle risk work into Govern, Map, Measure and Manage. Identify affected populations and deployment context, consult relevant communities, evaluate harmful bias and document results rather than relying only on aggregate performance. Assign clear responsibilities, executive accountability and human-oversight roles. Evaluate under conditions resembling deployment, document limits and unmeasurable risks, and monitor after release. Engineering implication: material subgroup harms or ineffective oversight should affect deployment scope, mitigations and whether to proceed, with explicit ownership of acceptance and incident decisions.

21. EDPB Guidelines 07/2020 on controller and processor

    Controller and processor roles follow actual activities rather than contractual labels. A controller determines purposes and essential means; a processor is a separate entity processing on its behalf. The controller is ordinarily the organization, not its individual employee. A subprocessor is another processor engaged within that processing chain. Engagement requires prior specific or general written authorization, with change notification and opportunities to object under general authorization. Assessment includes intended subprocessors’ locations, activities and safeguards. At termination, deletion or return follows the controller’s choice; existing copies must be deleted unless applicable EU or Member State law requires storage. Processors must provide compliance information and support audits.

22. NIST SP 800-53A Revision 5: Assessing Security and Privacy Controls

    NIST connects assessment findings to explicit control requirements. Assessment objects include written specifications, technical mechanisms, human activities and responsible people. Examination gathers evidence through inspection or observation; interviews clarify operation; tests exercise mechanisms or activities under stated conditions and compare actual with expected behavior. Assessment depth and coverage should match needed assurance. Assessments continue during operation and include disposal, because correct initial implementation does not establish continuing effectiveness.

23. NIST SP 800-63-4: Digital Identity Guidelines

    A digital identity distinguishes someone within an online-service context without necessarily establishing their real-world identity; one person can have several digital identities. NIST permits anonymous or pseudonymous accounts when real-world identity assurance is unnecessary. Identity proofing distinguishes the applicant and validates identity evidence and attributes. Authentication instead verifies possession or control of authenticators bound to an active subscriber account. These are different functions with separately selected assurance levels.

24. OWASP Access Control

    Authentication establishes identity; authorization decides which actions that identity may perform on particular resources. A user allowed to initiate a transfer must still be authorized for the source account. Least privilege limits the authority of running code and service accounts, while centralized checks reduce inconsistent enforcement. In an AI application, tool availability and a model-produced argument are therefore insufficient grounds to execute a business operation; the application must apply resource- and action-level policy.

25. RFC 8693: OAuth 2.0 Token Exchange

    Delegation preserves the distinction between the party represented and the actor exercising delegated rights. Impersonation instead makes the actor appear as the represented party within the authorized context. RFC 8693 supports subject and actor tokens and a JWT actor claim for expressing delegation. Token issuance and downstream scope depend on authorization-server policy; token exchange does not itself prescribe the deployment’s trust model.

26. NIST SP 800-162: Guide to Attribute Based Access Control

    Attribute-based access control evaluates characteristics of the requester, protected resource and environment against policy to allow or deny an operation. Requesters can be humans or non-person entities. Protected resources include records and systems receiving information. Read, write, edit, delete and copy are distinct operations. Authorization evaluates current attribute values rather than merely recognizing an identity. This supplies a vocabulary for expressing different handling permissions for a user, service, record and requested action.

27. Identity for AI Agents

    Authentication to the agent and permission to access upstream resources are separate steps, even when both applications use the same credentials.

28. Regulation (EU) 2016/679: notices and conditional individual rights

    Articles 12–15 require understandable notices and provide access to personal data and handling information. Additional identity information is permitted when reasonable doubts exist and must be necessary to confirm identity; identity documents are not universally required. Article 18 permits restriction during accuracy or objection verification, for unlawful processing where restriction replaces erasure, or for data needed by the person for legal claims. Storage may continue; other processing has limited exceptions. Article 21 distinguishes situation-based objections to public-task or legitimate-interest processing, subject to overriding grounds or legal claims, from direct-marketing objections requiring that use to stop.

29. Directive (EU) 2016/943: lawful and unlawful handling of trade secrets

    Article 4 treats use or disclosure without the holder’s consent as unlawful when the person acquired the secret unlawfully, breaches a confidentiality duty, or breaches a duty limiting use. Acquisition includes unauthorized access or copying and conduct contrary to honest commercial practices. Downstream acquisition, use or disclosure can also be unlawful when the recipient knew or should have known of the source’s unlawful handling. Article 3 permits independent discovery and specified observation or testing where no legally valid acquisition restriction applies, and handling required or allowed by law.

30. EDPB Guidelines 05/2020 on consent

    Controllers must demonstrate valid consent, including when and how it was obtained and what information the person received. The guidance illustrates retaining evidence of the consent session and the contemporaneous workflow. Withdrawal must be as easy as giving consent and possible without detriment. Previously lawful processing does not become unlawful retrospectively upon withdrawal. Processing for another independently established purpose, such as performing a contract, does not necessarily require erasure when consent for a different purpose is withdrawn. Purposes and their legal bases should therefore be distinguished from the outset.

31. PROV-DM: The PROV Data Model

    PROV represents entities, activities and responsible agents, including people, organizations and software. Derivation connects a resulting entity to a source that affected it; merely participating in the same activity does not establish derivation. Attribution connects an entity to an agent, association records responsibility for an activity, and delegation represents acting on another agent’s behalf while that agent retains responsibility. Identifiers and attributes describe these relationships. This supports lineage records connecting source artifacts, transformations, outputs and responsible actors.

32. Operationalizing Data Minimization for Privacy-Preserving LLM Prompting

    The authors search combinations of retaining, abstracting and redacting detected sensitive spans, testing whether the resulting prompt preserves task utility. Their experiments cover conversation prompts and medical and legal multiple-choice questions. Acceptable minimization varies across models and tasks; direct model predictions of what to remove often differ from the search results. Separate recovery tests find that some transformed information remains recoverable, demonstrating why preserved usefulness and reduced disclosure require distinct checks.

33. ICO: What is special category data?

    UK GDPR special categories include health, genetic information, political opinions, religious beliefs and biometrics processed for unique identification. The categories receive additional protection because processing can threaten fundamental rights or enable discrimination. Other information, including financial information, can be sensitive without belonging to these categories. Intentionally inferring a special-category attribute, or treating someone differently using such an inference, can trigger special-category requirements regardless of confidence in its correctness. Merely holding a name from which someone could guess religion does not automatically have that effect.

34. NIST SP 800-188: De-Identifying Government Datasets—Techniques and Governance

    Redaction removes information; pseudonymization replaces direct associations with pseudonyms that can preserve linkage across observations. Quasi-identifiers are attributes that can identify someone when associated with other information. Aggregation produces summaries rather than individual records, but repeated releases can disclose more than an isolated release. NIST's teaching example removes patient names and medical identifiers while retaining room numbers and visit times: another dataset linking rooms and times to names can restore identification. Transformations can also change analytical usefulness or introduce bias, so privacy protection and task usefulness require separate evaluation.

35. Re-identification risk in released recommendation histories

    Removing direct identifiers does not necessarily anonymize sparse behavioral records. Narayanan and Shmatikov show how auxiliary knowledge of a few movie ratings and approximate dates can help link a person to a released Netflix rating record. Sparse combinations can be distinctive even when individual movies are common. A successful linkage can expose additional ratings that were not public in the auxiliary source. The paper includes experiments with imperfect auxiliary information and a small IMDb-based proof of concept, demonstrating a concrete risk from publishing detailed recommendation histories.

36. OpenLineage: Column Level Lineage Dataset Facet

    OpenLineage records which input columns influence output columns and how. Its delivery-time example derives a duration from order and delivery timestamps. The specification distinguishes direct value transformations from indirect influences such as filtering, joining and sorting. This matters because a field can affect which records appear without appearing in the output. The documentation also shows how representing indirect dependencies repeatedly for every output field can inflate lineage metadata.

37. Citation Needed: Provenance for LLM-Built Knowledge Graphs

    A synthesized fact can hide both its original wording and the authority of its actual source, so retain verbatim inputs and explicit links to derived artifacts.

38. Citation Needed: Provenance for LLM-Built Knowledge Graphs

    Lineage must survive graph mutation: entity merges retain both source sets, and invalidation records the new evidence responsible for the change.

39. The Protection of Information in Computer Systems: Basic Principles

    Least privilege limits each user and program to permissions needed for its job. Complete mediation requires authority checks on every access to every object, including initialization, recovery, shutdown, and maintenance. It requires reliable identification of request sources and care with cached authorization when permissions change. Fail-safe defaults base access on explicit permission. Applied to a harness, these principles imply that protected operations must pass through an enforcement mechanism that the requesting program cannot bypass or modify; a prompt instructing the model to behave is not that mechanism.

40. LLM Safeguards: Security, Privacy, Compliance, Anti-Hallucination

    Query data sources using the requesting user's proper role; organizing documents does not solve authorization.

41. RFC 9396: OAuth 2.0 Rich Authorization Requests

    Rich Authorization Requests represent permissions as structured authorization details. Published examples distinguish reading account information from initiating a payment and identify payment amount, currency and recipient. Another example grants different read and write permissions to different file paths. The authorization server must make approved details available to the resource server so it can enforce them; audience-specific filtering limits which details each resource server receives.

42. RFC 9110: HTTP Semantics

    If-Match makes a request conditional on the current representation matching a supplied entity tag using strong comparison. It is commonly used for state-changing requests to prevent concurrent clients from accidentally overwriting each other’s changes. The origin evaluates the precondition before performing the method and must not perform the requested method when the condition is false. This provides a concrete mechanism for rejecting a proposed record update whose reviewed version has become stale.

43. Zanzibar: Google’s Consistent, Global Authorization System

    Zanzibar illustrates why permission checks must account for changes over time. Its published example removes Bob’s access before new content is added; evaluating an old access-control list against the new content could disclose information to Bob. The system coordinates authorization and content versions through consistency tokens, ensuring checks are sufficiently fresh. This permits many checks to use replicated data while respecting relevant permission changes.

44. Zep: Episode metadata projection

    Zep associates derived facts, entities, observations and summaries with source episodes—the ingested messages, text or JSON. An artifact's effective metadata combines distinct values from its associated episodes, and source-based access policies evaluate that effective metadata. Search filtering has different semantics: a result matches when at least one associated episode satisfies the filter, with all AND conditions satisfied by that same episode. The published fixture combines CRM and support-ticket provenance on one edge.

45. Myers and Liskov: A Decentralized Model for Information Flow Control

    Myers and Liskov's decentralized model attaches source owners and permitted readers to information. Combining values preserves every source's restrictions rather than choosing whichever source grants broader access. In the paper's example, one owner permits readers r1 and r2 while another permits r2 and r3; their common permitted reader is r2. An output channel may receive information only when its readers satisfy the information's restrictions. Declassification means relaxing a restriction and requires authority for the owner whose policy changes.

46. Wearing the Agent: Engineering a Family-and-Friends Personal Agent, from Group Chats to Glasses

    Choose the delivery channel according to who should receive the information.

47. ICO: Right to rectification

    The guidance distinguishes incorrect or misleading factual information from a record clearly identifying an opinion and, where appropriate, its author. A challenge requires reasonable accuracy checks considering the person’s evidence and the consequences of use. The ICO recommends restricting processing while checking, even without a separate restriction request. If the controller maintains that the record is accurate, it should explain its decision and complaint and judicial-remedy routes; recording the dispute and reasons is good practice. A historical mistake may remain accurately recorded alongside its correction.

48. NARA: Guide to Inventorying, Scheduling and Disposition of Federal Records

    A records schedule can distinguish the end of active use from the start of a retention or transfer period and eventual destruction or transfer. Cutoff instructions may use a specific event, such as case closure, or an age measured from creation or receipt. NARA recommends clear, machine-implementable instructions and cautions that vague disposal instructions require someone to decide when records are no longer needed. Different record groupings need meaningful triggers for the records they contain.

49. OWASP: Logging Cheat Sheet

    Avoid directly logging passwords, access tokens, session identifiers, encryption keys, database connection strings, payment details, sensitive personal data and commercially sensitive content. Remove or appropriately transform sensitive fields before recording events. Restrict and periodically review log access, monitor access, protect integrity and secure transmission. Retention rules must cover debug logs, backups, copies and exports as well as primary storage. Engineering application: prompts, retrieved passages, tool arguments and model outputs require the same classification and redaction controls as ordinary application data.

50. ICO: Right to erasure

    For a valid erasure request without an applicable exemption, the ICO says organizations must address backups as well as live systems. Immediate live-system erasure may coexist with backup copies awaiting scheduled overwrite. Such backup information must be placed beyond use and not used for another purpose while awaiting replacement. Organizations must explain what will happen to the information, including backups. The guidance identifies exceptions including legal obligations and establishing, exercising or defending legal claims.

51. One Login to Rule Them All: Cross-App Access for MCP

    Separately issued MCP tokens and API keys can leave access paths that survive SSO revocation and require their own inventory and revocation.

52. Changed and Deleted Blobs — Azure AI Search

    Blob indexers detect changes through LastModified, but physical source deletion alone does not remove indexed documents. Configure deletion detection from the first run. Soft deletion leaves an observable marker so the indexer can remove the corresponding search document before permanent source removal. Retention must substantially exceed the indexing interval and allow recovery from failures. Stable document keys and paths are essential to tracking. Restoring a blob may not advance LastModified, so resaving metadata can trigger reindexing. Application implication: verify successful deletion processing before purging markers and retain parent-to-chunk identities for derived cleanup.

53. Azure AI Search: Changed and Deleted Blobs

    Azure Storage indexers detect updates using source timestamps on subsequent runs. Source deletion requires a configured detection policy; deleting a blob does not automatically remove its search document. Native soft deletion works only if the indexer processes the blob while its deletion marker remains available. Retention therefore needs substantial margin beyond the indexing interval and possible outages. Stable document keys support tracking. Adding a deletion policy after documents were already deleted does not recover those missed deletions, even after an indexer reset.

54. Zep: Deleting Data from the Graph

    Deleting a Zep episode removes associated edges and nodes only when no other episode associations remain. Shared node names and summaries are not regenerated, so information from the deleted episode may remain in them. Deleting an episode that invalidated a fact does not reverse that invalidation. The automatically created user entity also survives episode deletion. By contrast, deleting a node removes its connected edges, while deleting an edge preserves its nodes.

55. Elasticsearch: Delete a document

    Deletion can be conditional on sequence number and primary term, preventing deletion of a document changed since it was read. Custom routing must match the routing used to index the document. Deleted versions remain available only for the interval controlled by index.gc_deletes. Search visibility is separate: refresh=wait_for waits for a refresh exposing the deletion. Application inference: bound delayed retries or keep durable source tombstones/version checks beyond the search engine's deletion-retention window to prevent obsolete events from recreating deleted evidence.

56. Verification of Machine Unlearning is Fragile

    Machine unlearning aims to make a trained model forget selected training data. This paper studies whether a dishonest provider can pass unlearning verification while preserving information associated with the supposedly removed data. It constructs adversarial methods targeting verification through reproduced training evidence and backdoor tests, and evaluates them on image-classification datasets. The results demonstrate that passing the studied checks need not establish removal of training influence.

57. EDPB Opinion 28/2024 on personal data in AI models

    An AI model trained with personal data is not automatically anonymous. Assessment must consider extraction and identification through queries, reasonably available means, release context and auxiliary information. The opinion requires evidence supporting insignificant likelihood of obtaining training-related personal data. For legitimate interests, controllers must establish an interest, necessity and a balance against affected people’s rights; public availability is only one contextual consideration. Roles and responsibilities should be assessed before processing. Development and deployment can involve separate purposes, and the consequences of unlawful development processing require case-specific assessment.

58. OpenAI: Data controls in the OpenAI platform

    OpenAI distinguishes model-training use, abuse-monitoring logs and feature-specific application state. API content is not used for model improvement by default, but this does not imply no storage. Monitoring logs normally have a retention period of up to 30 days, with legal and harm-prevention exceptions. Zero Data Retention has endpoint and capability limitations; the documentation also describes notified model-specific exceptions affecting retention and human review. Third-party services apply their own retention policies. Regional storage and regional processing are separate capabilities, with exclusions for system data and third-party services.

59. Claude API and data retention

    Anthropic documents different storage needs and retention arrangements across API features. Features requiring storage can fall outside zero-data-retention eligibility, while retained data is not used for training without express permission. The documentation distinguishes Anthropic-operated processing from integrations where a cloud provider is the processor. It also identifies separate retention models for other organizational features. These distinctions make training use, storage requirements, feature eligibility and processing relationships separate vendor-review questions.

60. AWS: Shared Responsibility Model

    Operational responsibility depends on the service abstraction. AWS documents that customers operating virtual machines manage guest operating systems, patches and installed applications, while abstracted services transfer more infrastructure and platform operation to the provider. Customers still manage their data classification and permissions. AI deployment inference: self-hosting assigns the operator more responsibility for inference software, capacity, patching and availability; managed inference transfers some of that work under service-specific terms without transferring responsibility for application authorization or appropriate data use.

61. Apple: Private Cloud Compute—A new frontier for AI privacy in the cloud

    Apple's June 10, 2024 technical introduction connects cloud inference capability to explicit handling requirements: use personal inputs only to fulfill the request, retain none after returning the response, and prevent privileged operators from bypassing those limits. The described design replaces general-purpose administration and inspection tools with restricted operational metrics. Requests are encrypted directly to validated compute nodes; the inference process deletes request data on completion, and process address spaces are periodically recycled.

62. Apple: Expanding Private Cloud Compute

    On June 8, 2026, Apple announced extending PCC to Google Cloud infrastructure with NVIDIA GPUs. It retained the stated requirements for stateless processing, constrained privileged access and verifiable transparency while changing the infrastructure implementation. Apple said it would retain control of PCC software and that devices would trust only software cryptographically approved by Apple. The announcement described a summer preview gradually reaching the complete set of protections, with additional research tooling and documentation to follow.

63. OpenTelemetry: Handling sensitive data

    OpenTelemetry cannot determine what is sensitive in an application's context; implementers must review emitted telemetry and protect it. The guidance favors collecting only data needed for observability and avoiding unnecessary personal information. Collector processors can delete or modify attributes, filter entire records, enforce attribute allowlists, and transform values. Credentials and session tokens are among the explicitly identified sensitive categories. Hashing predictable identifiers does not reliably anonymize them because candidate values can be enumerated.

64. NIST SP 800-61r3: incident response and verified recovery

    Triage validates an incident report and estimates severity and urgency; response priority considers impact, scope, and available resources. Containment limits expansion, while eradication removes persistence mechanisms and entry points. Investigators preserve the integrity and provenance of evidence and action records, with restricted access and defined retention. Recovery can begin during response under explicit criteria. Verify restoration assets before use, check restored systems for compromise, remediate root causes, and verify restoration before production use. Confirm service restoration with owners and monitor its adequacy. For an AI deployment-state example, specify affected components, containment, preserved evidence, authorized recovery actions, trusted restoration inputs, verification criteria, and who confirms resumed service; these are application choices implementing the guidance.

65. OpenLLMetry is all you need

    A self-deployed OpenTelemetry collector can preprocess telemetry before it reaches an observability provider.

66. NIST AI RMF 1.0: accountability, appeals and override

    NIST calls for documented responsibilities and communication, defined human oversight, feedback channels that let affected people report problems and appeal outcomes, and monitoring that includes appeal and override. It also calls for documenting responses to errors; its human-AI discussion identifies override frequency and rationale as useful evidence. Engineering application: attach a dispute to its decision ID and original input/model/policy versions; route it to an accountable reviewer empowered to inspect evidence and authorize correction or override. Record the reviewer, evidence, rationale, revised disposition and downstream correction status, and communicate the result to the affected person. Feed recurring errors into evaluation and remediation. A trace alone does not provide this correction path.

67. GPU-less, Trust-less, Limit-less: Reimagining the Confidential AI Cloud

    The n8n demo separates patient identifiers from diagnostic inputs before invoking the model, then recombines them for reporting.

68. LLM Safeguards: Security, Privacy, Compliance, Anti-Hallucination

    Retrieved internal text can expose personal information through generated responses; filter sensitive content before it reaches the LLM.

69. LLM Safeguards: Security, Privacy, Compliance, Anti-Hallucination

    Surface prompt-injection flags and patterns of sensitive-data submission while minimizing prompt and completion retention.

70. Identity for AI Agents

    The workshop adds capabilities in stages: a public stock-price tool, authorized portfolio reads, and only later order creation.