Back to blog

Claude as a Diary: What a Florida Case Teaches Us About AI Privacy

Hello HaWkers, an October 2026 news story raised an uncomfortable question: what happens when someone treats a chatbot as a personal diary? According to reporting by Decrypt, a Florida woman was charged after messages she sent to Claude went through a safety review and reached police. The charge still has to be examined in court; the report neither establishes guilt nor reveals every detail of the proceedings.

Do you know who can access a conversation that looks private on your screen? In this article, we'll separate what was reported about the case from what Anthropic's documents actually say, look at the available controls, and build a practical routine for reducing the exposure of personal data. The goal is to use AI with a clear idea of where information goes, without turning one headline into a universal rule.

What we know about the case and what remains open

The report, published on October 5, 2026, identifies the user as Carli Michelle Heller and attributes the description of messages about violence against a law enforcement agency to an arrest report. According to that account, safety systems flagged the messages, a human review followed, and the company informed the authorities. The investigation led to a written-threat charge. Those details come from news coverage of the case, not from court records that we have examined directly.

That distinction matters. An allegation, a police report, and a conviction are different things. Nor can we learn from this report alone the complete sequence of messages, the internal criteria that prompted the review, what content was sent to investigators, or how a court will assess the context. Reproducing isolated excerpts from an intimate conversation could add harm without helping readers understand the process. The focus here is how the platform works and what privacy expectations are reasonable.

The word “diary” appears because, according to the coverage, the user said she used the chatbot that way. A paper diary remains under the writer's physical control; a message sent to an online service passes through the company's servers, policies, and processes. A chat interface can feel like a private conversation, but that feeling alone does not set the limits of access and disclosure.

There is a real tension: platforms need to assess risks of serious harm, while users need to know when the text they wrote may be examined. A responsible answer neither assumes that employees read every conversation nor promises absolute confidentiality. It checks the applicable policy and makes a deliberate decision about what to send.

What Anthropic says about review and disclosure

In its Privacy Center, Anthropic says employees do not access conversations by default. It describes exceptions for content voluntarily submitted as feedback and for reviews needed to enforce its usage policy. In those cases, it says access is limited to designated trust and safety staff. This describes the company's policy; it is not an independent audit of every event.

The Claude consumer terms also say material flagged for safety review may be used to improve detection of harmful content, even when a user has opted out of using their conversations for general model training. So switching off a training option does not prevent every kind of safety analysis. These are separate processes and purposes. Read the settings without reducing everything to a single button labeled “privacy.”

Anthropic's policy for government requests says it generally requires valid legal process before disclosing data in response to government requests. It provides an exception when the company believes an emergency poses a risk of imminent physical harm or death and immediate disclosure may prevent it. Its transparency hub distinguishes requests for content, records without content, and emergency disclosures.

These documents help explain why a hosted conversation does not carry the same expectation of secrecy as a note kept only at home. They do not justify concluding that people at the company read every message, or automatically establish that the decision in this case satisfied every criterion. The specific incident needs its own evidence; the documents explain the service's stated rules.

Four questions before sending sensitive text

The first question is: do I need to send the raw data? If you want AI to improve a letter, you may not need to include a full name, address, phone number, identification number, and details about other people. A version with placeholders such as [CLIENT] and [CITY] often preserves the writing problem. This substitution reduces the amount of data transmitted, but it does not guarantee anonymity when the surrounding context still identifies someone.

The second is: who controls the account? In its consumer terms, Anthropic warns that accounts linked to an organization's domain may be associated with that organization's account, giving its administrator monitoring and control options. A work device may also be subject to company policies on history, extensions, and files. Before pasting intimate writing or customer data, find out whether you are using a personal or managed account.

The third is: what retention rules apply? Deleting a conversation from the interface is not the same as instantly removing every copy from internal systems. The documentation for personal plan users says a conversation immediately disappears from history and is deleted from backend systems within 30 days, with exceptions for policy enforcement and legal obligations. Rules can change; check the current version before making an important decision.

The fourth is: does this text need a cloud service? For diaries, health notes, personal conflicts, and other people's data, a local tool may make more sense. “Local” still calls for care: files may end up in backups, synced folders, or shared directories. Privacy depends on the whole path the data takes, from the keyboard to storage and any eventual export, not only on the AI model.

In practice: reduce data before using a chatbot

One simple step is to prepare a working copy with obvious identifiers removed. The Node.js example below reads a local file and replaces email addresses and phone-number-like sequences with placeholders. It sends nothing over the network. This is an initial filter, not an anonymization system: names, unusual places, context, and unexpected formats can still identify someone. Review the output manually before pasting it into any service.

// Save as limpar-texto.mjs and run: node limpar-texto.mjs entrada.txt
import { readFile, writeFile } from 'node:fs/promises';

const entrada = process.argv[2];
if (!entrada) throw new Error('Provide the path to the input file.');
const texto = await readFile(entrada, 'utf8');
const semEmails = texto.replace(/\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/gi, '[EMAIL]');
const reduzido = semEmails.replace(/\+?\d[\d ()-]{7,}\d/g, '[PHONE]');
await writeFile('texto-revisao.txt', reduzido, { flag: 'wx', mode: 0o600 });
console.log('Review texto-revisao.txt before sharing.');

The flag: 'wx' option prevents an earlier review file from being overwritten accidentally. The 0o600 mode limits access to the user on file systems that honor it, but does not protect against software running under the same account or automatic syncing. If the input is in a cloud folder, the original file may already have synced. The filter only makes sense as part of a broader routine for classifying and discarding data.

For text about other people, get consent when needed and try to reframe the question without individual details. “How can I make this message clearer?” may work with fictional characters and generic details. In professional settings, follow your contract and organization rules: removing an email address does not automatically make customer data free to share.

In practice: keep personal notes under your control

If you want to record your thoughts, one option is to keep the content locally and use AI only on selected excerpts later. The small script below writes an encrypted note using a password supplied through the environment. It uses Node.js's built-in crypto library, derives a key with scrypt, and authenticates the content with AES-256-GCM. It is a demonstration for individual files, not a replacement for a diary app with backup, recovery, and key management.

// Save as guardar-nota.mjs; run: node guardar-nota.mjs nota.txt nota.enc
import { readFile, writeFile } from 'node:fs/promises';
import { randomBytes, scryptSync, createCipheriv } from 'node:crypto';

const [origem, destino] = process.argv.slice(2);
const senha = process.env.SENHA_NOTA;
if (!origem || !destino || !senha) throw new Error('Provide a source, destination, and SENHA_NOTA.');
const sal = randomBytes(16);
const iv = randomBytes(12);
const chave = scryptSync(senha, sal, 32);
const cifra = createCipheriv('aes-256-gcm', chave, iv);
const plano = await readFile(origem);
const dados = Buffer.concat([cifra.update(plano), cifra.final()]);
const pacote = Buffer.concat([sal, iv, cifra.getAuthTag(), dados]);
await writeFile(destino, pacote, { flag: 'wx', mode: 0o600 });
console.log('Note encrypted. Keep the password in a safe place.');

Do not put the password literally in a command saved in your shell history. Use a secure way to set it in the environment and remove it from the session when you finish. If you lose the password, this example offers no recovery. Also, do not delete the original until you have verified that you can open the encrypted file and that your backup is intact. Security is a process of use, not a magical property of one API call.

Use a second script to check the file. GCM authentication makes reading fail if the password is wrong or the bytes have changed. The example writes the text to standard output; mind terminal logs, session recordings, and anyone who can see your screen. In a real tool, the unlocking experience and handling of temporary copies would need their own review.

// Save as ler-nota.mjs; run: node ler-nota.mjs nota.enc
import { readFile } from 'node:fs/promises';
import { scryptSync, createDecipheriv } from 'node:crypto';

const arquivo = process.argv[2];
const senha = process.env.SENHA_NOTA;
if (!arquivo || !senha) throw new Error('Provide the file and SENHA_NOTA.');
const pacote = await readFile(arquivo);
const sal = pacote.subarray(0, 16);
const iv = pacote.subarray(16, 28);
const etiqueta = pacote.subarray(28, 44);
const dados = pacote.subarray(44);
const chave = scryptSync(senha, sal, 32);
const decifra = createDecipheriv('aes-256-gcm', chave, iv);
decifra.setAuthTag(etiqueta);
process.stdout.write(Buffer.concat([decifra.update(dados), decifra.final()]));

This route gives you control of the file, but it does not make you invisible. The operating system, backups, and storage services may retain metadata. If you later choose to send an excerpt to a chatbot, that excerpt becomes subject to the service's policy. The useful question is always “what information am I sharing now, and with whom?”, not simply “does the app show a lock?”.

How to review and reduce an existing chat history

For personal Claude accounts, Anthropic documents exporting data under Settings > Privacy > Export data on the web or desktop app. According to that page, the export includes conversations and account information; a link is sent by email and expires after 24 hours. These details are specific to the documentation consulted in October 2026. The procedure is not available in the same way in the mobile app, and team accounts are administered differently.

Export only to a folder you control. The package may gather information that was scattered throughout the interface; sharing it or putting it in a public repository increases exposure. Then look for categories of sensitive data such as credentials, identification numbers, addresses, health information, customer names, and other people's data. If you find a real password in a conversation, treat it as exposed and change it on the relevant service; deleting the chat does not undo the original submission.

The conversation deletion page describes deleting conversations individually or in batches. Before clearing everything, consider whether you need to preserve records for professional or personal reasons. After deletion, do not mistake its absence from the sidebar for instant confirmation that every system has erased it. Consult the retention policy for your account type and keep a secure copy only when you need one.

You can also change your habits from now on: make a personal rule against pasting secrets, prepare minimal versions of documents, and review training and sharing settings. If your organization uses AI tools, turn these choices into clear guidance for the team. A short warning when someone is about to paste data may prevent more exposure than a policy page nobody reads.

What changes for products offering conversational AI

The case exposes a design question: when an interface invites people to write freely, they may understand that space as confidential. A responsible product needs to explain, in plain language, who can review content, when it may be retained, and how users exercise their controls. A generic link to lengthy terms cannot replace an explanation near the moment of submission.

Product teams also need to distinguish data minimization, retention, and emergency response. Minimization means collecting no more than the feature needs. Retention defines how long data remains. Emergency response requires criteria, appropriate human review, and a record of decisions. These are separate choices that one button cannot settle. Publishing transparency reports helps the public ask better questions, although aggregate numbers cannot explain every individual case.

For developers, the principle is similar to what we discussed in JavaScript application security: data needs classification, access controls, and paths to deletion from the start of a project. A chatbot integrated into a product is more than a text box. It can receive customer secrets, workplace conversations, and stories from vulnerable people. Design for those real uses, not only for an ideal demo.

Looking ahead: trust requires understandable limits

The reported Florida story still has open legal and factual questions. We do not know how a court will assess the charge, and this article does not try to predict that outcome. What the public policies already let us verify is that safety review exists, that data may be disclosed under certain conditions, and that personal plan users have export and deletion controls with documented limits.

The practical lesson is to treat an AI chat as communication with a service, rather than a sheet of paper locked in a drawer. Send less data, choose the right account, check the settings, and reserve local tools for material you do not want to transmit. At the same time, ask companies for simple explanations of review and transparency. Public safety and privacy are both real needs; trust depends on proportionate, understandable processes.

If you use AI to write, research, or organize your life, you do not have to abandon the tool to take privacy seriously. You need to know where each piece of information is and what benefit justifies sending it. Today, review one old conversation and one data setting. That small habit is worth more than assuming absolute protection or reacting only after a story goes viral.

Let's go! 🦅

📚 Want to Keep Up With What Is Coming?

This article covered privacy in AI conversations, but the ecosystem changes every week, and not everything becomes an article here.

On X, I share what I'm testing, behind-the-scenes updates from my projects, and news before it turns into a blog post.

Follow Me There

👉 Follow @jeffbruchado on X

💡 Daily content about development, careers, and the tools I actually use

Comments (0)

This article has no comments yet 😢. Be the first! 🚀🦅

Add comments