NexTier
Back to Blog
August 19, 2026 10 min read AI Best Practices

What “Redaction Before AI” Actually Means: A Plain-Language Tour

Share

In the privacy policy of nearly every app that touches your inner life, there's now a sentence like this: we remove personal information before sending your data to AI providers.

It's meant to be reassuring, and it does a lot of work for very little specificity. "We remove personal information" can describe an engineering effort that took months — or a regular expression that catches email addresses and nothing else. You cannot tell which from the sentence.

We build one of these systems, so treat this as a tour from inside rather than a neutral survey. The aim is to hand you enough vocabulary to interrogate anyone's answer, ours included — a continuation of the seven questions, zoomed in on the one that's hardest to evaluate from outside.

What actually happens when an app "uses AI"

Start with the plumbing — the vocabulary only makes sense once you can picture the trip.

You type something. The app adds context — instructions, maybe some of your history — and sends the bundle over the internet to a model, almost always run by a different company. The model returns text.

The important part is the middle. Your words leave the app's servers and arrive at someone else's, and everything "redaction before AI" refers to happens in the seconds before that departure.

Three questions hide in that one reassuring sentence: what gets stripped, when, and what the receiving company may do with what still arrives. Products blur them, and a product can be strong on one and weak on another.

Three ways to strip personal information

The methods differ enormously in what they catch, and knowing which you're being sold is most of the evaluation.

Pattern matching. Rules that recognize the shape of sensitive data: an email address has an @ and a dot, phone numbers and credit cards have characteristic digit groupings, a US social security number is three-two-four.

This works well on formatted things and is the workhorse of most systems including ours. Its limitation is structural: it can only catch what has a recognizable shape. "My sister Sarah has been drinking again" contains a name and a health-adjacent disclosure, and neither has a shape a rule can grab. You can add rules for titled names, introductions and named relations, and we do — but a bare name mid-sentence remains hard.

Named-entity recognition. A model trained to recognize that a word is functioning as a person, a place, an employer, regardless of shape — genuinely better at the case pattern matching misses. It costs more, adds latency, and — the part vendors skip — is itself a model making probabilistic judgements.

Layering. More than one pass, at different points, since different methods fail differently.

Being specific about our own

Here's where a post like this usually gets vague. So, concretely.

NexTier runs two redaction passes, and both are pattern-based. The first happens when your context is assembled; the second runs immediately before anything leaves for an external provider, re-running the full redaction on every message rather than trusting the first pass.

"Two passes" can imply more than it should, so: the outbound pass carries the full ruleset — emails, phone numbers, social security numbers, IP addresses, credit-card-shaped numbers, dates in an explicit birth context, postal addresses, titled names, self-introductions, named relations, and a configured list of sensitive clinical terms. On the journal path the first pass is narrower, covering formatted identifiers only. One full pass plus a thinner one, not two of the same.

We do not currently use named-entity recognition. It's the known gap, and the module that does the redacting says so about itself in its own comments: it's a rule-based allowlist rather than a complete redactor, and sentence-initial bare names, or names in phrasings it wasn't built for, can still get through.

We say so because the alternative — "we remove personal information before sending your data to AI" — would be true and would leave you with a much rosier picture than the code supports. Our privacy page puts it the same way: best-effort, no automated system is perfect, no guarantee every piece is removed. That costs us something in marketing terms. It's the accurate one.

The question underneath: what is redaction for?

Redaction is often sold as protection against a threat it doesn't address, so it's worth being exact about the threat model.

Redaction is not primarily protection against a provider reading your diary out of curiosity. The realistic risks are mundane and systemic: data retained longer than expected, used to improve a model, exposed in a breach, or inherited by whoever buys the company.

What redaction buys is reducing how much of the sensitive payload exists outside your own system at all. If a name never leaves, no downstream failure can expose it — damage limitation by subtraction, valuable precisely because it doesn't depend on anyone else's promises holding.

So the honest way to assess it isn't "does it catch everything." It's: given that something will eventually go wrong somewhere in the chain, how much less bad is it because this ran?

Training is the part you can't take back

Of the three, the least reversible is what the receiving company may do with what arrives.

If your content is used to train a model, it becomes part of that model's parameters. You can delete your account. There is no mechanism by which you can delete yourself from a set of weights. That irrevocability is why we've argued journals should never be training data in particularly strong terms — a practice whose entire value depends on revocable trust should not feed the one destination revocation cannot reach.

Here's the part worth understanding about how this protection actually works, at us and everywhere else: it is contractual, not technical. The commitment that a provider will not train on the data you send is a term in an agreement. Our code does not — cannot — enforce what happens on someone else's servers after the request arrives.

That's not a loophole; it's the structure of the arrangement, and any company implying otherwise is overselling. But it does change what you should ask. Not "is it technically impossible for them to train on my data" — that isn't a thing anyone can offer. Ask instead: which provider, under which terms, and can you say the commitment out loud in specific language? Vagueness there is the signal.

Retention is the other half of the question

"We don't train on your data" is the sentence everyone reaches for, and it answers a narrower question than it appears to.

Training is one thing that can happen to text you send. Storage is another, and it's the one that governs everything else. A provider can be entirely truthful that your text never entered a training run while still holding it for a period — abuse monitoring, debugging, a subprocessor's logs. None of that is sinister. All of it means the text exists somewhere after your session ended, and text that exists can be subpoenaed, breached, or reached by a future policy nobody has written yet.

So the two questions are separate, and an answer to one is not an answer to the other. Ask both: does my text train anything, and how long does it exist afterwards, and who can reach it in that window? A company that has thought about this can answer the second in a sentence. A company that hasn't will answer the first one again, more emphatically.

And the honest thing about journals

One more specific, because it's the case where an over-simple answer is most tempting.

People assume that a private, encrypted journal never goes near a model. For us, that's not quite the shape of it, and the accurate version is worth the extra sentence.

The text of your journal entries is encrypted where it's stored, and so is the summary we derive from it. Not everything around them is — the mood tag and the entry type sit in ordinary columns, and we'd rather say that than let "encrypted journal" do more work than it should.

When the system builds a summary of an entry — the thing that lets AI features notice patterns across your writing — the entry text does go to the model, under redaction. What gets kept and reused afterwards is that summary, not the original. Ordinary AI coaching context uses those summaries and never reaches for the raw entry.

One detail to be exact about, because "redacted summary" could easily do more work than it should too — and this paragraph has a correction to own. When this post first ran, the summary we store was scrubbed with the narrower of our two rulesets, the one covering formatted identifiers, and we said so. Since early August that's no longer the whole story: the stored summary now gets the full ruleset as well — the same one that runs on everything leaving for a provider — before it's written down. Both passes, not one thin one. The earlier sentence understated today's protection, which is the direction we'd rather err in, but an out-of-date sentence is out of date in either direction, so: corrected.

So: "your journal never leaves" would be false. "Your journal is summarized once, under redaction, and only that summary is reused" is true, and it's the sentence we'd want you to hold us to.

How to interrogate anyone's answer

Five questions. They work on any product, and the pattern of answers tells you more than any single answer.

1. Which method — patterns, a model, or both? A product that can't answer this hasn't thought about it. A product that says "advanced AI-powered privacy protection" and stops has answered by not answering.

2. What specific categories do you catch, and which do you know you miss? The second half is the real question. Every system has known gaps. A team that can name theirs has audited their own work; a team that claims none has either not looked or isn't telling you.

3. Does redaction happen before the data leaves your servers, or after? After is meaningfully different, and worse.

4. Which provider receives it, and what are the terms on training and retention? You want a named provider and a specific commitment, not "industry-leading partners."

5. Where's the honest sentence about limits? Same meta-question as ever: a real posture has limits and says so. Marketing that promises perfect anonymization is either naïve about its own systems or misrepresenting them.

You're not grading a test — you're checking whether the person answering has the shape of the system in their head. A team that answers all five with variations on "we take privacy very seriously" has told you the most useful thing available: nobody there has had to say it precisely before.

The category has earned this scrutiny, incidentally. Mozilla's 2022 review of mental-health and prayer apps found it faring worse on privacy than any other product area they'd assessed, and the FTC's 2023 action against BetterHelp turned on a therapy platform sharing users' health information — including intake answers — with advertising platforms after promising it wouldn't. That's the backdrop against which every reassuring sentence in this category should be read.

What to do with all this

A calibration, since the point isn't to frighten you about software.

Match your scrutiny to what you're typing. A habit tracker holding your gym schedule doesn't need this interrogation. A journal holding your marriage does. And the strongest available option remains the boring one: anything you'd truly rather no system held, write on paper. Paper passes every question on this list effortlessly, and there's no shame in reserving a category of thought for it.

For everything else the goal isn't zero risk. It's knowing what happens to your words, from a company willing to describe it precisely — including the parts that don't flatter them.

Where NexTier fits, briefly

This post is the long version of what our trust page summarizes, and since we just spent a section demanding that companies name the provider, here is ours. For the AI features we run, it's Gemini via Vertex AI. If you bring your own API key, your content goes to whichever provider you chose instead — that's your contract, not ours. Two pattern-based passes, no named-entity recognition yet, a no-training commitment that lives in a contract rather than in our code, and journals summarized once under redaction with only the summary reused.

We publish the gaps because the alternative is asking you to trust a sentence that sounds better than the system. If you're evaluating us or anyone else, the five questions above are the ones we'd want asked — and the fifth one is the one that sorts the field.

This post is part of a series on personal development organized around what we call Maslow's extended hierarchy — our synthesis of his later work. Sources: U.S. Federal Trade Commission, In the Matter of BetterHelp, Inc. (2023) — ftc.gov; Mozilla Foundation, "Privacy Not Included" review of mental-health and prayer apps (2022, updated 2023). Disclosure: NexTier builds AI features and the redaction system described here is our own; product descriptions were verified against the live codebase at the time of writing and may change as the product does. This post is educational content, not legal or security advice.

Found this useful? Pass it along — it helps more than you'd think.