Endpoint Security
How to Securely Erase Local LLM Data from Enterprise AI PCs
A practical enterprise guide to discovering and securely removing local AI models, conversations, document indexes, caches and vector data.
The New Local AI Data Footprint
Artificial intelligence is moving from centralized cloud platforms onto employee laptops, engineering workstations and other enterprise endpoints.
Windows AI APIs can process supported workloads locally using a device's NPU, while Microsoft Foundry Local can download models into an on-device cache and run inference without sending input or output to Microsoft's cloud. This can reduce external data transmission, but it also means the organization becomes responsible for model files, prompts, responses, document indexes, caches and other AI-related artefacts retained on the endpoint.
Featured Insight
Local LLM data can include downloaded model weights, chat histories, prompts, generated responses, uploaded documents, embeddings, vector indexes, logs and temporary files stored on an endpoint. Secure removal requires identifying every relevant application location, erasing the approved data scope, verifying the outcome and using full-drive sanitization when the device leaves organizational control.
An NPU is primarily a processing component; it should not be described as the main persistent storage location for AI data. The artefacts of concern generally reside on the laptop's SSD or NVMe storage, in application folders, user profiles, model caches, document indexes, databases and synchronized locations.
This creates a new endpoint-security problem. An employee can download a multi-gigabyte model, attach confidential documents, create an internal knowledge collection, discuss sensitive projects in saved conversations, and then uninstall the visible application. Some or all of the associated data may remain elsewhere in the user profile or in a custom model directory.
Why this matters during the device lifecycle
The local AI footprint should be reviewed when a device is:
- reassigned to another employee;
- returned after offboarding;
- sent to a third-party repair provider;
- returned to a leasing company;
- transferred to another department;
- sold through an ITAD provider;
- recycled or donated;
- involved in a privacy, legal or security investigation.
Where Local LLM Tools Store Data
IT administrators rarely search only for “local AI applications.” They search for the product name, operating system and specific residue they need to remove. Here are commonly encountered tools and what each one may retain:
| Tool | Verified local location or behaviour | Data that IT teams should inspect |
|---|---|---|
| Ollama | %HOMEPATH%\.ollama contains models and configuration. Uses %LOCALAPPDATA% for application files/logs, and %TEMP%. | Model blobs, manifests, configuration, logs, temporary files and any custom model directory. |
| LM Studio | Saved conversations stored as JSON under %USERPROFILE%\.lmstudio\conversations. | Conversation JSON files, attached or duplicated documents, configured model directories. |
| GPT4All | Default path: C:\Users\{username}\AppData\Local\nomic.ai\GPT4All. | Models, saved chats, LocalDocs collections, text snippets, embeddings, source-document references. |
| Jan | Default path: %APPDATA%\Jan\data. Stores models, threads, settings and logs locally. | GGUF models, thread data, application logs, attached files, RAG/vector data. |
| NVIDIA ChatRTX | (Deprecated project) Ran locally and supported RAG against documents/notes. | Legacy model files, indexed content, RAG data, FAISS-style vector indexes. |
| Microsoft Foundry Local | Models downloaded into a local cache. Can be inspected via CLI. | Model cache, customized cache directories, local service configuration, databases. |
Why uninstalling is not enough
An uninstaller normally removes files that the installer manages. It may not know about custom model directories, downloaded models stored outside the application directory, saved conversations, manually imported models, document collections, embeddings and vector indexes, developer projects, container volumes, browser front-end storage, temporary exports, files synchronized to another device, or data already deleted through the operating system and left in unallocated space.
Ollama explicitly warns that downloaded models in a changed OLLAMA_MODELS location are not removed by its Windows installer. Jan separately documents a user data folder containing models, threads, settings and logs. These examples demonstrate why "application uninstalled" and "data sanitized" must be treated as different lifecycle states.
Secure Local LLM Data Erasure Workflow
Start by defining the lifecycle event and required assurance level. For an internally reassigned laptop, the goal may be to remove one employee's conversations, unapproved models and confidential document collection while retaining Windows and approved corporate applications. For a leased, sold, donated or recycled device, selective deletion may be too narrow, and full-drive sanitization is generally more defensible.
1. Inventory local AI runtimes and front-ends
Review more than the Windows installed-applications list. An effective inspection should cover Ollama and its connected front-ends, LM Studio, GPT4All, Jan, legacy NVIDIA ChatRTX deployments, Microsoft Foundry Local, browser-based interfaces, Python virtual environments, Docker/WSL, custom model directories, and synchronized folders.
2. Use vendor's inventory and removal functions
Before applying an enterprise erasure tool, use application-native controls to determine what is present. Stop the application and its background services first, as active local-LLM services may lock model files. This step improves scope accuracy but does not replace sanitization verification.
3. Configure D-Secure File Eraser for validated targets
D-Secure File Eraser can be configured to erase known local-AI files and folders included in an approved erasure policy. IT teams should first identify and validate the paths used by each application, because model locations and conversation stores can change by version, operating system and user configuration. Target specific files like .gguf, .onnx, LM Studio JSON files, Jan thread logs, and relevant unallocated space.
4. Apply an approved method rather than generic "NIST overwrite"
Apply the sanitization method approved by the organization's data-classification and media-sanitization policy. Record the target, method, result and verification evidence in a process aligned with NIST SP 800-88 Rev. 2 and the applicable media-specific standard. For SSD or NVMe devices, a full-device firmware or cryptographic sanitization operation using D-Secure Drive Eraser is more appropriate for end-of-life media.
5. Retain defensible audit evidence
The erasure record should identify asset details (hostname, serial), the user scope, the AI applications found (Ollama, LM Studio), target locations, the method used, start/completion time, verification evidence, and final disposition. D-Secure File Eraser and Drive Eraser provide digitally signed, tamper-proof certificates that capture this information.
Selective Erasure vs Full-Drive Sanitization
The correct technique depends on whether the device will remain under organizational control and whether the local AI footprint can be completely identified.
- Remove one unauthorized model: Selective file and folder erasure. The operating system and unrelated business data must remain.
- Remove LM Studio conversations before internal reassignment: Selective erasure plus verification. Conversation JSON files can be scoped, but attached documents and copies must also be checked.
- Reassign an endpoint internally: Selective erasure plus appropriate free-space handling and verification. The OS may need to remain, but prior user data must not transfer.
- Return a leased AI PC or ITAD transfer: Validated full-drive sanitization. Administrators cannot safely assume every local AI location was found.
- Local AI footprint is unknown: Full-drive sanitization. Selective erasure cannot provide assurance over unidentified data.
Important SSD and NVMe Limitation
Do not describe free-space wiping as universally sufficient for an SSD or NVMe AI PC that is leaving the organization. Flash storage controllers may remap blocks and manage wear independently of the operating system. A file-level operation can be useful for removing active logical content on a retained endpoint, but external disposition normally requires a validated, media-appropriate full-drive method under the organization's sanitization policy.
Secure the complete lifecycle of local AI data
Local AI keeps inference closer to the user, but it also distributes sensitive models, conversations and document indexes across enterprise endpoints. D-Secure helps organizations address both sides of the problem: targeted erasure for known local-AI artefacts on active systems and full-drive sanitization for devices being retired, returned or transferred.
Frequently Asked Questions
Comments (0)
Your email address will not be published. Providing an email is optional.
Have Questions About This Topic?
Send us an enquiry regarding: How to Securely Erase Local LLM Data from Enterprise AI PCs
No comments yet. Be the first to comment.