Abstract
A locally running language model may reduce a meaningful external processing path for private writing material. That fact is often described with the word local, then treated as if it settled confidentiality. It does not. A transcript, prompt, attached file, generated summary, chat record, model file, local service, extension, update process, synchronized folder, and cloud feature can belong to different paths before, during, and after one inference event. Calling the inference local may accurately identify one boundary while leaving the rest unnamed.
This paper introduces the inference boundary: the stated location at which a model receives and processes an input, distinguished from the broader material pathway surrounding that event. It develops the Inference Exposure Ledger, a ten-field teaching instrument that records material class, processing locus, input and output paths, persistent local state, network-adjacent dependencies, a model/provenance caveat, verified protective practice, unverified exposure, and non-conclusion. The instrument is designed for a writer, editor, publishing-program steward, or small-press operations lead who needs a more exact question than “Is this AI private?”
Primary documentation for local-model applications distinguishes locally running models from cloud features and identifies configuration choices around host binding, optional network service, updates, model downloads, and integration.[1] [2] [3] Operating-system documentation separately shows that locally stored Documents folders may be selected for cloud backup and cross-device synchronization.[4] Risk frameworks, privacy scholarship, regulator guidance, editorial policy, and model-card documentation together support a modest teaching conclusion: inference location matters, but it does not exhaust the privacy, provenance, retention, or editorial-confidentiality questions created by an AI-assisted writing workflow.[5] [6] [7] [8] [9] [10]
1. The transcript on the airplane
A developmental editor has promised an interviewee that a recorded conversation will remain within a small editorial team until the resulting profile is approved. On a flight with no connection, the editor opens a laptop, starts a locally installed writing assistant, and asks for a short list of recurring themes in the transcript. The model runs on the laptop. Nothing is deliberately pasted into a web page. The editor receives a useful outline, pastes it into a working note, and feels entitled to say that the material stayed private.
The sentence is not necessarily wrong. It may describe a consequential fact: the particular model inference occurred on the device rather than at a remote service. A local inference path can remove one route by which a prompt, attachment, or response might otherwise be processed outside the editor’s immediate environment. That difference should not be trivialized. Primary documentation for local-model applications distinguishes local operation from optional cloud models or cloud features, and describes configurations in which models run on a device or a loopback address.[1] [2]
But “it ran locally” cannot tell the editor everything the promise requires. Where was the transcript before the flight? Is the source file inside a Documents folder selected for backup or synchronization? Did the assistant keep a history, an index, a cache, or a log? Is the local service available only to the machine or configured to answer a network request? Has an extension been granted access to it? Did the model arrive through a download path with its own account, update, license, or provenance record? Has the resulting outline been copied into a folder that will synchronize when the laptop reconnects? Which of these conditions is observed, which is documented by a provider, and which is simply unknown?
The editor cannot answer those questions by repeating the word local. Nor should the editor treat the questions as proof that the practice has failed. A privacy analysis becomes less useful when every unknown is announced as a breach and every technical distinction collapses into alarm. The real work is more disciplined: name the material, identify the boundary that has actually been established, trace the paths that remain relevant, and make uncertainty visible where a reviewer has not inspected the system.
A local inference claim is a statement about one processing boundary. It is not, by itself, a complete account of where private writing material travels, persists, becomes reachable, or remains unknown.
This paper calls that narrower location the inference boundary. The phrase names the point at which a model receives and processes an input; it does not mean that the whole writing practice has a single boundary. An interview transcript may be one object. The prompt drawn from it may be another. A generated outline, a local chat record, an application setting, a downloaded model, an API binding, and a synchronizing draft folder may each belong to a different pathway. A useful review must therefore begin with the material at stake rather than the marketing or technical label attached to an application.
2. One boundary inside a larger material path
A path is not a metaphor for general unease. It is a sequence of identifiable relations. A private source document may be copied from a local folder into a prompt field; a process may run in device memory; a response may appear in an interface; the response may then be pasted into a draft; the draft may later be retained, backed up, shared, or deleted. Some parts of that sequence may be documented. Some can be inspected in an actual workflow. Some may be outside the writer’s competence or visibility. The goal is not to invent a hidden motive or danger at every point. The goal is to stop a single true fact from being mistaken for the whole sequence.
NIST’s Generative AI Profile gives a reason to preserve that distinction. It describes generative-AI risks as varying by lifecycle stage, source, scope, architecture, model access, data type, component integration, and application context. It identifies data privacy, information security, and value-chain/component integration as separate risk areas, and it notes that some risks are difficult to evaluate because visibility and evidence remain limited.[5] The profile is a voluntary risk-management resource for organizations; it is not a device-level security test and does not prescribe an author’s writing practice. Its useful lesson here is one of scale. An inference event belongs to a system and a use case. It should not be asked to carry every conclusion about them.
Two scholarly sources sharpen the limit. Miranda and colleagues’ survey describes privacy issues connected with large-scale training data, private-data fine-tuning, memorization, inadvertent disclosure, and mitigations across the learning pipeline.[6] Jin and colleagues organize the literature through risk, mitigation, and application dimensions related to a privacy framework.[7] Neither source predicts that the transcript in this constructed case will be revealed by a model. Neither source measures the privacy of a particular local assistant. Together, they make a bounded methodological point: model, system, component, and application questions can be related without being interchangeable.
The difference appears clearly in public technical records. Ollama’s FAQ says that local use runs locally and separately describes cloud-hosted models, model downloads, configurable host bindings, default loopback binding, possible browser-extension origins, and cloud-feature settings.[1] LM Studio’s privacy policy distinguishes entirely on-device local use from update checks, model search/download, and optional cloud services.[2] Its developer documentation says a locally served model can be made available on localhost or on a network through API endpoints.[3] These are records of named applications, not evidence that all locally run models work identically. They are helpful because they expose categories a generic word conceals: where a model runs; whether a service is local-only or network available; whether an optional feature is invoked; and which other operations are distinct from the inference event.
The editor in the airplane case does not need to become a network administrator to recognize the distinction. A review can simply record, “The processing locus is stated as local. The current service binding is not verified.” That sentence is not an accusation. It is a narrow truth with an identified remainder.
3. What is the material, exactly?
Private writing practice is often described as though it concerns a single thing called “the document.” AI-assisted work breaks that simplification apart. A workflow may contain several materials whose sensitivity, persistence, and later destinations differ.
| Material class | Example in the constructed case | Question the class raises | What it does not imply |
|---|---|---|---|
| Source material | The original interview transcript. | Where is the source stored, copied, or selected? | That every sentence must be treated as equally sensitive. |
| Prompt or attached context | The passage placed before the model and the instruction to identify themes. | How does this material enter the process? | That a copied excerpt has the same path as the source file. |
| Generated output | The outline of recurring themes. | Where is the response displayed, saved, pasted, or shared? | That an output is harmless because it is not verbatim source text. |
| Interaction residue | A history, log, cache, local index, or temporary file. | What remains after a session ends? | That all local retention is improper or avoidable. |
| Model and distribution record | A downloaded model, its version, license, or associated documentation. | What is known about origin, intended use, limits, or derivation? | That such a record reveals the current prompt path. |
| Working-copy path | The outline placed in a draft folder. | Will the new artifact enter backup, sync, sharing, or an archive? | That the model itself has transmitted the file. |
The table is not a universal taxonomy of sensitivity. Its purpose is to make a practical separation. A writer may reasonably decide that a model output is less sensitive than the original transcript, or that a summary carries the same confidentiality obligation because it retains identifiable or commercially sensitive themes. The ledger does not decide that question. It creates a field in which the decision can be stated rather than smuggled into the word private.
This material-first approach also prevents a common confusion about local persistence. A locally stored artifact may be an intentional protective choice: an editor may need a working file, a version history, or a backup in case of device loss. Local retention is not the opposite of privacy. The relevant question is narrower: What is retained, for which purpose, where, under whose access conditions, and for how long? That question will not produce the same answer for a private journal, a confidential source transcript, a publisher’s embargoed proof, a public press release, or a fictional draft.
The Information Commissioner’s Office frames a related, though jurisdiction-specific, discipline for AI systems. Its guidance advises reviewers to assess whether information is adequate, relevant, and limited for a purpose; map information use across system phases; track unnecessary duplication; consider redaction; and document retention or disposal decisions.[8] The guidance is directed to technical and compliance roles and is currently under review. It does not tell this paper’s editor whether an interview may be processed. It supports a much smaller practice: before expanding a material path, ask whether the whole material, every identifier, or an indefinite retained copy is necessary for the stated task.
4. Five questions after the word “local”
The inference boundary becomes useful only when it leads to questions a reader can actually ask. The following five questions are not an audit sequence and do not require a reader to prove a negative. They are a pathway anatomy for one identifiable material.
4.1 Where does the material enter?
A transcript can be copied into a chat window, attached as a file, read from a local index, passed by an extension, submitted to an API, or reached through a route the editor has not examined. These are not interchangeable. The entry path may determine whether only a selected excerpt or a broader collection is available to the process. The relevant record is descriptive: “A selected paragraph was pasted” is different from “The process read a directory,” and both are different from “Unknown.”
4.2 Where is it processed?
The processing locus asks where the model transformation is stated to occur. The answer may be local device memory, a remote service, a local server, a managed internal environment, or an unknown combination. This is the question to which a local-model claim can provide a real answer. It should be recorded precisely rather than inflated. A primary document may say that the model runs locally; that statement can be logged as an attributed configuration fact, not independently validated as a total privacy finding.[1] [2]
4.3 What remains after use?
A useful answer may be “nothing that this reviewer can identify,” but the sentence should not be assumed in advance. The source transcript may remain unchanged in a folder. The assistant may retain a conversation locally. The generated outline may persist in a new draft. A temporary index or cache may exist. A backup may later include one or more of those artifacts. This is a question about residue, not a demand to delete every working trace. A system with no recoverable history can impair a correction or an editorial explanation; a system with unlimited history can make a private practice needlessly durable. The appropriate balance depends on material, purpose, risk, and accountable retention practice.
4.4 Which component or setting can reach the path?
A local model does not exist in conceptual isolation. A user may turn on a local API server, authorize an extension, select cloud search, retrieve a model update, or place drafts in a synchronized location. The technical documents used here show that specific applications distinguish local-only and network configurations, updates, downloads, cloud features, or extension access.[1] [2] [3] They do not establish what is enabled in the constructed case. The ledger’s job is to name the dependency category and to mark a setting as verified, stated by documentation, or unknown.
4.5 What has not been inspected?
The final question protects against false precision. A non-specialist cannot infer hardware isolation, access control, account compromise, software integrity, or model behavior from a visible interface. A project may not have authority to inspect a publisher’s device, an organization’s network, a provider’s code, or a model’s training records. The correct entry is not an invented assurance. It is unverified exposure.
That field is distinct from evidence of harm. “Backup status unknown” does not mean a transcript has been exposed. “Model provenance record not reviewed” does not mean the model is improper. The distinction gives an editor a way to stop at the limits of observation without pretending the limits have disappeared.
5. A model record is not a prompt record
The question of model provenance requires a separate treatment. A model is not merely a neutral engine inside a laptop. It may have an associated version, license, intended-use statement, base-model relation, dataset references, evaluation record, or limit statement. Hugging Face’s documentation describes model cards as accompanying model files that can supply such information, including intended uses, limitations, training parameters, dataset references, evaluation results, license information, and relationships to base models.[10]
A model card is not proof that every listed disclosure is complete or accurate. It is not a privacy guarantee. It does not reveal where the editor’s transcript currently travels. It does, however, prevent another category error: treating the physical location of inference as the complete provenance of the system doing the inference. A reviewer can record, “A model distribution record was available but its training-data description was not independently assessed,” or “No model card was reviewed.” Both entries have more integrity than implying that the model is transparent because it is installed locally.
This distinction also separates the present inquiry from the contribution-record question treated in WEXLEY-WP-049, which asks what traces should be retained or redacted when human and machine work interleave. WEXLEY-WP-047 does not design a full contribution record. It asks only what can be known about the model and its distribution as one component in the pathway surrounding private material.
6. The Inference Exposure Ledger
The Inference Exposure Ledger is a working record for one bounded material and one bounded use. It is intended for inquiry before, during, or after a private AI-assisted drafting episode. It is not a scorecard. A check mark in one field does not cancel an unknown in another; an unknown does not automatically condemn the workflow.
| Field | Reader records | Why the field matters | What the field does not decide |
|---|---|---|---|
| 1. Material class | The source text, prompt, attachment, retrieved context, output, log, model file, or draft copy at stake. | Different materials can have different paths and obligations. | That all material has the same sensitivity. |
| 2. Processing locus | Where the stated inference occurs and the evidence for that statement. | Captures the particular distinction a local claim may establish. | That the entire workflow remains on that device. |
| 3. Input path | Copy/paste, attachment, local index, extension, API, or unknown. | Entry can create exposure before inference begins. | Whether the input path is secure or proportionate. |
| 4. Output path | Where the response appears, is copied, saved, or shared. | Generated material can become a new private artifact. | Whether the output is accurate or authorized. |
| 5. Persistent local state | Identified history, cache, index, folder, backup, or an explicit unknown. | Privacy concerns include residue and retention, not only transmission. | That all persistence is a defect. |
| 6. Network-adjacent dependency | Update, model download, cloud feature, web search, extension, remote binding, sync, or another connected component. | Separates local computation from surrounding dependencies. | That every dependency receives the material. |
| 7. Model/provenance caveat | What the distribution record states—and what it does not state—about version, origin, license, data, limits, or evaluation. | Makes the model a visible component rather than an assumed black box. | That documentation proves privacy or quality. |
| 8. Protective control or practice | A verified constraint, redaction, material minimization step, retention choice, or access limitation. | Records a real protective act without exaggeration. | That one act settles the pathway. |
| 9. Unverified exposure | What remains untested, undocumented, outside scope, or outside competence. | Gives uncertainty an accountable place. | That an unknown is a demonstrated incident. |
| 10. Non-conclusion | What the trace cannot certify, recommend, or approve. | Prevents the ledger from becoming a false security grade. | A decision to adopt or reject a tool. |
The source/owner distinction is deliberately distributed across the fields. A provider’s policy may be the evidence for an attributed statement about local operation. A system setting may be a locally observed fact. A folder path may be directly inspected. A model card may be a partial provenance record. A reviewer should not write all of these as though they carry the same authority. The ledger asks for a description before a conclusion.
7. Worked trace: the transcript and the folder
The constructed example can now be traced without declaring it safe or unsafe.
| Ledger field | Constructed entry | Editorial reading |
|---|---|---|
| Material class | An unpublished recorded interview transcript and a generated theme outline. | Source and output are related but should not be assumed to share the same persistence path. |
| Processing locus | The editor reports that the model was run on the laptop while the device had no connection. | The claim identifies a bounded local inference event; the setting was not independently audited. |
| Input path | The editor copied selected transcript passages into a local assistant interface. | The record identifies an entry method but not every application component that may have handled it. |
| Output path | The assistant displayed a theme outline; the editor pasted it into an interview-profile draft. | The outline is a new artifact whose later path must be traced independently. |
| Persistent local state | The source transcript remains in a Documents folder; chat history and cache status are unverified. | “Unverified” is a valid record, not a claim that a hidden log exists. |
| Network-adjacent dependency | The laptop will later reconnect; the draft folder’s backup/sync status is unknown. | The local inference statement does not settle the later storage path. |
| Model/provenance caveat | No model card was reviewed in the constructed case. | Absence of review is not a model-quality judgment; it names an evidence gap. |
| Protective control or practice | The editor used selected passages rather than the full transcript and did not invoke a known cloud feature during the flight. | This may reduce a defined material path but does not certify confidentiality. |
| Unverified exposure | Host binding, extension permissions, chat retention, folder backup, and model distribution record remain unverified. | The task is to decide whether further review is proportionate to the material, not to invent a result. |
| Non-conclusion | The ledger does not establish that the transcript was completely private or that the assistant should be used again. | It turns an undifferentiated reassurance into a bounded, reviewable description. |
The trace creates a practical pause. The editor may decide that the material is sensitive enough to inspect the folder’s backup status before reconnecting. The editor may decide that a local history is legitimate because it supports later revision, but set a retention decision. The editor may ask whether an extension is necessary for the task. Or the editor may decide that the available evidence is too thin to call the practice confidential. These are different possible next actions. The ledger does not choose among them.
8. Privacy is not maximal isolation
The strongest counterpoint to this paper is that a path-based account can become paralyzing. If every update, file, permission, model record, and possible service is treated as an unacceptable exposure, authors may lose useful forms of offline work, data minimization, local control, accessibility support, and recoverable editing. An author who needs private drafting does not necessarily need a disconnected machine with no backup, no update path, no model documentation, and no way to recover a file after loss.
That is why the paper begins by recognizing a local inference boundary as a potentially meaningful fact. Vendor policies and technical records may describe local execution separately from optional cloud features; a reader can use that distinction to ask a better, smaller question.[1] [2] Regulator guidance on minimization likewise emphasizes relevance, retention, and necessary processing rather than a demand to retain every possible record or process every available item.[8] The appropriate objective is not purity. It is proportionate visibility: enough information to see a material’s path, enough restraint to avoid needless collection and retention, and enough humility to recognize what the trace does not show.
Editorial policy offers a parallel, but carefully limited, lesson. Elsevier’s journal policy describes manuscripts under review as confidential and tells editors and reviewers not to upload them to AI tools when that may violate confidentiality or proprietary rights. It describes a private tool in terms of retention, reuse, sharing, and learning from submitted content.[9] This is a policy for scholarly publishing, not a universal rule for a small press or private author. It demonstrates, however, that “private” has an operational content beyond the model’s brand or placement. A responsible reader may need to ask whether material is retained, reused, shared, or used for training—alongside where an inference happened.
9. What the ledger leaves unresolved
The Inference Exposure Ledger cannot test network traffic, inspect proprietary code, verify a cloud provider’s policy, assess encryption, determine whether an account has been compromised, identify all device-level access, or establish a model’s training-data history. It cannot decide whether an editor has met a contract, a privacy law, a journal policy, or an interviewee’s consent expectation. It cannot determine that a generated summary is accurate, unbiased, non-infringing, or appropriate for publication. These are not minor omissions. They are the boundary of a teaching instrument designed for description and accountable questioning.
The ledger is also not a replacement for a stage-based manuscript threat model. A threat model asks who or what may act against an asset at different stages and with what consequence. This paper’s instrument is narrower: it follows one material around one claimed inference boundary. It is not a local-first preservation method, either. It does not ask whether a manuscript remains durable, exportable, or under author control over time. And it is not an AI disclosure form. It does not decide what a reader, publisher, or institution should be told about assistance. Those are separate teaching jobs in this Atlas.
The narrowness is productive. An editor who cannot honestly say more than “local inference was reported; later backup and interaction retention remain unknown” has not failed to make a decision. The editor has prevented a more serious failure: converting a partial technical fact into a total promise of confidentiality.
10. The private-writing question after “local”
When the airplane lands, the editor can reconnect the laptop. Before doing so, the editor can read the ledger again. The transcript is not a generic data object. It is a material held under a promise. The model’s location matters. So do the input path, output path, persistence, connected components, model record, minimized material, and unexamined remainder.
A responsible final question is therefore not “Is a local assistant private?” The more exact question is:
What does the stated local inference boundary establish about this material, and what pathway does it leave unexamined?
A reader who can answer that question has not produced a security certificate. The reader has produced something more proportionate: a clear description of what is known, a record of what remains unknown, and a better basis for deciding whether further technical, editorial, legal, or consent review is necessary.
References
[1] Ollama. “FAQ.” Accessed 20 August 2026.
[2] LM Studio. “Desktop App Privacy Policy.” Effective June 2026; accessed 20 August 2026.
[3] LM Studio. “Local LLM API Server.” Accessed 20 August 2026.
[4] Microsoft Support. “Back up your folders with OneDrive.” Accessed 20 August 2026.
[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1, 2024).
[6] Miranda, M., Ruzzetti, E. S., Santilli, A., Zanzotto, F. M., et al. “Preserving Privacy in Large Language Models: A Survey on Current Threats and Solutions.” 2024.
[7] Jin, Y., et al. “Toward Privacy-Preserving Large Language Models: A NIST Privacy Framework-Based Analysis.”
[8] Information Commissioner’s Office. “Data minimisation.” Accessed 20 August 2026.
[9] Elsevier. “Generative AI Policies for Journals.” Accessed 20 August 2026.
[10] Hugging Face. “Model Cards.” Accessed 20 August 2026.