Blog · Review Essay · Last reviewed June 25, 2026

Privacy in Context and the Rules of Information Flow

Helen Nissenbaum's Privacy in Context gives AI governance a missing grammar. Privacy is not just secrecy, ownership, or a consent checkbox. It is the integrity of information flows inside social contexts: who sends what, about whom, to whom, under what conditions, and for what purpose.

For this review, contextual integrity means that a privacy claim must be tested as a flow, not as a static data field. The unit of analysis is the subject, sender, recipient, information type, transmission principle, purpose, retention, downstream action, and contest path. A system can keep a fact technically non-public and still violate privacy by moving it into the wrong relationship.

The practical test is a flow warrant: name the source context, receiving context, authorized actors, transmission principle, data transformation, derivative artifact, retention limit, deletion path, and affected-person remedy before the system trains on, retrieves, remembers, scores, or exports the information. If the institution cannot write that warrant plainly, the flow is not yet governed.

The Book

Privacy in Context: Technology, Policy, and the Integrity of Social Life was published by Stanford University Press in November 2009 through Stanford Law Books. The publisher lists it at 304 pages, with hardcover ISBN 9780804752367, paperback ISBN 9780804752374, and ebook ISBN 9780804772891.

Nissenbaum is the Andrew H. and Ann R. Tisch Professor of information science at Cornell Tech and the Cornell Ann S. Bowers College of Computing and Information Science. Cornell Tech also lists her as director of the Digital Life Initiative, with research across privacy, trust, accountability, security, ethics, policy, law, computing, digital media, and data science. That range matters. The book is not a narrow privacy-law manual. It is a theory of how information technology disturbs social life by moving data out of the settings that once gave it meaning.

The book predates large language models, app-store identity systems, today's data-broker economy, AI companions, and workplace copilots. Its central concept has only become more useful. Contextual integrity names the privacy harm that appears when information still looks "public," "consented to," or "already shared," but has been moved into a new institutional relation where the old expectations no longer hold.

That makes the book especially useful for AI because modern systems often do not need to reveal a secret in order to change someone's life. They can infer, summarize, rank, remember, route, train, or act. The privacy question becomes whether a data flow remains appropriate after it has been transformed into model behavior, retrieval context, memory, evaluation data, or administrative action.

Current Context

As of June 25, 2026, contextual integrity has become a practical test for AI data governance rather than only a privacy-theory lens. The official NIST Privacy Framework page still presents the framework as a voluntary tool for identifying and managing privacy risk, while NIST's Privacy Framework 1.1 materials remain in initial-public-draft and "coming soon in 2026" status. NIST AI 600-1, the Generative AI Profile, adds a lifecycle vocabulary for generative-AI risks including data privacy, provenance, transparency and documentation, human-AI configuration, and value-chain integration.

European sources point in the same direction without adopting Nissenbaum's term. GDPR Article 5 anchors purpose limitation, data minimisation, storage limitation, fairness, transparency, security, and accountability. EU AI Act Article 10 requires high-risk AI data governance to fit the intended purpose and, for personal data, to account for the original purpose of collection. Article 53 requires general-purpose AI model providers to keep technical documentation and publish a sufficiently detailed public summary of training content, and the Commission published the explanatory notice and template for that public summary on July 24, 2025.

U.S. and data-protection regulators frame the same problem through commitments and minimization. The FTC's January 9, 2024 technology blog warned AI companies that privacy and confidentiality commitments still bind model development, including when firms change data practices after users supplied data. The California Privacy Protection Agency's 2024 enforcement advisory says businesses should apply data minimization to each purpose for collecting, using, retaining, and sharing personal information. CNIL's AI-development recommendations add concrete AI controls: reduce memorization risk, support objection and erasure paths for training datasets, and keep GDPR duties such as purpose definition, minimization, security, and rights handling in force during model development.

The current policy lesson is narrow and concrete: regulators and standards bodies are asking for purpose, origin, lifecycle control, documentation, and accountability. They are not saying that every data movement is forbidden. They are saying that data movement has to remain explainable after AI turns records into training signals, embeddings, memories, classifications, summaries, decisions, and agent actions.

The Flow Warrant

A flow warrant is the operational version of contextual integrity. It is not a broad privacy notice, a one-time consent click, or a vendor assurance. It is the record that justifies a specific movement of information from one relationship into another.

This makes the privacy claim testable. The warrant should link to the AI system inventory, data provenance, model or system card, audit trail, procurement record, and explanation or appeal route where those records exist. If a system cannot produce that chain, "contextual integrity" is being used as rhetoric rather than governance.

Privacy as Context

The argument starts from a simple observation: people share information all the time. A patient tells a doctor intimate facts. A student submits work to a teacher. A worker explains a disability accommodation to human resources. A customer gives a payment processor financial details. A friend tells another friend something fragile. None of these acts means the information has become free material for every other actor.

Contextual integrity asks whether an information flow fits the norms of the social context in which it occurs. The key variables include the information subject, the sender, the recipient, the kind of information, and the transmission principle that governs the flow. Confidentiality, stewardship, reciprocity, legal compulsion, sale, consent, and professional duty are not interchangeable routes. They change what the information means.

A contextual-integrity review can therefore be written as a record: original context, proposed new context, subject, sender, recipient, information type, purpose, transmission principle, retention period, inference risk, action enabled, and contest path. That record is more useful than a generic privacy statement because it forces the institution to say what movement is being justified.

AI systems make that record more demanding because a flow no longer ends at collection. A disclosure can become an embedding, a vector index, a memory, a safety label, an evaluation set, a support ticket, a fine-tuning example, a model card claim, or an audit log. Each artifact may travel to a different recipient or survive on a different retention clock. Contextual integrity treats those derivative artifacts as part of the flow, not as technical exhaust.

The sharper AI-era definition is therefore: privacy is preserved when the derivative artifact remains bound to the context that justified its creation. A medical note summarized for the treating clinician, a school essay used for feedback, and a customer-support transcript used to resolve a ticket may all fit their source contexts. The same artifacts used to train a general model, score a worker, target an ad, or personalize a companion create different flows and need separate warrants.

This makes the book a direct companion to Sorting Things Out, The Digital Person, Data and Goliath, and Seeing Like a State. Each book rejects the fantasy that records are neutral once captured. A record becomes powerful through the institution that reads it, the category it is placed in, and the action it authorizes.

Nissenbaum's strongest move is to break the stale public/private distinction. A fact can be visible in one setting and still be violated by extraction into another. A courthouse record, school assignment, search query, location ping, medical note, workplace chat, or social post may be accessible in some sense, but accessibility is not permission for every downstream use. The question is not "was the data secret?" The question is "what relationship made this flow appropriate, and what relationship is now using it?"

The case most often used to illustrate the framework is Facebook's launch of the News Feed in September 2006. Nothing newly private was exposed; every item the feed broadcast, a changed relationship status, a new friend, a wall post, was already sitting on a profile that friends could have visited. Yet hundreds of thousands of users revolted within days, and Facebook scrambled to add controls. On a secrecy model of privacy the outrage makes no sense, because no secret was revealed. On Nissenbaum's model it is obvious: the information had not become more public, but its flow had changed, from something a friend had to walk over and look up into something automatically aggregated and pushed to everyone at once. The transmission principle changed, and that, not the secrecy of any single fact, was the violation. It is the cleanest demonstration that privacy lives in the flow, not in the record.

Privacy in Context also explains why notice-and-consent systems fail so reliably. A consent banner or terms-of-service checkbox tries to compress a whole social relationship into a moment of individual choice. It asks the person to understand future flows, unknown recipients, model training, mergers, government requests, retention periods, inference, resale, breach risk, and product redesign before clicking.

That model is especially weak when refusal is costly. A worker may need the platform to keep a job. A parent may need the school portal. A patient may need the hospital system. A tenant may need the landlord's app. A creator may need a social platform. A citizen may need the government website. The click exists, but the relationship is not symmetrical.

Contextual integrity shifts the burden. Instead of asking whether a user technically accepted a flow, it asks whether the flow is appropriate to the context's purposes, roles, and governing norms. A school can collect student work to teach. That does not automatically make the work training data for a vendor's general-purpose model. A hospital can collect symptoms to treat. That does not automatically make the notes marketing data, actuarial data, or product telemetry. A workplace can route messages to accomplish work. That does not automatically make every sentence a permanent behavioral profile.

This is why AI training opt-outs and cookie banners are not enough by themselves. They may record a preference, but they do not prove that the underlying flow is fair, necessary, proportionate, or compatible with the original relationship. A designed click cannot carry the whole burden of a pipeline the person cannot inspect.

Useful consent has to be flow-specific. It should distinguish service operation, safety review, legal compliance, support, personalization, analytics, model improvement, general training, human labeling, backups, and vendor transfer. It should also say what is excluded. A person cannot meaningfully consent to "AI use" when the phrase hides several different institutional moves.

The AI-Age Reading

Read in 2026, Privacy in Context is one of the clearest books for thinking about AI data reuse. The AI stack constantly tempts institutions to collapse contexts. Data gathered for communication becomes training material. Data gathered for safety becomes scoring material. Data gathered for support becomes product improvement. Data gathered for identity becomes fraud detection, ad targeting, risk analysis, or model memory.

Large models intensify the problem because they do not merely store information. They learn patterns, infer sensitive facts, summarize records, generate explanations, personalize interfaces, and act through tools. A training set can absorb traces from many contexts and return them as a general capability. A retrieval system can collapse source boundaries inside one answer. A model memory feature can make a user's past disclosure operational in future moments the user did not imagine.

This is why "we only use public data" is often an inadequate defense. Public to whom, in what role, under what norm, at what scale, with what retention, with what inference, and with what future use? A street photo, a forum post, a court docket, a product review, a classroom discussion, and an open-source issue are not morally identical because a crawler can reach them.

As of June 25, 2026, current governance has partly caught up with Nissenbaum's point. GDPR Article 5 names purpose limitation, data minimisation, storage limitation, fairness, transparency, integrity and confidentiality, and accountability as core principles. NIST's Privacy Framework treats privacy as a risk-management problem, and NIST AI 600-1 frames the Generative AI Profile as a companion to the AI RMF for governing generative-AI risks across the lifecycle, including data privacy and content provenance.

EU AI Act Article 10 requires high-risk AI data governance to consider the intended purpose and the specific context of use, including the environment where the system will operate. Article 53 requires general-purpose AI model providers to keep technical documentation and publish a sufficiently detailed summary of training content. The European Data Protection Board's 2024 opinion on AI models says legitimate interest requires a structured balancing analysis and that claims of model anonymity need case-by-case assessment. California's privacy regulator has also emphasized applying data minimization to collection, use, retention, and sharing in relation to purpose and context. None of these sources codifies contextual integrity as such. Together they move governance toward the same institutional demand: justify the flow, not only the collection.

AI makes contextual collapse feel technically natural. The model wants a corpus. The enterprise wants a connector. The assistant wants memory. The dashboard wants all signals in one place. But social life is not one place. It is many overlapping settings with different obligations. The power of Nissenbaum's framework is that it lets governance defend those differences without pretending data should never move.

Agents That Cross Boundaries

The next pressure point is agentic AI. A normal app usually sits inside a somewhat legible context: the banking app, the school portal, the clinic system, the team chat. An agent is designed to cross boundaries. It reads email, calendars, documents, tickets, customer records, code repositories, payment tools, browsers, and internal databases, then acts across them.

That boundary crossing is the product's value. It is also the privacy risk. The agent may have permission to read a document in one role and use the extracted fact in another. It may summarize a private exchange into a management report. It may pull a health clue into a scheduling decision. It may combine procurement data, chat sentiment, and performance metrics into a recommendation that no single context would have authorized.

Contextual integrity turns agent governance into a design problem. Access control is not enough. The system needs source boundaries, purpose limits, transmission principles, retention rules, role separation, audit trails, and user-facing explanations that name the context of each flow. A good agent should not merely ask "can I access this file?" It should ask "for this task, in this role, under this relationship, should this information flow to this recipient?"

That is a higher bar than most current enterprise AI systems clear. Permission inheritance tells the model what it can see. Contextual integrity asks what the model may appropriately carry across the boundary after seeing it.

The practical control is a context boundary register tied to the agent's tool permissions. If an agent can read documents, email, tickets, calendars, CRM records, or chat logs, the system should record which context each source belongs to, which recipients are allowed, which uses are prohibited, how long the derived context persists, and which audit trail can explain a contested action. Access control says what the agent may read. The register says what the agent may carry forward, remember, write, send, or use to justify an action. Otherwise a successful agent becomes a cross-context leak with a friendly interface.

That register also needs a negative space. It should name data the agent may inspect but not remember, summarize but not export, retrieve but not train on, use for one transaction but not profile, and cite for one recipient but not expose to another. Without those prohibitions, a broad connector turns contextual integrity into an after-the-fact aspiration.

Governance and Safety

As of June 25, 2026, the governance implication is concrete: privacy review has to follow data through the AI lifecycle. Collection is only the first event. Training, fine-tuning, evaluation, retrieval, embedding, vector indexing, memory, summarization, safety review, human labeling, vendor transfer, deletion, and agent action are all new opportunities for contextual collapse.

A serious AI privacy review should start with a flow map. For each data source, record the original context, the authority or legal basis for collection, the expected recipients, the transmission principle, the AI use, the derivative artifact, the retention period, the model or system affected, the downstream action enabled, the vendor or subprocessor, the high-risk group affected, and the contest or deletion path. This connects contextual integrity to AI data provenance, data minimization, AI data retention, AI audit trails, and algorithmic impact assessments.

For training data, the safety question is not only whether the data was lawfully obtained. It is whether reuse for general model capability is compatible with the context that produced it. A forum post, school assignment, workplace message, medical note, customer-support ticket, or companion chat can all become technically useful training material. Contextual integrity asks whether that usefulness is a legitimate reason to move the material into a new institutional role.

For retrieval and memory systems, the safety question is whether the system preserves source boundaries after ingestion. A vector database can make documents searchable across old departmental, clinical, educational, or personal limits. A memory feature can make a past disclosure operational in future sessions. Those systems need purpose-bound indexes, role-aware retrieval, retention limits, deletion propagation, and explanations that identify which context supplied the answer.

For vendors, the safety question is whether a buyer can prove the flow it approved. Contracts and product settings should specify training and model-improvement use, subprocessors, retention, logging, deletion, human review, security review, model substitution, and incident notice. Vendor promises belong in vendor governance, not only in a privacy policy that no procurement record remembers.

For high-risk contexts, the default should be no reuse without a new warrant. Minors, health, education, employment, finance, housing, legal services, immigration, biometric identification, crisis support, spiritual testimony, and intimate companionship all carry role-based duties that a general training pipeline or enterprise assistant can easily erase. When reuse is allowed, the institution should document why a narrower, less persistent, or locally processed alternative would not achieve the same purpose.

Useful controls are specific: purpose-bound indexes, context labels on retrieved passages, data-use firewalls between service operation and model improvement, deletion propagation tests, subprocessor records, role-aware access, redacted audit trails, appeal channels for affected people, and re-review when a new connector, model, memory feature, analytics partner, or training use is added. A privacy program that cannot name the context drift event will usually miss it.

The practical standard is simple: do not let data cross a context boundary unless the organization can name the boundary, justify the transfer, enforce the limit, log the movement, and give affected people a realistic way to contest misuse.

Where the Book Needs Friction

The book's framework is powerful, but not self-executing. Social contexts can be unjust. A workplace norm may already favor surveillance. A school norm may already normalize suspicion. A policing norm may already treat some communities as risk sources. Preserving contextual norms is not always the same as protecting people.

Nissenbaum anticipates this by treating norms as open to evaluation, not as sacred tradition. Still, AI-era readers need to pair contextual integrity with political economy, civil-rights analysis, labor power, disability justice, and public-interest technology. Otherwise the framework can become too polite: a map of existing expectations where the deeper problem is that the expectations were built by unequal institutions.

The second difficulty is operational. Translating contextual integrity into systems requires more than a privacy policy. It requires machine-readable roles, data lineage, purpose binding, retention controls, model-use restrictions, interface design, human appeal, and institutional willingness to say no to convenient reuse. The 2006 formalization work by Barth, Datta, Mitchell, and Nissenbaum shows that some parts can be expressed in logical privacy rules, but real organizations rarely maintain their information flows with that level of precision.

The third difficulty is inference. AI systems can derive sensitive information from data types that seem harmless. A norm may restrict medical data, but a model may infer health from purchases, movement, language, sleep, or social ties. Contextual integrity still helps, but it has to govern inferences and generated classifications, not only original records.

A fourth difficulty is scale. Contextual integrity is strongest when a social context is legible enough to name its roles and norms. Platform data, data-broker dossiers, foundation-model training sets, and enterprise knowledge graphs often mix contexts so thoroughly that the original relationship is hard to reconstruct. In those cases, the framework does not fail; it exposes the governance debt. If the context cannot be reconstructed, the institution may not have a defensible basis for high-impact reuse.

What This Changes

The practical lesson is to stop asking privacy questions only at the point of collection. Collection matters, but AI governance also needs to ask about movement, transformation, training, retrieval, memory, inference, summarization, disclosure, and action.

A contextual-integrity review of an AI system would ask: What context produced the data? Who is the subject? Who sent it? Who receives it? What kind of information is it? What principle allowed the flow? Is it being retained, combined, trained on, or used to act in a different context? Can the affected person see and contest that movement? What social purpose is being served, and what power is being expanded?

This test is sharper than generic privacy talk. It can distinguish a hospital tool that summarizes notes for the treating clinician from a vendor pipeline that uses those notes to train a commercial model. It can distinguish a school tutor that forgets session details from a student model that follows a child across years. It can distinguish an enterprise assistant that respects role boundaries from one that quietly turns every document into cross-department memory.

Privacy in Context belongs on the AI shelf because it makes one neglected point hard to avoid: information systems do not only know things. They move things between relationships. When those movements violate the roles, duties, and limits that make social life trustworthy, the harm is not solved by better notice, cleaner UI, or more accurate prediction. The system has changed the meaning of the information, and with it, the terms on which people become readable to power.

The immediate policy consequence is to make context drift a reviewable event. A new AI feature, connector, training use, memory layer, analytics partner, or data export should trigger a fresh flow map, not a vague update to terms. Privacy survives when institutions remember why the information was given in the first place.

Source Discipline

This review separates theory, book metadata, regulatory posture, and implementation claims. Stanford University Press and Cornell Tech verify the book and author context. Nissenbaum's articles and the formalization paper establish the conceptual framework. GDPR, OECD, NIST, the EDPB, FTC, CPPA, CNIL, and EU AI Act materials show current governance vocabulary around purpose, minimization, privacy risk, AI model development, training-content transparency, data-subject rights, and interface manipulation. Those sources do not prove that a particular AI product respects contextual integrity.

Source discipline for privacy claims means naming the evidence layer and date. A privacy policy is a promise. A product setting is an interface. A data-processing agreement is a contract. A model card is a disclosure artifact. A regulator opinion is legal interpretation or enforcement posture. An audit log is operational evidence. A serious privacy claim should say which layer supports it, which product version or policy date it describes, and which layer remains unknown.

It also means avoiding the phrase "the user consented" unless the flow is specified. Consent to collection is not consent to training. Consent to service operation is not consent to advertising. Access permission is not permission to carry a fact into another role. Deletion of a source record is not automatic removal from embeddings, memories, backups, evaluation sets, support logs, or trained model weights. Public availability is not the same as contextual permission.

For current-law claims, distinguish final law from guidance, draft framework, template, regulator opinion, enforcement advisory, and provider documentation. The GDPR and EU AI Act are legal texts. NIST frameworks are voluntary risk-management tools. The EDPB AI-model opinion is authoritative data-protection analysis but still applied case by case by competent authorities. FTC and CPPA advisories indicate enforcement posture rather than a complete AI privacy code. A Commission template for training-content summaries is a disclosure instrument, not a complete provenance audit.

Sources

Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.

Buy on Amazon Browse Books

Return to Blog · Return to Books