Encrypt Local AI Chats: FileVault and BitLocker Checklist

Keeping a conversation off a provider’s server solves one problem. Leaving the laptop in a taxi is another. The answer to that second problem is not a more private language model. It is protecting the files already on the machine.

For local AI chats, disk encryption is a practical starting point. First check what your computer actually has enabled, then check how you would regain access after a failure. Do both before treating the laptop as a safe place for intimate conversations.

The scope here is a lost or stolen computer and the copies of your chats you create. This is not a claim that encryption makes an unlocked session safe from another person or from malicious software.

Local storage does not certify encryption

The short version: Ask where the data lives and how it is protected as separate questions.

An app can store messages locally in a readable database. It can encrypt a character export while leaving chat rows in a different storage format. Neither fact is contradictory. Different artifacts can have different protection.

In the Local Waifu implementation reviewed for this article, the default database connection opens app.db using ordinary SQLite. There is a database-encryption hook, but it is disabled by default. The encryption module explicitly describes the SQLCipher backend and existing-data migration as work that is not completed there. Its presence is not a feature promise.

Do not use an environment variable from a source comment as a do-it-yourself encryption switch. A key-setting hook without the required database backend and migration is not a verified protection workflow. Changing storage experiments on your only copy of a relationship archive is the wrong risk to take.

The useful question is whether the volume containing your application data is protected by the operating system. For a broader map of the files and data paths involved, see where AI companion chats go. This article focuses on the laptop after those files exist.

FileVault adds password-bound protection on a Mac

The short version: Check FileVault in System Settings, even when your Mac already has hardware-backed storage encryption.

Apple distinguishes those layers in its FileVault guide. On Apple silicon and Macs with a T2 Security Chip, data is encrypted automatically. Turning on FileVault adds protection that requires your login password to access the data. On older Macs without those chips, FileVault is also how you turn on disk encryption.

Open System Settings, then Privacy & Security, then FileVault. Read the current state instead of assuming the Mac is protected because it is recent. If you turn it on, follow Apple’s prompts and choose a recovery method you understand.

Apple offers an iCloud-based recovery choice or a recovery key. With a key, keep a copy somewhere other than the encrypted startup disk. A note saved only on the computer you cannot open is not a recovery plan. Apple also warns against keeping the key in the same physical location as the Mac.

If this is a work or school device, the institution can have recovery access. Disk encryption does not establish privacy from the organization managing the machine. A personal conversation belongs on a device whose access arrangements you understand.

Windows Device Encryption needs an actual state check

The short version: Windows edition alone does not tell you whether the drive is encrypted.

Microsoft’s Device Encryption documentation explains that the feature enables BitLocker encryption on the operating-system drive and fixed drives. It is available on supported devices beyond the editions that provide the manual BitLocker Drive Encryption interface, including Windows Home.

On Windows, sign in as an administrator and check Settings, Privacy & security, then Device encryption. If that page is missing, Microsoft says the device may not support it, or the current account may be a standard user. Do not interpret a missing switch as proof that your files are already protected.

Microsoft also distinguishes account types. Device Encryption can turn on automatically during setup with a Microsoft account or a work or school account, with a recovery key attached to that account. With a local account, it is not turned on automatically. Check the state rather than relying on what normally happens on someone else’s computer.

If your edition uses the BitLocker management interface, inspect protection for the drive containing the app data. Do not change firmware settings or repartition a disk merely to make a tutorial’s screenshot match your screen. Ask the device administrator when management policies are involved.

Recovery is part of privacy, not an afterthought

The short version: Encryption that locks you out of your only archive is not a successful setup.

Before you depend on disk encryption, establish where the recovery material lives and whether you can retrieve it without the laptop. Do not post it in a support ticket or send a screenshot of it to a public forum.

Microsoft’s recovery-key backup guide recommends verifying that the backup exists and is accessible. It warns against storing a printed key or a USB containing the key with the computer. Someone stealing both has a route past the protection you intended.

Microsoft Support cannot recreate a lost recovery key. Apple’s guide similarly warns that losing the required login and recovery access can mean losing the files. Keep that trade-off in mind before clicking through prompts you have not read.

A sensible check is to locate the recovery record from another trusted device, without testing a destructive reset or deliberately triggering recovery on your working computer. Confirm that you know which machine it belongs to. Then leave the stored key alone until it is needed.

An exported chat is a new copy with new risks

The short version: Protection on your laptop does not automatically follow a file onto a USB drive or into an email.

A chat export copied to another disk is governed by that destination’s protections. An unencrypted external drive can become the easiest place to read a conversation, even when the laptop’s own storage is protected. A readable text file attached to a support message has left the original boundary entirely.

Make a small inventory of where your private copies live. Include manual exports and the backup destination you actually use. Check those locations rather than assuming that an operating-system encryption switch covers every duplicate everywhere.

Keep original data and backups distinct. If you are changing backup tools, verify you can restore a harmless sample before entrusting your only archive to the new setup. That is a proposed check, not a restoration test performed for this article.

Deleting a visible chat is also different from managing older backups. The guide to deleting app data explains why uninstalling and removing stored records are separate operations. Encryption does not turn either one into guaranteed erasure of every historical copy.

An accessible session remains an accessible conversation

The short version: Disk encryption protects storage; your account and physical habits protect the running session.

Someone sitting at your unlocked desktop can read the conversation through the app. Disk encryption does not add a separate password to each message. Software running with access to your account’s files can also operate inside that signed-in environment.

Use a real account password and lock the screen when you step away. Avoid sharing the same signed-in account with someone from whom you need privacy. Keep recovery access separate from the laptop rather than leaving a printed key in its sleeve.

For a computer you are about to leave unattended during travel, shutting it down is a conservative habit. It does not replace correct encryption settings or safe key storage. No single checkbox covers the whole situation.

A local companion gives you control over where selected inference and storage happen. FileVault or BitLocker addresses a different question: what happens to the disk when the hardware leaves your possession. Check both boundaries before you share something you cannot take back.

Questions people ask

Back to the blog